Python or C/C++ based web bridge

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).

[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.

[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.