ROS 2 (Roboter-Middleware) Treiber

Überblick

ROS 2 (Robot Operating System 2) ist die Standard-Middleware für mobile Roboter, AGV, kollaborative Roboter und Drohnen. Auf Basis von DDS (Data Distribution Service, RTPS over UDP/TCP) stellt es publish / subscribe / service / action bereit. Durch das Abonnieren von Topics (z. B. /odom, /scan, /battery_state) wird der Roboterzustand überwacht.

Eintrag	Wert
`opc_type`	`ROS2`
Implementierungsklasse	`plantpulse.driver.protocol.ros2.ROS2Driver`
Bibliothek	rosbridge_suite (JSON over WebSocket, eigener Client)
read	✅ Topic-Abonnement — `<topic>:<field.dot.path>`
write	⛔ nicht unterstützt (nur lesend)
Sicherheit	DDS-Security / SROS2 (herstellerabhängig)

Aktueller Stand: rosbridge produktiv implementiert (2026-07)

ROS2 ist eine reale Implementierung, die sich per WebSocket mit dem rosbridge_server verbindet und Topics abonniert. Maßgeblich für Registrierung und Adresskonvention ist Verbindungstypen — ROS 2; darüber hinaus verwenden Sie eines der bridge-Muster unter Alternative Betriebsmethoden.

Warum eine native Implementierung schwierig ist

Der Java-Client von ROS 2, rcljava, ist keine reine Java-Bibliothek, sondern besteht aus C++-Kern (rcl, rmw) + JNI-Bindings.

Abhängigkeit	Beschreibung	Auswirkung auf das Deployment
`rcl` (C)	Kern der ROS 2 client library	plattformspezifische .so / .dll erforderlich
`rmw` middleware	Abstraktion der eigentlichen DDS-Implementierung	Wahl des DDS wird zur Build-Zeit festgelegt
`rmw_cyclonedds_cpp`	Eclipse CycloneDDS Backend	native lib + Lizenz (EPL/EDL)
`rmw_fastrtps_cpp`	eProsima Fast DDS Backend	native lib + Lizenz (Apache 2.0)
Abhängigkeit von der ROS 2 distro	Humble / Iron / Jazzy / Rolling — jede LTS mit abweichender ABI	muss zur OS-Version des Gateway passen
JNI bridge	rcljava selbst	Konfliktrisiko zwischen Java-Speichermodell und DDS thread pool

Für eine Java-Anwendung wie PlantPulse Edge, die auf unterschiedlichsten Betriebssystemen und Architekturen (x86-64 Linux, ARM64 Linux, Windows Server) laufen muss, ist das direkte Einbetten eines nativen ROS 2 Clients daher hinsichtlich Deployment, Bibliothekskonflikten und Versionsabgleich sehr aufwendig.

Alternative Betriebsmethoden

Das ROS 2 Umfeld hat für die Integration externer Systeme bridge-Nodes standardisiert. PlantPulse muss lediglich die Ausgabeschnittstelle der bridge entgegennehmen.

Option 1. rosbridge_server (WebSocket / REST)

Wird auf ROS 2 Seite rosbridge_suite gestartet, lassen sich Topics per JSON over WebSocket / HTTP abonnieren.

Zu verwendender PlantPulse-Treiber	Seite
`HTTP` (REST polling oder WebSocket bridge)	HTTP

Option 2. MQTT bridge

Mit einer bridge wie ros2-mqtt-bridge werden ROS 2 Topics in MQTT Topics umgesetzt.

Zu verwendender PlantPulse-Zugang	Seite
Sparkplug B Eingang	Sparkplug B

Option 3. OPC UA Robotics Companion Specification

Immer mehr Robotersteuerungen (z. B. ABB OmniCore, KUKA KR C5, Universal Robots PolyScope X) unterstützen die von OPC Foundation und VDMA standardisierte OPC UA Robotics Companion Spec. In diesem Fall kann statt ROS 2 selbst direkt der OPC UA Server der Steuerung angebunden werden.

Zu verwendender PlantPulse-Treiber	Seite
`OPCUA`	OPC-UA

Welche Option ist die richtige

Situation	Empfehlung
Eigenentwickeltes ROS 2 System (mobile AGV usw.)	rosbridge_server + HTTP-Treiber
Viele Roboter + zusätzlich Cloud-Erfassung	MQTT bridge → Sparkplug B
Industrielle Robotersteuerung (ABB / KUKA / UR)	OPC UA Robotics Companion → OPCUA-Treiber
Einfache Zustandstelemetrie mit 1–2 Topics	rosbridge_server REST polling

Überlegungen für eine spätere native Implementierung

Option	Abhängigkeiten	Schwierigkeit
rcljava einbetten	native .so / .dll von rcl + rmw + DDS	sehr hoch
ROS 2 Java Client (Forks wie jros2client)	inoffiziell, schwache Pflege	hoch
Eigener RTPS-Parser (UDP-Multicast)	RTPS-Spezifikation selbst implementieren	sehr hoch

Fazit

Innerhalb des Single-jar-Deploymentmodells von PlantPulse Edge ist das Einbetten eines nativen ROS 2 Clients nicht geplant. Die offiziell empfohlenen Integrationswege sind rosbridge_server (HTTP) oder OPC UA Robotics Companion (OPCUA).

stub-Registrierung (nur für Tests)

curl -X POST http://<edge-host>/api/v1/opc \
  -H "Content-Type: application/json" \
  -d '{
    "opc_id": "OPC_ROS2_STUB",
    "opc_type": "ROS2",
    "opc_name": "ROS 2 stub",
    "opc_agent_ip": "192.168.0.0",
    "opc_agent_port": "0",
    "site_id": "SITE_00001",
    "auto_collect": false,
    "timecycle": 5000,
    "tag_list": []
  }'

Überblick​

Warum eine native Implementierung schwierig ist​

Alternative Betriebsmethoden​

Option 1. rosbridge_server (WebSocket / REST)​

Option 2. MQTT bridge​

Option 3. OPC UA Robotics Companion Specification​

Welche Option ist die richtige​

Überlegungen für eine spätere native Implementierung​

stub-Registrierung (nur für Tests)​