Hi @lentinjoseph, thanks for posting this here! If there are any questions about this work, I am happy to respond (I’m the author)!
Wolf
Reading the post, I noticed this:
Nowadays, the Jupyter notebook and the ipywidgets framework offer a compelling alternative for several reasons:
- Code and interface are not separated — both are in the same notebook.
From a separation of concerns perspective this seems like a peculiar comment.
I’m not a Jupyter expert by any means: is there something that makes this a desirable characteristic of the integration?
Well, you’re still allowed to put your display logic into a different python import file, and it’s even encouraged to put “library” code into a library file.
But you can also interactively e.g. change your callback function right from the notebook, and make some tweaks to your functions, explore other parameters (e.g. via ipywidgets @interact decorator) … in the exploratory/experimental phase of a project this can be quite productive.
Afterwards, there are projects such as “voila” (http://github.com/QuantStack/voila/) that we’ve started to convert a Notebook GUI to a standalone web application that can be served to customers, for example.
@wolfv thanks for that package, looks very interesting indeed.
I have been also looking at providing some interactive python feature on top of ROS node, given that many people coming to rostful, usually just want a simple UI, not a full-fledged REST backend.
Using jupyter would be a nice solution indeed.
I noticed that :
- jupyter-ros is not published as a ros package (I m guessing you just want to keep it a pure python package ?)
- users might have issues with the python / ros environment setup.
So I thought you might want to have a look at :
- https://github.com/pyros-dev/pyros-setup (to load ros environment from within python)
- https://github.com/pyros-dev/rosimporter (to load ros messages and generate message class dynamically at import time)
I m thinking these can help bridge ros and python workflow a bit better than what is currently done.
I developed and have been using these for quite some time, but ultimately we’ll need more usecases to consolidate code, so please send me some feedback if you ever try them 
Hope you find these helpful.
We have installed the Jupyter ROS at the ROS Development Studio, so now it is available to be used off the shelf in the ROSDS.
-
Here a rosject example that teaches how to use Jupyter ROS for show the grid, the URDF of the robot, the scan, and markers: http://www.rosject.io/l/d4b0981/ (everything ready to execute with no installation).
-
Here a video with a full explanation: https://youtu.be/lE9lR0AvtnQ
Hope this helps!
I’ve started working on a ros2 implementation of jupyter-ros on a different fork. I sent a message to @wolfv and maybe we can get a separate branch or project going.
Awesome!
I might just rename your fork jupyter-ros2 so that casual passersby can know what you’re cooking up.
I would love to do that. I’ll wait to see from the owner of the code I’m forking if he is ok with that!
So you dont need to ask – if you just go to settings in the repo you can rename your fork whatever you’d like. It does effect the connections to the original repository.
Ex https://github.com/ericyao2013/ROS2-navigation2 this user renamed their fork of navigation2 to ROS2-navigation2 which still links against navigation2 as parent.