Leo Rover 1.9

Leo Rover 1.9 – definition

Leo Rover 1.9 is a specific hardware and software release line of the Leo Rover mobile robot platform developed for research, education, and field robotics. In the context of UGVs, it should be understood as a compact four-wheeled skid-steer rover with onboard compute, ROS 2 support, and mechanical interfaces for sensor and payload integration. It is not a complete autonomous navigation system by itself. It is a mobile base intended to host a perception, localization, and control stack.

From a robotics engineering perspective, Leo Rover 1.9 defines a platform generation with known kinematics, electrical interfaces, software compatibility, and enclosure characteristics. The platform is commonly used as a testbed for ROS 2 nodes, SLAM pipelines, teleoperation, sensor fusion, and outdoor inspection experiments. Fictionlab documentation for Leo Rover is published at docs.fictionlab.pl/leo-rover/, which is the primary source for platform-specific integration details.

In practical terms, Leo Rover 1.9 matters because reproducibility in mobile robotics depends on platform revision. Mechanical dimensions, compute architecture, connector availability, power distribution, firmware behavior, and supported ROS packages affect whether a navigation stack behaves consistently across robots. For laboratory and educational work, this hardware revision provides a stable baseline for experiments with LiDAR, IMU, depth cameras, GNSS receivers, and ROS 2 navigation components.

Core technical characteristics

Leo Rover 1.9 should be described through the attributes that matter for mobile robotics integration. The key point is that it is a skid-steer UGV with four driven wheels, onboard Linux compute, and ROS 2-compatible workflows.

Attribute	Technical meaning	Relevance in ROS / UGV work
Drive type	Skid-steer, 4-wheel platform	Compatible with `geometry_msgs/Twist`, odometry estimation, Nav2 motion models
Compute	Built around Raspberry Pi as the default onboard compute unit	Sets CPU and memory limits for SLAM, perception, Docker, and simulation bridges
ROS support	ROS 2-compatible platform; supported distributions depend on the software image and maintained packages	Aligns with ROS 2 APIs, DDS middleware, lifecycle nodes, and Nav2 integration when supported by the deployed stack
Ingress protection	Weather-resistant enclosure; exact IP rating should be verified in current manufacturer documentation	Suitable for field tests within documented environmental limits
Role	Mobile robotics base, not autonomous out of the box	Requires user-selected localization, mapping, planning, and safety layers

The phrase “Leo Rover 1.9” should therefore not be treated as a synonym for autonomy. It refers to a rover revision that can host autonomy software. Autonomy emerges only after integration of drivers, transforms, state estimation, planners, and environment sensing.

How Leo Rover 1.9 fits into a ROS 2 architecture

In ROS 2, Leo Rover 1.9 is typically the base layer of a distributed system. The rover publishes motion and platform state, while additional packages provide perception and navigation. The architecture follows standard ROS message and transform conventions defined in REP-103 for units and coordinate conventions, and REP-105 for mobile platform frames such as map, odom, and base_link.

A common ROS 2 stack on Leo Rover 1.9 includes the following subsystems:

base driver node for wheel control and state feedback
odometry publisher using wheel encoder and optionally IMU data
robot_state_publisher with a URDF model
sensor drivers for LiDAR, camera, IMU, or GNSS
state estimation with robot_localization using EKF or UKF
SLAM or localization package such as slam_toolbox or AMCL
Nav2 for global planning, local planning, recovery behaviors, and costmaps

The minimal command interface is usually the standard velocity command topic. For skid-steer robots this is normally a subscription to /cmd_vel with message type geometry_msgs/msg/Twist. Odometry is published as nav_msgs/msg/Odometry, and TF provides the transform tree required by localization and planning nodes.

ros2 topic list
ros2 topic echo /cmd_vel
ros2 topic echo /odom
ros2 run tf2_tools view_frames

If the robot is used for Nav2, the transform chain must be internally consistent. A typical chain is:

map -> odom -> base_link -> laser_frame
map -> odom -> base_link -> camera_link
map -> odom -> base_link -> imu_link

Integration scope on Leo Rover 1.9

Leo Rover 1.9 is most useful when treated as a sensor-ready UGV platform. It can host the full autonomy pipeline, but performance depends on payload, CPU budget, power draw, and the quality of calibration. On a Raspberry Pi-class computer, lightweight mapping and navigation are feasible, while heavy 3D perception or neural inference may require offloading or an auxiliary compute module.

Typical integrations on this platform include:

2D LiDAR for obstacle detection and 2D SLAM
IMU for heading stabilization and state estimation
depth camera for near-field perception and point cloud generation
GPS or RTK GNSS for outdoor global positioning
teleoperation via Wi-Fi with ROS 2 topics or web interfaces

For example, a LiDAR may publish sensor_msgs/msg/LaserScan at 5-15 Hz depending on the vendor and scan mode, while an IMU commonly publishes sensor_msgs/msg/Imu at tens or hundreds of hertz. The exact rate depends on the sensor model and driver configuration. These rates matter because local planners and EKF filters rely on predictable update timing.

Example ROS 2 configuration pattern

On Leo Rover 1.9, one common pattern is to fuse wheel odometry and IMU data, then feed the result into Nav2 or SLAM. The example below shows a simplified robot_localization configuration. It is not platform-specific firmware, but it reflects a standard mobile robotics deployment approach.

ekf_filter_node:
  ros__parameters:
    frequency: 30.0
    two_d_mode: true
    publish_tf: true
    map_frame: map
    odom_frame: odom
    base_link_frame: base_link
    world_frame: odom

    odom0: /wheel/odometry
    odom0_config: [true, true, false,
                   false, false, true,
                   true, true, false,
                   false, false, true,
                   false, false, false]

    imu0: /imu/data
    imu0_config: [false, false, false,
                  false, false, true,
                  false, false, false,
                  false, false, true,
                  false, false, false]

This reflects a standard 2D UGV assumption. Position is estimated in the plane, yaw is the dominant orientation state, and roll or pitch are often ignored unless terrain modeling is required.

Use cases with Leo Rover and Raph Rover

Leo Rover 1.9 is best suited for compact research and educational workflows where moderate payload and moderate compute are sufficient. It is appropriate for ROS 2 teaching, SLAM demonstrations, perception prototyping, and repeatable indoor-outdoor experiments. Its size and compute profile make it practical for laboratory environments and student projects.

In contrast, Raph Rover addresses a different system class. It is a larger and heavier platform intended for applications that need more payload capacity. That distinction matters during system design.

Leo Rover 1.9 – preferred for education, algorithm validation, compact field testing, and mobile robotics labs
Raph Rover – preferred when the sensor suite, battery system, or onboard compute is heavier and requires a more capable carrier

Raph Rover does not replace Leo Rover for teaching and small-scale experimentation. The two platforms serve different constraints. In Fictionlab deployments, the same ROS 2 concepts apply to both, but payload budget, terrain tolerance, and compute architecture influence package selection and tuning.

Limitations and engineering trade-offs

Leo Rover 1.9 has clear strengths, but also clear constraints. Those constraints should be explicit in a glossary definition because they affect architecture decisions.

It is not an autonomous vehicle by default – navigation requires additional sensors and software
Raspberry Pi-class onboard compute limits heavy perception workloads
Skid-steer kinematics simplify control but introduce slip and can reduce odometry accuracy on some surfaces
Weather resistance does not remove the need for environmental risk assessment
Outdoor localization quality depends strongly on GNSS quality, calibration, and multipath conditions

For this reason, Leo Rover 1.9 should be specified as a UGV platform revision, not as a complete autonomy product. In research documentation, that distinction improves reproducibility and prevents ambiguity about what is provided by the base robot and what is provided by the user stack.

Normative references and standards

The interpretation of Leo Rover 1.9 in ROS-based robotics should align with established ROS conventions and manufacturer documentation. The most relevant references are:

ROS 2 documentation at docs.ros.org
REP-103 – Standard Units of Measure and Coordinate Conventions
REP-105 – Coordinate Frames for Mobile Platforms
Nav2 documentation for ROS 2 navigation architecture
URDF and robot_state_publisher documentation for robot modeling
Fictionlab technical documentation at docs.fictionlab.pl/leo-rover/

These sources define how Leo Rover 1.9 should be modeled in software, integrated into TF, and operated as a mobile robotics platform in a technically correct ROS 2 workflow.