¿Puedo conservar mis nodos ROS2 existentes?

Sí — ese es el diseño. Flujo B (sidecar): el supervisor MOS4 ejecuta un contenedor sidecar que aloja nodos rclcpp/rclpy sin ninguna dependencia del MOS SDK ni recompilación. Flujo A (puente): el micro service mos-ros2 se une al grafo DDS del cliente como un peer RTPS estándar y reenvía topics como eventos EventBus y métodos de servicio. Cambios en el código de los nodos del cliente: cero.

¿Por qué no usar simplemente ROS2 sobre una plataforma Linux ligera?

ROS2 es un middleware de robótica, no un sistema operativo embebido. No proporciona ruta OTA de flota, pilas de protocolo vehicular, paquete de observabilidad ni supervisor de ciclo de vida de componentes a nivel de OS. MOS4 proporciona esas primitivas y aloja nodos ROS2 dentro.

¿Es el puente un cuello de botella?

Es un paso de traducción por topic dentro del presupuesto IPC estándar de componentes. Para bucles internos ajustados, el patrón canónico es mantenerlos dentro del sidecar ROS2. Solo los topics entre dominios atraviesan el puente.

¿Qué políticas QoS DDS están soportadas?

Se soportan las políticas de fiabilidad BEST_EFFORT y RELIABLE. Cuatro perfiles con nombre — sensor_data, pose_estimate, actuation_cmd, latched_config — son configurables por entrada de mapeo y cubren los patrones de robótica más habituales. Matriz QoS completa disponible bajo petición.

¿MOS4 incluye su propia implementación DDS?

No para la ruta sidecar. El sidecar usa la capa DDS estándar de ROS2 — Cyclone DDS o Fast DDS. Para el puente (Flujo A), el micro service mos-ros2 usa iceoryx2 DDS al completo vía mos-frame — basado en rustdds, sin r2r ni FFI rcl, sin libstdc++.

¿Cuándo gana ROS2-solo a MOS4 + ROS2?

Cuando el programa es un prototipo de investigación de un único vehículo sin flota, sin integración de bus vehicular más allá de un driver CAN y sin requisito de OTA. Los programas que se despliegan en una flota de dispositivos en producción típicamente se benefician de la capa MOS4 alrededor de los nodos.

¿Está cualificado para despliegues AGV o de robots móviles?

mos-ros2 ejecuta rclcpp/rclpy sin modificar dentro de MCM — el patrón sidecar validado. Para la cualificación de producción AGV y robótica, hable con ingeniería.

Comparativa

MOS4 vs ROS2

ROS2 es un middleware de robótica. MOS4 aloja sus nodos rclcpp y rclpy existentes sin modificar dentro de un contenedor supervisado, puentea topics DDS al EventBus tipado y añade OTA de flota, pilas de protocolo vehicular y observabilidad alrededor.

Hablar con ingeniería Leer la arquitectura

Grafo de nodos ROS2 envuelto dentro del contorno de un contenedor MOS4 — acento ámbar en el borde del contenedor

Rutas de integración

Puente o sidecar — nodos inalterados en ambos casos.

flowchart TB
  subgraph A["Flujo A — puente (mos-ros2 como peer RTPS)"]
    R1[nodo rclcpp / rclpy] -->|topic DDS| Br[micro service puente mos-ros2] -->|protobuf EventBus| Mc[componente MOS4]
  end
  subgraph B["Flujo B — sidecar (nodos sin modificar)"]
    Sup[supervisor MOS4] --> Side[contenedor sidecar ROS2]
    Side --> R2[nodo rclcpp 1]
    Side --> R3[nodo rclpy 2]
    Side <-->|loopback MQTT| Bus[bus MOS4]
  end

Cara a cara

Comparación de capacidades.

Alojamiento de nodos ROS2 Los nodos ROS2 corren en el entorno de ejecución ROS2. Sin supervisor de ciclo de vida externo. MOS4 Los nodos rclcpp/rclpy existentes corren sin modificar dentro de un contenedor sidecar gestionado por MCM. Sin dependencia del MOS SDK, sin recompilación requerida.

IPC ROS2 Pub/sub DDS y RTPS sobre UDP. Esquema en archivos .msg y .srv. MOS4 Bus protobuf nativo. El puente mos-ros2 traduce topics DDS a eventos EventBus tipados. Micro servicio a micro service en el mismo chip: dmabuf iceoryx2 + memoria compartida (zero-copy). Puente ROS2: iceoryx2 DDS al completo vía mos-frame.

QoS DDS ROS2 Superficie QoS DDS completa: RELIABILITY, DURABILITY, HISTORY, DEADLINE, LIVELINESS. MOS4 BEST_EFFORT y RELIABLE soportados. Cuatro perfiles con nombre: sensor_data, pose_estimate, actuation_cmd, latched_config. Matriz QoS completa bajo petición.

