Um exemplo maior
Sumário
Até este capítulo, vimos como instalar o mestre ROS e os nós ROS, além de como investigar os tópicos que estes nós usam para se comunicarem uns com os outros. Essa seção termina com um exemplo um pouco maior que o da Seção 2.3, com o objetivo de ilustrar, de forma mais completa, como as mensagens e os tópicos funcionam.
Primeiramente, pare qualquer nó que esteja em execução. Comece com roscore se ainda não estiver ativo e, então, execute estes quatro comandos:
rosrun turtlesim turtlesim_node _ _name:=A
rosrun turtlesim turtlesim_node _ _name:=B
rosrun turtlesim turtle_teleop_key _ _name:=C
rosrun turtlesim turtle_teleop_key _ _name:=D
Isso deveria iniciar dois exemplos do simulador turtlesim - estes devem aparecer em duas janelas separadas - e dois exemplos de nós de teleoperação turtlesim.
O único elemento nesse exemplo que poderia não ser familiar é o parâmetro _ _name do rosrun. Esses parâmetros substituem o nome padrão que cada nó tenta atribuir para si mesmo. Eles são necessários porque o ROS mestre não permite múltiplos nós com o mesmo nome.
⏩ Se você tentar iniciar dois nós com o mesmo nome, o novo nó iniciará sem nenhum problema, mas o nó original terminará com uma mensagem assim:
[WARN][1369835799.391679597]:Shutdown request received.
[WARN][1369835799.391880002]:Reason given for shutdown:</br>[new node registered with same name].Embora estejamos trabalhando para evitar isso, essa conduta pode ser útil no geral. Isso é especialmente verdade se você está fazendo debugging revisando o nó porque isso garante que você não tenha múltiplas versões do mesmo nó rodando por engano.
Antes de discutirmos sobre o exemplo dos quatro-nós, você pode pensar um pouco como esse sistema se comportará. Como seria o gráfico, mostrado por rqt_graph? Quais tartarugas se moveriam em resposta a quais nós de teleoperação?
Certamente, você previu que o gráfico seria semelhante ao da Figura 2.5 e que ambas tartarugas fariam os mesmos movimentos em resposta ao pressionamento das teclas que são enviados para qualquer nó de teleoperação. Veremos o porquê.
Figura 2.5: Um gráfico um pouco mais complexo do ROS, com dois nós `turtlesim` nomeados A e B e dois nós de teleoperação nomeados C e D.
A comunicação por meio de tópicos é de muitos para muitos
Você poderia ter esperado cada nó de teleoperação se conectar a um simulador, criando dois simuladores controlados independentemente1. Note que esses dois tipos de nós publicados e subscritos, respectivamente, no tópico /turtle1/cmd_vel/. Mensagens publicadas neste tópico, independentemente de qual nó o publica, são entregues a todos assinantes deste tópico.
Nesse exemplo, toda mensagem publicada pelo nó de teleoperação C é entregue a ambos nós de simulação, nomeados A e B. Da mesma forma, mensagens publicadas por D são entregues a A e B. Quando essas mensagens chegam, as tartarugas se movem adequadamente, independente de qual nó o publicou. A ideia principal aqui é que tópicps e mensagens sejam usadas para uma comunicação de muitos para muitos. Muitos editores e assinantes podem compartilhar um único tópico.
Os nós são fracamente acoplados
Sem dúvidas, você já percebeu que não precisamos reprogramar o simulador turtlesim para aceitar comandos de movimentos de várias origens, nem o nó de teleoperação precisava ser projetado para conduzir várias instâncias do simulador ao mesmo tempo. Na verdade, seria um exercício fácil ampliar este exemplo para diversos2 tipos de nó.
Por outro lado, imagine o que aconteceria se o simulador turtle começasse de forma isolada, sem quaisquer outro nó. Nesse caso, o simulador esperaria por mensagens em /turtle1/cmd_vel, felizmente isso acontece, visto que não existe editores para esse tópico.
O ponto principal é que, especificamente, os nós turtlesim - e, geralmente, os nós ROS mais bem projetados - são fracamente acoplados. Nenhum dos nós sabe, explicitamente, sobre os outros; suas únicas interações são feitas de forma indireta, no nível dos tópicos e mensagens. Essa independência dos nós, juntamente a decomposição, facilita tarefas maiores, quebrando-as em peças menores e reutilizáveis, esse é um dos principais recursos de design da ROS.
- Software (como
turtle_teleop_key) que produzem informações, podem publicá-las, sem se preocupar como essas informações são consumidas. - Software (como
turtlesim_node) que consomem informações, podem se inscrever nos tópicos contendo os dados necessários, sem se preocupar como esses dados são produzidos.
O ROS fornece um mecanismo, chamado serviços, para uma comunicação um pouco mais direta, chamada “um a um”. Essa técnica secundária é muito menos comum, mas tem suas usualidades. O Capítulo 8 descreve como criar e usar esses serviços.
1 No capítulo 6,veremos o jeito certo de criar esssas imulações paralelas e independentes.
2 … com razão. Meu computador começa a reclamar quando existem muitos clientes ativos após iniciar 100 simulações simultaneamente do turtlesim_node.