¿Qué tan madura es la programación en tiempo real en robótica? [cerrado]

Editar: No sé por qué, pero esta pregunta parece confundir a muchas personas. Soy consciente de cuándo / dónde / por qué / cómo usar en tiempo real. Estoy interesado en saber si las personas que tienen una tarea en tiempo real realmente se preocuparían lo suficiente como para implementarla en tiempo real o no.

No es necesario mencionar por qué las operaciones en tiempo real son importantes para un robot. Mi pregunta es, sin embargo, ¿cuánto se usa realmente en robótica?

Toma esta pregunta por ejemplo. Solo una respuesta menciona cualquier plataforma con capacidades en tiempo real, y también está lejos de ser la mejor. Al parecer, ROS es una plataforma muy popular que no es en tiempo real.

Sin embargo, en el mundo en tiempo real, RTAI ¹ parece ser la única plataforma de uso en tiempo real gratuita y viable . Sin embargo, está limitado a Linux (sin problema), mal documentado y desarrollado lentamente.

Entonces, ¿cuánto se busca el comportamiento en tiempo real entre los desarrolladores de robótica?La pregunta es, ¿cuánto se inclinan los desarrolladores a escribir aplicaciones en tiempo real cuando realmente se necesita un comportamiento en tiempo real? Si no mucho, ¿por qué?

Por ejemplo, el comportamiento reflexivo basado en datos táctiles no puede pasar por ROS porque perdería su propiedad en tiempo real. ¿Pero la gente realmente encuentra una solución en tiempo real o usa ROS de todos modos, ignorando la propiedad en tiempo real?

¹ o similar Xenomai

Recuerde que hay tiempo real y hay tiempo real .

El tiempo real difícil es difícil de lograr sin soporte de hardware o soporte de software de bajo nivel, pero a menudo no necesita todo para ser capaz de tiempo real duro . La respuesta en tiempo real suave y firme es mucho más fácil de lograr y, a menudo, es más que adecuada para muchas aplicaciones.

Además, diferentes partes de un sistema pueden tener requisitos de tiempo real muy diferentes . Si está ejecutando bucles PID de software, realmente deberían tener una respuesta dura en tiempo real (realmente no desea tener que elegir entre ajustar sus PID o ajustarlos de manera suave y hacer que ocasionalmente se vuelvan inestables, por ejemplo). Un sistema de visión puede tener requisitos firmes de respuesta en tiempo real , el rendimiento se degradará si no puede procesar la imagen a tiempo para la próxima decisión, pero no necesita evitar que el sistema se ejecute, en este caso si no puede procesarlo a tiempo. es mejor tirar los resultados parciales y no perder el tiempo comenzando el análisis en el siguiente cuadro. Finalmente, su planificación y coordinación general (probablemente la más complejaparte de su sistema robótico) a menudo puede permanecer firmemente en el dominio del tiempo real suave .

Incluso en el ámbito de las PC con Windows, puede obtener un rendimiento duro en tiempo real , solo necesita el software correcto con los ganchos correctos en el núcleo. Beckhoff 's Twincat suave PLC corrió alegremente una alta velocidad de barrido del PLC por corte de la mitad de los ciclos de la máquina de un procesador Pentium, dando a la otra mitad a Windows NT, y esto fue hace más de una década. Incluso los sistemas de control modernos, como algunas opciones en la gama A3200 de Aerotech, hacen el trabajo duro en la PC host, ya que el kernel de bajo nivel toma tanto tiempo de CPU como necesita para los requisitos de tiempo real y deja el resto de los ciclos de CPU para Windows 7 ¡usar!

No se requiere realmente un sistema de tiempo real para muchos (¿la mayoría?) Sistemas de control robótico. Siempre que tenga un bucle de control que funcione lo suficientemente rápido, con una fluctuación lo suficientemente baja y no pierda demasiados ciclos, esto es bastante adecuado para el control robótico y el servo.

Como evidencia de esto, permítanme presentarles la PR2 y la Mano del Robot Sombra:

Este robot tiene unos 20 grados de libertad, todos los cuales son servidos a través del bucle principal de ROS. ¿O qué tal la Mano de Robot de Sombra, que también tiene 20 DOF, más una variedad de sensores táctiles y otros, y también se sirve a través del bucle principal de ROS.