Drift de esquema ROS2 .msg y .proto se mantienen por separado; el drift se detecta en tiempo de decodificación de mensaje en ejecución. MOS4 proto2ros deriva las definiciones .msg de ROS2 y el glue CDR a partir de los archivos .proto de MOS en tiempo de build. Los cambios de esquema en mos-interfaces se propagan automáticamente; el drift se detecta en tiempo de compilación.

Supervisor de ciclo de vida ROS2 Ciclo de vida gestionado por nodo (nodos lifecycle ROS2). Sin supervisor a nivel de flota. MOS4 Supervisor MOS4: arranque ordenado por dependencias, on_start/on_stop/hot-swap, watchdog por componente, reinicio automático. El sidecar ROS2 supervisado como contenedor.

OTA de flota ROS2 Fuera de alcance. Sin mecanismo OTA de flota en ROS2. MOS4 mos-update: paquetes delta firmados con Ed25519, particiones A/B, rollback automático vía bootcount. OTA por cohorte y canario vía el complemento cloud de Munic.

Protocolos vehiculares ROS2 Traiga su propio driver. Sin pilas de protocolo vehicular nativas. MOS4 obdstacks-v2: 16 protocolos (CAN, CAN-FD, DoIP, UDS, J1939, ISOBUS y más). Valores de señal decodificados vía llamada de servicio SubscribeData — pila JSON declarativa, sin recompilación Rust.

Observabilidad ROS2 ros2_tracing y eventos de ciclo de vida por nodo. Sin pila de observabilidad de flota. MOS4 ObservabilityRegistry: histogramas de tiempo de respuesta por componente, contadores de error, eventos de ciclo de vida. Exportación OTLP de OpenTelemetry, propagación de W3C Trace Context, batching estructurado de errores con mos-sentry.

Fuente — ROS2 desde docs.ros.org; MOS4 desde /es/architecture.

Mapeos de sensores

Mapeos canónicos MOS4 ↔ ROS2.

El registro mappings/mos-ros2-canonical.yaml impone el contrato de mapeo en tiempo de build vía la CLI mos-ros2-mapping. Un filtro CI de matriz de cobertura bloquea los merges que reducen la cobertura de mapeo.

Mapeos canónicos de sensores MOS4 a ROS2
Evento EventBus MOS4	Topic ROS2	Tipo ROS2
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 (soportado hasta 2029) es la distro validada. Peers Cyclone DDS y Fast DDS probados.

FAQ

Las preguntas que más oímos.

¿Puedo conservar mis nodos ROS2 existentes?

Sí — ese es el diseño. Flujo B (sidecar): el supervisor MOS4 ejecuta un contenedor sidecar que aloja nodos rclcpp/rclpy sin ninguna dependencia del MOS SDK ni recompilación. Flujo A (puente): el micro service mos-ros2 se une al grafo DDS del cliente como un peer RTPS estándar y reenvía topics como eventos EventBus y métodos de servicio. Cambios en el código de los nodos del cliente: cero.
¿Por qué no usar simplemente ROS2 sobre una plataforma Linux ligera?

ROS2 es un middleware de robótica, no un sistema operativo embebido. No proporciona ruta OTA de flota, pilas de protocolo vehicular, paquete de observabilidad ni supervisor de ciclo de vida de componentes a nivel de OS. MOS4 proporciona esas primitivas y aloja nodos ROS2 dentro.
¿Es el puente un cuello de botella?

Es un paso de traducción por topic dentro del presupuesto IPC estándar de componentes. Para bucles internos ajustados, el patrón canónico es mantenerlos dentro del sidecar ROS2. Solo los topics entre dominios atraviesan el puente.
¿Qué políticas QoS DDS están soportadas?

Se soportan las políticas de fiabilidad BEST_EFFORT y RELIABLE. Cuatro perfiles con nombre — sensor_data, pose_estimate, actuation_cmd, latched_config — son configurables por entrada de mapeo y cubren los patrones de robótica más habituales. Matriz QoS completa disponible bajo petición.
¿MOS4 incluye su propia implementación DDS?

No para la ruta sidecar. El sidecar usa la capa DDS estándar de ROS2 — Cyclone DDS o Fast DDS. Para el puente (Flujo A), el micro service mos-ros2 usa iceoryx2 DDS al completo vía mos-frame — basado en rustdds, sin r2r ni FFI rcl, sin libstdc++.
¿Cuándo gana ROS2-solo a MOS4 + ROS2?

Cuando el programa es un prototipo de investigación de un único vehículo sin flota, sin integración de bus vehicular más allá de un driver CAN y sin requisito de OTA. Los programas que se despliegan en una flota de dispositivos en producción típicamente se benefician de la capa MOS4 alrededor de los nodos.
¿Está cualificado para despliegues AGV o de robots móviles?

mos-ros2 ejecuta rclcpp/rclpy sin modificar dentro de MCM — el patrón sidecar validado. Para la cualificación de producción AGV y robótica, hable con ingeniería.

Traiga su pila ROS2.

Una llamada de 30 minutos con ingeniería. Planificaremos la ruta de puente o sidecar para sus nodos y discutiremos la cualificación AGV o de robótica.

Hablar con ingeniería Glosario