ROSboard: a web server on the robot that shows its ROS topics in a browser

A web server that runs on the robot itself

ROSboard is a ROS node that runs a web server on your robot. You start the node, point a browser at the robot's address on port 8888, and you get visualisations of the topics being published.

The deployment choice is the interesting one. Most ROS visualisation tooling assumes a workstation attached to the robot, with a desktop stack running on it. ROSboard inverts that. The server runs on the robot, which means the machine that publishes the data also serves the interface, and you can walk up to the robot with a phone and open its address.

That is why the README lists mobile friendliness as a headline feature. The design goal is stated plainly: you can walk around next to your robot with a phone while viewing ROS topics. A debugging tool that needs a laptop tethered to the machine is useful in a lab and useless in the field, at a competition, or during a hardware bring-up in someone else's lab.

The second claim is about weight. The README says ROSboard does not depend on much and consumes extremely little resources when it is not actually being used, which matters for a robot with a constrained compute budget where every process competes with the control loop.

The third claim is extensibility, and it is the most concrete of the three. Writing a visualisation for a custom message type requires adding a single `.js` file in the viewers directory and referencing it from the top of `index.js`. The FAQ repeats the same recipe from the other direction: add a viewer class inheriting from `Viewer`, following the examples of the default viewers, then add it to the imports at the top of `index.js`.

The tool is also usable away from a robot. The README notes you can run it on your desktop and play a ROS bag, which is how you would work with recorded data rather than live data.

One codebase for ROS1 and ROS2 through the rospy2 shim

Supporting both ROS versions is the piece of engineering that distinguishes this project, and the author explains the mechanism in detail.

The answer is rospy2, a shim library the author wrote that behaves like ROS1's `rospy` but speaks ROS2 to the system, communicating with `rclpy` in the background. The same node code therefore runs on both versions, and only the package metadata files differ, `package.xml` and `CMakeLists.txt`, which is why there are configure scripts.

The trade-off is stated plainly: everything is written in ROS1 style. The benefit is compatibility with both ROS1 and ROS2 without maintaining multiple branches or repositories, which for a project of this size is a considerable saving.

The practical consequence for a user is that the two installation paths are the same shape. For ROS1 you run it with `rosrun rosboard rosboard_node` or put it in a launch file, and for ROS2 with `ros2 run rosboard rosboard_node` or the same launch file mechanism. The package drops into a `catkin_ws/src/` or a `colcon_ws/src/` directory and, in the README's phrasing, just works.

The dependency footprint follows from that design. The prerequisites are standard Python packages rather than ROS-specific ones, and the README gives a specific reason: many times in the past, the robot web tools are not available immediately on apt-get when ROS distros are released, and one has to wait months. Depending only on `tornado` and optionally `PIL` means ROSboard should theoretically work immediately when a new distro is released, rather than after the ecosystem catches up.

A custom Tornado websocket bridge instead of rosbridge

The FAQ asks why the project does not use rosbridge-suite or Robot Web Tools, and the answer is the most technical part of the README.

The author used them initially and moved to a custom Tornado-based websocket bridge for five stated reasons.

Compatibility comes first. Depending on those libraries makes ROS1 and ROS2 support harder, whereas the custom websocket API speaks exactly the same language regardless of whether the back end is ROS1 or ROS2.

Second, a custom implementation allows lossy compression on large messages, such as Image and PointCloud2, before they go over the websocket, along with robot-side timestamps on all messages, and possibly throttling in the future. The lossy compression is the most consequential of these, because a camera feed over a phone's browser connection is the case where bandwidth decides whether the tool is usable at all, and the cost of that compression is fidelity that you do not get back.

Third, the browser is deliberately not given superuser access to the ROS system, only the functionality needed for this to work. That is a real security property. A browser that can publish arbitrary topics, call services and inspect the whole graph is a very different thing from a browser that can subscribe to the topics it displays.

Fourth, the author wants to add basic username and password authorization. The wording is that this is planned for the future, which means it is not there yet, and this is the single most important thing to know before exposing the node on a network.

The fifth reason is the apt-get availability argument described earlier, the one about ROS distros shipping late.

The web side is built from a small set of well known libraries, listed in the credits: Tornado for the web and websocket server, simplejpeg for JPEG encoding and decoding, psutil for monitoring system resource utilisation, Masonry for laying out the cards on the page, Leaflet.js for rendering `sensor_msgs/NavSatFix` messages, Material Design Lite for the general UI, jQuery for DOM manipulation, litegl.js and glMatrix for the 3D visualisations, rosbag.js for reading ROS 1 `.bag` files, uPlot for all time-series plots, and JSON5 for encoding and decoding messages.

Running it without a workspace, then as a package

The quick path avoids installing anything into a ROS workspace. The prerequisites are two pip installs, with the second recommended but optional:

sudo pip3 install tornado
sudo pip3 install simplejpeg  # recommended, but ROSboard can fall back to cv2 or PIL instead

If you intend to use it with melodic or earlier, you also need `rospkg`, so that Python 3 ROS1 nodes work:

sudo pip3 install rospkg      # required for melodic and earlier distros

Then source your ROS installation and run the bundled script:

source /opt/ros/YOUR_ROS1_OR_ROS2_DISTRO/setup.bash
./run

The browser then goes to `http://localhost:8888`, or you replace localhost with the robot's IP. The README calls this the easy way, for running without installing it into a workspace, and it is the right way to try the tool before deciding to package it.

Installing as a ROS package is the other route. The package works in either ROS1 or ROS2, and you simply drop it into your `catkin_ws/src/` or `colcon_ws/src/` directory. For ROS1 you run it with `rosrun rosboard rosboard_node`, and for ROS2 with `ros2 run rosboard rosboard_node`, or you put either into a launch file.

The packaging metadata shows what a ROS package needs. The `setup.py` declares the console entry point `rosboard_node = rosboard.rosboard:main`, installs `package.xml` into the package share directory and a resource marker into the ament index, and requires `tornado>=4.2.1` with `psutil` as an optional extra under the name `system_stats`. The package data list covers the HTML, fonts, CSS, JavaScript and the viewers and transports subdirectories, which is what makes the web interface install correctly rather than breaking on a packaged install. The version in `setup.py` is 1.3.1, and `requirements.txt` lists tornado and simplejpeg.

The licence situation needs a look before you redistribute it

There is an inconsistency in the licensing information that anyone planning to vendor or redistribute this code should resolve first.

The `setup.py` metadata declares `license='BSD'`, which is what ends up in the installed package metadata on PyPI and in some toolchains. The project metadata for the repository records the licence as other, a custom licence that GitHub cannot classify, and points to the `LICENSE` file. The README's credits section, meanwhile, lists the licences of the libraries the project uses: Tornado under Apache 2.0, simplejpeg under MIT, psutil under BSD 3-clause, Masonry and jQuery and litegl.js and glMatrix and rosbag.js and uPlot and JSON5 under MIT, and Leaflet.js under a BSD 2-clause licence, Material Design Lite under Apache 2.0, and the two fonts, JetBrains Mono and Titillium Web, under the SIL Open Font License.

That last point matters for a different reason. A SIL Open Font Licence font embedded in a web interface you ship has its own conditions, and the fonts are part of what the package installs, since the package data list includes `html/fonts/*`.

This is a note about what the files say rather than legal advice, and the practical step is small: read the `LICENSE` file, and if the custom terms conflict with the BSD string in the packaging metadata, raise it with the maintainer before you build on it. For a personal debugging tool that you run on your own robot, none of this affects you, and it is a legitimate use of the project.

The maintenance state is worth stating too. The repository has no GitHub releases, so there is no versioned artefact to pin in a launch file or a Dockerfile, and the last push was on 2026-08-21. The repository is not archived, and there is a `CHANGELOG.txt` at the root for tracking changes in the source tree.

Where ROSboard stops being the right tool

There are three limits, and only the first is about the software.

The first is the missing authorization. The README states that the author wants to add basic username and password authorization in the future, so today the web server is open to anything that can reach port 8888. Combined with the deliberate decision not to give the browser superuser access, the exposure is limited to what the visualisation needs, but limited is not the same as authenticated. On a robot connected to a lab network, a conference wifi network, or anything with untrusted peers, that is a risk to weigh. The mitigations available to you are network-level ones, such as keeping the node on a wired link or behind a firewall, since the node itself offers no access control.

The second is fidelity. The custom bridge can apply lossy compression to large messages, and the README is open that this is a feature. If you are reading a camera topic to judge whether an image pipeline is correct, a compressed image may mislead you in exactly the situation you brought the tool to investigate. For a quick look, that is a good trade. For pixel-level work, it is the wrong tool.

The third is scope. ROSboard is a visualisation server for a single robot. It is not a fleet tool, it has no multi-user story, no persistent storage of what was seen, and no way to compare runs over time. And because the repository publishes no releases, you have no upstream version to track, only the tip of a branch that was last pushed on 2026-08-21.

The alternative approach, for comparison, is a terminal-based viewer in the same author's toolkit, the README points at ROSshow as a companion, and the project also reads ROS 1 `.bag` files directly through rosbag.js, so recorded data can be replayed into the same interface. The difference in approach is that a full browser stack gives you interactive plots, camera views, map displays and 3D visualisations in one page, while a terminal tool gives you a fast text view of a topic with no bandwidth cost and no server to secure. For a phone next to the robot, the browser wins. For a debug loop over SSH, the terminal view is faster.

Editorial conclusion

Adopt ROSboard if you debug a physical robot and want to inspect its topics from a phone or laptop without installing a full desktop stack on the machine, since the node is light, works in both ROS versions from one codebase, and accepts a new message type with a single viewer file. Do not adopt it as a production data path, as a fleet monitoring tool, or on a robot whose network is reachable by anyone you do not trust, because the README states that username and password authorization is still planned for the future. Verify three things first: that the custom websocket bridge is acceptable in your security model, since the browser deliberately gets no superuser access to the ROS system, that the licence in the LICENSE file matches what the packaging metadata claims, since the package metadata says BSD while the repository licence is recorded as custom, and that the topic data you plan to expose is the data you intend to publish.

Frequently asked questions

Official sources

1. dheera/rosboard on GitHub
2. Issues
3. README