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

20

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 1 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?

1 o similar Xenomai

Shahbaz
fuente
1
Creo que esta es una gran pregunta. Considere dividirlo en dos y aclarar su pregunta principal. '¿Se puede usar ROS en tiempo real?' o '¿Se usa ROS en tiempo real?' (2 preguntas diferentes) están separadas de su pregunta principal.
hauptmech
@hauptmech, bueno, ROS ciertamente no se puede usar en tiempo real, ¡ya que no lo es!
Shahbaz
Estoy de acuerdo con @hauptmech. Las preguntas son confusas. En la parte superior, está preguntando, cuántas personas / con qué frecuencia se utilizan los sistemas en tiempo real y luego pregunta cuándo / en qué caso . Ambas son buenas preguntas, así que divídalas en dos o reduzca a una. ¡Gracias!
bit-pirate el
@ bit-pirate, no entiendo por qué dices que pregunté cuándo / en qué caso . Nunca pregunté tal cosa. Como dije La pregunta es, ¿cuánto se inclinan los desarrolladores a escribir aplicaciones en tiempo real cuando realmente se necesita un comportamiento en tiempo real? En otras palabras, ¿qué porcentaje de las aplicaciones que hacen requerir comportamiento en tiempo real, son realmente implementados en tiempo real? Personalmente, sé cuándo y en qué caso se necesita un comportamiento en tiempo real y no tengo absolutamente ninguna duda al respecto. De hecho, me sorprende ver respuestas que lo explican .
Shahbaz
¡Gracias por la aclaración! Para mí, el título fue confuso. La implementación + programación en tiempo real de IMO está madura en robótica, pero implica más esfuerzos (tiempo, dinero, habilidad, etc.), por lo que la mayoría de las personas lo evitan, cuando no es realmente necesario.
bit-pirate

Respuestas:

10

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!

Mark Booth
fuente
La distinción aquí es bastante pertinente ... incluso en sistemas de bajo nivel del "mundo real", el bit en tiempo real es bastante pequeño (basado en una interrupción de tic del temporizador) mientras que la mayoría del sistema es nominalmente en tiempo real (pero + / - unos pocos nanosegundos aquí y allá es tolerable). Sonrío cuando veo gente hablando de aplicaciones en tiempo real creadas en WindowsCE o Linux ...
Andrew
1
Como digo @Andrew con el software adecuado, incluso Windows 7 se puede hacer difícil en tiempo real con un RTX . Sin embargo, no estoy seguro de por qué no considera que Windows CE sea en tiempo real, ya que tiene una programación determinista de tareas en tiempo real ya que la versión 2 y Linux se pueden hacer en tiempo real con un núcleo como RTLinux .
Mark Booth
Hola de nuevo la marca (no estoy seguro que está acechando que aquí ...) - Estoy de acuerdo que puede hacerlo, pero dura experiencia ha demostrado que en muchos casos los usuarios (manager) ignoran los complementos necesarios y asumir (la mayoría?)? que hará el sistema de vainilla.
Andrew
@ Andrew - Mi experiencia con RTX fue que simplemente funcionó . De vuelta en el Pentium 4 días, tenía que tener cuidado de no usar gráficos o audio integrados que saturaran el bus PCI, pero eso no debería ser un problema en estos días.
Mark Booth
Ha pasado mucho tiempo, pero al leer esta página, especialmente en lo que respecta a las ventanas, me gustaría decir que solo mencionas parte de cómo se hace un sistema en tiempo real. La programación en tiempo real es importante, por supuesto, pero hay todo tipo de cosas que pueden generar picos que también deben manejarse para hacer que un sistema sea en tiempo real. Las interrupciones son el ejemplo común, SMI, cachés y ancho de banda de memoria son otros ejemplos. El hecho de que haya un planificador en tiempo real no hace que un sistema sea en tiempo real.
Shahbaz
8

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:

PR2

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.

Rocketmagnet
fuente
En resumen, ¿está diciendo que a menudo no se usa el tiempo real, porque el software que no es en tiempo real funciona "suficientemente bien"?
Shahbaz
@Shahbaz: no puedo comentar exactamente con qué frecuencia se usa realmente, pero puedo decir que si se usa, puede ser innecesario. Solíamos usar RTAI, luego lo abandonamos porque en realidad estaba obstaculizando más que ayudando.
Rocketmagnet
1
Me gustaría enfatizar un punto: tiene tanta potencia de procesamiento en el PR2 que podría obtener algo "suficientemente bueno". Trabajé en un robot con "solo" un Core2 Duo. Esa no es una opción allí: la pila completa toma cada núcleo 100% la mayor parte del tiempo. Aquí, Rock (Orocos) y RT-Linux fueron necesarios para mantener unido el bucle de control de 1 kHz.
sylvain.joyeux
@ sylvain.joyeux - Estoy de acuerdo. ROS funciona bastante mal para el control cuando solo tienes 2 núcleos.
Rocketmagnet
@Rocketmagnet Lamento tener que rechazar este, pero la parte PR2 está mal. En el PR2 hay un único bucle en tiempo real que se ejecuta a 1000 Hz en paralelo a ROS (en Linux + RT PREEMPT), que se comunica a través de Ethercat con las placas del controlador del motor, haciendo el control real del motor de cada DOF. Debe tener cuidado al programar controladores (por ejemplo, un controlador de trayectoria conjunta) para no interrumpir en tiempo real y también tienen herramientas especiales para administrarlos (por ejemplo, cargarlos / descargarlos). Mira aquí para más detalles.
bit-pirate el
4

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.

ronalchn
fuente
Gracias por la respuesta. Tal vez mi pregunta necesita una mejor redacción, pero no quería preguntar "cuándo usar el tiempo real", sino "con qué frecuencia las personas usan el tiempo real cuando es necesario". Sin embargo, su comportamiento en tiempo real en microcontroladores, sin la necesidad de una plataforma en tiempo real, fue un buen punto que no había considerado.
Shahbaz
En una nota al margen, en tiempo real y rápido son dos conceptos ortogonales. Si un planificador de ruta tiene que decidir estrictamente dentro de un minuto, entonces es una aplicación en tiempo real. Aunque entiendo por qué mencionarías un robot rápido.
Shahbaz
2

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.

Crake
fuente
2

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.

hauptmech
fuente
2

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.

Joe
fuente
2

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.

Jay Beavers
fuente
0

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. :-)

pirata
fuente
0

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.

hauptmech
fuente
0

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

usuario3150208
fuente