Best Practices NRP Development Workflow

#1

I am new to NRP and trying to establish a good workflow for development of my NRP experiments (Local Install)

In particular I am thinking about the built-in NRP editors which don’t seem to have code-completion or in-line tooltips/docstring etc. unless I am missing something?

I am curious how others are doing it so I would love to hear if you are developing the scripts directly inside NRP or externally in an IDE or similar, and then how do you bring it back into the platform for testing, execution and debugging etc.? Also I would love to hear in general what sort of setups you have made to make your life easier?

Finally, I am sorry if I have missed somewhere in the manual that lists best-practices, but in that case I would love to be pointed in the right direction.

Cheers and thanks in advance

  • Jakob
#2

I also would be interested in such.

#3

Hi Andy,

As your post suggests, I am not the only one who would’ve appreciated a bit of help in workflow. For that reason I will briefly outline what I have ended up doing after 4 months of NRP usage:

First of all, a lot of features appear to be in the pipeline for future updates, but the development team are quite busy to say the least, so there are still issues here and there.

Important notes for me was:

  • NRP works with Experiment folders. These either include all the needed files for running the experiment, or the links to said files.
  • I like to use links as much as possible (ie. to link to a model SDF) to I can have multiple experiments with same model link, to allow easy test of changes in multiple situations.
  • When you want to run an experiment you ‘clone’ it, which will make a copy of the Experiment folder in your ~/.opt/nrpStorage
  • I do all edits in my Experiment folder, delete the previous ‘clone’ from the nrpStorage (Through the NRP interface) and re-clone the experiment, to make sure that I have everything saved, and that the whole package continues to work together.
  • You could edit directly in the experiment clone in nrpStorage to avoid deleting old clone and re-cloning, but I like the feeling of a clean slate when I re-clone, which also clears out saved CSV data and whatnot
  • I do all script editing outside of NRP, mainly to be certain of what is saved and what is not, and because I use git for revisions.
  • I didn’t find a way to reload experiment script files without exiting a simulation (stopping it) and restarting it, so every time I make a change I have to: Edit my files externally, save changes to Experiment folder, remove old clone, clone experiment again, launch simulation and start it
  • I use the transfer function Recorder extensively, for debugging and everything else
  • I use Jupyter Notebook with Virtual Coach for running experiments and analyzing data/plotting it in a single go. More info here: Virtual coach functionality
  • All my scripts are created with glue and hacks from existing example files. First make something simple to work and build from there. NRP doesn’t always have good error handling, so I recommend to remember what you changed for each test, to find your way back to a working state if you break something accidentally
  • My confidence in editing TF’s is slowly increasing but I am still very careful and testing all the time in short simulations. This was due to a few annoying situations where I couldn’t find the bug and the error messages weren’t helping, so I had to go waaaayy back to re-establish a working experiment.

If you, as me, also develop a robot plugin, then I can recommend to develop in Gazebo standalone first, with a caveat. If you are new to Gazebo/ROS as well as NRP, like me, then it is definitely a good idea to look into Gazebo/ROS standalone no matter what, and getting someting running in Gazebo was for me much more intuitive than NRP. However, not everything that works in Gazebo/ROS will work in NRP, so I would recommend to test often, both places.

I am sure there are many more points that should go here, but I will update later, if I think of something.

Finally, if anyone sees this and realizes that I am doing something in a really inefficient way or who can otherwise help out with further comments, then I am all ears.
My currently workflow feels quite awkward to me, but it is the best I have been able to put together so far.

Cheers

#4

Hi Andy,

you brought up a line of valid argumentation, theres nothing inefficient about it, its more the opposite, I personally dont know anybody working with the NRP and scripting entirely online. Although if youre just fine-tuning this kind of immediate feedback is quite efficient. From my perspective there are some point about it:

  • If you are used to a code editor like VIM, Emacs, … you certainly do not want to code in a web-browser. It’s not only about code-completion but also linting, auto-intending , auto-brackets, efficient move key-bindings,… Its not a good idea to reinvent the wheel because its still in a web-browser which feels rather “kinky” and each of the editors themselves has a community of thousands of people continuously updating their code base.
  • Editing the files in the storage is a much better workflow, but thats just good for the local install.

Maybe its time to decide if the NRP should be a local framework to use or an online service architecture. I think both at the same time does not work very well. My preference is clearly to develop local, define information precessing and transfer (TFs, connections to a network, the network itself) and put it then to simulation which i can observe/debug visually.

On the other hand, if the dev team decides that online-editing is preferred than maybe LSP (https://langserver.org/) can help with code checking