Vou construir um pequeno sistema de robô , e parece que o ROS serve uma boa estrutura para controlar e programar o sistema.

No entanto, gostaria de saber qual é a melhor prática para gerenciar os componentes do meu robô.

• Faz sentido colocar todos os sensores em um nó?

• Devo colocar apenas os sensores do mesmo tipo em um nó ou é melhor ter um nó para um sensor?

• É uma boa prática ter algum tipo de nó manipulador, que receba informações dos sensores e direcione os atuadores correspondentes ou os nós do atuador e os sensores devem se comunicar diretamente?

1. Nós sensores sensores e nós atuadores com manipulador

2. Nós de sensor e atuador únicos com manipulador

3. Comunicação direta

Para mim, acho que o melhor é ter algum tipo de manipulador, que lide com a comunicação entre sensores e atuadores e ter um nó para cada elemento do robô (como na figura 2), porque o sistema é dessa maneira fracamente acoplado e pode ser estendido facilmente, mas quero saber qual é a sua opinião.

Resposta muito curta: 2

Sensores

Quanto à leitura dos sensores, todos em um nó ou em cada um separadamente, você deve se perguntar:

Os sensores não têm sentido sem o outro?

Esta pergunta pergunta se os sensores estão fortemente acoplados ou não. Por exemplo, digamos que você tenha um sensor sensível à temperatura (e precise compensá-lo). Você adiciona um sensor de temperatura principalmente para fixar o valor do outro sensor. Nesse cenário, faz sentido ler os dois valores ao mesmo tempo, pois estão fortemente acoplados. De fato, sem as leituras do sensor de temperatura, as leituras do sensor original são inúteis.

Por outro lado, se os sensores forem úteis individualmente, mantenha-os em nós separados. Isso tem muitos benefícios:

• Os nós podem ser executados em processadores separados
• Os nós podem ser reutilizados em futuros robôs
• Falha na comunicação com um nó não desativa todo o sistema
• O reinício da aquisição a partir de uma placa de sensor com defeito pode ser feito separadamente dos outros

De fato, se você precisar de algum dos benefícios acima, teria que usar nós separados, mesmo que os sensores estejam fortemente acoplados, mas isso geralmente não acontece.

Atuadores

Isto é análogo.

Os atuadores não têm sentido sem o outro?

Por exemplo, se você está projetando um pulso com tendões robóticos, em que, para cada tendão (por qualquer motivo), dois motores são responsáveis ​​por trabalhar simultaneamente para mover uma junta em uma ou outra direção, tê-los servidos no mesmo nó faz muito mais sentido do que separado.

Por outro lado, onde os atuadores são independentes (caso comum), faz sentido ter um nó para cada atuador. Nesse caso, cada um pode ser colocado em um nó diferente. Além dos mesmos benefícios que os sensores, há esse benefício adicional:

• Se um atuador estiver parado (por qualquer motivo), os outros atuadores ainda funcionarão. Se houver graus redundantes de liberdade, eles podem até compensá-lo completamente.

Isso tem uma implicação. Se você precisar que os atuadores trabalhem em harmonia, coloque-os no mesmo nó. Isso não ocorre apenas por falha na comunicação, mas porque nós diferentes significam atrasos diferentes; em um sistema distribuído, cada nó está em uma parte diferente da rede e, portanto, a diferença de atrasos; em um sistema centralizado, ocorrem atrasos diferentes em altas cargas de CPU devido à sorte de cada processo no agendamento.

Deve haver um manipulador?

Mesmo que a resposta seja "depende", existe uma abordagem comum com muitas vantagens. Vamos mudar o nome e chamá-lo de "controlador". A abordagem é "sim, deve haver um controlador".

As vantagens de ter um controlador são (entre muitas):

• Processamento desacoplado: cada nó é responsável por uma coisa que significa:
  • Simplicidade: o que implica
    • Desenvolvimento mais fácil
    • Depuração mais fácil
    • Menos erros
    • Menos chance de falha
  • Reutilização: porque o mesmo controlador pode ser usado com nós de sensores diferentes se eles tiverem a mesma funcionalidade (por exemplo, formatos de mensagem e serviço).
