European Rover Challenge (ERC)

European Rover Challenge (ERC) – definition

The European Rover Challenge (ERC) is an international engineering competition focused on the design, integration, and field operation of Mars rover prototypes. The event was first held in 2014 and combines a rover competition with scientific and technology-oriented activities related to planetary exploration robotics. Source: European Rover Challenge

In mobile robotics, ERC is a systems-engineering benchmark rather than a single navigation or perception task. A team must integrate a mobile base, onboard computing, power distribution, communications, sensors, manipulation or scientific payloads where required, and operator interfaces into a rover that can complete the tasks defined in the rules of a specific edition. The exact tasks, scoring rules, and safety requirements are edition-dependent. The official rulebook for the relevant year is therefore the primary technical reference.

ERC rovers are generally developed as off-road unmanned ground vehicles (UGVs). They operate in constrained outdoor terrain and must handle imperfect localization, uneven ground, sensor occlusion, and limited onboard compute resources. These constraints make the competition relevant to ROS 2 navigation, sensor fusion, computer vision, simulation, and repeatable deployment workflows.

ERC as a mobile robotics systems test

An ERC project is evaluated through the behavior of the complete robotic system. A rover may have functional individual components but still fail a mission because coordinate frames are inconsistent, localization drifts, a sensor driver is unstable, or the power system cannot sustain the required payload.

For a ROS-based UGV, the integration scope usually includes the following subsystems:

Mobility: wheel odometry, motor control, velocity limiting, and terrain-aware driving.
State estimation: fusion of wheel encoders, IMU data, GNSS data where permitted, and visual or LiDAR odometry.
Perception: camera, depth camera, and LiDAR processing for obstacle detection, terrain interpretation, and target recognition.
Navigation: map representation, localization, path planning, recovery behavior, and teleoperation fallback.
Operations: telemetry, logging, diagnostics, remote access, simulation, and repeatable software deployment.

Competition performance should be measured at subsystem and mission level. Useful metrics include localization error, obstacle detection precision and recall, navigation completion rate, battery voltage under load, CPU and memory utilization, packet loss, and mean time required to recover from a failed node.

Subsystem	Typical ROS 2 interface	Validation metric
Drive base	`geometry_msgs/msg/Twist`, `nav_msgs/msg/Odometry`	Command tracking and odometry consistency
Laser scanner	`sensor_msgs/msg/LaserScan` or `sensor_msgs/msg/PointCloud2`	Detection coverage and timestamp stability
IMU	`sensor_msgs/msg/Imu`	Orientation drift and acceleration noise
GNSS / RTK receiver	`sensor_msgs/msg/NavSatFix`	Position availability and covariance quality
Camera pipeline	`sensor_msgs/msg/Image`, `sensor_msgs/msg/CameraInfo`	Frame delivery, calibration validity, inference latency

ROS 2 architecture for an ERC rover

ROS 2 provides middleware, package conventions, message definitions, lifecycle patterns, and tools for composing the rover software stack. It does not provide a complete ERC solution by itself. Navigation, perception, teleoperation, mission logic, and hardware drivers must be selected, configured, and tested for the rover and terrain.

A robust architecture separates hardware interfaces from higher-level autonomy nodes. The base controller publishes odometry and transforms, while localization and navigation consume standardized data. ROS coordinate frames should follow REP 105, which defines common frames such as map, odom, and base_link. Physical units and axis conventions should follow REP 103. Source: REP 105 Source: REP 103

# Example frame and topic contract for a differential-drive ERC UGV
base_controller:
  ros__parameters:
    odom_frame_id: odom
    base_frame_id: base_link
    cmd_vel_topic: /cmd_vel
    odom_topic: /odom

robot_localization:
  ros__parameters:
    map_frame: map
    odom_frame: odom
    base_link_frame: base_link
    world_frame: odom
    two_d_mode: true

The transform tree must remain connected and internally consistent. For example, a LiDAR mounted above the chassis requires a static transform from base_link to the sensor frame. Incorrect extrinsic calibration can produce map distortion, false obstacles, or navigation failures even when the sensor driver is working correctly.

Using Leo Rover and Raph Rover in ERC-oriented development

Leo Rover can be used as a compact development platform for ERC-relevant software subsystems. Its four-wheel skid-steer chassis, integrated Raspberry Pi compute unit, and ROS 2-compatible software stack make it suitable for validating teleoperation, odometry, sensor drivers, TF trees, Nav2 configuration, and perception pipelines before deployment on a larger rover. Leo Rover is IP55-rated, but it is not an autonomous vehicle out of the box. A navigation stack, sensor suite, calibration, and safety validation are required.

For a Leo Rover prototype, a practical scope is to validate the software contract rather than reproduce a full competition rover. This can include:

publishing calibrated IMU, camera, and LiDAR data with synchronized timestamps;
testing robot_localization state estimation and wheel-slip behavior;
running Nav2 in a controlled outdoor test area;
recording sensor and control data with ros2 bag for offline analysis;
building the same ROS 2 workspace in Docker for reproducible deployment.

Raph Rover is more appropriate when the experiment requires a larger payload, additional compute hardware, larger sensors, or more substantial power and mechanical integration. It should be selected when payload and terrain requirements exceed the scope of a compact laboratory platform. It does not replace Leo Rover for introductory ROS 2 work, classroom exercises, or rapid laboratory validation.

Verification and documentation

ERC-oriented development benefits from configuration control. Teams should version URDF or Xacro models, sensor extrinsics, controller parameters, container definitions, launch files, and mission procedures. Simulation can validate interfaces and nominal behavior, but physical testing remains necessary for wheel slip, vibration, lighting variation, radio performance, and power-system effects.

The following references define commonly used technical conventions:

European Rover Challenge (ERC)