Leo Rover

Leo Rover – definition

Leo Rover is a compact unmanned ground vehicle (UGV) platform designed for mobile robotics research, education, and field prototyping. In technical terms, it is a four-wheel, differential-drive rover with onboard computing, ROS support, and a mechanical and software architecture intended for sensor integration and autonomous navigation experiments. Within the Fictionlab ecosystem, Leo Rover is the smaller platform compared with Raph Rover. It is optimized for laboratory work, classroom use, algorithm development, and light outdoor testing rather than high-payload missions.

In the context of ROS-based mobile robotics, Leo Rover should be understood as a reference hardware platform for testing perception, localization, teleoperation, SLAM, and navigation pipelines on a real UGV. It is not an autonomous robot by default. Autonomy requires integration of a suitable sensor stack, robot description, state estimation, control interfaces, and a navigation framework such as Nav2 in ROS 2. This distinction matters because many robotics terms such as SLAM, local planning, or obstacle avoidance describe software capabilities, not chassis features.

Leo Rover uses a Raspberry Pi-based onboard compute unit as the default controller. Fictionlab documentation states ROS support, with ROS 2 supported in current software stacks. The rover has an IP54 enclosure rating and a differential-drive kinematic model. For ROS users, that means the platform maps naturally to the standard geometry_msgs/Twist velocity interface, wheel odometry, sensor_msgs/Imu when an IMU is installed, and the TF tree conventions commonly used by Nav2 and robot_localization.

Mechanical and software architecture

Leo Rover is best treated as a modular mobile base. Its value in engineering work comes from the combination of a reproducible chassis, accessible onboard compute, and ROS-compatible interfaces. For research and teaching, this reduces integration overhead compared with building a rover from raw components.

From a robotics system perspective, the most relevant architectural properties are:

Locomotion model – differential drive with four driven wheels.
Compute model – embedded Linux computer, typically Raspberry Pi based.
Operating middleware – ROS, with ROS 2 available in current software stacks.
Environment – indoor and light outdoor operation, with IP54 protection.
Extensibility – support for payloads such as LiDAR, depth cameras, GNSS, and companion computers.

The differential-drive assumption is important because ROS navigation, odometry fusion, and controller tuning depend on it. In REP 105, the standard mobile robot frame hierarchy uses map, odom, and base_link. A Leo Rover deployment for autonomous navigation should publish these frames consistently. In practice, odom -> base_link comes from wheel odometry and optionally IMU fusion, while map -> odom is generated by SLAM or global localization.

How Leo Rover works in ROS 2

Leo Rover fits the ROS 2 model of a mobile base with sensor drivers, state publishers, and navigation nodes running as separate processes. The exact package names may vary by deployment, but the interface pattern is standard and verifiable against ROS 2 documentation and REP conventions.

A minimal ROS 2 stack for Leo Rover usually includes:

Motor control and wheel odometry publisher.
robot_state_publisher with a URDF model.
IMU, LiDAR, or camera drivers.
robot_localization for fused state estimation.
SLAM Toolbox or another SLAM node.
Nav2 for path planning, recovery behaviors, and waypoint following.

Typical ROS 2 interfaces on a Leo Rover-class platform include the following topics and message types:

Function	Topic	ROS message type	Typical rate
Velocity command	`/cmd_vel`	`geometry_msgs/msg/Twist`	10 – 30 Hz
Wheel odometry	`/odom`	`nav_msgs/msg/Odometry`	20 – 50 Hz
2D LiDAR scan	`/scan`	`sensor_msgs/msg/LaserScan`	5 – 15 Hz
IMU	`/imu/data`	`sensor_msgs/msg/Imu`	50 – 200 Hz
TF transforms	`/tf`, `/tf_static`	`tf2_msgs/msg/TFMessage`	event-driven / continuous

The rates above are typical engineering values for UGV integration. Final settings depend on the selected sensors and compute budget. On a Raspberry Pi-class computer, CPU and memory limits become relevant once LiDAR processing, visual SLAM, and Nav2 are active at the same time.

ros2 topic list
ros2 topic echo /odom
ros2 run tf2_tools view_frames
ros2 launch nav2_bringup navigation_launch.py use_sim_time:=false

