FreeRTOS

FreeRTOS – definition

FreeRTOS is a real-time operating system kernel for microcontrollers and small embedded processors. It is designed for deterministic task scheduling, low memory usage, and predictable interrupt handling. In mobile robotics, FreeRTOS is typically used on low-level control boards rather than on the main computer running ROS 2. Its role is to execute time-critical functions such as motor control, encoder acquisition, power monitoring, watchdog supervision, and sensor sampling.

In a UGV architecture, FreeRTOS usually sits below Linux and ROS 2. A Raspberry Pi, NVIDIA Jetson, or x86 computer handles high-level autonomy, perception, and communication. A microcontroller running FreeRTOS handles hard real-time or near-real-time loops. This separation is common because standard Linux is not a hard real-time operating system, while tasks such as PWM updates, current limiting, and wheel odometry timing often require bounded latency in the range of microseconds to a few milliseconds.

For platforms such as Leo Rover and Raph Rover, FreeRTOS is relevant when a custom carrier board, motor controller, sensor hub, or battery management interface is added to the rover. Leo Rover supports ROS 2 on its Raspberry Pi-based compute unit, but that does not remove the need for deterministic firmware on auxiliary electronics. In practice, FreeRTOS can be used to build the embedded layer that exposes rover hardware to ROS 2 through UART, CAN, USB CDC, or micro-ROS.

How FreeRTOS fits into a mobile robot stack

A UGV usually has at least two computation layers. The high-level layer plans motion and processes perception data. The low-level layer drives actuators and reads hardware signals. FreeRTOS belongs to the second layer.

In this split architecture, the operating system choices map to timing requirements:

ROS 2 on Ubuntu or Debian handles navigation, SLAM, logging, remote access, and visualization.
FreeRTOS on an MCU handles control loops at fixed rates such as 100 Hz, 500 Hz, or 1 kHz.
A transport layer bridges both worlds using custom serial protocols, CAN frames, or DDS-XRCE through micro-ROS.

Typical functions assigned to FreeRTOS in a UGV include:

closed-loop wheel velocity control
quadrature encoder counting
IMU polling over SPI or I2C
battery voltage, current, and temperature monitoring
safety interlocks and emergency stop logic
heartbeat supervision for the main computer

This division is practical on Leo Rover, where the Raspberry Pi may run ROS 2 Humble or newer, while embedded peripherals may need deterministic timing. It is also practical on Raph Rover, especially when higher payload, higher motor power, or more sensor channels increase the complexity of the embedded layer.

Scheduling model and real-time behavior

FreeRTOS uses a priority-based scheduler and can be configured for preemptive scheduling. Tasks are assigned priorities, and the highest-priority ready task executes first. The kernel also provides software timers, queues, semaphores, mutexes, event groups, and stream buffers. For robot firmware, this model is sufficient for many control and acquisition problems if the designer keeps interrupt service routines short and avoids blocking high-priority tasks.

A simplified rover firmware layout may look like this:

1 kHz task – motor PID update and current protection
200 Hz task – IMU read and filtering
50 Hz task – odometry packet assembly
10 Hz task – battery diagnostics and thermal state
asynchronous interrupt handlers – encoders, fault pins, communication RX

The control period can be expressed as:

T = 1 / f

For example:

at 1 kHz, T = 1 ms
at 200 Hz, T = 5 ms
at 50 Hz, T = 20 ms

These values matter because wheel control quality, odometry latency, and communication timeout behavior depend directly on loop frequency and jitter.

FreeRTOS and ROS 2 integration

FreeRTOS is not a ROS 2 replacement. It is usually a companion runtime for embedded nodes or firmware services. In ROS-based mobile robots, there are three common integration patterns.

The first pattern is a custom protocol between the MCU and a ROS 2 node on Linux. The second pattern is CAN-based integration, often with a ROS 2 driver translating CAN frames into topics. The third pattern is micro-ROS, which allows ROS 2-compatible communication on microcontrollers using an RTOS such as FreeRTOS.

With micro-ROS, an MCU application can publish and subscribe to ROS 2 topics through an agent running on the main computer. This is useful when the rover needs a cleaner interface than a proprietary serial bridge.

