Qual a maturidade da programação em tempo real em robótica? [fechadas]

Edit: Eu não sei por que, mas esta pergunta parece estar confundindo muitas pessoas. Estou ciente de quando / onde / por que / como usar em tempo real. Estou interessado em saber se as pessoas que têm uma tarefa em tempo real se importariam o suficiente para implementá-la em tempo real ou não.

Não é necessário mencionar por que as operações em tempo real são importantes para um robô. Minha pergunta é, no entanto, quanto é realmente usada em robótica?

Veja esta pergunta, por exemplo. Apenas uma resposta menciona qualquer plataforma com recursos em tempo real e também está longe do topo. Aparentemente, o ROS é uma plataforma muito popular que não é em tempo real.

No mundo em tempo real, no entanto, o RTAI ¹ parece ser a única plataforma de uso em tempo real gratuita e viável . No entanto, é limitado ao Linux (sem problemas), mal documentado e desenvolvido lentamente.

Então, quanto é procurado o comportamento em tempo real entre os desenvolvedores de robótica?A questão é: quanto os desenvolvedores tendem a escrever aplicativos em tempo real quando o comportamento em tempo real é realmente necessário? Se não muito, por quê?

Por exemplo, o comportamento reflexivo baseado em dados táteis, não pode passar pelo ROS porque perderia sua propriedade em tempo real. Mas as pessoas realmente apresentam uma solução em tempo real ou usam o ROS de qualquer maneira, ignorando a propriedade em tempo real?

¹ ou similarmente Xenomai

Lembre-se de que há tempo real e tempo real .

É difícil obter tempo real difícil sem suporte de hardware ou suporte de software de baixo nível, mas muitas vezes você não precisa de tudo para ter capacidade para tempo real . A resposta em tempo real suave e firme é muito mais fácil de obter e geralmente é mais do que adequada para muitas aplicações.

Além disso, diferentes partes de um sistema podem ter requisitos muito diferentes em tempo real . Se você estiver executando loops de PID de software, eles realmente devem ter uma resposta difícil em tempo real (você realmente não deseja escolher entre ajustar suavemente seus PIDs ou ajustá-los com força e fazê-los ocasionalmente ficar instáveis, por exemplo). Um sistema de visão pode ter requisitos firmes de resposta em tempo real ; o desempenho diminuirá se você não puder processar a imagem a tempo da próxima decisão, mas não precisará impedir a execução do sistema; nesse caso, se você não puder processá-la a tempo. é melhor jogar fora os resultados parciais e não perder tempo iniciando a análise no próximo quadro. Finalmente, seu planejamento e coordenação geral (provavelmente o mais complexoparte do seu sistema robótico) pode permanecer firmemente no domínio do tempo real suave .

Mesmo nos PCs com Windows, você pode obter um desempenho difícil em tempo real , basta o software certo com os ganchos certos no kernel. O CLP macio TwinCat da Beckhoff executou muito bem um CLP de alta taxa de varredura, cortando metade dos ciclos de máquina do Pentium, dando a outra metade para o Windows NT, e isso foi há mais de uma década. Até sistemas de controle modernos, como algumas opções da linha A3200 da Aerotech, fazem o trabalho pesado no PC host, com o kernel de baixo nível demorando o tempo de CPU necessário para os requisitos de tempo real e deixando o restante dos ciclos de CPU para o Windows 7 usar!

Um sistema em tempo real não é realmente necessário para muitos (a maioria?) Sistemas de controle robótico. Contanto que você tenha um loop de controle que seja rápido o suficiente, com jitter baixo o suficiente e não perca muitos ciclos, isso será adequado para o controle robótico e servo.

Como prova disso, deixe-me apresentar o PR2 e o Shadow Robot Hand:

Este robô tem cerca de 20 graus de liberdade, todos servidos pelo loop principal do ROS. Ou o Shadow Robot Hand, que também possui 20 DOFs, além de uma variedade de sensores táteis e outros, e também é servo através do loop principal do ROS.

