¿Cómo puedo controlar un sistema en tiempo real rápido (200Hz) con un sistema lento (30Hz)?

Actualmente estamos diseñando un robot móvil + brazo montado con múltiples grados controlados de libertad y sensores.

Estoy considerando una arquitectura en dos partes:

1. Un conjunto de controladores en tiempo real (ya sea Raspeberry Pis que ejecuta un RTOS como Xenomai o microcontroladores de metal desnudo) para controlar los motores y codificadores del brazo. Llamemos a estas máquinas RTx, con x = 1,2,3 ... dependiendo del número de microcontroladores. Este bucle de control se ejecutará a 200Hz.

2. Una potente máquina Linux de vainilla que ejecuta ROS para calcular SLAM, mocap y ejecutar lógica de alto nivel (decidir la tarea del robot y calcular la posición y velocidad deseadas de los motores). Este bucle de control se ejecutará a 30Hz.

Sé que mi marco debe ser escalable para tener en cuenta más motores, más sensores, más PC (por ejemplo, para mocap externo).

Mi principal problema es decidir cómo hacer que los diferentes RTx se comuniquen con PC1. He examinado documentos relacionados con la arquitectura de robots (por ejemplo, HRP2 ), la mayoría de las veces describen la arquitectura de control de alto nivel, pero aún no he encontrado información sobre cómo hacer que el nivel bajo se comunique con el nivel alto y de forma escalable. ¿Me he perdido algo?

Para conectar las máquinas RT rápidas que aseguran el control del motor con PC1, he considerado TCP / IP, CAN y UART:

• TCP / IP: no determinista pero fácil de implementar. ¿Es el no determinismo un problema real (ya que de todos modos solo se usará a una velocidad lenta de 30Hz)?
• CAN: lento, muy confiable, dirigido a automóviles (he visto que hay algunos ejemplos que usan CAN con robots pero se veía exótico)
• UART: si solo hubiera tenido una máquina RT para el control del motor, habría considerado UART pero supongo que este puerto no escala bien con muchas RTx ¿Es realmente TCP / IP un no ir debido a sus características no deterministas? Es tan facil de usar…

Por el momento, ninguna solución realmente me parece obvia. Y como no puedo encontrar ningún ejemplo serio de robot usando una solución específica confiable y escalable, no me siento seguro de tomar una decisión.

¿Alguien tiene una visión clara sobre este punto o literatura para señalar? ¿Existen soluciones de comunicación típicas o convencionales utilizadas en los robots?

Creo que has dado un buen primer paso; ha dividido el problema en una plataforma móvil (que tiene incertidumbre de posición y debe navegar) y el brazo (que tiene una buena certeza de posición en tiempo real, a través de codificadores).

He examinado documentos relacionados con la arquitectura de robots [...] pero todavía no he encontrado información sobre cómo hacer que el nivel bajo se comunique con el nivel alto y de forma escalable. ¿Me he perdido algo?

Según su descripción, parece que está tratando de vincular cada controlador RTx directamente a la PC1, que ejecuta ROS. Lo que se ha perdido es que ROS está diseñado para manejar un grupo de aplicaciones que pueden producir y consumir datos a diferentes velocidades.

Lo que su aplicación necesita es un puente de comunicaciones : una interfaz única entre su bucle de 200Hz y su entorno ROS. En otras palabras, en lugar de atar cada controlador RTX PC1, atar todos los controladores de TxR juntos y conectar que a PC1.

Por ejemplo, use un bus I2C para vincular los sistemas RTx y agregue otro controlador RTx para ser el "Arm Master" (AM). El trabajo de la AM sería aceptar los comandos entrantes en algún formato y protocolo compatible con PC1, y convertir esos comandos en mensajes I2C. Luego escribirías una aplicación ROS para enviar comandos a la AM.

Otra forma de hacerlo con I2C sería colocar un controlador I2C directamente en la PC1 y escribir toda la lógica de control del brazo en una aplicación ROS. Esto puede parecer una forma más ágil de lograr su objetivo, pero puede dificultar la depuración a medida que elimina la modularidad del sistema; tendrá que solucionarlo como un gran sistema complejo en lugar de dos componentes fácilmente comprobables.

