Foi escolhido o paradigma híbrido uma vez que o BUV proposto necessita de aliar o comportamento reativo da rede de sensores-atuadores com as atividades deliberativas necessárias para realizar tarefas mais complexas.
Foi tido como base do projeto da arquitetura robótica híbrida o modelo das três camadas. No entanto, fez-se algumas alterações na organização dos componen- tes principais da arquitetura. Foram adicionados alguns componentes presentes em outras arquiteturas (Gallimore, Stokey & Terrill, 2018; Huang, 2008; Pinto et al.,
2013; Siegwart, Nourbakhsh & Scaramuzza,2011):
• Camada de planeamento:
– Supervisor do veículo (ou vehicle supervisor ): responsável por monitori-
zar o estado do veículo, isto é, o nível de baterias, os sensores de LA e os níveis de corrente das ligações críticas. Verifica também se os restantes sensores estão operacionais (GPS, IMU, comunicações, etc). Este ele- mento, se verificar que as condições de emergência foram estabelecidas, deverá comunicar, diretamente, com o piloto para emergir o veículo. Faz parte deste elemento o Vehicle Supervisor Node;
5.2. Arquitetura robótica implementada
– Controlador de missão (ou mission controller ): responsável pela interface
com o operador, isto é, faz o acompanhamento e o feedback das missões ao operador e faz o upload das missões criadas pelo operador;
– Coordenador de missão (ou mission planner ): responsável por armazenar
o planeamento de missões com data e hora para a sua execução e, quando chegar à hora da realização da missão, ordenar à camada executiva a execução da missão;
– Cartógrafo (ou cartographer ): responsável por criar, atualizar e fazer a
manutenção dos mapas ou modelos do mundo;
– Sistema de cooperação multi-BUV’s (ou multi-BUV cooperation): res-
ponsável pelo interface entre os diversos veículos que farão parte de uma determinada missão.
• Camada executiva:
– Navegador (ou navigation planner ): responsável por gerar o planeamento
de navegação para a missão com base na informação disponibilizada pelo coordenador de missão, como por exemplo waypoints, tempo entre cada waypoint, velocidade máxima de missão, entre outros;
– Piloto (ou pilot): é o organizador de sequências responsável por gerar
um conjunto de comportamentos a serem adotados para realizar uma determinada sub-tarefa e determina quaisquer sequência e condições de ativação. Recebe a informação da missão pelo coordenador de planea- mento, o planeamento de navegação pelo navegador e o modelo do mundo pelo cartógrafo. Com base nestes dados executa um determina comporta- mento, calculando os setpoints e enviando-los aos controladores dos atu- adores. Em caso de emergência executa um comportamento predefinido hierarquicamente superior, isto é, deixa de seguir as ordens da camada de planeamento;
– Gestor de recursos (ou resource manager ): responsável por alocar os re-
cursos aos comportamentos, isto é, está diretamente ligado à parte senso- rial de RECON do BUV e que deve verificar qual é o sensor mais adequado para cada situação/missão do robô;
– Monitorização de execução (ou performing monitoring): responsável pela
em caso de falha, reúne o log do erro. Abaixo da sua hierarquia existe o Este componente está em sincronia com o controlador de missão.
• Camada funcional:
– Sensores (ou sensors): drivers e tarefas associadas a cada sensor respon-
sáveis pelas atividades de interpretação e integração dos sensores. Fazem parte deste grupo o Bar30 Node, AHRS Node, Ublox GPS Node e o Echo- sounder Node;
– Atuadores (ou actuators): drivers de hardware desenvolvidos em C++ e
controlados por nodes que permitem que o veículo se desloque no meio aquático. Fazem parte deste grupo o BCU Node, Lateral Fin Node e o Fin Node;
– Comunicadores (ou comms): drivers e tarefas associadas a cada módulo
de comunicação, responsáveis pelo envio e receção de mensagens entre o veículo e o operador. Fazem parte deste grupo o GSM Node, Acustic Node e o WiFi Node;
– Estimadores (ou estimators): responsáveis pelo tratamento da informação
proveniente dos sensores, aplicando os filtros necessários para obtenção de todas as variáveis do sistema (filtro de Kalman). Faz parte deste grupo o Localization Node;
– Controladores (ou controllers): responsáveis pela tradução dos comandos
provenientes da camada executiva para os atuadores (controladores PID) e para os sensores de RECON. Fazem parte deste grupo o Control Node, Sinusoidal Generator Node e o RECON Control Node;
– Interpretador (ou interpreters): responsável pela interpretação e tradução
de mensagens. Compila a informação a ser enviada e envia a mensagem para o comunicador, selecionado pelo gestor de recursos, enviar para o operador. Na receção, recebe a mensagem provinda do comunicador e traduz enviando as intenções do operador ao controlador da missão. Na figura 5.4 pode observar-se a organização da arquitetura robótica do veículo implementada. Na presente dissertação apenas foi desenvolvida e aplicada a arquitetura da camada funcional. Para o desenvolvimento de toda a camada funcional foi utilizado o ROS como sistema middleware. Optou-se por utilizar o C++ para desenvolver os drivers de todo o hardware e os sistemas de controlo por
5.2. Arquitetura robótica implementada
e o Python para as aplicações de RECON por ser mais rápida a construção da aplicação.
Figura 5.4: Arquitetura de robótica do veículo.
O estilo de codificação deve ser limpo e consistente para que seja possível a sua interpretação, depuração e manutenção. O código não deve apenas ser fun- cional também deve ser elegante para que possa ser reutilizado e aprimorada por outros membros do projeto. Desta forma fez-se uma análise das recomendações das melhores práticas de codificação utilizados em ROS para desenvolvimento em C++, que se encontra presente no website http://wiki.ros.org/CppStyleGuide. Optou-se por utilizar o estilo da Google presente no website https://google.github.io/stylegu ide/cppguide.html. Todo o código desenvolvido foi construído com este estilo.
Capítulo 6
Desenvolvimento
Neste capítulo é relatado todo o desenvolvimento da camada funcional da arquitetura proposta no capítulo anterior. A camada funcional do veículo foi desen- volvida em ROS e organizada hierarquicamente por módulos, sendo eles os drivers, estimadores, comunicadores e controladores.
Desta forma foi criado um projeto ROS da camada funcional, chamado tobias_ros. Este é constituído por metapackages, que contêm diversos módulos, constituídos por pacotes de software em ROS. Este software encontra-se disponível, à comunidade cientifica, no repositório do GitHub https://github.com/hilarioar aujo/tobias_ros. Através do acesso ao repositório pode-se descarregar o software bem como aceder a toda a documentação (em linguagem Markdown) presente nos ficheiros README.md dos pacotes ROS desenvolvidos.
6.1
Configuração inicial
Inicialmente foi necessário configurar a Jetson Nano para que fosse possí- vel utilizá-la e para se poder implementar a framework ROS. No apêndice A está presente um pequeno guia que foi elaborado para a preparação da Jetson Nano.