Raspberry Pi

Raspberry Pi – definition

Raspberry Pi is a family of single-board computers developed by Raspberry Pi Ltd. In mobile robotics, it is commonly used as an onboard computer for running Linux, ROS 2 nodes, sensor drivers, communication services, and application-specific control software. It is not a real-time motion controller by default. Deterministic motor control, encoder counting, and safety functions should be delegated to a dedicated microcontroller or motor controller where required.

On a UGV, a Raspberry Pi typically sits between low-level hardware and high-level autonomy software. It receives odometry, inertial, camera, LiDAR, or GNSS data; publishes ROS 2 topics; runs localization or navigation nodes; and sends velocity commands to the mobile base. This architecture applies directly to Leo Rover, which uses a Raspberry Pi as its default onboard compute unit and supports ROS 2 Humble or newer distributions.

Raspberry Pi boards use ARM-based system-on-chip devices and run Linux distributions such as Raspberry Pi OS or Ubuntu. ROS 2 deployments on these boards normally use the 64-bit ARM architecture (aarch64 or arm64). ROS 2 Humble Hawksbill targets Ubuntu 22.04 on arm64 as a Tier 1 platform according to REP 2000. Source: ROS REP 2000.

Raspberry Pi as an onboard computer for UGVs

A Raspberry Pi is usually responsible for computation and connectivity, not direct power switching. In a differential-drive robot, the software pipeline commonly converts a ROS 2 geometry_msgs/msg/Twist command into left and right wheel velocity targets. A motor controller then applies closed-loop motor control using encoder feedback.

For Leo Rover, this separation is important. The platform has four wheels and differential-drive kinematics. The Raspberry Pi can run the ROS 2 interface, teleoperation, mapping, and navigation layers, while the rover’s embedded electronics handle low-level drivetrain communication. Leo Rover is rated IP55, but the Raspberry Pi itself and attached USB peripherals must still be installed in a protected enclosure. Source: Leo Rover technical documentation.

A typical Raspberry Pi-based UGV software stack includes the following components:

ROS 2 middleware and application nodes.
Base-driver nodes publishing wheel odometry and robot status.
Sensor drivers for USB, Ethernet, UART, I2C, SPI, or GPIO-connected devices.
Localization, SLAM, or Nav2 nodes where compute resources permit.
Remote access services, including SSH, ROS 2 networking, and telemetry bridges.

Hardware interfaces and key specifications

Raspberry Pi boards provide standard interfaces relevant to robotics integration. The exact availability depends on the board generation, carrier board, operating system, and enabled kernel overlays. GPIO pins operate at 3.3 V logic levels. Connecting a 5 V logic output directly to a GPIO input can damage the board, so level shifting is required for incompatible devices. Source: Raspberry Pi documentation.

Interface	Typical UGV use	Integration note
USB	LiDAR, depth camera, Wi-Fi adapter, SSD	Check power budget and Linux driver support.
Ethernet	Network LiDAR, industrial camera, remote workstation	Useful for stable ROS 2 DDS communication.
UART	GNSS/RTK receiver, microcontroller, motor controller	Verify baud rate, voltage level, and serial device permissions.
I2C / SPI	IMU, environmental sensors, expansion boards	Suitable for short internal connections, not long unshielded cables.
GPIO	Triggers, status signals, simple digital inputs	Not a substitute for a safety-rated control interface.

For reference, Raspberry Pi 4 Model B uses a quad-core Arm Cortex-A72 processor clocked at 1.5 GHz and is available with up to 8 GB RAM. Raspberry Pi 5 uses a quad-core Arm Cortex-A76 processor clocked at 2.4 GHz and supports up to 16 GB RAM. These specifications affect build time, image-processing throughput, and the number of concurrent ROS 2 nodes. Source: Raspberry Pi 4 specifications; Source: Raspberry Pi 5 specifications.

Using Raspberry Pi with ROS 2

ROS 2 uses DDS-based middleware for communication between nodes. A Raspberry Pi can publish sensor data, subscribe to control commands, and expose services or actions in the same way as an x86 Linux computer. Resource limits become relevant when processing dense point clouds, high-resolution image streams, or computationally expensive visual SLAM pipelines.

The following commands verify the ROS 2 distribution and list active topics on a Leo Rover network:

printenv ROS_DISTRO
ros2 topic list
ros2 topic echo /odom
ros2 topic hz /scan

For mobile navigation, common interfaces include sensor_msgs/msg/LaserScan for planar LiDAR, sensor_msgs/msg/Imu for inertial data, nav_msgs/msg/Odometry for wheel odometry, and geometry_msgs/msg/Twist for velocity commands. Coordinate frames should follow ROS conventions defined by REP 103, including metres as the default length unit and radians as the default angular unit. Source: ROS REP 103.

Practical use on Leo Rover and Raph Rover

On Leo Rover, the built-in Raspberry Pi is suitable for ROS 2 education, teleoperation, sensor integration, mapping experiments, and moderate-complexity navigation workloads. Autonomous operation is not enabled by the platform alone. It requires an integrated sensor set, calibrated transforms, localization or SLAM software, obstacle handling, and validated velocity limits.

Raph Rover can carry larger payloads and may require a more capable compute architecture when operating multiple cameras, 3D LiDAR, RTK GNSS, or GPU-accelerated perception. A Raspberry Pi can still act as an auxiliary computer for telemetry, sensor gateway tasks, or distributed ROS 2 nodes. Compute selection should be based on measured CPU load, memory use, thermal behaviour, storage reliability, and sensor bandwidth.

Limitations and engineering considerations

Linux on Raspberry Pi is not a hard real-time operating environment in its default configuration. Timing jitter can affect software PWM, high-rate control loops, and timestamp-sensitive sensor fusion. Use hardware timestamps where supported and move time-critical functions to dedicated embedded hardware.

Mobile deployments should also address the following engineering constraints:

Use a regulated power supply sized for board, storage, sensors, and transient load.
Prevent abrupt filesystem corruption by implementing controlled shutdown or read-only deployment strategies.
Use active cooling when sustained CPU load causes thermal throttling.
Synchronize clocks across distributed computers with NTP, Chrony, or PTP where sensor timestamp accuracy is required.
Validate USB bandwidth and power consumption before combining depth cameras, LiDAR, and external SSD storage.