El bucle principal de ROS sufre de una pequeña fluctuación, a veces hasta 100us, e incluso a veces pierde ciclos por completo. Pero no importa si el 99.9% de los ciclos se ejecutan con éxito.

El uso de muchos núcleos dentro de las PC host significa que un núcleo completo está dedicado a ejecutar el bucle principal, por lo que rara vez se retrasa por otras tareas.

La razón principal para usar un sistema operativo realmente en tiempo real para un sistema robótico es por seguridad. Si el robot está trabajando en una situación crítica de seguridad, es su responsabilidad garantizar el 100% de tiempo de actividad de control, y parte de esto es garantizar la naturaleza en tiempo real del mismo.

Ya sea que use un sistema operativo en tiempo real o no, sus servos deben hacer algo seguro en caso de que el bucle de control muera por completo. Este sistema de seguridad también sería útil en la rara ocasión en que su sistema operativo en tiempo no real omita más de un ciclo. Por ejemplo, en Shadow Hand, los motores se detienen si el bucle de control pierde más de 20 ciclos (20 ms). Sin embargo, nunca he visto que esto suceda.

Adicional

Otra forma de pensarlo es esta: ¿qué tasa de actualización necesita realmente su sistema servo? Si se trata de un brazo más grande y no necesita un rendimiento súper alto ni un posicionamiento de alta velocidad, entonces 500 Hz podrían ser suficientes. Para conducir, 200Hz es probablemente suficiente. En ambos casos, si su bucle realmente se está ejecutando a 1000Hz, entonces un ciclo tardío o faltante realmente no es ningún problema, siempre que su algoritmo de control tenga en cuenta el tiempo real transcurrido entre bucles.

El propósito del software determina si necesita ser estrictamente en tiempo real.

Cuando el propósito es la planificación o localización de rutas, a menudo es suficiente una baja frecuencia, por ejemplo, 10Hz. En estos casos, una configuración de jugador / escenario que se ejecuta en Linux está bien. Podemos ver que hay pocos problemas si un paso de tiempo es un poco más largo o más corto.

Se requiere un comportamiento estrictamente en tiempo real si la dinámica del robot es rápida. Por ejemplo, mover un brazo robótico para seguir una posición, o para manipular / agarrar objetos y moverlos. Si se pierde un paso de tiempo, la posición puede sobrepasarse indeseablemente, y podemos querer un comportamiento más predecible. En este caso, podemos tener una frecuencia de hasta 1 kHz o más. Si se utiliza un sistema operativo, queremos un sistema operativo en tiempo real.

El comportamiento en tiempo real se puede lograr en aplicaciones integradas, utilizando temporizadores e interrupciones (código C compilado en un microcontrolador). En este caso, debemos asegurarnos de que la carga de procesamiento no sea demasiado alta para que se pueda mantener una frecuencia de muestreo regular.

Los robots que usan computadoras / microprocesadores (porque se requiere más potencia de procesamiento), necesitarán usar un sistema operativo en tiempo real para garantizar altas tasas de muestreo.

Por lo tanto, si se requiere un comportamiento en tiempo real depende de para qué pretende utilizarlo el desarrollador.

Nuestra empresa construye robots con FreeRTOS que se ejecutan en microcontroladores PIC. Para nosotros, las razones principales para usar FreeRTOS es la facilidad de reorganizar las prioridades en las tareas, manejar múltiples líneas de comunicación simultáneamente y la comunicación fácil entre los manejadores de interrupciones y las tareas principales. Los microcontroladores son mucho más baratos que poner una máquina Linux completa en cada robot que producimos también.

Si realmente necesita en tiempo real, entonces utiliza un sistema operativo en tiempo real. La supervisión de seguridad, la adquisición de datos y los bucles de control de frecuencia de muestreo constante son subsistemas comunes que utilizan la programación en tiempo real.

La parte de la programación en tiempo real suele ser lo más pequeña posible, porque es más difícil de depurar y es menos fácil verificar que el código sea más correcto. La documentación sobre sistemas operativos en tiempo real suele ser bastante buena (incluyendo RTAI / Xenomai).

He usado QNX y RTAI-> Xenomai en diferentes proyectos de robótica real . Preferí QNX pero Xenomai fue igual de efectivo.