O loop principal do ROS sofre um pouco de instabilidade, às vezes até 100us, e às vezes perde completamente os ciclos. Mas não importa se 99,9% dos ciclos são executados com sucesso.

O uso de muitos núcleos nos PCs host significa que um núcleo inteiro é dedicado à execução do loop principal e, portanto, raramente é adiado por outras tarefas.

O principal motivo para usar um sistema operacional em tempo real para um sistema robótico é por segurança. Se o robô estiver trabalhando em uma situação crítica de segurança, é de sua responsabilidade garantir 100% do tempo de atividade do controle, e parte disso é garantir a natureza em tempo real do mesmo.

Se você usa um sistema operacional em tempo real ou não, seus servos devem fazer algo seguro caso o loop de controle morra completamente. Esse sistema de segurança também seria útil nas raras ocasiões em que seu sistema operacional não em tempo real pula mais de um ciclo. Por exemplo, no Shadow Hand, os motores são interrompidos se o loop de controle falhar mais de 20 ciclos (20ms). Eu nunca vi isso acontecer embora.

Adicionado

Outra maneira de pensar sobre isso é: Que taxa de atualização o seu sistema servo realmente precisa? Se for um braço largo e não precisar de desempenho super alto, posicionamento em alta velocidade, 500Hz poderá ser suficiente. Para dirigir, 200Hz é provavelmente suficiente. Nos dois casos, se seu loop estiver realmente funcionando a 1000Hz, um ciclo atrasado ou ausente realmente não será problema, desde que o algoritmo de controle leve em consideração o tempo decorrido real entre os loops.

O objetivo do software determina se ele precisa ser estritamente em tempo real.

Onde o objetivo é o planejamento ou localização de caminhos, geralmente uma frequência baixa é suficiente, por exemplo, 10Hz. Nesses casos, uma configuração de player / estágio em execução no Linux está correta. Podemos ver que existem poucos problemas se uma etapa for um pouco mais longa ou mais curta.

É necessário um comportamento estritamente em tempo real se a dinâmica do robô for rápida. Por exemplo, mover um braço robótico para rastrear uma posição ou manusear / segurar objetos e movê-los. Se um passo no tempo for perdido, a posição poderá ultrapassar indesejáveis, e podemos querer um comportamento mais previsível. Nesse caso, podemos ter uma frequência de até 1kHz ou mais. Se um sistema operacional for usado, queremos um sistema operacional em tempo real.

O comportamento em tempo real pode ser realizado em aplicativos incorporados, usando temporizadores e interrupções (código C compilado em um microcontrolador). Nesse caso, devemos garantir que a carga de processamento não seja muito alta para que uma frequência de amostragem regular possa ser mantida.

Os robôs que usam computadores / microprocessadores (porque é necessário mais poder de processamento), precisarão usar um sistema operacional em tempo real para garantir altas taxas de amostragem.

Portanto, se o comportamento em tempo real é necessário, depende do motivo pelo qual o desenvolvedor pretende usá-lo.

Nossa empresa cria robôs usando o FreeRTOS rodando em microcontroladores PIC. Para nós, os principais motivos para usar o FreeRTOS são a facilidade de reorganizar as prioridades nas tarefas, manipular várias linhas de comunicação simultaneamente e facilitar a comunicação entre os manipuladores de interrupção e as tarefas principais. Microcontroladores são muito mais baratos do que colocar uma máquina linux completa em cada robô que produzimos também.

Se você realmente precisar de tempo real, use um sistema operacional em tempo real. O monitoramento de segurança, a aquisição de dados e os loops de controle de taxa de amostragem constante são subsistemas comuns que usam programação em tempo real.

A parte da programação em tempo real é geralmente a menor possível, porque é mais difícil depurar e menos código é mais fácil de verificar a exatidão. A documentação em sistemas operacionais em tempo real geralmente é muito boa (incluindo RTAI / Xenomai).

Eu usei o QNX e o RTAI-> Xenomai em diferentes projetos de robótica real . Eu preferia o QNX, mas o Xenomai era igualmente eficaz.

