OTTO stellt Proton-Protokoll für die Kommunikation in kompakten Robotersystemen vor

Eine Kommunikationslücke in modernen Robotern

Tom Wallis, Ingenieur bei OTTO von Rockwell Automation, stellte Proton auf der ROSCon 2026 vor. Das Projekt entstand aus einer praktischen Herausforderung bei OTTO und Clearpath Robotics von Rockwell Automation: kundenspezifische Embedded-Boards effizient mit modernen ROS-2-Systemen zu verbinden.

Roboter können zahlreiche eingebettete Subsysteme für Antriebssteuerung, Wärmemanagement und Sensorintegration enthalten. Diese Funktionen werden häufig von einfachen Mikrocontrollern mit begrenztem Speicher und begrenzter Rechenleistung übernommen. Solche Geräte benötigen weiterhin eine zuverlässige Kommunikation mit dem restlichen Roboter, brauchen möglicherweise aber nicht die vollständigen Fähigkeiten von DDS, der ROS-2-Middleware oder komplexen verteilten Netzwerkstacks.

Die Teams untersuchten unter anderem Industrial ROS-native, IOT, CANOpen, Micro-ROS, MQTT, EtherNet/IP, Zenoh Pico, PROFINET, J1939 und Modbus. Laut der Präsentation erfüllten alle Technologien wichtige Anforderungen, brachten jedoch Zielkonflikte mit sich, etwa bei Transportabhängigkeiten, festen Datenstrukturen, Komplexität oder der Eignung für die latenzarme interne Robotersteuerung.

Proton setzt auf Signale, Bundles und eine gemeinsame Registry

Proton wurde auf Transportunabhängigkeit, die Unterstützung von Ethernet- und seriellen Protokollen, eine mögliche CAN-Unterstützung in der Zukunft, einen geringen Ressourcenbedarf und die Kompatibilität mit ROS-2-Ökosystemen ausgelegt. Statt ein Serialisierungssystem von Grund auf neu zu entwickeln, wählten die Entwickler Protocol Buffers beziehungsweise Protobuf als Grundlage.

Das Protokoll verwendet ein vereinfachtes Datenmodell auf Basis von skalaren Werten wie Ganzzahlen, Gleitkommazahlen, booleschen Werten und Zeichenketten. Diese Werte werden als Signale dargestellt, die sich zu Bundles gruppieren lassen. Änderungen an Signalen oder Bundles erfordern keine Neukompilierung des Protobuf-Nachrichtenschemas.

Ein zentrales Designkonzept ist die Signal-Registry. Beteiligte Knoten halten die zuletzt empfangenen Signalwerte vor. Dadurch können Anwendungen die neuesten IMU-Messwerte, Radgeschwindigkeiten, Temperaturmessungen oder Zustände von Motorbefehlen abfragen. Proton kann Programme außerdem benachrichtigen, wenn benutzerdefinierte Bundles empfangen werden, und so ein bestehendes Modell zur Nachrichtenverarbeitung unterstützen.

Entwickelt für die Verbindung eingebetteter Systeme mit ROS 2

Proton ist dafür ausgelegt, ohne ein RTOS und ohne Kenntnisse der zugrunde liegenden Hardware zu arbeiten. Es kann in ein bestehendes eingebettetes System integriert werden, ohne dessen Softwarearchitektur zu verändern. Das Projekt wird als standardmäßiges CMake-Paket bereitgestellt und kann als Bibliothek oder als Quelldateien installiert werden. Laut Quelle sind keine zusätzlichen Protobuf-Abhängigkeiten erforderlich.

Standardmäßig reserviert Proton keinen dynamischen Speicher. Die Quelle bezeichnet dies als potenziell wertvoll für Branchen mit strengen Anforderungen an die Softwarezertifizierung, darunter die Automobilindustrie, die Luft- und Raumfahrt sowie die industrielle Automatisierung. Zur Kompilierungszeit gesetzte Feature-Flags ermöglichen es, dieselbe Kernbibliothek sowohl für Firmware-orientierte Anwendungsfälle als auch für leistungsfähigere Plattformen mit dem Parsen der Signal-Registry zur Laufzeit und vollständigen C++-Möglichkeiten zu verwenden.

Eine ROS-2-Bridge bildet Proton-Datenstrukturen auf ROS-Schnittstellen ab. Signale und Bundles werden in YAML definiert, Bundles ROS-Nachrichtentypen zugeordnet und Topics mit diesen Definitionen verknüpft. Automatisch generierte Plugins übersetzen zwischen Proton- und ROS-2-Nachrichten. Dadurch können vorhandene ROS-Topics und -Nachrichten weiter genutzt werden, während das eingebettete Gerät über das einfachere Protokoll kommuniziert.

Tests deuten auf geringeren Ressourcenbedarf hin

Zur Bewertung von Proton verwendete der Referent ein ESP32-Entwicklungsboard mit simulierten IMU-Daten, die mit 100 Hz ausgeführt wurden. Das Protokoll wurde anhand von Faktoren wie Bibliotheksgröße, statischem Speicherbedarf und Netzwerkbandbreite mit micro-ROS, Zenoh Pico und EtherNet/IP verglichen.

Den vorgestellten Ergebnissen zufolge war Proton ungefähr 12-mal kleiner als die nächstgrößte getestete Protokollimplementierung, etwa 30-mal kleiner als micro-ROS und benötigte rund 22-mal weniger statischen RAM. Die Quelle berichtet außerdem, dass Proton keinen dynamischen Speicher alloziert, während alle anderen getesteten Middlewares eine dynamische Speicherzuweisung erforderten.

Diese Ergebnisse untermauern die vorgesehene Rolle von Proton als Kommunikationsschicht für kleine eingebettete Geräte, die an Robotersystemen auf Basis von ROS 2 teilnehmen müssen. Für Entwickler, die mit kundenspezifischen Boards arbeiten, bietet das Projekt eine Möglichkeit, die ROS-2-Integration beizubehalten und zugleich die Anforderungen an Software und Speicher der eingebetteten Hardware zu begrenzen.