Glossary

Imitation learning

Imitation Learning – definition

Imitation learning is a machine learning method in which a robot learns a control policy from demonstrations rather than from a manually designed rule set or a reward function alone. In mobile robotics, a demonstration is usually a time-ordered record of observations, robot states, and motion commands collected while an operator drives a UGV through a task environment.

The learned policy maps an observation or state vector ot to an action at. For a differential-drive UGV, the action commonly contains linear and angular velocity commands:

π(o_t) → a_t = [v_t, ω_t]

where vt is linear velocity and ωt is angular velocity. In ROS 2, these commands are commonly represented by geometry_msgs/msg/Twist or geometry_msgs/msg/TwistStamped. The message definitions are maintained in the ROS 2 common interfaces repository and documented by Open Robotics.

For UGVs, imitation learning is used to reproduce driving behaviour such as corridor following, obstacle avoidance, waypoint approach, terrain-dependent speed selection, or local path tracking. It does not make a Leo Rover or Raph Rover autonomous by default. A complete deployment still requires sensor integration, state estimation, command safety limits, and validation in the intended operating environment.

How imitation learning differs from conventional navigation

Classical ROS 2 navigation usually combines localisation, global planning, local planning, costmaps, and a controller. Imitation learning can replace or complement part of this stack, most often a local control component. It can also provide a learned behaviour that is selected by a higher-level state machine or behaviour tree.

The main distinction is the source of control knowledge:

  • Rule-based control uses explicitly programmed conditions and thresholds.
  • Conventional navigation uses maps, robot kinematics, costmaps, and planning algorithms.
  • Reinforcement learning optimises a policy against a defined reward signal.
  • Imitation learning estimates a policy from expert or operator demonstrations.

Behaviour cloning is the most direct imitation-learning method. A dataset contains pairs of observations and actions, and the model is trained with supervised learning. A common objective is:

L(θ) = Σt || πθ(o_t) - a_t ||²

This loss is appropriate for continuous velocity outputs. Classification losses may instead be used when the action space is discretised into actions such as forward, reverse, turn left, turn right, and stop.

Demonstration data for a mobile UGV

A useful demonstration must preserve the temporal relationship between sensor data and the command issued by the operator. Timestamp alignment is critical. A camera frame captured after a steering command must not be paired with that earlier command during training.

A ROS 2 recording for a vision- or LiDAR-based policy can include the following interfaces:

Data type Typical ROS 2 message Purpose in the dataset
Velocity command geometry_msgs/msg/Twist Demonstrated target action
Laser scan sensor_msgs/msg/LaserScan Obstacle geometry and free space
Camera image sensor_msgs/msg/Image Visual scene representation
Depth image or point cloud sensor_msgs/msg/Image, sensor_msgs/msg/PointCloud2 Range-aware perception
Odometry nav_msgs/msg/Odometry Measured robot motion and pose estimate
IMU sensor_msgs/msg/Imu Angular velocity, orientation, and acceleration

Frame identifiers must be consistent with ROS coordinate conventions. REP 103 defines standard units and coordinate conventions, while REP 105 describes common mobile-platform coordinate frames, including map, odom, and base_link. Sensor extrinsics should be published through tf2 and recorded with the dataset where they affect perception.

ROS 2 workflow for Leo Rover and Raph Rover

Leo Rover is a differential-drive mobile platform that can be used with ROS 2. It is therefore suitable for collecting teleoperation demonstrations in controlled indoor, educational, or light field environments. The onboard computer can publish platform data and manage low-level motion, while computationally expensive training or inference may be moved to an external computer or an additional compute payload when required.

Raph Rover can be relevant when an imitation-learning experiment requires a higher payload capacity, such as for a heavier sensor suite, an edge computer, protected enclosures, or additional power distribution hardware. Platform selection does not remove the need to validate braking distance, traction, sensor visibility, and command-loss behaviour.

The following ROS 2 command records selected topics into an MCAP or SQLite bag, depending on the configured rosbag2 storage plugin:

ros2 bag record \
  /cmd_vel \
  /scan \
  /camera/image_raw \
  /camera/depth/image_raw \
  /odom \
  /imu/data \
  /tf \
  /tf_static

The learned node should not publish directly to motor hardware without a safety layer. A practical architecture routes its output through a velocity multiplexer, a watchdog, and a limiter that enforces platform-specific velocity and acceleration constraints.

imitation_policy:
  ros__parameters:
    input_topic: /scan
    output_topic: /cmd_vel_policy
    command_frame: base_link
    require_fresh_sensor_data: true
    publish_zero_on_timeout: true

Dataset shift and safety limitations

Behaviour cloning has a known failure mode called covariate shift. During deployment, a small steering error can move the UGV into a state that was absent from the demonstrations. The policy may then produce unreliable commands because it has not been trained on that observation.

Dataset Aggregation, commonly called DAgger, addresses this issue by collecting corrective demonstrations from states visited by the learned policy. The method was formalised by Ross, Gordon, and Bagnell in 2011. For mobile robots, corrective data should include near-obstacle states, poor lighting, wheel-slip conditions, and recovery manoeuvres where these conditions are relevant to the task.

Imitation learning should not be treated as a replacement for deterministic safeguards. Independent checks remain necessary for emergency stop operation, stale sensor data, invalid transforms, obstacle proximity, actuator saturation, and loss of communication.

Normative references and technical sources

The term imitation learning is used broadly in research literature and is not defined by a single ROS REP or IEEE robotics standard. ROS 2 specifies interfaces and middleware behaviour, not a required learning algorithm. The following primary and technical sources are relevant when implementing an imitation-learning pipeline for a UGV:

See also