Glossary

UGV

UGV – definition

UGV stands for Unmanned Ground Vehicle. In robotics, the term describes a mobile robot that operates on land without a human onboard. The vehicle may be remotely operated, partially autonomous, or autonomous within a defined task scope. In robotics literature and engineering practice, a UGV is usually treated as a ground-based robotic platform combining locomotion, sensing, computation, communication, and control.

In the context of mobile robotics, a UGV is not just a chassis with motors. It is a complete system. It includes the mechanical base, drive kinematics, embedded controllers, power subsystem, onboard computer, sensors, and software stack. In ROS and ROS 2 deployments, a UGV is commonly represented as a set of nodes publishing state, sensor, and command interfaces such as odometry, IMU, laser scans, camera streams, and velocity commands.

For Fictionlab platforms, Leo Rover and Raph Rover are examples of UGV platforms used for research, education, and field robotics integration. Leo Rover is a compact four-wheel rover with native ROS support and an onboard Raspberry Pi-based compute unit. Raph Rover is a larger UGV designed for applications that require higher payload capacity and more space for sensors or compute hardware. Neither platform should be equated with a complete autonomy solution by default. A UGV platform becomes autonomous only after integration of localization, perception, planning, and safety layers.

Core components of a UGV

A UGV is typically described through its subsystems. This matters in engineering because each subsystem maps to measurable interfaces and constraints. In ROS 2, these constraints directly affect topic rates, transform trees, controller loops, and navigation performance.

  • Locomotion – wheels, tracks, or articulated suspension; for Leo Rover, a four-wheel rover drivetrain.
  • Actuation and low-level control – motor drivers, encoders, microcontroller, closed-loop wheel control.
  • State estimation – wheel odometry, IMU fusion, optional GNSS or visual odometry.
  • Perception – LiDAR, RGB camera, depth camera, stereo camera, ultrasonic sensors, bumper or contact sensors.
  • Compute – onboard SBC or edge computer such as Raspberry Pi or NVIDIA Jetson.
  • Communication – Wi-Fi, Ethernet, LTE, or mesh networking for teleoperation, telemetry, and remote logging.
  • Software stack – ROS 2 drivers, TF tree, robot description, SLAM, Nav2, diagnostics, and mission logic.

From a systems engineering point of view, a UGV is defined by interfaces. A practical baseline in ROS 2 includes /cmd_vel, /odom, /tf, /joint_states, and one or more sensor topics. This is what allows a platform to be integrated with generic tooling such as Nav2, RViz2, rosbag2, and simulation.

How UGVs are represented in ROS 2

ROS 2 does not define a UGV as a single built-in object. Instead, it defines communication patterns, message types, and conventions. A UGV is modeled through nodes, topics, transforms, parameters, and robot description files. Several ROS standards are relevant here, especially REP 103 for standard units and coordinate conventions, REP 105 for mobile platform coordinate frames, and URDF for robot kinematic description.

A minimal ROS 2 UGV integration usually includes the following interfaces.

Function Typical ROS 2 interface Example message type Typical rate
Velocity command /cmd_vel geometry_msgs/msg/Twist 10 – 50 Hz
Wheel or fused odometry /odom nav_msgs/msg/Odometry 20 – 100 Hz
Transform tree /tf, /tf_static tf2_msgs/msg/TFMessage dynamic or static
IMU /imu/data sensor_msgs/msg/Imu 50 – 400 Hz
2D LiDAR /scan sensor_msgs/msg/LaserScan 5 – 20 Hz
Camera /image_raw sensor_msgs/msg/Image 15 – 60 Hz

REP 105 defines the common frame hierarchy used on mobile robots: base_link, odom, and map. This distinction is essential on UGVs. odom is locally continuous but drifts. map is globally corrected by SLAM or localization. A ground robot that ignores this separation will usually show unstable navigation behavior.

ros2 topic list
ros2 topic echo /odom
ros2 run tf2_ros tf2_echo odom base_link
ros2 topic hz /scan

UGV kinematics and motion models

