LeoCore

LeoCore – definition

LeoCore is the low-level control and hardware interface layer used in the Leo Rover platform. In mobile robotics terms, it is the subsystem that connects the onboard computer running Linux and ROS 2 with the rover electronics responsible for motion, power management, and basic telemetry. It is not a SLAM package, not a navigation stack, and not a perception algorithm. Its role is closer to a base driver or robot hardware abstraction for a skid-steer 4-wheel UGV.

On Leo Rover, LeoCore provides the bridge between high-level software and the rover chassis. A ROS 2 application can publish velocity commands, read odometry-related data, inspect battery state, and monitor low-level status through this interface. This is consistent with the standard ROS robot architecture, where hardware drivers expose capabilities through topics, services, actions, and parameters, while higher layers such as localization, Nav2, or custom autonomy nodes operate above them.

In practice, LeoCore should be understood as the platform-specific control stack that makes Leo Rover usable as a robotic base for research, teaching, and field prototyping. For engineers, this means it is the starting point for integration of autonomy functions on Leo Rover and a reference model for similar integration work on larger UGVs.

How LeoCore fits into a ROS 2 mobile robot stack

In ROS 2, a mobile robot stack is usually layered. Low-level drivers expose actuator and sensor interfaces. Mid-level nodes estimate state and provide transforms. High-level nodes handle mapping, planning, and mission logic. LeoCore belongs to the low-level layer.

For a mobile rover, the minimum data path usually includes commanded body velocity, wheel or motor feedback, and a robot pose estimate in the local frame. ROS conventions for these interfaces are defined by common message types and coordinate frame practices, especially REP 103 for units and conventions and REP 105 for coordinate frames.

geometry_msgs/msg/Twist is typically used for commanded linear and angular velocity on /cmd_vel.
nav_msgs/msg/Odometry is used for local odometry output on topics such as /odom.
sensor_msgs/msg/JointState may expose wheel positions or velocities, depending on the implementation.
tf2 transforms typically include at least odom -> base_link and the robot body frame hierarchy defined according to REP 105.

On Leo Rover, LeoCore is the part that makes these interfaces available from the physical rover base. This matters because ROS 2 navigation and localization software expects clean, time-consistent low-level data. If the base interface is unstable, delayed, or inconsistent in frame naming, the rest of the autonomy stack becomes difficult to validate.

Core functions in the context of Leo Rover

Leo Rover is a 4-wheel, skid-steer UGV with a built-in Raspberry Pi compute unit and ROS 2 support. Because the rover is not autonomous out of the box, LeoCore is the layer that provides the controllable mobile base required for integration with localization, mapping, and planning software.

In this context, LeoCore usually covers the following functions:

motor command execution from high-level velocity setpoints
encoder or drivetrain feedback acquisition
base odometry publishing
battery and power status reporting
health and diagnostic communication with the onboard computer
safe stop behavior on communication timeout or fault

For field and education use, these functions are more important than they may appear. A rover can run Nav2, SLAM Toolbox, or a custom autonomy node only if the base driver reliably converts software commands into physical motion and reports enough state for feedback control.

Interfaces, topics, and configuration examples

A practical ROS 2 integration with LeoCore follows standard ROS command and telemetry patterns. Topic names may vary by software release, but the structure generally resembles a conventional mobile base driver.

Interface	Typical ROS 2 type	Purpose
`/cmd_vel`	`geometry_msgs/msg/Twist`	Commanded linear and angular velocity
`/odom`	`nav_msgs/msg/Odometry`	Base odometry estimate
`/joint_states`	`sensor_msgs/msg/JointState`	Wheel or drivetrain state
`/tf`, `/tf_static`	`tf2_msgs/msg/TFMessage`	Coordinate transforms
battery topic	`sensor_msgs/msg/BatteryState` or platform-specific	Power monitoring
diagnostics	`diagnostic_msgs/msg/DiagnosticArray`	Health and status reporting

A minimal command test from a ROS 2 terminal looks like this:

ros2 topic pub /cmd_vel geometry_msgs/msg/Twist \
"{linear: {x: 0.2, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 0.3}}"

A typical launch workflow checks whether LeoCore is publishing the expected interfaces before bringing up localization or navigation:

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

A simplified configuration block for a mobile base controller may include limits such as command timeout and geometry parameters:

base_controller:
  ros__parameters:
    cmd_vel_timeout: 0.5
    wheel_separation: 0.36
    wheel_radius: 0.09
    publish_rate: 30.0
    base_frame_id: base_link
    odom_frame_id: odom

The exact values depend on the hardware revision and software release. They should always be verified against platform documentation and measured rover geometry.

LeoCore in autonomy workflows

LeoCore does not perform autonomous navigation by itself. It enables it. This distinction is important on Leo Rover, because the platform requires integration of a navigation stack for autonomous driving.

A typical autonomy pipeline on Leo Rover is:

LeoCore exposes the mobile base interface.
An IMU, LiDAR, depth camera, or GNSS receiver is added.
Localization is configured using wheel odometry, IMU fusion, or GNSS fusion.
SLAM or mapping software is launched if no prior map exists.
Nav2 or a custom planner sends velocity commands back to the base through /cmd_vel.

For example, a Leo Rover configured with 2D LiDAR and wheel odometry can use SLAM Toolbox on ROS 2 for indoor or semi-structured outdoor mapping. In that setup, LeoCore is responsible for stable odometry and motion execution. If odometry drift is large, map quality and local planner performance degrade. If velocity tracking is poor, path following accuracy decreases.

On larger UGV platforms, the same architectural role exists even if the low-level implementation differs. A larger payload capacity allows more advanced sensor suites, but the concept remains the same: a low-level base interface must provide predictable motion control and status data to the rest of the ROS 2 stack.

Key technical constraints and trade-offs

Because Leo Rover uses a Raspberry Pi as the default onboard compute unit, low-level software design has to consider CPU budget, I/O latency, and deterministic behavior. This affects update rates, logging volume, and how many additional perception nodes can run on the same machine.

The main engineering trade-offs are the following:

higher telemetry frequency improves observability but increases CPU and bus load
aggressive velocity tracking improves responsiveness but may reduce stability on uneven terrain
pure wheel odometry is simple but accumulates drift on slip-prone ground
tight safety timeouts reduce runaway risk but can interrupt operation on overloaded systems

For outdoor UGV work, wheel slip is a major practical issue. On loose soil, grass, gravel, or ramps, odometry derived only from drivetrain feedback may diverge from actual motion. LeoCore therefore should be treated as a base-state source, not as a complete state estimator. In research deployments, it is often fused with IMU and GNSS data using packages such as robot_localization.

Standards and references relevant to LeoCore

The term LeoCore is platform-specific, but the interfaces around it are governed by widely used ROS conventions and message standards. These are the key technical references when evaluating or extending such a subsystem:

REP 103 – Standard Units of Measure and Coordinate Conventions
REP 105 – Coordinate Frames for Mobile Platforms
ROS 2 interface definitions for geometry_msgs, nav_msgs, sensor_msgs, and diagnostic_msgs
ros2_control concepts for hardware abstraction and controller integration where applicable
Leo Rover technical documentation at docs.fictionlab.pl/leo-rover

For implementation work, these references matter more than platform branding. They define how a mobile base should expose motion and state to the rest of the robotic system in a reproducible way.