Yo diría que cualquier aplicación donde se requiera una gran cantidad de nodos de comunicaciones (sensores o actuadores) se beneficiaría de implementarse como un bus del sistema (en contraste con los enlaces punto a punto como UART o Ethernet), debido a la complejidad del cableado, el determinismo y modularidad.

Cualquier sistema de control requiere un alto grado de determinismo, en el que los canales de ancho de banda alto (como Ethernet) generalmente son deficientes (especialmente cuando se usa con un sistema operativo de propósito general que introduce grandes cantidades de fluctuación de programación, consulte el siguiente enlace para una discusión sobre el determinismo de programación ) Los procesadores de aplicaciones (como el ARM11 de la Raspberry Pi) también probablemente no se ajustan a los sistemas en tiempo real (debido a efectos como la latencia de interrupción y el revestimiento de la tubería de instrucciones). Vea la siguiente discusión digikey que compara el comportamiento en tiempo real de un núcleo de aplicación ARM frente a un microcontrolador .

Es una pena que la disponibilidad de CAN integrado no esté tan extendida como UART (RS-485) o I2C (todavía), porque creo que realmente simplifica el problema de la detección distribuida y la actuación. Y aunque el 1 Mbps habitual puede parecer lento, generalmente es más que suficiente después de calcular las frecuencias de actualización de todos los miembros del bus (y la velocidad de transmisión siempre se puede aumentar, dependiendo de la longitud del bus, la impedancia y si sus transceptores lo permitirán). También hay un brillante software de simulación disponible, que básicamente garantiza los peores tiempos de respuesta del caso (por ejemplo, RealTime-at-work tiene un analizador de bus CAN gratuito llamado RTaW-Sim). Y finalmente, parece que la disponibilidad de sensores MEMS con CAN integrado es bastante pobre.

Otro ejemplo donde los actuadores están configurados como un bus (o anillo), es la serie Dynamixels AX y MX, donde cada motor está conectado en cadena al siguiente a través de un enlace UART. Esto simplifica enormemente el diseño del sistema si tiene una gran cantidad de actuadores.

Pero, para volver a la pregunta real, creo que si describe su sistema como puntos de ajuste en tiempo real, en lugar de comandos (p. Ej., Difunde continuamente un ángulo del motor en lugar de instruir un comando como goto angle), simplifica el acoplamiento entre el lazo de 200 Hz y 30 Hz.

Parece que tiene 2 problemas separados (pero relacionados) que está tratando de resolver a la vez. Desglosemos su enigma en pedazos más pequeños:

1. ¿Cómo comunico los comandos de un sistema lento (30Hz) a un controlador rápido (200Hz), y cómo comunico los datos que se reciben a 200Hz de vuelta a mi thinktank de 30Hz?
2. ¿Cómo controlo lo que sucede a 200Hz, cuando solo puedo decirle al robot qué hacer a 30Hz?

El elemento 1 se puede resolver en hardware como parece indicar su pregunta original: puede poner en cola los datos a 200Hz y enviar el paquete a 30Hz a su sistema de nivel superior. Puede hacer esto con TCP / IP, o posiblemente CAN, dependiendo de la cantidad de datos que desee enviar. Diferente hardware tiene diferentes velocidades máximas de datos. Agregar un nivel de arquitectura como ROS para actuar como puente de comunicación / árbitro como se sugiere en otras publicaciones también puede ayudar.

El ítem 2 es un problema de teoría de control que no se puede resolver solo con hardware. El SLAM, las determinaciones de posición y velocidad y la determinación de tareas que desee deberán ser más inteligentes, ya que envían y reciben información con menos frecuencia. Probablemente desee 2 bucles de control : 1 a 200Hz y 1 a 30Hz.

Hay muchas otras preguntas que cubren los bucles de control de avance, retroalimentación y PID, pero usted preguntó específicamente sobre la escalabilidad, la forma en que la mayoría de los sistemas gigantes escalan es superponiendo los bucles de control y la lógica para que la información mínima necesaria atraviese cualquier hardware terminas con Por ejemplo, su controlador de nivel superior solo puede dar puntos de posición de objetivo y una velocidad promedio de objetivo al nivel inferior, no cambiar la velocidad 30 veces por segundo.