This repository was archived by the owner on Nov 26, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 26, 2025. It is now read-only.
Python or C/C++ based web bridge #174
Description
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
nodecommand instead ofros2command). - 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).
Activity
jtbandes commentedon Jul 15, 2021
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_typesAPI, 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
goodbetter position to dynamically load datatype information — for two examples, the current rosbridge_server which uses__import__, and @dheera's rosboard usesimportlib.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_suitefor 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 commentedon Jul 16, 2021
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_nodejsthat automatically handlednpm installmuch in the same way that it handlessetup.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 buildcreate a virtualenv, install all the depedencies specified insetup.pyto 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 wantstensorflow-gpu==1.xand another that wantstensorflow-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-linercolcon build.minggangw commentedon Jul 16, 2021
Absolutely, thus nodejs developers can call
npm installas usually, and developers of C++/Python can continue callcolcon. https://github.com/RobotWebTools/rclnodejs-cli has extended the cli tool to the rclnodejs client, I think that is what we want forcolcon:)jtbandes commentedon Jul 16, 2021
It turns out
rosbridge_suitealready has aros2branch 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 exposeget_topics_and_raw_typesand just posted a PR: RobotWebTools/rosbridge_suite#574amacneil commentedon Jul 16, 2021
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 commentedon Jul 17, 2021
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 commentedon Jul 17, 2021
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 commentedon Jul 30, 2021
@threeal we had some discussion with the ros-web working group this week, and are going to revive and publish
rosbridge_suitefor 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
kumoproject speaks the rosbridge protocol or implements a custom protocol, but it would be good to collaborate if you are interested.defunctzombie commentedon Apr 12, 2024
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_suiteproject, the latter we found to not meet the performance needs of customers with large messages or high rate messages.