Can I keep my existing ROS2 nodes?

Yes — that is the design. Flow B (sidecar): the MOS4 supervisor runs a sidecar container hosting rclcpp/rclpy nodes without any MOS SDK dependency or recompile. Flow A (bridge): the mos-ros2 micro service joins the customer DDS graph as a standard RTPS peer and relays topics as EventBus events and service methods. Customer node code changes: zero.

Why not just use ROS2 on a lightweight Linux platform?

ROS2 is a robotics middleware, not an embedded operating system. It does not provide a fleet OTA path, vehicle protocol stacks, observability bundle, or component lifecycle supervisor at the OS level. MOS4 provides those primitives and hosts ROS2 nodes inside.

Is the bridge a bottleneck?

It is a per-topic translation step within the standard component IPC budget. For tight inner loops, the canonical pattern is to keep them inside the ROS2 sidecar. Only cross-domain topics traverse the bridge.

What DDS QoS policies are supported?

BEST_EFFORT and RELIABLE reliability policies are supported. Four named profiles — sensor_data, pose_estimate, actuation_cmd, latched_config — are configurable per mapping entry and cover the most common robotics patterns. Full QoS matrix available on request.

Does MOS4 ship its own DDS implementation?

No for the sidecar path. The sidecar uses the standard ROS2 DDS layer — Cyclone DDS or Fast DDS. For the bridge (Flow A), the mos-ros2 micro service uses iceoryx2 DDS in full via mos-frame — rustdds-based, no r2r or rcl FFI, no libstdc++.

When does ROS2-only beat MOS4 + ROS2?

When the programme is a single-vehicle research prototype with no fleet, no vehicle bus integration beyond a CAN driver, and no OTA requirement. Programmes shipping to a device fleet in production typically benefit from the MOS4 layer around the nodes.

Is this qualified for AGV or mobile robot deployments?

mos-ros2 is gamma-ready. Running rclcpp/rclpy unmodified inside MCM is the validated sidecar pattern. For AGV and robotics production qualification, talk to engineering.

Compare

MOS4 vs ROS2

ROS2 is a robotics middleware. MOS4 hosts your existing rclcpp and rclpy nodes unmodified inside a supervised container, bridges DDS topics to the typed EventBus, and adds fleet OTA, vehicle protocol stacks, and observability around them.

Talk to engineering Read the architecture

ROS2 node graph wrapped inside a MOS4 container outline — amber accent on the container border

Integration paths

Bridge or sidecar — nodes unchanged either way.

flowchart TB
  subgraph A["Flow A — bridge (mos-ros2 as RTPS peer)"]
    R1[rclcpp / rclpy node] -->|DDS topic| Br[mos-ros2 bridge micro service] -->|EventBus protobuf| Mc[MOS4 component]
  end
  subgraph B["Flow B — sidecar (nodes unmodified)"]
    Sup[MOS4 supervisor] --> Side[ROS2 sidecar container]
    Side --> R2[rclcpp node 1]
    Side --> R3[rclpy node 2]
    Side <-->|MQTT loopback| Bus[MOS4 bus]
  end

Side-by-side

Capability comparison.

Node hosting ROS2 ROS2 nodes run in the ROS2 execution environment. No external lifecycle supervisor. MOS4 Existing rclcpp/rclpy nodes run unmodified inside a MCM-managed sidecar container. No MOS SDK dependency, no recompile required.

IPC ROS2 DDS pub/sub and RTPS over UDP. Schema in .msg and .srv files. MOS4 Native protobuf bus. mos-ros2 bridge translates DDS topics to typed EventBus events. Same-chip micro service-to-micro service: iceoryx2 dmabuf + shared memory (zero-copy). ROS2 bridge: iceoryx2 DDS in full via mos-frame.

DDS QoS ROS2 Full DDS QoS surface: RELIABILITY, DURABILITY, HISTORY, DEADLINE, LIVELINESS. MOS4 BEST_EFFORT and RELIABLE supported. Four named profiles: sensor_data, pose_estimate, actuation_cmd, latched_config. Full QoS matrix on request.

Schema drift ROS2 .msg and .proto maintained separately; drift caught at runtime message decode. MOS4 proto2ros derives ROS2 .msg definitions and CDR glue from MOS .proto files at build time. Schema changes in mos-interfaces propagate automatically; drift caught at compile time.

