SPI

SPI – definition

SPI, short for Serial Peripheral Interface, is a synchronous serial communication bus used to connect a computing unit with peripheral devices over short distances on a circuit board or through a wiring harness. In mobile robotics, SPI commonly connects embedded computers or microcontrollers to inertial measurement units, analog-to-digital converters, motor-control electronics, encoders, digital-to-analog converters, radio modules, and some LiDAR or environmental sensors.

SPI is a controller-peripheral bus. The controller generates the clock and initiates transfers. A peripheral responds when selected through an individual chip-select signal. The traditional signal set contains SCLK (serial clock), MOSI (controller output, peripheral input), MISO (controller input, peripheral output), and CS or SS (chip select). Unlike UART, SPI does not use start and stop bits. Unlike I²C, standard SPI has no mandatory addressing or electrical arbitration mechanism. Each peripheral is normally selected by a separate CS line.

On a UGV, SPI is usually a board-level interface rather than a network interface. It is appropriate for low-latency exchange with directly attached electronics. It is not a replacement for Ethernet, CAN, USB, or ROS 2 middleware communication between distributed robot computers.

SPI signals, modes, and transfer model

An SPI controller shifts bits on clock edges while the selected peripheral samples and returns data. A full-duplex transfer sends and receives one bit per clock cycle. Read operations often require the controller to transmit dummy bytes while receiving sensor data on MISO.

The clock polarity (CPOL) and clock phase (CPHA) define four conventional SPI modes. The required mode is specified by the peripheral datasheet and must match the software configuration.

SPI mode	CPOL	CPHA	Clock idle level
0	0	0	Low
1	0	1	Low
2	1	0	High
3	1	1	High

SPI throughput depends on the configured clock frequency, protocol overhead, operating-system scheduling, and the peripheral’s timing limits. The theoretical payload bit rate is approximately equal to the clock rate for single-bit SPI:

payload_rate ≈ SCLK frequency [bit/s]

This expression excludes command bytes, register addresses, chip-select timing, retries, and software latency. A sensor datasheet remains the authoritative source for maximum clock frequency, setup time, hold time, logic voltage, and required transaction sequence.

SPI in Linux and ROS 2

Linux can expose SPI devices through the spidev userspace interface. A device is commonly represented as /dev/spidev<bus>.<chip_select>. Applications configure mode, bit order, bits per word, and maximum clock speed through ioctl calls defined by the Linux SPI userspace API.

ROS 2 does not define a standard SPI topic type, SPI driver API, or REP dedicated to SPI transport. SPI is below the ROS graph. A ROS 2 node normally reads the peripheral through a Linux driver or a userspace SPI library, converts raw registers into engineering units, and publishes standard ROS messages.

Typical message mappings include the following.

sensor_msgs/msg/Imu for angular velocity, linear acceleration, and orientation data.
sensor_msgs/msg/MagneticField for a magnetometer connected through an IMU board.
sensor_msgs/msg/Range for a supported single-beam range sensor.
sensor_msgs/msg/JointState or custom messages for encoder-derived wheel measurements.

For ROS 2 systems, sensor timestamps should use the clock at acquisition as closely as practical. If an SPI transaction is performed in a non-real-time Linux userspace process, timestamp jitter can be introduced by scheduling and bus contention. This matters when IMU data is fused with wheel odometry, GNSS, or camera data using packages such as robot_localization.

# Inspect available SPI character devices
ls -l /dev/spidev*

# Example: verify ROS 2 IMU messages after starting a driver node
ros2 topic echo /imu/data --once
ros2 topic hz /imu/data

SPI integration on Leo Rover and Raph Rover

Leo Rover uses an onboard Raspberry Pi compute unit and can run ROS 2 distributions supported by its software image. SPI can be used when an additional sensor or controller is connected to a compatible Raspberry Pi GPIO SPI interface and the required interface is enabled in the operating system. The physical connection must respect GPIO electrical limits and the logic-level requirements in both hardware specifications.

A practical Leo Rover use case is an SPI IMU mounted close to the rover frame. The driver node can publish sensor_msgs/msg/Imu, while wheel odometry is supplied by the rover base interface. The data can then be fused before being consumed by a navigation stack. This does not make Leo Rover autonomous by itself. Localization, obstacle sensing, map data, and a configured ROS 2 navigation stack are still required.

For Raph Rover payload assemblies, SPI remains suitable for local sensor boards inside the payload enclosure, but cable length, electromagnetic interference, and grounding become more significant as wiring distances increase. For remote sensors, CAN, Ethernet, or RS-485 may be more robust choices because SPI was designed primarily for short interconnects.

Hardware and electrical constraints

SPI does not define a universal connector, cable length, voltage level, or hot-plug behavior. These aspects are implementation-specific. A valid integration therefore requires checking the compute board documentation, peripheral datasheet, and wiring design rather than relying only on the SPI protocol name.

The following checks are essential before connecting an SPI payload to a rover.

Confirm the logic level. Raspberry Pi GPIO uses 3.3 V logic and is not 5 V tolerant according to Raspberry Pi documentation.
Confirm that MISO is not driven by more than one selected device at a time.
Use a dedicated chip-select line for each peripheral unless the hardware implements another validated selection scheme.
Set CPOL, CPHA, bit order, word length, and clock frequency from the peripheral datasheet.
Keep unbuffered SPI wiring short and provide a common ground between the compute unit and peripheral.
Validate behavior during rover motor operation, because switching noise can affect power integrity and signal quality.

SPI limitations in mobile robotics

SPI is efficient for local peripherals, but it has limitations that affect UGV integration. It has no built-in device discovery, no standard error recovery protocol, and no mandatory message-level checksum. Software must detect invalid register values, timeouts, stale samples, and sensor self-test failures where supported by the device.

SPI also does not provide clock synchronization between independent computers. If a sensor is attached to a separate microcontroller, the ROS 2 computer receives data after firmware buffering and transport delay. The driver should document the timestamp source and latency assumptions, especially for state estimation and perception pipelines.

Normative and technical references

The following primary documentation defines the relevant operating-system and ROS interfaces. Peripheral-specific timing and register behavior must always be taken from the manufacturer’s datasheet.

SPI