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:
- ROS REP 103 – Standard Units of Measure and Coordinate Conventions.
- ROS REP 105 – Coordinate Frames for Mobile Platforms.
- ROS 2 documentation – common interface concepts and message types.
- ROS 2 documentation – recording and playback with rosbag2.
- Ross, S., Gordon, G., and Bagnell, D. 2011. A Reduction of Imitation Learning and Structured Prediction to No-Regret Online Learning. AISTATS.