Orocos es un marco maduro de software de control de robótica en tiempo real. He visto que solía controlar con éxito manipuladores robóticos de alta velocidad con requisitos difíciles en tiempo real. Tiene muchos de los mismos componentes de nivel de marco que ROS, comunicaciones, configuración, serialización y empaquetado basado en componentes.

Comience a pensar en su robot en términos de múltiples CPU y los cambios de preguntas en tiempo real. Si tiene un algoritmo que necesita retroalimentación confiable de alta velocidad, como un equilibrador de dos ruedas o un estabilizador quad-copter o un servo pulso, el tiempo real es extremadamente importante, pero la tarea también es muy limitada.

Puede descargar un bucle de control como este en una CPU dedicada en tiempo real, como el AVR económico de 8 bits o los ARM de 32 bits de gama baja que se encuentran en la clase de dispositivos Arduino. No hay nada que le impida agregar muchas docenas de estas pequeñas MCU que ejecutan bucles de control dedicados, la enumeración de dispositivos USB incluso lo hace fácil.

Ahora que tiene los bucles de control sensibles al tiempo manejados por una CPU dedicada, puede relajar las necesidades en tiempo real del 'cerebro' del robot que puede ejecutar una lógica de extremo superior utilizando componentes como ROS en Linux o Kinect para Windows.

En respuesta a "cuándo / en qué caso" se utilizan sistemas en tiempo real:

En mi experiencia, el control de movimiento es la aplicación principal para sistemas en tiempo real. Para controlar motores, es importante una alta frecuencia (100Hz, 1000Hz y más) y baja fluctuación (variaciones de tiempo). La seguridad es un gran punto aquí. Considere un robot entre humanos: por ejemplo, desea / necesita asegurarse de que el robot (brazo) se detenga en un marco de tiempo / distancia específico.

Para otras tareas, como la planificación de rutas, el procesamiento de la visión y el sistema de razonamiento en tiempo real, no son tan importantes y a menudo se evitan debido a la sobrecarga en el tiempo de desarrollo y los costos de hardware.

Hoy en día, los grandes robots como el PR2 combinan ambos mundos. En el contexto en tiempo real del sistema operativo habilitado para RT (por ejemplo, Linux + Xenomai), el control de movimiento está ocurriendo y en la parte no en tiempo real (tierra del usuario), el procesamiento y la planificación de la visión están integrados en sistemas como ROS. Ambos pueden ejecutarse en la misma computadora.

Me complace editar esta respuesta, una vez que la pregunta ha sido aclarada. :-)

Sí, suponiendo que los recursos de hardware puedan cumplir con los requisitos de tiempo (potencia de procesamiento suficiente, latencia lo suficientemente baja), cuando el planificador no puede secuenciar procesos y subprocesos adecuadamente, entonces se usa un planificador en tiempo real, generalmente conectado a un núcleo específicamente optimizado para el desafíos de esto. Los controladores de hardware también se pueden optimizar para condiciones en tiempo real.

Sí, si no se puede garantizar que el software haga su trabajo en las limitaciones de tiempo requeridas, entonces se utilizan enfoques en tiempo real.

Una buena solución es hacer AMBOS. Un diseño que uso coloca funciones "duras" en tiempo real en un pequeño microcontrolador, circuitos de servocontrol estrechos y demás. Luego hay otra CPU que es más grande, que ejecuta Linux y ROS. Dejo que ROS se encargue de las tareas de nivel superior y el uP maneja cosas como controlar un motor paso a paso o ejecutar un bucle PID.

Como lo han dicho otros, PUEDE permitir que un sistema operativo que no sea en tiempo real ejecute bucles de control de 1KHz, pero para que esto funcione, necesita una computadora de tamaño bruto que pasa la mayor parte del tiempo en un bucle inactivo. Si ejecuta la computadora Linux / ROS con una utilización de CPU cercana al 100%, el rendimiento en tiempo real es deficiente. El uso de un diseño de dos niveles le permite obtener siempre un rendimiento de RT muy bueno y también usar una computadora más pequeña y que consume menos energía (posiblemente tareas de nivel superior Pi2). Actualmente, mi uP no ejecuta ningún sistema operativo, pero me estoy mudando a FreeRTOS