Orocos é uma estrutura madura de software de controle de robótica em tempo real. Eu já o vi usado para controlar com êxito manipuladores robóticos de alta velocidade com requisitos rígidos em tempo real. Ele possui muitos dos mesmos componentes no nível da estrutura que ROS, comunicações, configuração, serialização e empacotamento baseado em componentes.

Comece a pensar no seu robô em termos de várias CPUs e a pergunta em tempo real muda. Se você possui um algoritmo que precisa de feedback confiável em alta velocidade, como um balanceador de duas rodas, um estabilizador de quatro rodas ou um servo pulsado, o tempo real é extremamente importante, mas a tarefa também é muito limitada.

Você pode descarregar um loop de controle como esse para uma CPU em tempo real dedicada, como o AVR barato de 8 bits ou os ARMs baixos de 32 bits encontrados na classe de dispositivos Arduino. Não há nada que o impeça de adicionar muitas dezenas desses pequenos MCUs executando loops de controle dedicados; a enumeração de dispositivos USB facilita isso.

Agora que você tem os loops de controle sensíveis ao tempo processados ​​por uma CPU dedicada, pode relaxar as necessidades em tempo real do 'cérebro' do robô, que pode executar lógica de ponta usando componentes como o ROS no Linux ou o Kinect para Windows.

Em resposta a "quando / nesse caso" sistemas em tempo real são usados:

Na minha experiência, o controle de movimento é a principal aplicação para sistemas em tempo real. Para o controle de motores, são importantes alta frequência (100Hz, 1000Hz e mais) e baixa instabilidade (variações de tempo). A segurança é um grande ponto aqui. Considere um robô entre humanos: por exemplo, você deseja / precisa garantir que o robô (braço) pare em um período / distância específica.

Para outras tarefas, como planejamento de caminho, o processamento da visão e o sistema de raciocínio em tempo real não são tão importantes e muitas vezes evitados devido à sobrecarga no tempo de desenvolvimento e nos custos de hardware.

Atualmente, grandes robôs como o PR2 combinam os dois mundos. No contexto em tempo real do sistema operacional ativado por RT (por exemplo, Linux + Xenomai), está ocorrendo controle de movimento e, na parte não em tempo real (terra do usuário), o processamento e o planejamento da visão são incorporados em sistemas como o ROS. Ambos podem ser executados no mesmo computador.

Fico feliz em editar esta resposta, depois que a pergunta for esclarecida. :-)

Sim, supondo que os recursos de hardware possam atender aos requisitos de tempo (poder de processamento suficiente, latência baixa o suficiente), quando o planejador não pode sequenciar processos e encadeamentos adequadamente, então utiliza-se um planejador em tempo real, geralmente conectado a um kernel otimizado especificamente para o desafios disso. Os drivers de hardware também podem ser otimizados para condições em tempo real.

Sim, se não for possível garantir que um software faça seu trabalho nas restrições de tempo exigidas, então usaremos abordagens em tempo real.

Uma boa solução é fazer AMBOS. Um projeto que eu utilizo coloca funções "duras" em tempo real em um pequeno microcontrolador, circuitos de servo controle apertados e outros. Depois, há outra CPU maior, executando Linux e ROS. Deixei o ROS lidar com as tarefas de nível superior e a UP lidar com coisas como controlar um motor de passo ou executar um loop PID.

Como já foi dito por outras pessoas, você PODE permitir que um sistema operacional não em tempo real execute loops de controle de 1 KHz, mas para que isso funcione, é necessário um computador de tamanho exagerado que passe a maior parte do tempo em um loop inativo. Se você executar o computador Linux / ROS com quase 100% de utilização da CPU, o desempenho em tempo real será baixo. Usar um design de duas camadas permite obter sempre um desempenho RT muito bom e também usar um computador menor e com menos consumo de energia (possivelmente tarefas de nível superior Pi2). Atualmente, meu uP não executa nenhum sistema operacional, mas estou migrando para o FreeRTOS