ros2 run micro_ros_agent micro_ros_agent serial --dev /dev/ttyACM0

A low-level MCU on a rover may publish data equivalent to these ROS interfaces:

sensor_msgs/msg/Imu
sensor_msgs/msg/BatteryState
nav_msgs/msg/Odometry
diagnostic_msgs/msg/DiagnosticArray

When using ROS 2, frame naming and message semantics should remain consistent with standard ROS conventions. For mobile robots, that usually means compatibility with base_link, wheel odometry frames, and sensor frames used by the navigation stack.

Key parameters in a robotics implementation

For engineering work, the term FreeRTOS is only meaningful if timing and resource constraints are defined. The most important parameters are not branding-level features but measurable runtime properties.

Parameter	Typical range in UGV firmware	Why it matters
Control loop rate	100 Hz – 1 kHz	Determines actuator responsiveness and odometry freshness
Task jitter	tens of µs to a few ms	Affects control stability and timestamp quality
UART link rate	115200 – 3000000 baud	Limits telemetry and command throughput
MCU RAM/Flash	device-specific	Limits queue sizes, logging, and middleware footprint
Watchdog timeout	10 ms – 500 ms	Defines fault recovery behavior

On a compact platform such as Leo Rover, resource-efficient firmware is important because auxiliary boards often use modest microcontrollers. On Raph Rover, larger sensor sets or more advanced drive electronics may justify a stronger MCU, but the same timing principles apply.

Example configuration logic

In practice, the FreeRTOS side often exposes a compact hardware interface, while ROS 2 handles parameter management and logging. A simple serial-to-ROS bridge might use a YAML file like this on the Linux computer.

motor_controller:
  port: /dev/ttyUSB0
  baudrate: 1000000
  odom_rate_hz: 50
  imu_rate_hz: 200
  cmd_timeout_ms: 200
  wheel_radius_m: 0.065
  wheel_separation_m: 0.27

This file does not configure FreeRTOS directly. It configures the ROS 2 node that communicates with the MCU firmware. The embedded side still has its own compile-time or non-volatile configuration for timers, interrupts, and safety limits.

Use cases on Leo Rover and Raph Rover

On Leo Rover, FreeRTOS is most useful in custom extensions. Examples include a dedicated motor controller board, a power supervision module, or an environmental sensor hub that must sample at stable rates and survive temporary reboots of the Raspberry Pi. Because Leo Rover is not an autonomous platform out of the box, developers often add their own navigation and sensing stack. A reliable embedded layer helps isolate hardware timing from experimental ROS 2 software.

On Raph Rover, FreeRTOS becomes even more relevant when payload and terrain demands increase. Heavier drives, more aggressive current transients, and broader sensor integration can justify a more structured embedded architecture. The MCU can enforce local safety policies even if the main computer is overloaded by LiDAR processing, SLAM, or camera inference.

Limitations and trade-offs

FreeRTOS solves a specific class of problems. It is not meant for large-scale perception, map optimization, or GPU pipelines. It also does not provide the full process isolation, package management, and developer tooling of Linux. For that reason, a UGV should not move SLAM, Nav2, or dense computer vision workloads into FreeRTOS firmware.

The main trade-off is architectural complexity. Splitting logic between ROS 2 and FreeRTOS improves determinism, but adds interfaces, firmware maintenance, and debugging overhead. Time synchronization, message versioning, and fault-state handling must be designed explicitly.

Normative references and standards

For a technically correct implementation, developers should verify behavior against official ROS and embedded documentation. ROS 2 interface behavior should follow the message definitions and frame conventions used by standard ROS packages. Where micro-ROS is used, the supported transport and middleware path should be checked against the current micro-ROS and ROS 2 distribution documentation.

Useful reference families include:

ROS 2 documentation from docs.ros.org for message definitions, lifecycle, and middleware behavior
REP documents from ros.org/reps for ROS conventions and coordinate frame practices
FreeRTOS kernel documentation for scheduler behavior, API semantics, and memory management models
MCU vendor reference manuals for timer, DMA, interrupt, and watchdog details