Vergleich

MOS4 vs. ROS2

ROS2 ist eine Robotik-Middleware. MOS4 hostet Ihre bestehenden rclcpp- und rclpy-Knoten unverändert in einem überwachten Container, verbindet DDS-Topics mit dem typisierten EventBus und fügt Flotten-OTA, Fahrzeugprotokoll-Stacks und Observability darum hinzu.

ROS2-Knoten-Graph eingewickelt in eine MOS4-Container-Umrandung — bernsteinfarbener Akzent auf dem Container-Rand

Integrationspfade

Bridge oder Sidecar — Knoten in beiden Fällen unverändert.

Zwei Integrationsflüsse. Fluss A: Der mos-ros2-Bridge-micro service tritt dem Kunden-DDS-Graph als RTPS-Peer bei, entdeckt Topics und leitet sie als EventBus-Protobuf-Ereignisse an MOS4-Komponenten weiter. Fluss B: Der MOS4-Supervisor verwaltet einen ROS2-Sidecar-Container, der rclcpp- und rclpy-Knoten ohne jede MOS-SDK-Abhängigkeit hostet und über MQTT-Loopback mit dem MOS4-Bus kommuniziert.

flowchart TB
  subgraph A["Fluss A — Bridge (mos-ros2 als RTPS-Peer)"]
    R1[rclcpp / rclpy Knoten] -->|DDS-Topic| Br[mos-ros2-Bridge-micro service] -->|EventBus protobuf| Mc[MOS4-Komponente]
  end
  subgraph B["Fluss B — Sidecar (Knoten unverändert)"]
    Sup[MOS4-Supervisor] --> Side[ROS2-Sidecar-Container]
    Side --> R2[rclcpp-Knoten 1]
    Side --> R3[rclpy-Knoten 2]
    Side <-->|MQTT-Loopback| Bus[MOS4-Bus]
  end

Gegenüberstellung

Fähigkeitsvergleich.

Knoten-Hosting ROS2 ROS2-Knoten laufen in der ROS2-Ausführungsumgebung. Kein externer Lebenszyklus-Supervisor. MOS4 Bestehende rclcpp/rclpy-Knoten laufen unverändert in einem MCM-verwalteten Sidecar-Container. Keine MOS-SDK-Abhängigkeit, keine Neukompilierung erforderlich.
IPC ROS2 DDS-Pub/Sub und RTPS über UDP. Schema in .msg- und .srv-Dateien. MOS4 Nativer Protobuf-Bus. mos-ros2-Bridge übersetzt DDS-Topics in typisierte EventBus-Ereignisse. micro service-zu-micro service auf demselben Chip: iceoryx2 dmabuf + Shared Memory (Zero-Copy). ROS2-Bridge: iceoryx2 DDS in vollem Umfang über mos-frame.
DDS-QoS ROS2 Vollständige DDS-QoS-Oberfläche: RELIABILITY, DURABILITY, HISTORY, DEADLINE, LIVELINESS. MOS4 BEST_EFFORT und RELIABLE unterstützt. Vier benannte Profile: sensor_data, pose_estimate, actuation_cmd, latched_config. Vollständige QoS-Matrix auf Anfrage.
Schema-Drift ROS2 .msg und .proto separat gepflegt; Drift wird beim Laufzeit-Nachrichten-Decode erkannt. MOS4 proto2ros leitet ROS2-.msg-Definitionen und CDR-Glue aus MOS-.proto-Dateien zur Build-Zeit ab. Schemaänderungen in mos-interfaces propagieren automatisch; Drift wird zur Compile-Zeit erkannt.
Lebenszyklus-Supervisor ROS2 Verwalteter Lebenszyklus pro Knoten (ROS2-Lifecycle-Knoten). Kein flottenweiter Supervisor. MOS4 MOS4-Supervisor: abhängigkeitsgeordneter Start, on_start/on_stop/Hot-Swap, Watchdog pro Komponente, automatischer Neustart. ROS2-Sidecar als Container überwacht.
Flotten-OTA ROS2 Außerhalb des Geltungsbereichs. Kein Flotten-OTA-Mechanismus in ROS2. MOS4 mos-update: Ed25519-signierte Delta-Pakete, A/B-Partitionen, automatischer Rollback per Bootcount. Kohorten- und Canary-OTA über den Munic-Cloud-Companion.
Fahrzeugprotokolle ROS2 Bringen Sie Ihren eigenen Treiber mit. Keine nativen Fahrzeugprotokoll-Stacks. MOS4 obdstacks-v2: 16 Protokolle (CAN, CAN-FD, DoIP, UDS, J1939, ISOBUS und weitere). Dekodierte Signalwerte über SubscribeData-Service-Call — deklarativer JSON-Stack, keine Rust-Neukompilierung.
Observability ROS2 ros2_tracing und Lifecycle-Ereignisse pro Knoten. Kein flottenweiter Observability-Stack. MOS4 ObservabilityRegistry: Response-Time-Histogramme pro Komponente, Error-Counter, Lifecycle-Ereignisse. OpenTelemetry-OTLP-Export, W3C-Trace-Context-Propagation, mos-sentry strukturiertes Error-Batching.

