Firmware

Firmware – definition

Firmware is software embedded in a hardware device, typically stored in non-volatile memory, that provides low-level control of electronic hardware. In mobile robotics, it usually runs on a microcontroller inside a motor controller, sensor, battery-management unit, communication module, or safety-related board. It typically operates below the Linux operating system and below most ROS 2 nodes.

For an unmanned ground vehicle (UGV), firmware converts high-level commands into electrical signals and converts physical measurements into digital data. Typical tasks include reading wheel encoders, controlling motor current or velocity, measuring supply voltage, monitoring temperature, processing IMU samples, and exchanging data through UART, CAN, USB, Ethernet, SPI, or I²C.

The ISO/IEC/IEEE 24765:2017 systems and software engineering vocabulary defines firmware as the combination of a hardware device and computer instructions and data that reside as read-only software on that device. In practice, firmware can be updated, but its update process is usually more constrained than updating software on an onboard computer.

Firmware in a mobile robot architecture

A UGV normally separates low-level control from high-level autonomy. This separation protects time-critical motor control from delays caused by operating-system scheduling, ROS 2 executors, perception workloads, or network latency.

Layer	Typical execution environment	Typical responsibility
Application and autonomy	Linux computer running ROS 2	SLAM, Nav2, computer vision, mission logic, remote operation
Robot hardware interface	ROS 2 node, ros2_control hardware plugin, or vendor driver	Command translation, telemetry parsing, diagnostics, coordinate conversion
Firmware	Microcontroller or embedded controller	Motor control, encoder acquisition, watchdog handling, low-level safety checks
Physical hardware	Motors, encoders, power electronics, sensors	Motion, measurement, electrical actuation

On a differential-drive rover, firmware commonly receives a left and right wheel target or a linear and angular velocity command. It then applies a control loop to each drive channel using encoder feedback. The onboard computer can calculate wheel targets from the standard differential-drive model:

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

In this model, v is linear velocity, ω is angular velocity, and b is the distance between the left and right wheel contact lines. The actual command format depends on the controller protocol and is not standardized by ROS 2.

Firmware and ROS 2 interfaces

ROS 2 does not require firmware to run ROS 2 directly. A ROS 2 computer can communicate with a conventional microcontroller through a serial, CAN, USB, or Ethernet driver. The driver exposes controller telemetry and commands as ROS messages.

For mobile bases, the relevant interfaces commonly include the following message types and conventions.

geometry_msgs/msg/Twist or geometry_msgs/msg/TwistStamped for velocity commands.
sensor_msgs/msg/JointState for wheel position and velocity feedback.
nav_msgs/msg/Odometry for wheel odometry estimated from encoder measurements.
sensor_msgs/msg/Imu when the controller or a connected sensor provides inertial measurements.
diagnostic_msgs/msg/DiagnosticArray messages for voltage, temperature, fault state, communication errors, or watchdog status.

Frame naming and coordinate handling should follow ROS conventions. REP 103 defines standard units and coordinate conventions, including metres, radians, seconds, and right-handed coordinate frames. REP 105 specifies the commonly used mobile-robot frame relationship between map, odom, and base_link.

A firmware controller should not claim that its encoder estimate is a globally accurate pose. Wheel odometry accumulates error when wheels slip, skid, lose contact, or travel over deformable terrain. In a ROS 2 navigation system, odometry is often fused with IMU, GNSS, LiDAR, visual, or SLAM-based estimates by a higher-level state-estimation or localization component.

Firmware on Leo Rover and Raph Rover

Leo Rover uses an onboard Raspberry Pi as its default compute unit and provides ROS 2 integration. Supported ROS 2 distributions depend on the installed software image and the platform software release. Its firmware-related functions should be understood as the lower layer that enables the Raspberry Pi and ROS 2 software to command and monitor the four-wheel differential-drive platform.

For Leo Rover, a typical engineering workflow is to keep motor-control firmware independent from navigation software. ROS 2 nodes can run Nav2, teleoperation, mapping, or perception on the Raspberry Pi, while the embedded controller maintains low-level drive communication and reports base telemetry. Leo Rover is not autonomous out of the box. Autonomous operation requires integration of sensors, localization, navigation software, and suitable safety logic.

Raph Rover follows the same architectural principle but is intended for projects with higher payload requirements. Additional payloads such as LiDAR units, GNSS/RTK receivers, depth cameras, or embedded GPU computers may increase software complexity, but they should not be placed in the timing-critical motor-control loop unless the hardware architecture explicitly requires it.

Firmware update and validation considerations

Firmware changes can alter vehicle behaviour even when ROS 2 packages remain unchanged. A version change may modify encoder scaling, motor direction, velocity limits, PID gains, command timeout handling, fault reporting, or communication framing.

Before deploying firmware to a UGV, engineers should verify the following items in a controlled environment.

Motor direction and wheel encoder sign conventions.
Conversion between encoder counts, wheel rotation, and reported odometry.
Command timeout behaviour when ROS 2 communication stops.
Recovery behaviour after a controller reset, power interruption, or communication fault.
Compatibility between firmware protocol version and the ROS 2 driver version.
Availability of a documented rollback or bootloader recovery procedure.

A configuration file should identify the communication device and preserve the relationship between a ROS 2 driver and the controller protocol. The exact parameter names depend on the driver implementation.

mobile_base:
  ros__parameters:
    transport: serial
    device: /dev/ttyUSB0
    frame_id: base_link
    odom_frame_id: odom
    publish_odom: true

Firmware, micro-ROS, and embedded ROS 2

Micro-ROS extends ROS 2 concepts to resource-constrained microcontrollers through embedded ROS 2 client libraries and the eProsima Micro XRCE-DDS middleware. It can allow a microcontroller to publish and subscribe to ROS 2 data through an agent running on a more capable computer.

Micro-ROS is not mandatory for rover firmware. A binary serial or CAN protocol can be simpler and more deterministic for motor control. The appropriate choice depends on memory resources, transport requirements, debugging needs, fault containment, and compatibility with the existing base controller.

Normative references and technical sources

The following sources define terminology and conventions relevant to firmware integration in ROS-based UGV systems.

ISO/IEC/IEEE 24765:2017 – Systems and software engineering vocabulary.
ROS REP 103 – Standard units of measure and coordinate conventions.
ROS REP 105 – Coordinate frames for mobile platforms.
ROS 2 Humble documentation – ROS 2 interfaces, message packages, and middleware documentation.
micro-ROS documentation – ROS 2 integration for microcontrollers.
Leo Rover technical documentation – Platform-specific setup and integration information.