ROS 2 e Interoperabilidad DDS: Guía Práctica para Integración Sin Fisuras

ROS 2 depende de DDS para su capa de comunicación subyacente, sin embargo, lograr interoperabilidad impecable entre un despliegue DDS nativo y ROS 2 aún puede plantear desafíos sutiles. Esta guía destila los pasos prácticos y ajustes de configuración que han demostrado ser efectivos a partir del lanzamiento "Bouncy Bolson" (julio 2018) de ROS 2, ayudando a los equipos a evitar trampas comunes y aprovechar todo el poder de Connext DDS dentro de ROS 2.

Estado Actual de ROS 2

ROS 2 es un marco en rápida evolución, y futuros lanzamientos pueden introducir matices adicionales de interoperabilidad. Sin embargo, cuando ejecuta ROS 2 con la capa RMW rmw_connext_cpp, aún está usando la pila nativa Connext DDS. Eso significa que retiene todas las características avanzadas de Connext —como control QoS de grano fino y soporte multi-transporte— mientras disfruta de las abstracciones de alto nivel de ROS 2.

Ajustes Clave de Interoperabilidad

Nombres de Tópico y Particiones

ROS 2 codifica el namespace de un tópico ya sea en el nombre del tópico o en la partición DDS. Todos los tópicos de usuario ROS 2 residen en el namespace "rt" (ROS Topic). En DDS esto se representa como:

Tipos de Datos de Tópico

Cuando la capa RMW Connext está activa, ROS 2 anuncia cada tópico "rt/*" con un tipo de serialización genérico. Como resultado, una aplicación DDS pura que publica los datos originales fuertemente tipados experimentará un mismatch de QoS y no podrá conectarse.

El remedio más directo es suprimir la publicación automática de type-code desde participantes ROS 2. Agregue un archivo USER_QOS_PROFILES.xml al directorio que lanza sus nodos ROS 2. Una configuración mínima que oculta el type code y deshabilita el intercambio de type object se ve así:

Siéntase libre de ajustar la configuración de fiabilidad para adaptarla a su aplicación; el ejemplo anterior usa "Best Effort" como punto de partida.

Recuerde que este archivo QoS aplica solo a nodos ROS 2 iniciados desde el mismo directorio. Si necesita configuraciones aisladas, coloque un USER_QOS_PROFILES.xml dedicado junto a la carpeta de lanzamiento de cada nodo.

Selección de Transporte

Cuando un sistema DDS y un sistema ROS 2 comparten la misma red, pueden aparecer advertencias sobre transportes faltantes o no soportados (p. ej., udpv6 no disponible en un participante que solo soporta udpv4). Para evitar tales advertencias y asegurar conectividad confiable, configure preferencias de transporte explícitamente.

1. Defina los transportes permitidos en USER_QOS_PROFILES.xml agregando una máscara <transport_builtin> dentro de <participant_qos>:

<participant_qos> <transport_builtin> <mask>UDPV4|SHMEM</mask> </transport_builtin> </participant_qos> 

2. Cree un archivo NDDS_DISCOVERY_PEERS en el directorio de lanzamiento y liste las direcciones de peers que desea descubrir. Un ejemplo separado por comas que desactiva descubrimiento multicast es:

localhost,192.168.1.12,shmem:// 

Elección de la Capa RMW en ROS 2

Siempre establezca la variable de entorno RMW_IMPLEMENTATION a rmw_connext_cpp antes de iniciar nodos ROS 2:

export RMW_IMPLEMENTATION=rmw_connext_cpp 

O pásela en línea al lanzar un nodo:

RMW_IMPLEMENTATION=rmw_connext_cpp ros2 run demo_nodes_cpp talker 

Secuencias y Strings No Acotados

Algunos tópicos ROS 2 contienen secuencias o strings no acotados. Si su aplicación DDS necesita consumir o publicar estos tópicos, habilite "Unbounded Support" en el generador de código DDS. Consulte la documentación de RTI para cómo activar esta opción durante la generación de código.

Próximos Pasos con RTI

Cubriremos una brecha temporal en el conjunto de características actual de ROS 2 —grabación y reproducción de datos de tópico— en la próxima entrega de esta serie. Mientras tanto, si está listo para desplegar una solución ROS 2 robusta respaldada por DDS, contacte a nuestros expertos de RTI. Le ayudaremos a afinar su configuración y acelerar time-to-market.