ROS 2 (Robot Middleware) Driver

Overview

ROS 2 (Robot Operating System 2) is the standard middleware in the mobile robot / AGV / collaborative robot / drone space, providing publish / subscribe / service / action on top of DDS (Data Distribution Service, RTPS over UDP/TCP). It monitors robot status by subscribing to topics (e.g. /odom, /scan, /battery_state).

Item	Value
`opc_type`	`ROS2`
Implementation class	`plantpulse.driver.protocol.ros2.ROS2Driver`
Library	rosbridge_suite (JSON over WebSocket, in-house client)
read	✅ Topic subscription — `<topic>:<field.dot.path>`
write	⛔ Not supported (read-only)
Security	DDS-Security / SROS2 (vendor-specific)

Current status: rosbridge production implementation (2026-07)

ROS2 is a production implementation that connects to rosbridge_server over WebSocket and subscribes to topics. The authoritative reference for registration and address contracts is Connection Types — ROS 2; otherwise, use one of the bridge patterns under Alternative Operating Methods below.

Why a native implementation is difficult

rcljava, the Java client for ROS 2, is not a pure Java library but a C++ core (rcl, rmw) + JNI binding structure.

Dependency	Description	Deployment impact
`rcl` (C)	ROS 2 client library core	Platform-specific .so / .dll required
`rmw` middleware	Abstraction over the actual DDS implementation	Which DDS to use is decided at build time
`rmw_cyclonedds_cpp`	Eclipse CycloneDDS backend	native lib + license (EPL/EDL)
`rmw_fastrtps_cpp`	eProsima Fast DDS backend	native lib + license (Apache 2.0)
ROS 2 distro dependency	ABI differs with every LTS: Humble / Iron / Jazzy / Rolling	Must match the gateway OS version
JNI bridge	rcljava itself	Risk of conflict between the Java memory model and the DDS thread pool

For a Java application like PlantPulse Edge that must run on a wide range of OSes / architectures (x86-64 Linux, ARM64 Linux, Windows Server), embedding a native ROS 2 client directly is therefore very costly in terms of deployment, library conflicts, and version matching.

Alternative Operating Methods

The ROS 2 community has standardized bridge nodes for integration with external systems. PlantPulse only needs to consume the bridge's output interface.

Option 1. rosbridge_server (WebSocket / REST)

Running rosbridge_suite on the ROS 2 side enables topic subscription over JSON via WebSocket / HTTP.

PlantPulse driver to use	Page
`HTTP` (REST polling or WebSocket bridge)	HTTP

Option 2. MQTT bridge

Use a bridge such as ros2-mqtt-bridge to convert ROS 2 topics into MQTT topics.

PlantPulse entry point to use	Page
Sparkplug B input	Sparkplug B

Option 3. OPC UA Robotics Companion Specification

A growing number of robot controllers (e.g. ABB OmniCore, KUKA KR C5, Universal Robots PolyScope X) support the OPC UA Robotics Companion Spec standardized by the OPC Foundation and VDMA. In this case you can connect directly to the controller's OPC UA server instead of to ROS 2 itself.

PlantPulse driver to use	Page
`OPCUA`	OPC-UA

Which option to choose

Situation	Recommendation
In-house ROS 2 system (mobile AGV, etc.)	rosbridge_server + HTTP driver
Many robots plus cloud collection	MQTT bridge → Sparkplug B
Industrial robot controllers (ABB / KUKA / UR)	OPC UA Robotics Companion → OPCUA driver
Simple status telemetry, 1–2 topics	rosbridge_server REST polling

Considerations for a future native implementation

Option	Dependencies	Difficulty
Embed rcljava	native .so / .dll for rcl + rmw + DDS	Very high
ROS 2 Java client (jros2client and other forks)	Unofficial, poorly maintained	High
In-house RTPS parser (UDP multicast)	Direct implementation of the RTPS spec	Very high

Conclusion

There are no plans to embed a native ROS 2 client within the single-jar deployment model of PlantPulse Edge. The officially recommended integration paths are rosbridge_server (HTTP) or OPC UA Robotics Companion (OPCUA).

stub registration (test only)

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": []
  }'

Overview​

Why a native implementation is difficult​

Alternative Operating Methods​

Option 1. rosbridge_server (WebSocket / REST)​

Option 2. MQTT bridge​

Option 3. OPC UA Robotics Companion Specification​

Which option to choose​

Considerations for a future native implementation​

stub registration (test only)​