Advanced guides

ROS 2 support (experimental)


How to use

To use Leo Rover with ROS 2, you need to flash the experimental LeoOS with ROS 2 support. Download either the lite or full version and flash the image onto the SD card:

Flashing a new raspberry pi image

After starting the robot, connect to the Rover AP and login to Raspberry Pi via SSH:

Connect to Leo Rover AP
Connect via SSH

The ROS 2 version requires different firmware for the motor controller. To firmware update process looks almost exactly the same as it was before:

Firmware update

The only difference is that to invoke the update script, you need to type:


The experimental OS functions very similarly to the current stable release of LeoOS. The network configuration works the same, no new system services are started, even the ROS API is almost identical. There are, however, a few changes, apart from the ROS distribution, that should be taken into account:

Micro-ROS instead of ROSSerial

As ROSSerial project is not available for ROS 2, we had to find another protocol for serial communication between Raspberry Pi and the motor controller. Thus, the new firmware utilizes the Micro-ROS project to expose the ROS topics and services via the Micro-ROS Agent running on the Raspberry Pi.

New systemd user services

Instead of one system service leo which started the ROS functionality, the new OS provides two user services:

  • ros-nodes - Starts the /etc/ros/robot.launch.xml ROS 2 launch file.
  • uros-agent - Starts the Micro-ROS Agent.

Both of these services can be configured through the /etc/ros/setup.bash file.

To facilitate the process of managing these services, we developed a set of bash aliases. For example, to stop both services, you can type:

v4l2_camera instead of raspicam_node

Due to the Raspberry Pi MMAL libraries no longer being supported on 64 bit systems, we were unable to port raspicam_node to ROS2 Humble. Instead, we switched to using v4l2_camera to expose the camera images on ROS topics.

image_proc nodes running by default

As an experimental feature, we added [image_proc] debayer and rectify nodes that are running by default. They add the following topics:

RDP no longer supported

Due to the fact that tigervnc-scraping-server seems to work a lot faster than xrdp and allows utilizing hardware acceleration, we decided to drop support for remote desktop via RDP protocol. The new OS, by default, only allows remote desktop connections via VNC protocol.

Current limitations

Because of the new architecture, some new problems, that limit some functionalities of the robot, were introduced. We are actively trying to mitigate them but you should take them into account for now.

No way to permanently change firmware parameters

The ROSSerial-based firmware was retrieving parameter values from the Parameter Server during initialization. This allowed to change the firmware parameters from Raspberry Pi and make the changes persistent across reboots. As ROS 2 does not have a global parameter server, the new firmware loses this ability. On a sidenote, the new firmware allows changing parameters at runtime via, for example, rqt_reconfigure tool.

Not compatible software integrations

If you used any of our integrations guides, you will have to adapt the software integration parts yourself. In some cases, it won't be possible due to missing ROS 2 packages.

Problems with multi-robot setups

The ROS namespace and domain id of the firmware node (the ROS node running on the motor controller) is currently hardcoded and there's no way to change it without changing firmware code and reflashing the board. This makes it a lot harder to work with multi-robot setups due to topic name collisions.


Need help? Contact us - contact@fictionlab.pl