ROS / ROS 2
ROS / ROS 2 – definition
ROS, short for Robot Operating System, is not an operating system in the kernel sense. It is a robotics middleware and software framework for building distributed robot applications. The term was introduced with ROS 1 by Willow Garage around 2007. ROS 2 is the newer generation of the framework, designed to address limitations of ROS 1 in real-time behavior, multi-robot communication, security, embedded deployment, and production use. ROS 2 uses DDS – Data Distribution Service – as its communication layer. This is a key architectural difference from ROS 1, which relied on a centralized ROS Master for discovery and topic registration.
In mobile robotics and UGV platforms, ROS / ROS 2 provides standard abstractions for sensors, actuators, robot kinematics, localization, mapping, navigation, simulation, diagnostics, and remote operation. It defines common message interfaces such as sensor_msgs/LaserScan, sensor_msgs/Imu, sensor_msgs/Image, nav_msgs/Odometry, and geometry_msgs/Twist. These interfaces allow LiDARs, IMUs, wheel odometry, cameras, GPS receivers, and motor controllers to be integrated in a modular way.
For platforms such as Leo Rover and Raph Rover, ROS 2 is the practical integration layer between the compute unit, the base controller, and the autonomy stack. It is the software substrate on which SLAM, Nav2, teleoperation, sensor fusion, and perception pipelines are usually deployed. On Leo Rover this typically runs on a Raspberry Pi-based onboard computer with ROS 2 Humble or newer. On Raph Rover, ROS 2 is used in the same way, but usually with more compute headroom and higher payload capacity for larger sensor sets.
ROS 1 vs ROS 2 in UGV systems
The distinction between ROS 1 and ROS 2 matters in field robotics. ROS 1 remains common in legacy research code, but ROS 2 is the recommended choice for new UGV deployments. This is especially true when a robot must run autonomously on unreliable networks, use multiple computers, or require better lifecycle management.
The most important technical differences for mobile robot integrators are listed below.
| Aspect | ROS 1 | ROS 2 |
|---|---|---|
| Discovery | Central ROS Master | Distributed DDS discovery |
| Transport | TCPROS, UDPROS | DDS/RTPS |
| QoS | Limited | Configurable reliability, durability, history, deadline |
| Lifecycle nodes | No standard lifecycle model | Managed nodes supported |
| Security | No native standard security layer | SROS 2 based on DDS Security |
| Target systems | Mainly Linux | Linux, embedded Linux, Windows, macOS, microcontrollers via micro-ROS |
ROS 2 distributions are released on a schedule and differ in support windows. For example, Humble Hawksbill was released in 2022 as an LTS distribution. Jazzy Jalisco followed in 2024 as another LTS line. In practice, Humble remains common on deployed UGVs because many sensor drivers and Nav2 configurations are already validated on it.
How ROS 2 works on a mobile robot
ROS 2 applications are built from nodes. A node is a process that performs a specific function, such as publishing IMU data, estimating odometry, or computing velocity commands. Nodes communicate through topics, services, and actions. In UGV systems, topics are used for streaming sensor and control data, services for request-response interactions, and actions for long-running goals such as navigation to a waypoint.
A typical ROS 2 software graph on a rover includes the following components.
- Base driver node publishing wheel odometry and accepting
cmd_vel - LiDAR driver publishing
sensor_msgs/LaserScanat 5-20 Hz depending on the device - IMU driver publishing
sensor_msgs/Imuoften at 50-200 Hz - Robot state publisher generating the TF tree from URDF
- Localization or SLAM node publishing
map -> odom - Nav2 stack consuming map, costmaps, odometry, TF, and goal actions
The TF2 transform system is central. For a differential-drive UGV, a valid transform chain typically includes map, odom, base_link, and sensor frames such as laser or camera_link. REP 105 defines standard coordinate frames for mobile platforms. REP 103 defines units and coordinate conventions, including SI units and right-handed frames.
ros2 topic list
ros2 topic hz /scan
ros2 topic echo /odom
ros2 node list
ros2 action list
ros2 run tf2_tools view_framesKey interfaces and parameters
ROS 2 integration quality depends on whether the platform exposes standard interfaces. This is more important than the specific hardware vendor. In practice, a UGV stack becomes reusable when it publishes standard messages at stable rates and with valid timestamps.
The interfaces below are the ones most often required for navigation and autonomy.
| Function | Typical topic | ROS message type | Typical rate |
|---|---|---|---|
| Velocity command | /cmd_vel |
geometry_msgs/Twist |
10-50 Hz |
| Wheel odometry | /odom |
nav_msgs/Odometry |
20-100 Hz |
| 2D LiDAR | /scan |
sensor_msgs/LaserScan |
5-20 Hz |
| IMU | /imu/data |
sensor_msgs/Imu |
50-200 Hz |
| RGB image | /camera/color/image_raw |
sensor_msgs/Image |
15-30 Hz |
| GNSS fix | /fix |
sensor_msgs/NavSatFix |
1-20 Hz |
These rates are engineering ranges, not formal ROS limits. Actual values depend on device specifications, for example LiDAR scan frequency, IMU output rate, camera resolution, USB bandwidth, and CPU budget. The timestamp source must also be consistent. If sensor messages use unsynchronized clocks, localization and mapping accuracy will degrade.
Use on Leo Rover and Raph Rover
On Leo Rover, ROS 2 is a common software environment for extending the base platform into a research or educational UGV. The platform uses differential drive, so standard ROS 2 controllers, odometry models, and Nav2 configurations for nonholonomic robots are applicable. Leo Rover supports ROS 2 on its Raspberry Pi-based compute unit, but autonomy is not provided out of the box. A user still has to integrate the navigation stack, calibrate odometry, define the robot model, and connect external sensors such as LiDAR, IMU, depth camera, or RTK GNSS.
On Raph Rover, ROS 2 plays the same role, but the system design usually targets heavier payloads and more demanding field use. That makes ROS 2 useful for multi-sensor fusion, higher-power compute modules, and larger perception pipelines. Raph Rover does not replace Leo Rover in lab and teaching scenarios. It is a different UGV class with different payload and deployment assumptions.
A minimal ROS 2 launch pattern for a rover might look like this.
# nav2_params.yaml
amcl:
ros__parameters:
use_sim_time: false
controller_server:
ros__parameters:
controller_frequency: 20.0
local_costmap:
local_costmap:
ros__parameters:
update_frequency: 10.0
publish_frequency: 5.0ros2 launch leo_bringup base.launch.py
ros2 launch slam_toolbox online_async_launch.py
ros2 launch nav2_bringup navigation_launch.py params_file:=nav2_params.yamlStandards, REPs, and implementation references
ROS / ROS 2 is documented through official documentation, package documentation, and ROS Enhancement Proposals. For UGV integration, several references are especially important because they define conventions rather than just examples.
- REP 103 – Standard Units of Measure and Coordinate Conventions
- REP 105 – Coordinate Frames for Mobile Platforms
- REP 2000 – ROS 2 Releases and Target Platforms
- ROS 2 documentation on nodes, topics, QoS, actions, parameters, lifecycle, and TF2
- DDS specifications from OMG for underlying middleware behavior
When working with Leo Rover or Raph Rover, those conventions are not optional details. They determine whether third-party packages can interoperate without custom glue code. A rover that publishes nonstandard frames, wrong units, or invalid covariance matrices may appear functional in teleoperation but fail in SLAM, localization, or autonomous navigation.
Limitations and trade-offs
ROS 2 improves modularity and integration speed, but it does not guarantee autonomy by itself. A ROS 2-based rover still depends on correct hardware selection, calibration, compute sizing, and environmental assumptions. For example, a LiDAR-only stack may work well indoors but fail in sparse outdoor terrain. A Raspberry Pi-class computer may be sufficient for teleoperation and 2D SLAM, but not for dense visual perception or multi-camera pipelines.
There is also a trade-off between generic interfaces and hardware-specific optimization. Standard topics improve compatibility, while vendor SDKs may expose lower latency or advanced features. In field robotics, the usual pattern is to wrap vendor drivers in ROS 2 nodes so the rest of the stack can remain standard.