Mobile robot

Mobile robot – definition

A mobile robot is a robot that can move through its operating environment under onboard or external control. In mobile robotics, the term normally refers to a vehicle with locomotion, sensing, computation, and a control system. A mobile robot may be teleoperated, execute pre-planned motion, or navigate autonomously. It is distinct from a fixed-base industrial robot because its base pose changes in relation to the environment.

For an unmanned ground vehicle (UGV), mobility is usually produced by wheeled, tracked, or legged locomotion. Leo Rover and Raph Rover are wheeled UGV platforms. Their motion is constrained by terrain, wheel-ground contact, vehicle kinematics, payload mass, power availability, and sensor visibility. A mobile robot platform is therefore not autonomous by definition. Autonomy typically requires additional software for state estimation, perception as needed, planning, and control; mapping may also be required depending on the application.

The IEEE robotics ontology standard treats a robot as an agent that performs tasks through sensing and actuation. In this context, a mobile robot combines these functions with locomotion. The relevant system boundary includes the chassis, motors, motor controllers, compute unit, sensors, communication links, and software interfaces.

Mobile robot architecture for UGVs

A practical UGV is a layered system. Low-level firmware controls motors and reads encoders. A robot computer publishes sensor data and receives velocity commands. Higher-level applications perform localization, navigation, perception, or teleoperation. ROS 2 provides a common middleware layer between these components.

Locomotion layer: motors, gearboxes, wheels, encoders, motor drivers, and emergency-stop hardware.
State-estimation layer: wheel odometry, IMU data, GNSS data, and sensor fusion.
Perception layer: LiDAR scans, depth images, RGB images, point clouds, and object detections.
Navigation layer: maps, localization, costmaps, global planning, local control, and recovery behavior.
Application layer: inspection logic, data logging, teleoperation, experiment orchestration, or a field-specific payload.

On a ROS 2 system, these layers communicate through topics, services, actions, and parameters. ROS 2 commonly uses DDS implementations through its middleware interface, although the selected middleware implementation and quality-of-service settings can affect communication behavior. Sensor streams commonly use best-effort delivery where occasional loss is acceptable, while command and state interfaces may require reliable delivery.

Differential-drive mobile robots

Leo Rover uses a four-wheel differential-drive configuration. In differential drive, the left and right wheel sets are commanded at different velocities. Equal wheel velocities produce forward or reverse motion. A velocity difference produces rotation around an instantaneous center of curvature.

The ideal planar kinematic model is commonly expressed as:

v = (vR + vL) / 2
ω = (vR - vL) / b

In this model, v is linear velocity, ω is angular velocity, vR and vL are right and left wheel linear velocities, and b is the effective distance between wheel contact tracks. Real UGV motion deviates from this model because of wheel slip, uneven ground, tire deformation, backlash, and encoder error. Wheel odometry should therefore be treated as an estimate, not as ground truth.

ROS conventionally represents the robot base with the base_link frame and publishes odometry in an odom frame. REP 105 defines the commonly used relationship between map, odom, and base_link. REP 103 defines coordinate-frame conventions, including right-handed axes where x points forward, y points left, and z points upward.

ROS 2 interfaces used by a mobile robot

ROS 2 packages should expose standard message interfaces where possible. This improves compatibility with tools such as RViz, rosbag2, Nav2, robot_localization, and simulation environments. A driver should publish measurements with valid timestamps and a coherent TF frame tree.

Function	Typical ROS 2 interface	Purpose
Velocity command	`geometry_msgs/msg/Twist` on `/cmd_vel`	Requests linear and angular base motion.
Wheel odometry	`nav_msgs/msg/Odometry`	Publishes estimated pose in the odometry frame and velocity relative to the child frame.
Laser scanner	`sensor_msgs/msg/LaserScan`	Provides planar range measurements for mapping or obstacle detection.
Inertial measurement	`sensor_msgs/msg/Imu`	Provides angular velocity, linear acceleration, and orientation when available.
Frame transforms	`tf2_msgs/msg/TFMessage`	Transports transforms between sensor, base, odometry, and map coordinate frames.

A minimal command-line check for a mobile base interface is shown below. It sends a forward velocity command and should only be used in a clear, controlled test area.

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

Mobile robot platforms in the Fictionlab context

Leo Rover is a compact mobile robotics platform with an integrated Raspberry Pi compute unit, four-wheel differential drive, and IP55 protection. It supports ROS 2, with compatibility depending on the installed software image and ROS 2 distribution. The platform can be used as a base for teleoperation, mapping, visual perception, outdoor data collection, and navigation research. It does not provide autonomous navigation out of the box. A deployment typically requires suitable sensors, a robot description, TF configuration, localization or SLAM, and a navigation stack.

Raph Rover is a larger and heavier UGV platform intended for projects that require greater payload capacity. It is relevant when a mobile robot must carry larger sensor assemblies, compute hardware, batteries, inspection equipment, or research payloads. It does not replace Leo Rover in laboratory and educational workflows where a smaller platform is sufficient.

Key engineering constraints

A mobile robot design must be evaluated as a complete system. Navigation performance depends on more than the chassis. Sensor placement, timing accuracy, compute load, network behavior, and calibration directly affect localization and obstacle avoidance.

Wheel odometry can drift during slip, especially on loose soil, wet grass, gravel, or ramps.
LiDAR and depth cameras require unobstructed fields of view and stable frame extrinsics.
IMU fusion requires correct axis orientation, covariance handling, and timestamp consistency.
GNSS or RTK positioning can improve outdoor global localization but may degrade near buildings, trees, or terrain occlusions.
Payload mounting changes the robot’s center of mass and can affect traction, vibration, and sensor alignment.

Normative references and technical sources

The following sources define the main ROS interfaces and coordinate-frame conventions used when integrating a mobile robot.