Glossary

Fictionlab > Glossary > Tracked UGV (continuous track)

Tracked UGV (continuous track)

Tracked UGV (continuous track) – definition

A tracked unmanned ground vehicle (UGV) is a mobile robot that moves on two continuous tracks instead of wheels. Each track is a closed belt, typically made from rubber, reinforced elastomer, or linked metal segments, driven by a sprocket and supported by idlers, rollers, or skid plates. Motion is produced by independently controlling the left and right track velocities.

In mobile robotics, a tracked UGV is usually modelled as a skid-steer or differential-drive vehicle. Straight motion requires approximately equal left and right track speeds. Turning is generated by a speed difference between tracks. A zero-radius turn is theoretically possible when one track moves forward and the other moves backward, but real terrain introduces track slip and soil deformation.

Continuous tracks are used where low ground pressure, obstacle traversal, and traction on loose terrain are more important than energy efficiency or highly accurate wheel odometry. Typical non-military applications include construction-site inspection, agricultural monitoring, tunnel inspection, field research, and planetary-analog testing.

Mechanical layout and mobility characteristics

A continuous-track drivetrain contains two independently driven track assemblies. Each assembly normally includes a drive sprocket, an idler, a tensioning mechanism, and a track belt. The effective contact area is generally larger than that of a wheeled platform with similar mass, which can reduce sinkage on soft ground.

The ground pressure can be approximated as:

p = W / A

where p is average ground pressure, W is vehicle weight, and A is the total track-ground contact area. This simplified model does not account for non-uniform contact pressure, soil compaction, grouser geometry, or dynamic loading.

Tracked UGVs have several practical characteristics that affect system design:

  • They can provide high traction on loose soil, sand, gravel, snow, and uneven construction terrain, depending on track and terrain conditions.
  • Higher drivetrain losses than rolling wheels due to track deformation and internal friction.
  • Skid steering during turns, which increases energy consumption and causes odometry error.
  • Track tension requirements, because insufficient tension can cause derailment and excessive tension can increase bearing and motor loads.
  • Potentially higher vibration levels, particularly when grousers or segmented tracks move over hard surfaces.

A tracked vehicle is not automatically suitable for all outdoor environments. Soft ground performance depends on mass distribution, track width, contact length, cleat design, terrain moisture, payload position, and drive torque.

Tracked UGV kinematics and ROS 2 control

For ROS 2 navigation, a tracked platform is commonly represented by the same planar velocity interface used for differential-drive robots. The command is usually published as geometry_msgs/msg/Twist or geometry_msgs/msg/TwistStamped on a cmd_vel topic. The robot controller converts linear velocity v and angular velocity ω into left and right track velocities.

v_left  = v - (ω * b / 2)
v_right = v + (ω * b / 2)

In this model, b is the effective distance between the centres of the left and right tracks. On a real tracked UGV, it is a calibration parameter rather than a purely geometric measurement because skid steering changes the instantaneous centre of rotation.

The ROS 2 diff_drive_controller from ros2_control can be used when each track is represented by a velocity-commanded joint and the required state interfaces are available. It publishes odometry and can publish the odom to base_link transform. The controller receives geometry_msgs/msg/TwistStamped commands on its controller-specific ~/cmd_vel topic. Its parameters include wheel separation, wheel radius, wheel-name arrays, command timeout, velocity limits, and covariance configuration. For tracks, the configured wheel radius represents the effective sprocket radius, while wheel separation should be validated experimentally.

diff_drive_controller:
  ros__parameters:
    left_wheel_names: ["left_track_joint"]
    right_wheel_names: ["right_track_joint"]
    wheel_separation: 0.42
    wheel_radius: 0.08
    publish_rate: 50.0
    cmd_vel_timeout: 0.5
    base_frame_id: base_link
    odom_frame_id: odom
    enable_odom_tf: true

The values above are integration examples, not universal tracked-vehicle specifications. They must be derived from the actual sprocket, track geometry, motor controller, and payload configuration.

Odometry, localisation, and navigation limitations

Track encoder odometry is useful for short-term motion estimation but should not be treated as an absolute position source. During skid turns, the commanded track displacement is not equal to the robot displacement. The error can become significant on low-friction surfaces, slopes, mud, loose aggregate, or terrain with asymmetric resistance.

A practical ROS 2 state-estimation configuration combines drivetrain odometry with inertial and external measurements. The following inputs are commonly used:

  • nav_msgs/msg/Odometry from the track controller or motor encoders.
  • sensor_msgs/msg/Imu for angular velocity and orientation estimation.
  • LiDAR scan matching or visual odometry for local motion correction.
  • GNSS or RTK GNSS for global outdoor positioning where sky visibility is available.

ROS coordinate frames should follow REP 103 and REP 105. REP 103 specifies SI units, including metres, radians, seconds, and coordinate conventions. REP 105 defines the commonly used map, odom, and base_link frame roles. A localisation system should maintain a continuous odom frame for local control and use map for globally corrected pose estimates.

Tracked UGVs in the Leo Rover and Raph Rover context

Leo Rover is a four-wheel, differential-drive UGV with an IP55-rated chassis and ROS 2 support on its integrated Raspberry Pi compute unit. It is not a tracked platform. Its standard wheel odometry and drivetrain configuration should therefore not be described as continuous-track mobility.

Leo Rover remains relevant when comparing tracked and wheeled UGV architectures. It provides a compact reference platform for ROS 2 navigation, sensor integration, URDF modelling, and differential-drive control. A tracked prototype can use a similar ROS 2 software architecture, but its motor interface, drivetrain parameters, URDF model, controller calibration, and odometry uncertainty require separate validation.

Raph Rover is a larger payload-oriented platform for projects requiring greater carrying capacity. A custom tracked configuration, if designed as part of an engineering project, must account for increased drivetrain torque, thermal load, track tension, suspension geometry, sensor vibration isolation, and power-system sizing. Neither Leo Rover nor Raph Rover should be assumed to provide autonomous navigation out of the box. Autonomous operation requires integration and validation of sensors, localisation, obstacle detection, and a ROS 2 navigation stack.

Normative references and technical documentation

The following sources define the ROS conventions and control interfaces commonly used when integrating a tracked UGV. Hardware dimensions, torque limits, ingress protection, and payload limits must always be taken from the specification of the specific platform and drivetrain.

See also