• Execução em hardware separado: cada nó pode ser movido na rede. Por exemplo, os nós do sensor e do atuador podem ser movidos para um microcontrolador dedicado ( por exemplo, Arduino (não recomendado)) e o controlador em um PC.
• Evite feiura extrema: se os sensores quisessem influenciar diretamente os atuadores, o resultado seria simplesmente uma bagunça. Assumindo que não há controlador, vamos analisar cada caso:
  • Um nó sensor: basicamente, isso significa que o nó sensor e o controlador são colocados juntos no mesmo nó. Não é tão ruim, mas muito desnecessário.
  • Muitos nós de sensores: essa é a bagunça. Isso significa que o controlador está distribuído entre os nós do sensor. Portanto, todos os nós dos sensores precisam conversar entre si para saber como controlar seus atuadores associados. Imagine uma falha na comunicação ou vários tipos de atrasos e verá como é difícil. Dado que isso é totalmente desnecessário, não há razão para fazê-lo!

Dito isto, também existem desvantagens. Ter mais nós (qualquer nó, não apenas o controlador) significa:

• Comunicação mais desperdiçada: os dados precisam se mover em formatos padrão (serializados e desserializados) através da rede ou da memória compartilhada, o núcleo do ROS precisa examiná-los e decidir a quem entregá-los etc. Em resumo, alguns recursos do sistema são desperdiçados em comunicação. Se todos os nós estivessem em um, esse custo poderia ter sido zero.
• Maior chance de falha: se por algum motivo um link de rede cair ou um nó morrer, ocorrerá uma falha no sistema. Se você não estiver preparado para isso, pode derrubar todo o sistema. Agora, na verdade, é uma coisa boa, em geral, perder parte do sistema, mas não todo ( degradação normal ), mas também existem aplicativos em que isso deve ser evitado o máximo possível. Cortar a comunicação e colocar todo o código em um nó ajuda na estabilidade do sistema. O lado negativo é claro: o sistema funciona bem ou morre repentinamente.
• Tempos caóticos: cada nó é executado sozinho. O tempo que leva para que as mensagens cheguem aos outros não é determinístico e varia de acordo com a execução. A menos que seus nós registrem o carimbo de data / hora de cada mensagem (como uma observação lateral: você precisa ter relógios sincronizados em um bom grau, o que o ROS não faz) e, a menos que cada nó receptor possa levar em consideração o atraso e controlar adequadamente (o que é uma tarefa muito difícil por conta própria), ter vários nós significa alta incerteza sobre a idade dos dados. Essa é realmente uma das razões (entre muitas) que a maioria dos robôs se move tão devagar; o loop de controle deles deve ser lento o suficiente para garantir que todos os dados correspondam ao período atual. Quanto maiores os atrasos, mais lento o loop de controle.

Em todas as desvantagens acima, a solução é reduzir o número de nós, de preferência para um único nó. Espere um minuto, isso não está mais usando o ROS! Exatamente.

Para resumir:

• Use o ROS para sistemas não em tempo real, onde os atrasos podem ficar esporadicamente altos. Nesse caso, sinta-se à vontade para ter quantos nós ROS desejar. De fato, é uma prática muito boa que cada nó do ROS faça uma e apenas uma coisa. Dessa forma, eles se tornam muito simples e altamente reutilizáveis.
• Por outro lado, para sistemas em tempo real, evite todos os meios ROS. Para isso, existem orocos e tecnologias como EtherCAT e, mais frequentemente, soluções ad-hoc.

Como uma palavra final, na prática, o ROS funciona bem. Não é ótimo, mas é bom. Muitas vezes, o sistema não é crítico e a chance de falha é tão pequena que, de vez em quando, uma reinicialização não é grande coisa. Este é o algoritmo de avestruz !