Podes explicar em meia duzia de linhas qual a vantagem de usar ROS face a um err Ubuntu ou Debian ou Raspi*Distro/Beagle*Distro?
Dado que uma coisa é o marketing wank que se vê na internet, outra é tu que tens experiência em primeira mão.
Sim, claro. Antes de mais, o ROS é uma framework que pode ser instalada no Ubuntu ou num sistema Debian sem grandes complicações (noutras distribuições pode ser instalado a partir da source, mas pode dar algum trabalho e ter algumas incompatibilidades que têm de ser resolvidas). Apesar de ROS significar Robot Operating System, não é um sistema operativo tal como o Ubuntu, mas sim algo que corre por cima do Ubuntu.
Quanto às vantagens de usar o ROS, a primeira que vou mencionar é que na arquitectura do ROS existem mensagens tipo predefinidas, o que te permite ter código feito para um robô e usares exactamente o mesmo código com outro robô diferente (tamanho diferente, fabricante diferente, encoders diferentes, etc.), desde que a camada de abstracção do hardware esteja feita de maneira a pemitir a interligação com o ROS.
Outra característica do ROS é que funciona com base em nós e tópicos, o que permite que tudo seja extremamente escalável e modular. Vou utilizar o exemplo do robô que temos no lab, o Anubis, que é um Pioneer 3DX com sensores de ultrasons + Hokuyo Laser Rangefinder + Bumblebee 2 Stereo Camera + Arbotix Turret. Para fazer o interface com tudo o que tem a ver com a base do Pioneer 3DX existe o pacote ROSaria, que trata de todo o interface com o hardware e é um nó que publica em tópicos separados as leituras dos encoders e a velocidade (linear e angular) actual do robô, por exemplo. Por outro lado, esse mesmo nó subscreve outro tópico onde fica à espera de receber comandos do tipo Twist (velocidade linear + angular). Se quisermos controlar o robô, só temos de criar um nó que publique para esse tópico o comando com as respectivas velocidades lineares e angulares. O mesmo tipo de arquitectura aplica-se a todos os outros componentes do robô, de modo que podemos criar nós que só subscrevam determinados tópicos e só publiquem determinados tópicos.
Para os mais novos e menos experientes na robótica vou utilizar uma analogia muito simples. Imaginemos que temos três pessoas:
- o Zé, que tira uma fotografia por segundo e mete numa caixa de correio;
- o João, que sempre que recebe uma carta na sua caixa de correio vai levar o cão a passear.
- Eu, que quero que o João vá passear o cão sempre que o Zé tire uma fotografia de gatos.
Basicamente o que eu faço é ir à caixa de correio do Zé ver as fotografias que ele mete lá e quando eu vir uma que tem um gato, vou à caixa de correio do João e meto lá uma mensagem a dizer para ele ir passear o cão. Para fazer isso eu não tenho de saber como é que o Zé tira fotografias nem de saber como é que o João passeia o cão. Mesmo que eu vá dormir, o Zé continua a publicar fotografias e o João continua à espera de mensagens para ir passear o cão porque o trabalho de cada um deles só depende das mensagens que enviam ou recebem.
Convertendo a analogia acima para o futebol robótico, temos:
- o nó da câmara a publicar uma fotografia por segundo no tópico /camera;
- um nó que faz processamento da imagem para detectar a bola cor de laranja que subscreve ao tópico /camera e por sua vez publica uma mensagem no tópico /chuta sempre que detecta uma bola;
- o nó do actuador que subscreve o tópico /chuta à espera de receber uma mensagem para activar o actuador.
Com esta arquitectura todo o sistema fica 100% modular e sem quaisquer problemas no fluxo de informação de um nó para outro.
A existência de tipos de mensagens predefinidas e a modularidade do sistema abre portas ainda a outra enorme possibilidade que é criar sistemas robóticos distribuídos por vários computadores de uma maneira extremamente fácil. Existe sempre um processo que é o roscore que tem de ser executado num dos computadores da rede. Desde que os outros computadores da rede tenham conhecimento do IP do computador onde está a correr o roscore, podem publicar ou subscrever os tópicos do sistema robótico. Por exemplo num ambiente de laboratório posso eu desenvolver um nó para reconhecimento de objectos, o meu colega desenvolver um nó para navegação, outro colega pode fazer um nó para actuação de um braço robótico e em vez de se meter tudo num único mega computador que aguente com o processamento todo, cada um dos nós pode estar a correr num computador separado, tendo como único problema a latência da rede.
Por fim, a outra grande vantagem do ROS, mais para os "high end users", é que os grandes grupos de investigação em robótica usam ROS e muitas vezes disponibilizam os módulos /pacotes deles para outros investigadores usarem/experimentarem. Um utilizador pode pegar num kit robótico qualquer com uma câmara, e, desde que faça a camada de abstracção do hardware compatível com ROS pode, em pouco tempo, fazer o download do pacote de navegação do RatSLAM (navegação e mapeamento simultâneo baseado em células do córtex cerebral dos ratos: place cells, grid cells, orientation cells) e meter o robô a navegar com um algoritmo que foi fruto do trabalho de investigação de diversos especialistas na área há 3 ou 4 anos.
Não sei se a explicação foi muito confusa e se deu para perceber o potencial do ROS mas se tiverem dúvidas tentarei esclarecê-las. Como disse, o ROS não é propriamente fácil para principantes porque leva-se algum tempo até se perceber todo o funcionamento e arquitectura do sistema. No entanto, uma vez ultrapassadas essas barreiras, as possibilidades e a facilidade de fazer as coisas é muito maior.