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

20

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

1 ou similarmente Xenomai

Shahbaz
fonte
11
Eu acho que essa é uma ótima pergunta. Considere dividi-lo em dois e esclareça sua pergunta principal. 'O ROS pode ser usado em tempo real?' ou 'O ROS é usado em tempo real?' (2 perguntas diferentes) são separadas da sua pergunta principal.
hauptmech
@hauptmech, bem, o ROS certamente não pode ser usado em tempo real, pois não é!
Shahbaz
Eu concordo com @hauptmech. As perguntas são confusas. No topo, você está perguntando, quantas pessoas / quantas vezes os sistemas em tempo real são usados ​​e, posteriormente, quando, quando / em que caso . Ambas são boas perguntas, portanto, divida-as em duas ou reduza para uma. Obrigado!
Pirate-bit
@ pirata de bit, não entendo por que você diz que perguntei quando / nesse caso . Eu nunca perguntei isso. Como eu disse A pergunta é: quanto os desenvolvedores tendem a escrever aplicativos em tempo real quando o comportamento em tempo real é realmente necessário? Em outras palavras, qual a percentagem de aplicações que fazer exigem comportamento em tempo real, são realmente implementadas em tempo real? Eu pessoalmente sei quando e nesse caso o comportamento em tempo real é necessário e não tenho absolutamente nenhuma dúvida sobre esse assunto. De fato, estou surpreso ao ver respostas explicando isso .
precisa
Obrigado pelo esclarecimento! Para mim, o título foi confuso. A programação em tempo real da IMO + a implementação está madura na robótica, mas envolve mais esforços (tempo, dinheiro, habilidade etc.), para que a maioria das pessoas evite isso, quando não for realmente necessário.
Pirate-bit

Respostas:

10

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!

Mark Booth
fonte
A distinção aqui é bastante pertinente ... mesmo em sistemas de baixo nível do "mundo real", o bit em tempo real é bastante pequeno (com base em uma interrupção do temporizador), enquanto a maioria do sistema é nominalmente em tempo real (mas + / - alguns nanossegundos aqui e ali são toleráveis). Sorrio quando vejo pessoas conversando sobre aplicativos em tempo real criados no WindowsCE ou Linux ...
Andrew
11
Como digo @Andrew com o software certo, até o Windows 7 pode ser dificultado em tempo real com um RTX . Porém, não sei por que você não considera o Windows CE em tempo real; ele possui agendamento determinístico de tarefas em tempo real, já que a versão 2 e o Linux podem ser feitos em tempo real com um kernel como RTLinux .
Mark Booth
Olá novamente Mark (não tenho certeza de quem está perseguindo quem aqui ...) - Concordo que você pode fazê-lo, mas a experiência dura mostrou que em muitos casos (? A maioria?) Os usuários (gerentes) ignoram os complementos necessários e assumem que o sistema de baunilha fará.
Andrew
@ Andrew - Minha experiência com o RTX foi que apenas funcionou . Nos quatro dias do Pentium, você precisava tomar cuidado para não usar gráficos ou áudio integrados que saturassem o barramento PCI, mas isso não deve ser um problema nos dias de hoje.
Mark Booth
Já faz muito tempo, mas lendo esta página, especialmente no que diz respeito ao Windows, gostaria de dizer que você está mencionando apenas parte de como um sistema é feito em tempo real. A programação em tempo real é importante, é claro, mas há todo tipo de coisa que pode gerar picos que também precisam ser manipulados para criar um sistema em tempo real. Interrupções são o exemplo comum, SMI, caches e largura de banda da memória são outros exemplos. Só porque existe um agendador em tempo real não cria um sistema em tempo real.
Shahbaz
8

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:

PR2

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.

Rocketmagnet
fonte
Então, resumindo, você está dizendo que o tempo real geralmente não é usado, porque o software não em tempo real funciona "suficientemente bom"?
Shahbaz
@ Shahbaz - Não posso comentar exatamente com que frequência ele é realmente usado, mas posso dizer que, se for usado, pode ser desnecessário. Costumávamos usar o RTAI, depois o abandonávamos, porque na verdade estava atrapalhando mais do que ajudando.
Rocketmagnet
11
Gostaria de enfatizar um ponto: você tem tanto poder de processamento no PR2 que pode obter algo "bom o suficiente". Eu trabalhei em um robô com "apenas" um Core2 Duo. Essa não é uma opção: a pilha completa está consumindo cada núcleo 100% na maior parte do tempo. Aqui, Rock (Orocos) e RT-Linux eram necessários para manter o loop de controle de 1kHz juntos.
sylvain.joyeux
@ sylvain.joyeux - eu concordo. O ROS tem um desempenho muito ruim para controle quando você possui apenas 2 núcleos.
Rocketmagnet
@Rocketmagnet Lamento ter que rebaixar esta, mas a parte PR2 está errada. No PR2, há um único loop em tempo real rodando a 1000Hz paralelo ao ROS (no Linux + RT PREEMPT), que está se comunicando via Ethercat com as placas controladoras do motor, realizando o controle real do motor de cada DOF. Você deve ter cuidado ao programar controladores (por exemplo, um controlador de trajetória conjunta) para não interromper o tempo real e eles também têm ferramentas especiais para gerenciá-los (por exemplo, carregar / descarregar). Veja aqui mais detalhes.
Pirate-bit
4

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.

ronalchn
fonte
Obrigado pela resposta. Talvez minha pergunta precise de uma redação melhor, mas não queria perguntar "quando usar em tempo real", mas "com que frequência as pessoas realmente usam em tempo real quando é necessário em tempo real". No entanto, seu comportamento em tempo real nos microcontroladores, sem a necessidade de uma plataforma em tempo real, foi um bom ponto que eu não havia considerado.
Shahbaz
Em uma nota lateral, em tempo real e rápido são dois conceitos ortogonais. Se um planejador de caminho precisa decidir estritamente em um minuto, é um aplicativo em tempo real. Embora eu entenda por que você mencionaria um robô rápido.
21412 Shahbaz
2

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.

Crake
fonte
2

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.

hauptmech
fonte
2

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.

Joe
fonte
2

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.

Jay Beavers
fonte
0

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

pirata de bit
fonte
0

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.

hauptmech
fonte
0

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

user3150208
fonte