Hardware-in-the-loop (HIL)

Hardware-in-the-loop (HIL) – definition

Hardware-in-the-loop (HIL) is a verification and validation method in which real robot hardware operates while part of its environment, sensors, actuators, or vehicle dynamics is simulated in real time. The hardware under test exchanges the same electrical signals, network messages, or ROS interfaces that it would use on a physical mobile robot.

In mobile robotics, HIL is used to test a UGV control stack before operating it in an uncontrolled environment. A test may include a real onboard computer, motor controller, safety circuit, GNSS receiver, LiDAR, IMU, or camera interface. The simulated part may provide wheel encoder ticks, IMU measurements, laser scans, GNSS fixes, terrain resistance, or obstacle motion.

HIL differs from pure software simulation. In simulation, the controller and the robot model may both run as software processes. In HIL, at least one physical component is included in the closed control loop. This makes timing, communication latency, driver behavior, power-up states, firmware limitations, and hardware I/O faults observable during the test.

HIL for UGV control systems

A typical UGV HIL setup replaces the physical terrain and vehicle response with a real-time plant model. The controller receives simulated feedback, calculates a command, and sends that command to the simulator or an interface device. The simulator then updates the vehicle state and publishes the next sensor or encoder values.

For a differential-drive platform, the simulated kinematic state commonly includes position, heading, linear velocity, angular velocity, and wheel angular velocities. The relationship between wheel speed and robot velocity can be expressed as follows:

v = r(ωR + ωL) / 2
ω = r(ωR - ωL) / b

In this model, r is wheel radius, b is the distance between the left and right wheel contact lines, ωR is right-wheel angular velocity, and ωL is left-wheel angular velocity. A HIL plant model can extend this ideal kinematic model with motor delay, encoder quantisation, wheel slip, actuator saturation, battery-voltage effects, and slope-dependent resistance.

HIL architecture in ROS 2

ROS 2 does not define one mandatory HIL framework. A HIL implementation is usually built from ROS 2 nodes, hardware drivers, a simulator or real-time plant model, and test orchestration tools. The required interfaces depend on whether the physical component is the onboard computer, the motor controller, the sensor payload, or the complete rover.

For a differential-drive UGV, the ROS 2 control path commonly uses the following data flow:

/cmd_vel using geometry_msgs/msg/Twist for requested linear and angular velocity.
/joint_states using sensor_msgs/msg/JointState for measured or simulated wheel positions and velocities.
/odom using nav_msgs/msg/Odometry for odometry estimates.
/tf and /tf_static for coordinate transforms.
/scan using sensor_msgs/msg/LaserScan when a LiDAR is simulated or replayed.
/imu/data using sensor_msgs/msg/Imu for inertial measurements.

Frame naming and transform semantics should follow ROS conventions. REP 103 defines standard units, axes, and coordinate conventions. REP 105 specifies commonly used mobile-robot frames, including map, odom, and base_link. These conventions are important in HIL because inconsistent frame IDs can produce apparently valid but physically incorrect navigation results.

ros2 topic hz /cmd_vel
ros2 topic hz /odom
ros2 topic echo /tf_static --once
ros2 run tf2_ros tf2_echo odom base_link

The measured topic rate, timestamp progression, transform availability, and command-to-feedback delay should be recorded as test evidence. ROS 2 Quality of Service settings also matter. A sensor stream using best-effort reliability can behave differently from a reliable stream when packets are lost or when the subscriber starts late.

Key HIL timing parameters

HIL is only representative when the timing of the closed loop is controlled and measured. The simulator does not always need to run faster than real time, but a test intended to validate controller timing should preserve the expected update period and communication delay.

Parameter	Meaning in a UGV HIL test	How to verify
Plant update period	Interval between simulated vehicle-state updates.	Log simulation timestamps and calculate period jitter.
Sensor latency	Delay between simulated physical event and delivered ROS message.	Compare source and reception timestamps using a common time source or synchronised clocks.
Command latency	Delay from a `/cmd_vel` command to simulated actuator response.	Correlate command and wheel-speed logs.
Real-time factor	Ratio of simulated elapsed time to wall-clock elapsed time.	Compare elapsed `/clock` time with elapsed wall-clock time.
Fault response time	Time from injected fault to safe controller state or diagnostic event.	Use timestamped logs and defined acceptance criteria.

For ROS 2 nodes configured with simulated time, the parameter use_sim_time must be set consistently. Nodes that use wall time while other nodes use /clock can create invalid timeout, watchdog, or navigation results.

/**:
  ros__parameters:
    use_sim_time: true
    publish_rate: 50.0

HIL with Leo Rover and Raph Rover

Leo Rover is a four-wheel, differential-drive mobile platform with an integrated Raspberry Pi compute unit. It can run ROS 2 software. HIL can therefore validate software running on the actual onboard computer while replacing motion feedback, sensor streams, or terrain response with simulated inputs.

A practical Leo Rover HIL test can run a navigation, teleoperation, or odometry node on the onboard Raspberry Pi and connect it to a simulator through Ethernet, Wi-Fi, serial communication, or a ROS 2 DDS network. The test should not assume that Leo Rover provides autonomous navigation by default. A navigation stack, localisation method, sensors, maps, and safety behaviour must be integrated and verified separately.

Raph Rover is intended for larger payloads and can be used when the HIL system must include heavier sensor assemblies, larger compute hardware, or field-oriented payload integration. Its larger mechanical scale does not remove the need to model actuator response, wheel slip, payload inertia, sensor mounting geometry, and communication delays.

Typical HIL test cases for mobile robots

HIL is particularly useful where a software defect could cause unsafe motion, loss of localisation, or incorrect mission behaviour. The test plan should define the simulated inputs, expected outputs, pass criteria, and the hardware and software versions under test.

Verify configured safety behaviour, such as commanding zero velocity, after LiDAR, IMU, or GNSS data becomes unavailable.
Inject wheel encoder disagreement and verify configured odometry diagnostics or localisation-degradation handling.
Test recovery behaviour after a ROS 2 node restart, DDS reconnection, or delayed transform publication.
Apply velocity saturation and confirm that planner limits match controller limits.
Replay recorded sensor data to reproduce a field failure under controlled timing conditions.
Validate emergency-stop input handling without moving the physical platform.

Limitations of HIL

HIL does not prove that a UGV will behave identically in the field. The result is limited by the fidelity of the plant model, simulated sensor noise, timing accuracy, and fault assumptions. Wheel-terrain interaction, multipath GNSS errors, LiDAR contamination, camera exposure changes, vibration, and wireless interference are difficult to represent completely.

HIL should therefore complement, not replace, staged physical testing. A typical workflow is software-in-the-loop testing, HIL testing with real compute and interfaces, indoor platform tests at limited speed, and supervised outdoor validation.

Normative references and technical sources

The following sources define commonly used ROS conventions and interfaces relevant to HIL implementation:

Hardware-in-the-loop (HIL)