The term UGV covers multiple locomotion types, but in ROS integration the motion model matters more than the label. Differential drive, skid-steer, Ackermann steering, and tracked motion produce different controller assumptions and odometry error characteristics.

Leo Rover is used as a skid-steer platform in ROS 2 integration. This means motion is commonly abstracted by linear velocity v and angular velocity ω. The standard planar model is:

x_dot = v * cos(theta)
y_dot = v * sin(theta)
theta_dot = omega

For practical navigation, this abstraction is sufficient for local planning and odometry interfaces. Real terrain adds slip, compliance, and wheel-ground interaction errors. Those effects become more significant on loose soil, grass, ramps, or rubble. Raph Rover, due to larger mass and payload potential, may require stronger attention to traction, braking distance, and IMU-assisted state estimation in outdoor environments.

Key parameters and metrics

A technical description of a UGV should include measurable parameters. These parameters define whether a platform is suitable for lab work, outdoor autonomy experiments, or payload-heavy integration.

  • Drive type – differential, skid-steer, Ackermann, tracked.
  • Payload – maximum mass available for sensors, compute, and tools.
  • Ingress protection – for Leo Rover, IP54.
  • Compute envelope – CPU, RAM, optional GPU, thermal budget.
  • Sensor bandwidth – image resolution, LiDAR scan rate, IMU update frequency.
  • Localization accuracy – odometry drift, GNSS/RTK accuracy, loop closure stability.
  • Endurance – runtime under nominal payload and terrain conditions.
  • Traversability – slope, obstacle clearance, wheel slip tolerance, ground clearance.

These metrics are not interchangeable. A UGV for education may prioritize ROS 2 accessibility and safe indoor operation. A UGV for field inspection may prioritize environmental resistance, RTK integration, and stable power delivery for LiDAR and edge AI compute.

Use cases with Leo Rover and Raph Rover

On Leo Rover, the UGV concept is usually implemented as a compact research or teaching platform. The onboard computer can run ROS 2, basic teleoperation, SLAM, and introductory autonomy stacks. Because it is not an autonomous rover out-of-the-box, users normally add a 2D LiDAR, depth camera, or GNSS module depending on the task.

  • Leo Rover – indoor SLAM, university courses, ROS 2 navigation experiments, camera and LiDAR integration, remote teleoperation, basic outdoor mapping.
  • Raph Rover – larger sensor payloads, field data collection, heavier compute setups, outdoor perception stacks, experimental inspection workflows.

In both cases, the engineering task is the same: define the robot model, publish reliable state estimates, calibrate sensors, and validate closed-loop motion before enabling autonomy. For UGV work, hardware capability and software architecture must be evaluated together.

Limitations and engineering trade-offs

The term UGV can be too broad if used without context. A teleoperated rover, a Nav2-enabled campus robot, and an RTK-equipped inspection platform are all UGVs, but their software and validation requirements differ significantly.

Typical trade-offs include:

  • Size vs agility – smaller UGVs are easier to use in labs, larger ones carry more payload.
  • Compute vs power – stronger onboard AI hardware increases thermal and battery demands.
  • Wheel odometry vs terrain reality – uneven ground increases slip and drift.
  • Autonomy vs integration effort – adding SLAM, Nav2, and sensor fusion requires calibration and testing.

This is why a UGV should be described not only by form factor, but also by its validated operating envelope, sensor stack, and software maturity.

Normative references and standards

For technical work, the following references are the most relevant. They provide terminology, frame conventions, and software interface assumptions used in UGV integration.

  • ROS REP 103 – Standard Units of Measure and Coordinate Conventions, ros.org.
  • ROS REP 105 – Coordinate Frames for Mobile Platforms, ros.org.
  • URDF – Unified Robot Description Format, ROS documentation.
  • ROS 2 documentation – topics, TF2, lifecycle nodes, ros2_control, Nav2 interfaces.
  • IEEE robotics terminology – definitions for unmanned and autonomous ground systems.
  • Platform documentation – docs.fictionlab.pl/leo-rover.

See also

  • ROS 2
  • SLAM
  • Nav2
  • LiDAR