Lifecycle supervisor ROS2 Per-node managed lifecycle (ROS2 lifecycle nodes). No fleet-level supervisor. MOS4 MOS4 supervisor: dependency-ordered startup, on_start/on_stop/hot-swap, per-component watchdog, automatic restart. ROS2 sidecar supervised as a container.

Fleet OTA ROS2 Out of scope. No fleet OTA mechanism in ROS2. MOS4 mos-update: Ed25519-signed delta packages, A/B partitions, automatic rollback via bootcount. Cohort and canary OTA via the Munic cloud companion.

Vehicle protocols ROS2 Bring your own driver. No native vehicle protocol stacks. MOS4 obdstacks-v2: 12 protocols (CAN, CAN-FD, DoIP, UDS, J1939, ISOBUS, and more). Decoded signal values via SubscribeData service call — declarative JSON stack, no Rust recompile.

Observability ROS2 ros2_tracing and per-node lifecycle events. No fleet observability stack. MOS4 ObservabilityRegistry: per-component response-time histograms, error counters, lifecycle events. OpenTelemetry OTLP export, W3C Trace Context propagation, mos-sentry structured error batching.

Source — ROS2 from docs.ros.org; MOS4 from /architecture.

Sensor mappings

Canonical MOS4 ↔ ROS2 mappings.

The mappings/mos-ros2-canonical.yaml registry enforces the mapping contract at build time via the mos-ros2-mapping CLI. A coverage-matrix CI gate blocks merges that reduce mapping coverage.

Canonical MOS4 to ROS2 sensor mappings
MOS4 EventBus event	ROS2 topic	ROS2 type
mos.events.gnss.Fix	/sensors/gnss/fix	sensor_msgs/NavSatFix
mos.events.imu.Raw	/sensors/imu/raw	sensor_msgs/Imu
mos.events.vslam.Pose	/sensors/vslam/pose	geometry_msgs/PoseStamped

ROS2 Jazzy LTS (supported to 2029) is the validated distro. Cyclone DDS and Fast DDS peers tested.

FAQ

The questions we hear most.

Can I keep my existing ROS2 nodes?

Yes — that is the design. Flow B (sidecar): the MOS4 supervisor runs a sidecar container hosting rclcpp/rclpy nodes without any MOS SDK dependency or recompile. Flow A (bridge): the mos-ros2 micro service joins the customer DDS graph as a standard RTPS peer and relays topics as EventBus events and service methods. Customer node code changes: zero.
Why not just use ROS2 on a lightweight Linux platform?

ROS2 is a robotics middleware, not an embedded operating system. It does not provide a fleet OTA path, vehicle protocol stacks, observability bundle, or component lifecycle supervisor at the OS level. MOS4 provides those primitives and hosts ROS2 nodes inside.
Is the bridge a bottleneck?

It is a per-topic translation step within the standard component IPC budget. For tight inner loops, the canonical pattern is to keep them inside the ROS2 sidecar. Only cross-domain topics traverse the bridge.
What DDS QoS policies are supported?

BEST_EFFORT and RELIABLE reliability policies are supported. Four named profiles — sensor_data, pose_estimate, actuation_cmd, latched_config — are configurable per mapping entry and cover the most common robotics patterns. Full QoS matrix available on request.
Does MOS4 ship its own DDS implementation?

No for the sidecar path. The sidecar uses the standard ROS2 DDS layer — Cyclone DDS or Fast DDS. For the bridge (Flow A), the mos-ros2 micro service uses iceoryx2 DDS in full via mos-frame — rustdds-based, no r2r or rcl FFI, no libstdc++.
When does ROS2-only beat MOS4 + ROS2?

When the programme is a single-vehicle research prototype with no fleet, no vehicle bus integration beyond a CAN driver, and no OTA requirement. Programmes shipping to a device fleet in production typically benefit from the MOS4 layer around the nodes.
Is this qualified for AGV or mobile robot deployments?

mos-ros2 is gamma-ready. Running rclcpp/rclpy unmodified inside MCM is the validated sidecar pattern. For AGV and robotics production qualification, talk to engineering.

Bring your ROS2 stack.

A 30-minute call with engineering. We will plan the bridge or sidecar path for your nodes and discuss AGV or robotics qualification.

Talk to engineering Glossary