Glossary

Fictionlab > Glossary > Microcontroller (MCU)

Microcontroller (MCU)

Microcontroller (MCU) – definition

A microcontroller unit (MCU) is an integrated circuit designed to execute embedded control software. It typically combines one or more processor cores, volatile memory, non-volatile program memory, timers, communication peripherals, and general-purpose input/output (GPIO) pins in one device. In mobile robotics, an MCU is commonly responsible for deterministic low-level functions that can operate independently of the main computer.

On an unmanned ground vehicle (UGV), the MCU usually sits below the Linux computer in the control hierarchy. It reads encoders, samples safety-related digital inputs, generates motor-control signals, monitors battery data, and exchanges commands or telemetry with a higher-level computer. The higher-level computer can run ROS 2, navigation, perception, and mapping workloads. The MCU executes firmware with tighter timing constraints and direct access to electrical interfaces.

Leo Rover uses a Raspberry Pi as its default onboard compute unit and can be used with ROS 2 distributions supported by its software image and documentation. Its embedded motor-control electronics provide the interface between ROS-level velocity commands and the differential-drive chassis. Raph Rover follows the same general architecture for larger payload-oriented mobile robotics systems: a host computer handles high-level software, while embedded controllers provide real-time access to actuators and low-level sensors.

MCU role in a mobile robot control stack

An MCU is not a replacement for a ROS 2 computer. It is a component for tasks where predictable execution, separation from application software, or direct peripheral access is required. A Linux process can be delayed by scheduling, I/O activity, or compute-heavy perception workloads. Firmware running on a dedicated MCU can maintain motor feedback and watchdog handling even when the host is busy.

In a typical UGV architecture, responsibilities are split between the embedded controller and the ROS 2 host as follows:

  • MCU firmware: wheel encoder counting, PWM or motor-driver control, current or voltage monitoring, safety-related input monitoring, odometry primitives, watchdogs, and CAN, UART, I2C, SPI, or RS-485 communication.
  • ROS 2 host: publishing geometry_msgs/msg/Twist, consuming odometry, running robot_localization, Nav2, SLAM, sensor drivers, logging, and remote visualization.
  • Safety functions: command timeout, motor disable logic, fault-state reporting, and recovery behavior should be implemented close to the motor driver where practical. Functions requiring a safety rating require an appropriate system-level safety design and should not rely solely on general-purpose MCU firmware.

For a differential-drive UGV, the host commonly sends linear velocity v and angular velocity ω. The controller converts these values into left and right wheel velocities:

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

The MCU can then close a speed-control loop using encoder feedback. This separates wheel-level control from the ROS 2 navigation stack, which works with robot-frame velocity commands and estimated poses.

Key MCU parameters for UGV integration

MCU selection should be based on interfaces, timing requirements, electrical design, and available firmware tooling. Clock frequency alone is not a sufficient selection criterion. A controller with hardware encoder timers and robust communication peripherals may be more appropriate than a faster device with limited timer resources.

Parameter Why it matters on a UGV Typical use
GPIO and interrupt capability Supports limit switches, safety-related input lines, and encoder signals. Quadrature encoder edge detection.
Hardware timers / PWM Provides stable motor-control output and periodic control-loop scheduling. H-bridge enable and PWM duty-cycle control.
UART, CAN, SPI, I2C Determines integration options with the host computer and peripherals. UART telemetry, CAN motor drivers, SPI IMUs.
ADC resolution and reference design Affects battery-voltage, current, and analog sensor measurement quality. Power-state monitoring.
Flash and RAM capacity Limits firmware size, buffering, diagnostics, and middleware support. micro-ROS client applications.
Watchdog timer Allows recovery from firmware stalls or communication failures. Triggering a defined motor-safe state after a firmware fault.

Encoder sampling and motor-control rates depend on drivetrain dynamics, encoder resolution, and controller design. These values must be configured and validated against the motor-driver and encoder specifications. They should not be inferred from the ROS 2 publish rate alone.

MCUs and ROS 2

ROS 2 nodes commonly run on a full operating system such as Linux. A constrained MCU can participate in a ROS 2 system through micro-ROS, a framework intended for microcontrollers and based on ROS 2 client-library concepts. micro-ROS uses the eProsima Micro XRCE-DDS protocol between an MCU client and a Micro XRCE-DDS Agent running on a more capable machine.

This design allows firmware to publish or subscribe to selected ROS 2 interfaces without placing a conventional DDS implementation on the MCU. The agent bridges the embedded transport, such as serial or UDP, to the ROS 2 DDS network.

# Example: start a micro-ROS serial agent on the ROS 2 host
ros2 run micro_ros_agent micro_ros_agent serial --dev /dev/ttyACM0 -b 115200

A low-level controller may subscribe to a velocity command and publish wheel odometry. The message contract must be explicit. For example, geometry_msgs/msg/Twist represents requested body velocity, while nav_msgs/msg/Odometry carries pose and twist estimates with frame information and covariance fields.

controller_bridge:
  ros__parameters:
    cmd_vel_timeout_ms: 500
    publish_odometry: true
    base_frame_id: base_link
    odom_frame_id: odom

The 500 ms value in this example is a configuration example, not a platform specification. Timeout values must be verified through safety testing and matched to the robot’s stopping distance, motor-driver behavior, and operating environment.

Practical integration on Leo Rover and Raph Rover

For Leo Rover, an external MCU can be useful when a project requires custom payload control that should not depend on the Raspberry Pi application layer. Examples include a sensor mast, a dedicated power-monitoring board, a custom CAN device, or a synchronized trigger interface for experimental sensors. The MCU should communicate through a documented interface and should not bypass the rover’s intended motor-control and safety architecture.

On Raph Rover, a dedicated MCU can serve additional payload hardware that requires more I/O, higher electrical power handling, or separate real-time control. This is relevant for field instrumentation, inspection payloads, agricultural sensing modules, and research prototypes. The MCU does not provide autonomy by itself. Autonomous operation also requires host-side localization, perception, and navigation software, as well as an appropriate system-level safety design.

Standards, documentation, and implementation references

ROS 2 interface design should follow ROS Enhancement Proposals where applicable. REP 103 defines standard units and coordinate conventions used in ROS, including meters, radians, and right-handed coordinate frames. REP 105 defines commonly used mobile-robot coordinate frames, including map, odom, and base_link. These conventions are important when MCU-derived odometry is fused with IMU, GNSS, or LiDAR localization data.

See also