MOS4 vs ROS2

Chemins d’intégration

Bridge ou sidecar — nœuds inchangés dans les deux cas.

flowchart TB
  subgraph A["Flux A — bridge (mos-ros2 comme pair RTPS)"]
    R1[nœud rclcpp / rclpy] -->|topic DDS| Br[micro service bridge mos-ros2] -->|EventBus protobuf| Mc[Composant MOS4]
  end
  subgraph B["Flux B — sidecar (nœuds sans modification)"]
    Sup[Superviseur MOS4] --> Side[Conteneur sidecar ROS2]
    Side --> R2[nœud rclcpp 1]
    Side --> R3[nœud rclpy 2]
    Side <-->|loopback MQTT| Bus[Bus MOS4]
  end

Mappings de capteurs

Mappings canoniques MOS4 ↔ ROS2.

Le registre mappings/mos-ros2-canonical.yaml impose le contrat de mapping au build via la CLI mos-ros2-mapping. Une porte CI de matrice de couverture bloque les merges qui réduisent la couverture de mapping.

ROS2 Jazzy LTS (supporté jusqu’en 2029) est la distro validée. Pairs Cyclone DDS et Fast DDS testés.

FAQ

Les questions qu’on nous pose le plus.

• Puis-je conserver mes nœuds ROS2 existants ?

  Oui — c’est le design. Flux B (sidecar) : le superviseur MOS4 exécute un conteneur sidecar qui héberge les nœuds rclcpp/rclpy sans aucune dépendance au SDK MOS ni recompilation. Flux A (bridge) : le micro service mos-ros2 rejoint le graphe DDS client comme pair RTPS standard et relaie les topics comme événements EventBus et méthodes de service. Changements de code des nœuds clients : zéro.

• Pourquoi ne pas simplement utiliser ROS2 sur une plateforme Linux légère ?

  ROS2 est un middleware robotique, pas un système d’exploitation embarqué. Il ne fournit pas de chemin OTA flotte, de stacks de protocoles véhicule, de bundle d’observabilité ni de superviseur de cycle de vie de composants au niveau OS. MOS4 fournit ces primitives et héberge les nœuds ROS2 à l’intérieur.

• Le bridge est-il un goulot d’étranglement ?

  C’est une étape de traduction par topic dans le budget IPC standard de composant. Pour les boucles internes serrées, le schéma canonique consiste à les garder à l’intérieur du sidecar ROS2. Seuls les topics inter-domaines traversent le bridge.

• Quelles policies QoS DDS sont supportées ?

  Les policies de fiabilité BEST_EFFORT et RELIABLE sont supportées. Quatre profils nommés — sensor_data, pose_estimate, actuation_cmd, latched_config — sont configurables par entrée de mapping et couvrent les schémas robotiques les plus courants. Matrice QoS complète disponible sur demande.

• MOS4 livre-t-il sa propre implémentation DDS ?

  Non pour le chemin sidecar. Le sidecar utilise la couche DDS standard de ROS2 — Cyclone DDS ou Fast DDS. Pour le bridge (Flux A), le micro service mos-ros2 utilise iceoryx2 DDS en intégralité via mos-frame — basé sur rustdds, sans r2r ni FFI rcl, sans libstdc++.

• Quand ROS2-only bat-il MOS4 + ROS2 ?

  Quand le programme est un prototype de recherche mono-véhicule sans flotte, sans intégration de bus véhicule au-delà d’un driver CAN, et sans exigence OTA. Les programmes qui livrent à une flotte de devices en production bénéficient typiquement de la couche MOS4 autour des nœuds.

• Est-ce qualifié pour les déploiements AGV ou robots mobiles ?

  mos-ros2 exécute rclcpp/rclpy sans modification dans MCM — le schéma sidecar validé. Pour la qualification production AGV et robotique, parlez à l’ingénierie.