Single-board computer (SBC)

Single-board computer – definition

A single-board computer (SBC) is a complete computer implemented on one printed circuit board. It typically combines a processor, memory, storage interfaces, power-management circuitry, network interfaces, and general-purpose input/output (GPIO). Unlike a microcontroller, an SBC normally runs a general-purpose operating system such as Linux and can execute multi-process robotics software, middleware, drivers, and development tools.

In mobile robotics, an SBC is commonly the high-level compute unit of an unmanned ground vehicle (UGV). It runs ROS 2 nodes, processes sensor data, publishes robot state, executes navigation software, and communicates with motor controllers or dedicated microcontroller-based hardware. On Leo Rover, the default embedded compute unit is a Raspberry Pi, while Raph Rover can accommodate a larger compute configuration when the payload or perception workload requires it.

An SBC is not equivalent to a motor controller. Real-time wheel control, encoder counting, safety interlocks, and low-level communication may run on a microcontroller. The SBC operates at a higher software layer and exchanges commands and feedback with that hardware through serial, USB, Ethernet, CAN, or another supported interface.

Role of an SBC in a ROS 2 UGV

ROS 2 software is distributed as nodes that communicate through topics, services, actions, and parameters. The SBC provides the Linux environment in which these processes run. It also hosts the ROS 2 middleware implementation, usually based on DDS.

For a differential-drive UGV such as Leo Rover, a typical SBC deployment includes the following functions:

Publishing robot velocity commands through geometry_msgs/msg/Twist on /cmd_vel.
Receiving wheel odometry and publishing nav_msgs/msg/Odometry.
Maintaining coordinate transforms through tf2, commonly map → odom → base_link.
Acquiring LiDAR, camera, IMU, GPS, or RTK receiver data through device drivers.
Running localisation, mapping, obstacle detection, and path-planning nodes.
Recording datasets with ros2 bag for repeatable testing and offline analysis.

ROS 2 distributions define supported target platforms through REP 2000. ROS 2 Humble Hawksbill is documented as a long-term support distribution, and its target platforms include Ubuntu 22.04 on 64-bit ARM (arm64), which is relevant to Raspberry Pi-based deployments. Source: ROS REP 2000.

Key SBC parameters for mobile robotics

SBC selection should be based on the computational pipeline, not only on processor clock frequency. A UGV that publishes wheel odometry and reads a 2D LiDAR has different requirements from a platform running stereo depth estimation, visual-inertial odometry, and neural-network inference.

Parameter	Why it matters on a UGV	Typical software impact
CPU architecture and core count	Determines capacity for concurrent ROS 2 nodes, drivers, planning, logging, and system services.	Limits callback processing latency and map or costmap update throughput.
RAM capacity	Defines the practical size of occupancy grids, point clouds, image buffers, containers, and rosbag caches.	Insufficient memory can cause swapping, process termination, or unstable timing.
GPU or AI accelerator	Useful for CUDA-enabled perception, semantic segmentation, object detection, and dense depth processing.	Can reduce CPU load, but requires compatible drivers and software builds.
USB and Ethernet interfaces	Determine how LiDARs, RGB-D cameras, GNSS receivers, and external computers are connected.	Shared bus bandwidth can affect image or point-cloud acquisition.
Storage type and endurance	Important for OS reliability and recording sensor datasets in field tests.	Impacts boot reliability and rosbag write performance.
Power and thermal design	Mobile platforms operate from batteries and may be enclosed or exposed to warm environments.	Thermal throttling can change execution timing during long runs.

The required processing rate depends on the complete data path. If a camera publishes images at frequency f and each uncompressed frame has size S, the approximate payload rate is:

data_rate = f × S

For image streams, S depends on resolution, pixel format, and encoding. ROS image data is represented by sensor_msgs/msg/Image, whose definition includes image height, width, encoding, row step, and byte data. Source: ROS 2 sensor_msgs/Image message definition.

SBC integration on Leo Rover and Raph Rover

Leo Rover uses a Raspberry Pi as its default onboard compute unit and supports ROS 2. Supported ROS 2 distributions depend on the installed system image and the available platform software release. Its four-wheel differential-drive base requires a navigation stack to be integrated separately for autonomous operation. The onboard SBC can run the base driver, teleoperation, robot-state publication, sensor drivers, and selected perception nodes. Platform-specific interfaces and supported software are documented by Fictionlab. Source: Leo Rover technical documentation.

A practical Leo Rover configuration may keep low-bandwidth control and basic localisation on the onboard Raspberry Pi, while offloading heavy workloads to an external computer when required. Examples include dense point-cloud processing, large visual models, or GPU-specific inference pipelines. This separation is useful when the robot must preserve stable control communication while experimental perception software is iterated.

# Inspect the ROS 2 graph on the SBC
ros2 node list
ros2 topic list
ros2 topic hz /odom
ros2 topic echo /cmd_vel

Raph Rover is intended for larger payloads and applications requiring more onboard capacity. An SBC or embedded GPU computer on Raph Rover can be selected around sensor interfaces, power budget, environmental constraints, and the expected ROS 2 workload. A larger platform does not automatically require a more powerful computer. The compute configuration should be derived from measured CPU load, memory use, message rates, and thermal behaviour during representative runs.

Operating system, containers, and reproducibility

Most ROS 2 SBC deployments use Ubuntu Linux because binary packages, build tools, and vendor drivers are commonly distributed for it. Containers can isolate a ROS 2 workspace from the host operating system and make builds reproducible across development machines and robots. Hardware access still requires explicit handling of devices such as serial ports, USB cameras, GPIO, and network interfaces.

services:
  robot:
    image: ros:humble-ros-base
    network_mode: host
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
    volumes:
      - ./ws:/ws
    command: bash -c "cd /ws && colcon build && source install/setup.bash && ros2 launch robot_bringup base.launch.py"

For ROS 2, container networking must also be tested with the selected DDS implementation and network topology. Discovery behaviour can differ between wired Ethernet, Wi-Fi, VLANs, and multi-robot deployments.

Limitations and engineering trade-offs

An SBC offers flexibility, but it does not provide deterministic hard real-time behaviour by default. Linux scheduling, device-driver latency, storage activity, and CPU contention can affect application timing. Time-critical low-level control should therefore remain on hardware designed for that function, while the SBC manages high-level autonomy and integration.

Compute selection also involves a trade-off between performance, electrical power, heat generation, physical size, and software support. A board with an accelerator may be appropriate for computer vision, but only if the required ROS 2 packages, kernel drivers, and model runtime support the selected architecture.