3.3
Arquitetura ROS
Com a adição de novos componentes ao projeto é necessário rever e reformular se necessário a arquitetura de software do sistema, nomeadamente a parte relacionada com ROS.
Aquando o início da elaboração desta dissertação o sistema era composto por cinco nós re- presentados na Figura3.1. Este diagrama foi obtido através do comando rqt_graph que permite a representação gráfica não só dos nós pertencentes ao projeto, as mensagens trocadas entre os mesmos e os tópicos a elas associados, bem como o sentido das mensagens (nós subscrevem ou publicam nos tópicos respetivos).
Figura 3.1: Arquitetura ROS inicial do projeto
O nó /uvc_camera é responsável pela configuração e manutenção da câmara. Fornece in- formações ao nó /p_calib sobre parâmetros de câmara e trata da aquisição em bruto da imagem correspondente ao mapa de jogo.
/p_calib subscreve ao tópico /calibration_thresh que corresponde ao valor introduzido pelo utilizador na UI quando o programa é iniciado que define os cantos do mapa de jogo captado pela câmara. Estes cantos são de seguida publicados pelo motor de jogo e subscritos por /april- tag_detectorpor forma de ser possível efetuar as transformações geométricas necessárias para o cálculo correto das posições das apriltags relativas ao mapa de jogo.
Por sua vez o nó /joystick é responsável por configurar e ler os comandos introduzidos pe- los jogadores em cada um dos diferentes joysticks. É de seguida enviada essa informação para o motor de jogo sobre forma de uma mensagem do tipo Twist, que é um tipo nativo de ROS perten- cente ao pacote /geometry_msgs. Esta mensagem é composta por um vetor tridimensional a que correspondem as velocidades lineares sobre o eixo do x,y e z e outro vetor tridimensional a que correspondem as velocidades angulares em volta do eixo x, y e z. Adicionalmente, visto apenas ser utilizado linear.x e angular.z, para não ser criada outra mensagem à parte, os comandos de disparar e de turbo são publicados com valores arbitrários sobre a variável angular.z o que não é uma prática decente e pode trazer problemas inesperados.
24 Soluções propostas para melhoramento do PiTank
Por fim, o nó /game_engine corresponde ao motor de jogo e é o nó central onde toda a informa- ção é processada ou distribuída entre os restantes nós. É responsável não só pela UI como também por implementar as regras de jogo e garantir que estas são cumpridas. Recebe as mensagens do comandos dos jogadores e converte-as numa trama possível de enviar para determinado robô.
Tendo em conta as novas funcionalidades a serem implementadas é necessária a criação de mais alguns nós. Foram considerados suficientes três nós adicionais como mostra a Figura 3.2
(arquitetura simplificada sem tópicos) e Figura3.4(arquitetura completa com tópicos).
Figura 3.2: Nova arquitetura ROS proposta para o projeto (apenas nós e suas ligações) Todos os nós já existentes foram mantidos, exatamente com as mesmas funções e foram apenas adicionados e integrados no sistema os três novos nós responsáveis pela simulação, IA e controlo dos robôs na ausência de joysticks. Houve também mudanças relativamente à tipologia e organi- zação das mensagens.
Em primeiro lugar será criado um namespace associado a cada robô (até um máximo de 4) ao contrário de um único namespace para todos como existia anteriormente. Isto é útil não só por ser intuitivo e produzir uma melhor organização como também será útil no controlo de cada um dos robôs no Gazebo pois se enviarmos, por exemplo, uma mensagem de controlo para quatro robôs com o mesmo modelo no mesmo namespace, todos irão responder da mesma forma, a não ser que a cada robô estejam associados quatro diferentes tópicos de controlo (cmd_vel) o que não é uma boa prática. Por outro lado se cada robô pertencer a um namespace único, basta ter a ele associado um único tópico (cmd_vel).
Outro fator mal implementado é o facto de as ações de disparo e turbo estarem associadas ao tópico das velocidades de cada robô. Até à data, não existia grande problema em utilizar este tipo de arquitetura para poupar um tópico ao sistema. No entanto, com a integração de um novo nó responsável pela simulação, em que cada robô é diretamente controlado pelo mesmo tipo de mensagem proveniente dos joysticks (Twist), a atribuição de um valor a angular.z irá influenciar
3.3 Arquitetura ROS 25
diretamente a velocidade angular de um certo robô. Desta forma, é mais correto criar uma men- sagem customizada que trata da informação relativa a disparar e utilizar turbo e criar um tópico associado a este tipo de mensagem para cada namespace dos diferentes robôs. Este tópico será chamado /shootandturbo como pode ser visto na Figura3.2.
Relativamente aos nós ROS, será necessário criar um nó associado ao simulador que será responsável por abrir o Gazebo, carregar a cena correta do mapa de jogo, carregar um certo número de robôs dependendo do que o utilizador definir, permitir o controlo de cada um desses robôs e publicar a posição dos mesmos num tópico subscrito pelo motor de jogo.
Desta forma, todas as regras e controlo do jogo serão na mesma efetuados no nó /game_engine sendo a única diferença a origem dos inputs relativos às posições de cada robô. Se o utilizador selecionar o sistema físico a origem será a leitura de cada AprilTag presente no mapa de jogo. Por outro lado, se o utilizador escolher o sistema simulado a origem será as posições de cada modelo do robô no Gazebo. Assim, é garantido um sistema bastante flexível e serão necessárias mudanças mínimas no nó /game_engine relativamente à integração do simulador.
Será também criado um nó de controlo dos robôs no caso de ausência de joysticks. Este nó será baseado no pacote nativo ROS teleop_twist_keyboard que publica mensagens do tipo Twist para controlo a partir do teclado. Serão efetuadas algumas alterações para ser possível acomodar quatro jogadores simultaneamente bem como a possibilidade de disparar e turbo.
Finalmente, resta o nó relativo a IA. Este nó será responsável pela tomada de decisão e con- trolo de cada robô do tipo IA (definido no início do jogo). Visto que a tomada de decisão será dependente não só das posições dos robôs, mas também do estado da UI (tempo de jogo, difi- culdade escolhida, etc..) e certos elementos de jogo como as paredes, é necessário que este nó subscreva aos tópicos associados a todos esses elementos publicados pelo /game_engine.
Um diagrama mais complexo (com tópicos associados aos nós) é mostrado abaixo na Figura
26 Soluções propostas para melhoramento do PiTank
3.3 Arquitetura ROS 27
Capítulo 4
Criação do Simulador para PiTank
4.1
Características do 3pi
Um dos fatores mais importantes na obtenção de uma simulação com resultados semelhantes à realidade é a utilização de um modelo que caracterize corretamente o modelo real.
Os robôs utilizados no PiTank são versões modificadas do robô 3pi desenvolvido pela Pololu [4]. Foi criada uma espécie de capota de forma a acomodar a utilização de AprilTags para deteção de cada um dos robôs durante o jogo. Desta forma, visto não existir nenhum modelo desta versão modificada do 3pi foi necessária a elaboração de um modelo 3D que o caracterize corretamente.
Figura 4.1: Robô Pololu 3pi original [4] Figura 4.2: Robô Pololu 3pi modificado A fase inicial corresponde, obviamente, à recolha e medição das características do modelo real, nomeadamente valores de altura, diâmetro do chassis, diâmetro das rodas, distância entre rodas, entre outros. Após a recolha de informação em [4] e medição de alguns valores relevantes foi criada a Tabela4.1abaixo.
Uma nota importante é o facto de devido às capotas terem sido criadas de forma customizada, existe uma pequena variância no valor de altura dos diferentes robôs, sendo que o seu valor médio ronda os 5 centímetros, pelo que foi adotado esse valor como altura de todos os robôs simulados.
30 Criação do Simulador para PiTank
Parâmetro Valor
Altura do robô 6.00 cm Diâmetro do chassis 9.50 cm Diâmetro das rodas 3.40 cm Distância entre rodas 9.00 cm Distância do chassis ao chão 0.85 cm Peso (com pilhas) 0.50 kg
Tabela 4.1: Características físicas do robô 3pi modificado
Foram desprezados os parâmetros de software e alguns parâmetros de hardware como tipo de processador e gama de tensões de funcionamento, visto não serem relevantes para o caráter físico do sistema.