UART

UART – definition

UART stands for Universal Asynchronous Receiver-Transmitter. It is a hardware peripheral or IP block that transmits and receives serial data without a shared clock signal. A UART converts parallel bytes used by a processor or microcontroller into a serial bit stream on a transmit line (TX), and reconstructs received bytes from a receive line (RX).

In mobile robotics, UART is commonly used for low-level communication between a robot computer and peripherals such as motor controllers, GNSS/RTK receivers, IMUs, LiDAR modules, radio modems, battery-management systems, and microcontrollers. UART is a transport interface. It does not define an application protocol, a ROS message type, or a navigation algorithm.

A conventional asynchronous UART frame contains a start bit, data bits, an optional parity bit, and one or more stop bits. Both endpoints must use compatible settings. The receiver derives timing from the transition at the start bit and samples the incoming signal according to the configured baud rate.

UART should not be confused with RS-232, RS-422, or RS-485. UART describes framing and byte transmission. RS-232, RS-422, and RS-485 define electrical signalling characteristics. A Raspberry Pi GPIO UART, for example, normally uses 3.3 V logic-level signals and is not directly compatible with the voltage levels defined by RS-232.

UART framing and key parameters

UART communication is configured independently at both endpoints. A configuration is often written as 8N1, meaning eight data bits, no parity bit, and one stop bit. The selected settings determine the frame length and the maximum theoretical payload throughput.

Parameter	Description	Practical relevance for UGV integration
Baud rate	Configured signalling rate in symbols per second.	Must support the sensor output rate and message size.
Data bits	Usually 7 or 8 bits per character.	Most embedded binary protocols use 8-bit bytes.
Parity	Optional per-character error-detection bit.	May be required by legacy GNSS or industrial devices.
Stop bits	One or more bits marking the end of a frame.	Both devices must use the same setting.
Flow control	Hardware RTS/CTS or software XON/XOFF control.	Reduces receive-buffer overruns on high-rate streams.

For an 8N1 configuration, each payload byte occupies ten transmitted bits: one start bit, eight data bits, and one stop bit. The theoretical payload rate is therefore:

payload_bytes_per_second = baud_rate / 10

At 115200 baud, the theoretical 8N1 payload limit is 11,520 bytes/s. Protocol headers, checksums, delimiters, retransmissions, and operating-system scheduling reduce the usable application throughput. The calculation follows directly from asynchronous serial framing described in the UART documentation for common embedded controllers.

Electrical layers and wiring

A reliable UART link requires compatible logic levels, a common signal reference, and crossed data lines. TX on one device connects to RX on the other device. Connecting two TX outputs together can cause contention and may damage hardware.

TTL or CMOS UART commonly uses 3.3 V or 5 V logic levels.
RS-232 uses voltage levels and polarity that differ from logic-level UART.
RS-485 commonly carries UART-framed data over a differential physical layer and is useful where cable length or electrical noise is significant.
UART itself has no mandatory connector, packet format, device discovery mechanism, or bus arbitration.

On Raspberry Pi computers, GPIO UART interfaces are exposed through GPIO pins, while the exact UART instance and pin configuration depend on the board and operating-system configuration. Raspberry Pi documentation identifies GPIO 14 as TXD and GPIO 15 as RXD for the primary UART pin assignment. GPIO pins use 3.3 V logic and are not 5 V tolerant.

For field robots, unshielded UART wiring can be affected by motor noise, ground potential differences, and electromagnetic interference. A USB-to-UART adapter may simplify development, but USB is not UART. Such adapters contain a bridge chip that exposes a UART interface as a USB serial device, often appearing in Linux as /dev/ttyUSB0. USB CDC serial devices commonly appear as /dev/ttyACM0.

UART in ROS 2 systems

ROS 2 does not define a universal UART message type or a standard serial protocol. ROS 2 nodes normally convert bytes received from a UART device into typed ROS messages, then publish them to topics. The message type depends on the payload: IMU data may become sensor_msgs/msg/Imu, GNSS fixes may become sensor_msgs/msg/NavSatFix, and wheel-controller feedback may become nav_msgs/msg/Odometry.

ROS 2 commonly uses DDS-based middleware communication between nodes. UART is typically below that layer. A serial driver node owns the Linux device, parses the peripheral protocol, validates checksums, timestamps measurements, and publishes ROS 2 data.

# Inspect a USB-to-UART device and configure 115200 baud, 8N1
ls -l /dev/ttyUSB*
stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb -ixon -ixoff

Before using a serial port from a ROS 2 node, permissions must be configured correctly. On many Linux distributions, access to serial devices is granted through groups such as dialout. The actual group and device path are system-dependent.

UART on Leo Rover and Raph Rover

On Leo Rover, UART is relevant when integrating peripherals with the built-in Raspberry Pi compute unit. Typical examples include a GNSS receiver providing NMEA or vendor-specific binary frames, an IMU connected to GPIO UART pins, or a microcontroller that exposes encoder, power, or custom sensor data. Leo Rover can be used with ROS 2, but the supported ROS 2 distribution depends on the installed operating system and Leo Rover software version. Autonomous navigation requires a separately integrated perception, localisation, and navigation stack.

A robust Leo Rover integration separates transport from robotics logic. The serial node should parse device-specific frames and publish timestamped ROS 2 messages. Navigation, sensor fusion, and logging nodes should consume those messages rather than directly accessing /dev/tty*.

Raph Rover can use the same architecture for larger payloads and field sensor packages. Where a sensor is mounted far from the main computer or operates near high-current drive wiring, RS-485 or Ethernet may be more appropriate than direct logic-level UART. The decision depends on cable routing, electrical environment, update rate, protocol support, and required fault tolerance.

UART limitations in mobile robotics

UART is simple and widely supported, but it has constraints that affect UGV system design. It is normally point-to-point, has no inherent device discovery, and does not provide the clock synchronisation required for precise multi-sensor timestamping. Application protocols must define packet boundaries, checksums, sequence numbers, error handling, and device configuration.

UART bandwidth can also limit perception payloads. It is suitable for compact telemetry, IMU output, GNSS data, and controller commands. It is generally unsuitable for raw depth images, high-resolution camera streams, or dense LiDAR point clouds, which are commonly transported through USB, Ethernet, or dedicated interfaces.

Normative references and technical documentation

The following primary documentation provides implementation-level references for UART and ROS 2 serial integrations.