OTTO presents Proton protocol for lightweight embedded robotics communication

A communication gap inside modern robots

Tom Wallis, an engineer from OTTO by Rockwell Automation, presented Proton at ROSCon 2026. The project emerged from a practical challenge encountered by OTTO and Clearpath Robotics by Rockwell Automation: connecting custom embedded boards to modern ROS 2 systems efficiently.

Robots can contain numerous embedded subsystems for drive control, thermal management and sensor integration. These functions are often handled by simple microcontrollers with limited memory and processing power. Such devices still need reliable communication with the rest of the robot, but may not require the full capabilities of DDS, ROS 2 middleware or complex distributed networking stacks.

The teams evaluated technologies including Industrial ROS-native, IOT, CANOpen, Micro-ROS, MQTT, EtherNet/IP, Zenoh Pico, PROFINET, J1939 and Modbus. According to the presentation, each addressed important requirements but introduced trade-offs involving transport dependencies, fixed data structures, complexity or suitability for low-latency internal robot control.

Proton uses signals, bundles and a shared registry

Proton was designed around transport independence, support for Ethernet and serial protocols, possible CAN support in the future, low resource usage and compatibility with ROS 2 ecosystems. Rather than creating a serialization system from scratch, its developers selected Protocol Buffers, or Protobuf, as the foundation.

The protocol uses a simplified data model based on scalar values such as integers, floats, booleans and strings. These values are represented as signals, which can be grouped into bundles. Changes to signals or bundles do not require recompiling the Protobuf message schema.

A central design concept is the signal registry. Participating nodes maintain the most recently received signal values, allowing applications to query the latest IMU readings, wheel speed values, temperature measurements or motor command states. Proton can also alert programs when user-defined bundles are received, supporting an existing message-processing model.

Designed to connect embedded systems with ROS 2

Proton is designed to operate without an RTOS and without knowledge of the underlying hardware. It can be added to an existing embedded system without changing that system's software architecture. The project ships as a standard CMake package and can be installed as a library or as source files. The source says no additional Protobuf dependencies are required.

By default, Proton does not allocate dynamic memory. The source identifies this as potentially valuable for industries with strict software certification requirements, including automotive, aerospace and industrial automation. Compile-time feature flags allow the same core library to support firmware-focused use cases and more capable platforms with runtime signal registry parsing and full C++ ergonomics.

A ROS 2 bridge maps Proton data structures to ROS interfaces. Signals and bundles are defined in YAML, bundles are mapped to ROS message types, and topics are associated with those definitions. Auto-generated plugins translate between Proton and ROS 2 messages, allowing existing ROS topics and messages to continue being used while the embedded device communicates through the simpler protocol.

Tests point to lower resource requirements

To evaluate Proton, the presenter used an ESP32 development board with simulated IMU data running at 100 Hz. The protocol was compared with micro-ROS, Zenoh Pico and EtherNet/IP using measures including library size, static memory usage and network bandwidth consumption.

According to the presented results, Proton was approximately 12× smaller than the next-largest protocol implementation tested, roughly 30× smaller than micro-ROS and used about 22× less static RAM. The source also reports zero dynamic memory allocation for Proton, while all other tested middlewares required dynamic memory allocation.

These results support Proton's intended role as a communication layer for small embedded devices that need to participate in ROS 2-based robotic systems. For developers working with custom boards, the project offers a way to retain ROS 2 integration while limiting the software and memory demands placed on the embedded hardware.