Python or C/C++ based web bridge

[threeal]

I want to open discussion about a Python or C/C++ based web bridge. There's some points that i think we should consider again about writing a Python based (or probably C/C++ based) web bridge instead of Node.js based web bridge.

• Normally, a ROS 2 package is written in either Python or C/C++. Also in the ROS 2 default bundle, it doesn't even install a Node.js or rclnodejs. Thus, it makes Node.js based web bridge to be more difficult to install and integrated into ROS 2 system (need to install Node.js first, and run it using node command instead of ros2 command).
• As an interpreted language, ROS 2 version for Python (rclpy) is more stable than ROS 2 version for Node.js (rclnodejs). Probably, rclpy also faster than rclnodejs. And the C/C++ version (rclcpp) even more stable and faster than them both.
• It's possible to implement what was written in this web bridge in Python. It doesn't have to be written in Node.js as we could still create a websocket server in Python, as easy as in Node.js. Python also support JSON, and could easily access any kind of topic/service without the need to link the DDS interfaces (just like when we run ros2 topic pub ...).
• Node.js based ROS 2 have different versioning system than the standard ROS 2 versioning system. There is no eloquent, foxy, rolling things in the rclnodejs. There's just newer or older version, if we want to use the older ROS 2 version, we probably need to use the rclnodejs version that previously still support that older ROS 2 version, but after that, there's no support for the older ROS 2 version (the development only be done for the newest ROS 2 version).

[jtbandes]

I'm interested in discussing this too. Our web visualizer (https://github.com/foxglove/studio) is able to speak the rosbridge v2 protocol, but currently depends on receiving the raw datatype (.msg) definitions using the topics_and_raw_types API, which is missing from ros2-web-bridge (discussed in #146). One limitation is a lack of support for dynamically querying/fetching these datatypes throughout the whole ROS 2 stack. rclnodejs only complicates the problem by adding an extra generate-ros-messages step that end users need to run each time they update a custom .msg file.

A Python web bridge would be in a good better position to dynamically load datatype information — for two examples, the current rosbridge_server which uses __import__, and @dheera's rosboard uses importlib.import_module. (This still requires a build step when you edit a custom .msg definition though — that might always be necessary.)

It would also be important for the web bridge to be easily installable and usable, preferably without the user needing to invoke a build step, like how you can apt install ros-noetic-rosbridge-suite && roslaunch rosbridge_server rosbridge_websocket.launch. (The current ros2-web-bridge installation instructions involve node.js and git.)

It actually seems like some work has been done in rosbridge_suite for ROS 2 compatibility: RobotWebTools/rosbridge_suite#345 I'm not sure the current status of this work, perhaps @jubeira, @minggangw, or @dirk-thomas know more?

[dheera]

Although I do agree with the general theme of core ROS libraries sticking to C++/Python to reduce dependencies, it would also be super nice if the ROS 2 build system could handle NodeJS packages properly and not require extra steps other than "colcon build". Maybe a build type called ament_nodejs that automatically handled npm install much in the same way that it handles setup.py? NodeJS can actually be blazingly fast for certain tasks compared to CPython interpreter, would be nice to have better support for it.

On another note -- maybe this feature request should go somewhere else -- but I really, really wish it were possible to have colcon build create a virtualenv, install all the depedencies specified in setup.py to that virtualenv, install the node along with the virtualenv so that we don't have two ROS packages fighting over Python library version dependencies (e.g. one that wants tensorflow-gpu==1.x and another that wants tensorflow-gpu==2.x, for example. Virtualenvs can solve Python dependencies 99% of the time without having to go to a full-on docker-container-for-each-ROS-node solution. It's actually kind of possible to do this now, but it seems that takes additional build steps, you can't do it with just a one-liner colcon build.

[minggangw]

it would also be super nice if the ROS 2 build system could handle NodeJS packages properly and not require extra steps other than "colcon build".

Absolutely, thus nodejs developers can call npm install as usually, and developers of C++/Python can continue call colcon. https://github.com/RobotWebTools/rclnodejs-cli has extended the cli tool to the rclnodejs client, I think that is what we want for colcon :)

[jtbandes]

It turns out rosbridge_suite already has a ros2 branch with some work on ROS 2 compatibility, although it hasn't been published in a ROS 2 release since Dashing. So I did some work to expose get_topics_and_raw_types and just posted a PR: RobotWebTools/rosbridge_suite#574

[amacneil]

Allowing the ROS 2 build system to handle nodejs is a good idea (that hopefully will be implemented), but that still doesn’t mean that we should introduce nodejs as a dependency where it isn’t necessary.

For a tool like rosbridge/web bridge, robotics developers should be able to install the package without needing to have apt install nodejs, pulling down (or bundling) thousands of extra packages from npm, etc. It’s perfectly possible to write a websocket server in python and avoid adding extra dependencies for your robot.

[threeal]

It's been a long time since the first time i posted this thread. Anyway, after a long times of inactivity in this thread, since March, my team decided to start a WebSocket bridge project for ROS 2. It's written in Python and currently support topics and services communication. We also create a serializer library to handle JSON to ROS 2's interface translation which is used in that bridge, and a JavaScript client library to be used with that bridge.

[dheera]

One thing I also wanted to mention is that I had to move away from the standard rosbridge protocol for my ROSboard project (https://github.com/dheera/rosboard) because they don't support the types of aggressive server-side compression needed to stream certain large datatypes, especially images and pointclouds. I created my own stripped-down websocket bridge for that project and my own serialization library that does lossy compression like reducing precision of floating point values and JPEG compression of raw images before sending them over the socket. I do my websocket logic in Python with tornado.

It might be a little hard to generalize lossy compression, since after all there will be e.g. people who are NOT trying to stream a 64-channel velodyne to a client on Wi-Fi and don't need the compression, but thought I'd just mention it to open the discussion since I imagine many web interface builders will run into the same issues -- especially as we start to see the cost of LIDAR come down.

[amacneil]

@threeal we had some discussion with the ros-web working group this week, and are going to revive and publish rosbridge_suite for ROS 2 (which is written in python). There is already a working ros2 branch, which will soon become the default branch (RobotWebTools/rosbridge_suite#577), and will be published as a deb package soon.

I'm not sure whether your kumo project speaks the rosbridge protocol or implements a custom protocol, but it would be good to collaborate if you are interested.

[defunctzombie]

We've created https://github.com/foxglove/ros-foxglove-bridge which is implemented in c++ and can bridge ROS 1 & 2 systems to other systems via websocket. It is an alternative to this project and the rosbridge_suite project, the latter we found to not meet the performance needs of customers with large messages or high rate messages.