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:
After starting the robot, connect to the Rover AP and login to Raspberry Pi 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:
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:
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.
Instead of one system service leo which started the ROS functionality, the new OS provides two user services:
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:
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.
As an experimental feature, we added [image_proc] debayer and rectify nodes that are running by default. They add the following topics:
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.
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.
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.
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.
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.
Find us on:
