RS-485
RS-485 – definition
RS-485 is a physical-layer standard for serial communication over balanced differential signalling. It is formally specified as TIA-485-A (ANSI/TIA/EIA-485-A-1998, since reaffirmed), published by the Telecommunications Industry Association (TIA). The standard defines electrical characteristics of drivers and receivers for multipoint communication. It does not define a packet format, connector, application protocol, or ROS interface, and it does not prescribe a specific operating data rate.
In mobile robotics, RS-485 is commonly used to connect a UGV computer or microcontroller to distributed devices such as motor controllers, battery-management systems, GNSS receivers, IMUs, actuator controllers, and environmental sensors. Its differential signalling provides better noise immunity than single-ended UART links when cables run near motors, DC/DC converters, encoders, or high-current power wiring.
RS-485 is often described as a “serial bus”, but this description needs qualification. The electrical bus can have multiple nodes, while the higher-level protocol must define device addressing, bus access, message framing, checksums, and error handling. Common protocols carried over RS-485 include Modbus RTU, vendor-specific binary protocols, and custom framed UART protocols.
Electrical operation and topology
An RS-485 transmitter drives the voltage difference between two signal conductors. The receiving device evaluates the differential voltage rather than the voltage of either conductor relative to ground. This reduces susceptibility to common-mode electrical noise, although a reference conductor or properly designed isolated interface may still be required.
A typical two-wire RS-485 network is half-duplex. All nodes share one differential pair and only one transmitter should drive the bus at a time. Four-wire RS-485 can support separate transmit and receive pairs, but it is less common for sensor and motor-controller networks on UGV platforms.
| Parameter | RS-485 characteristic | Integration consequence |
|---|---|---|
| Signalling | Balanced differential pair | Use twisted-pair cable for A/B conductors. |
| Topology | Linear multidrop bus | Avoid star wiring and long unterminated branches. |
| Legacy unit loading | Up to 32 unit loads on one bus | Modern transceivers may use fractional unit loads, but protocol timing remains limiting. |
| Maximum rate and distance | Typically represented as 10 Mbit/s at 12 m or 100 kbit/s at 1200 m | Actual limits depend on cable, termination, noise, transceivers, and network layout. |
The common rate-versus-distance figures are engineering reference points rather than guaranteed operating values. Cable impedance, capacitance, stubs, baud rate, and electromagnetic interference determine the practical limit. See the Texas Instruments RS-485 design guide for termination and topology calculations.
Termination, biasing, and signal integrity
A long RS-485 cable behaves as a transmission line. Reflections occur when its characteristic impedance is not matched at the physical ends of the bus. A common implementation places a termination resistor close to each end node. For a 120 Ω twisted-pair cable, 120 Ω termination resistors are commonly used.
Correct termination is only one part of a reliable installation. The following design rules are relevant to mobile robots operating around motors and power electronics.
- Place terminators only at the two physical ends of the main bus, not at every node.
- Keep stubs short. Long branches create reflections and reduce timing margin.
- Use fail-safe biasing when all transmitters can enter a high-impedance state.
- Route RS-485 separately from motor supply cables where possible.
- Use galvanically isolated RS-485 transceivers when ground offsets or power-system noise are expected.
- Verify A/B naming in each device manual. Manufacturers do not always label polarity consistently.
Termination adds a DC load to the transceiver. Two 120 Ω resistors appear as approximately 60 Ω across the differential pair. The selected transceiver must therefore provide sufficient differential output voltage for the installed network.
RS-485 in ROS 2 systems
ROS 2 does not define a standard RS-485 message type or a mandatory serial driver. RS-485 exists below ROS 2, at the electrical transport layer. A Linux serial device such as /dev/ttyUSB0, /dev/ttyACM0, or /dev/ttyAMA0 may be provided by a USB-to-RS-485 adapter or an onboard UART connected to an RS-485 transceiver. A ROS 2 node reads frames, validates them, converts units, and publishes application-level messages.
For example, an IMU gateway may publish sensor_msgs/msg/Imu, while a motor-controller interface may publish nav_msgs/msg/Odometry and subscribe to geometry_msgs/msg/Twist. Message definitions are maintained in the official sensor_msgs and nav_msgs packages.
# Inspect a USB-to-RS-485 adapter
ls -l /dev/ttyUSB*
# Set a temporary UART configuration
stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb
# Run a ROS 2 serial gateway node
ros2 run rover_serial_gateway rs485_bridge --ros-args \
-p port:=/dev/ttyUSB0 -p baudrate:=115200The node must also control transmit-enable direction for half-duplex operation. Some USB-RS-485 adapters handle this automatically. UART-based designs may require hardware RTS control, Linux RS-485 mode, or a dedicated GPIO connected to the transceiver’s driver-enable pin.
Use on Leo Rover and Raph Rover
On Leo Rover, RS-485 is suitable for external payload integration when a sensor or controller provides an RS-485 interface and does not have a directly supported ROS 2 driver. Leo Rover uses a Raspberry Pi-based compute unit and supports ROS 2 Humble or later. An external USB-to-RS-485 adapter is a practical interface when the payload is located away from the onboard computer or requires a robust differential cable connection.
A typical Leo Rover integration can connect an RS-485 IMU, GNSS/RTK receiver, or sensor hub to a ROS 2 bridge node. The bridge should preserve device timestamps when available, timestamp received data otherwise, report frame-validation errors, and publish diagnostics. Serial latency must be considered when fusing measurements with wheel odometry in robot_localization before providing the resulting odometry to a navigation stack.
Raph Rover can use the same architecture for larger payload configurations. Its greater payload capacity can accommodate additional sensor enclosures, isolated power converters, and longer cable runs. This does not remove the need for correct bus termination, grounding, and protocol-level arbitration.
Limitations and protocol considerations
RS-485 does not provide discovery, collision avoidance, encryption, timestamps, or packet integrity. These functions belong to the protocol implemented above the physical layer. A robust UGV integration should define a device address, frame delimiter or length field, CRC, timeout, retry policy, and safe behaviour after communication loss.
RS-485 is also not a replacement for high-bandwidth sensor interfaces. Cameras, 3D LiDARs, and dense point-cloud streams generally require Ethernet or USB because their data rates exceed practical RS-485 throughput. RS-485 is best suited to low-bandwidth telemetry, command channels, and scheduled device control implemented by an appropriate higher-level protocol.