Key parameters and metrics

For Leo Rover, the most useful definition is not only what the platform is, but which parameters determine whether a robotics stack will work reliably on it. In mobile robotics, platform capability is strongly coupled to payload mass, sensor field of view, compute throughput, power budget, and terrain interaction.

Important engineering metrics include:

Kinematic model – differential drive, which affects turning behavior, odometry drift, and local planner behavior.
Ingress protection – IP54, relevant for dust and splash resistance, but not submersion.
Compute class – Raspberry Pi default, suitable for moderate ROS 2 workloads, but limited for heavy 3D perception.
Localization source – wheel odometry alone is insufficient for long autonomous runs due to drift.
Sensor update rates – low LiDAR or camera rates can destabilize local costmap updates.

A practical state estimation pipeline on Leo Rover often uses the following fusion logic:

ekf_filter_node:
  ros__parameters:
    frequency: 30.0
    two_d_mode: true
    odom_frame: odom
    base_link_frame: base_link
    world_frame: odom
    odom0: /wheel/odometry
    odom0_config: [false, false, false,
                   false, false, false,
                   true,  true,  false,
                   false, false, true,
                   false, false, false]
    imu0: /imu/data
    imu0_config: [false, false, false,
                  true,  true,  true,
                  false, false, false,
                  true,  true,  true,
                  false, false, false]

This example follows the general configuration style of robot_localization. The exact mask must match the actual sensor outputs and frame conventions.

Sensor integration on Leo Rover

Leo Rover is frequently used as a base for sensor integration because the chassis and ROS environment simplify prototyping. In mobile robotics terms, the rover itself is only one layer of the system. The autonomy level depends primarily on the attached sensors and the quality of their calibration.

Common sensor combinations include:

2D LiDAR for mapping and local obstacle detection.
IMU for yaw stabilization and short-term motion estimation.
Depth camera for near-field perception and visual odometry.
GPS or RTK GNSS for outdoor global positioning.

On Leo Rover, a 2D LiDAR plus IMU is usually the most practical entry point for ROS 2 SLAM. For outdoor work, GNSS can anchor the robot globally, but wheel slip and uneven terrain still require local filtering. For heavier payloads, larger computers, or more demanding outdoor missions, Raph Rover is generally a better fit because it is intended for higher payload applications. It does not replace Leo Rover in teaching labs, where smaller footprint and lower system complexity are often preferable.

Use cases with Leo Rover and Raph Rover

Leo Rover is suitable when the goal is to validate mobile robotics software on a real UGV with moderate integration effort. The platform is commonly used for teaching ROS, testing SLAM pipelines, benchmarking localization, and validating payload mounts or sensor placement.

Typical use cases are:

ROS education with real odometry, TF, and sensor data.
Indoor and campus-scale SLAM experiments.
Remote teleoperation and autonomy handoff testing.
Prototype field inspection workflows with lightweight sensors.

Raph Rover becomes more appropriate when the mission requires more payload mass, larger batteries, or a stronger mechanical platform for rougher terrain. That distinction is operational, not semantic. Leo Rover remains the more natural reference platform for coursework, research iteration, and compact UGV deployments.

Limitations and trade-offs

Leo Rover should not be described as a complete autonomous vehicle. It is a mobile robotics platform that supports autonomy development. The difference is important for system design, testing, and safety analysis.

Main constraints include:

No autonomous navigation out of the box – a full perception and navigation stack must be integrated.
Raspberry Pi compute limits – advanced 3D perception may require an external or companion computer.
Differential-drive slip – odometry degrades on loose or uneven ground.
IP54 protection – adequate for dust and splashes, not for severe weather exposure.

Normative references and standards

The technical interpretation of Leo Rover in ROS-based systems should follow established ROS and robotics references. Relevant sources include ROS 2 documentation, REP 103 for standard units and coordinate conventions, REP 105 for mobile platform coordinate frames, the geometry_msgs, nav_msgs, and sensor_msgs interface definitions, and official hardware documentation at docs.fictionlab.pl/leo-rover. When configuring navigation, the Nav2 documentation for the chosen ROS 2 distribution is the correct reference baseline.