Estou de volta ao computador!
Como eu disse neste comentário , o ROS geralmente não é obrigatório. O ROS é uma plataforma entre muitas, famosa principalmente pela Willow Garage que oferece robôs gratuitos em algum momento para quem escreveu a maioria dos módulos de ROS. Dito isto, não é a melhor plataforma possível e certamente não é nada de especial. Particularmente, o referido concurso resultou em muitos módulos de baixa qualidade apenas para aumentar os números.
Com o tempo, a qualidade dos módulos ROS melhorou e há muitos deles também. Portanto, usando o ROS, você tem o benefício de reutilizar muito do que já foi feito. Você pode ler aqui algumas razões pelas quais você pode querer usar o ROS.
Com isso em mente, você também deve observar os efeitos colaterais.
Controle Distribuído
Com o ROS, você tem muitos nós que se comunicam através da rede. Às vezes, isso é bom e fácil, mas geralmente resulta em um atraso muito variável na recepção de mensagens. Como resultado, você teria que ter um grande atraso no controle para garantir que todas as mensagens chegassem, o que significa que você não pode reagir rapidamente aos eventos, o que, por sua vez, significa que você precisa mover o robô em velocidades mais lentas para não perder esses eventos.
Acredite ou não, as pessoas realmente controlam o robô através do ROS ( MoveIt! É o nome do conjunto relevante de componentes). Lento. Inseguro. Mas fácil!
Tempo não real
Mesmo quando não distribuído, o ROS não é uma plataforma em tempo real. Isso significa que você está a critério completo do kernel do Linux para agendar suas tarefas a qualquer momento que achar conveniente. Isso é bom para alguns aplicativos, mas não é bom para outros. Então, você precisa examinar seus próprios requisitos. Você precisa ter uma garantia de que sua tarefa seria concluída dentro de um prazo conhecido? Nesse caso, você precisa de um sistema em tempo real.
Ambiente de tempo de execução hospedado
Outro ponto a considerar é que, embora o ROS seja um protocolo geral de comunicação, ele é essencialmente suportado apenas em ambientes hospedados. Hospedado significa que o código é executado no topo de um kernel, em oposição ao autônomo, o que significa que o código controla diretamente o hardware (por exemplo, em um microcontrolador).
Se o seu aplicativo de robótica for executado próximo ao hardware e, portanto, você exigiria um programa que seja executado em um microcontrolador, o ROS não ajudará você.
Bloqueio da plataforma
Por último, mas não menos importante, o desenvolvimento para ROS resulta em um bloqueio da plataforma. Isso significa que se, no futuro, por um motivo ou outro, você decidir basear seu trabalho em outra plataforma robótica, como OROCOS, YARP, etc., isso seria excruciante.
Você também estaria um pouco bloqueado para o Linux. O Linux é o melhor, sem dúvida, mas um dia você pode ter que suportar outro sistema, como QNX, VxWorks, etc., e você também terá problemas.
Se você está escrevendo para microcontroladores, esqueça o ROS. Se você estiver escrevendo módulos de alto nível, eu recomendo escrever código portátil. Por exemplo, digamos que você tenha desenvolvido um novo sensor e deseje gravar um módulo que adquira dados desse sensor, conectado ao seu computador através do barramento CAN.
O que você poderia fazer nessa situação é escrever uma biblioteca independente, com funções capazes de trabalhar com seu sensor e adquirir dados. Você pode até pensar em gerar um encadeamento na biblioteca que adquire e enfileira dados periodicamente.
Depois de ter essa biblioteca auxiliar, você pode escrever uma CLI, GUI, módulo ROS, módulo OROCOS, módulo YARP, conectar-se ao Matlab ou qualquer outra coisa que desejar usar para interagir com seu sensor.
Nota final: o que eu disse aqui é geralmente aplicável a todas as plataformas de robótica e não apenas ao ROS.