Quelle — ROS2 von docs.ros.org; MOS4 von /de/architecture.

Sensor-Mappings

Kanonische MOS4 ↔ ROS2 Mappings.

Die Registry mappings/mos-ros2-canonical.yaml erzwingt den Mapping-Vertrag zur Build-Zeit über die mos-ros2-mapping-CLI. Ein Coverage-Matrix-CI-Gate blockiert Merges, die die Mapping-Abdeckung reduzieren.

Kanonische MOS4-zu-ROS2-Sensor-Mappings
MOS4-EventBus-Event ROS2-Topic ROS2-Typ
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 (unterstützt bis 2029) ist die validierte Distribution. Cyclone DDS- und Fast DDS-Peers getestet.

FAQ

Die Fragen, die wir am häufigsten hören.

  • Kann ich meine bestehenden ROS2-Knoten behalten?

    Ja — das ist das Design. Fluss B (Sidecar): Der MOS4-Supervisor betreibt einen Sidecar-Container, der rclcpp/rclpy-Knoten ohne jede MOS-SDK-Abhängigkeit oder Neukompilierung hostet. Fluss A (Bridge): Der mos-ros2 micro service tritt dem Kunden-DDS-Graph als Standard-RTPS-Peer bei und gibt Topics als EventBus-Ereignisse und Service-Methoden weiter. Änderungen am Kunden-Knoten-Code: null.

  • Warum nicht einfach ROS2 auf einer leichtgewichtigen Linux-Plattform verwenden?

    ROS2 ist eine Robotik-Middleware, kein Embedded-Betriebssystem. Es bietet keinen Flotten-OTA-Pfad, keine Fahrzeugprotokoll-Stacks, kein Observability-Bundle und keinen Komponenten-Lebenszyklus-Supervisor auf OS-Ebene. MOS4 stellt diese Primitive bereit und hostet ROS2-Knoten darin.

  • Ist die Bridge ein Engpass?

    Es ist ein Übersetzungsschritt pro Topic innerhalb des Standard-Komponenten-IPC-Budgets. Für enge innere Schleifen ist das kanonische Muster, sie im ROS2-Sidecar zu halten. Nur domänenübergreifende Topics durchqueren die Bridge.

  • Welche DDS-QoS-Policies werden unterstützt?

    BEST_EFFORT- und RELIABLE-Reliability-Policies werden unterstützt. Vier benannte Profile — sensor_data, pose_estimate, actuation_cmd, latched_config — sind pro Mapping-Eintrag konfigurierbar und decken die häufigsten Robotik-Muster ab. Vollständige QoS-Matrix auf Anfrage verfügbar.

  • Liefert MOS4 seine eigene DDS-Implementierung?

    Nein für den Sidecar-Pfad. Der Sidecar nutzt die Standard-ROS2-DDS-Schicht — Cyclone DDS oder Fast DDS. Für die Bridge (Fluss A) nutzt der mos-ros2 micro service iceoryx2 DDS in vollem Umfang über mos-frame — rustdds-basiert, kein r2r oder rcl FFI, kein libstdc++.

  • Wann schlägt ROS2-only MOS4 + ROS2?

    Wenn das Programm ein Einzelfahrzeug-Forschungsprototyp ohne Flotte, ohne Fahrzeugbus-Integration über einen CAN-Treiber hinaus und ohne OTA-Anforderung ist. Programme, die an eine Geräteflotte in Produktion ausliefern, profitieren typischerweise von der MOS4-Schicht um die Knoten herum.

  • Ist das für AGV- oder Mobile-Roboter-Deployments qualifiziert?

    mos-ros2 betreibt rclcpp/rclpy unverändert in MCM — das validierte Sidecar-Muster. Für AGV- und Robotik-Produktionsqualifizierung sprechen Sie mit dem Engineering.

Bringen Sie Ihren ROS2-Stack mit.

Ein 30-minütiges Gespräch mit dem Engineering. Wir planen den Bridge- oder Sidecar-Pfad für Ihre Knoten und besprechen die AGV- oder Robotik-Qualifizierung.

Bauen Sie auf MOS4?

Eine Antwort vom Engineering-Team, ~24 h. Kein Deck, kein NDA.

Mit Engineering sprechen