B. DEVELOPPEMENTS TECHNIQUES DE LA CAVITE

Como mencionado na secção 3.1.3existem diferenças entre veículos multi-copter e aviões de asa fixa, e essas diferenças traduzem-se em requisitos de hardware de comunicações diferentes e mais exigentes quando são dedicados a aviões de asa fixa. Sendo os principais veículos utilizados pelo LSTS aviões de asa fixa, o Hardware de comunicações é desenhado para suportar estes veículos. A necessidade de garantir comunicações em todos momentos da operação vai no sentido de ser possível diagnosticar problemas de forma imediata reduzindo ao máximo o tempo de reação; Estes problemas tem diversos pontos de origem: técnico, mecânico, eletrónico, firmware ou software.

O ambiente envolvente e condições atmosféricas podem também dificultar ou até mesmo impossibilitar a segurança e estabilidade do voo. A altitude elevada aliada a condições atmosféricas adversas podem impedir o piloto de ver diretamente o avião, tornando assim as informações de posição GPS, altitude e velocidade imperativas e com pouca tolerância a atrasos para o devido acompanhamento da missão e segurança do voo.

O maior alcance das comunicações é também uma necessidade devido a autonomia dos aviões de asa fixa ser maior, tal como a sua altitude máxima e velocidades, consequentemente estes veículos percorrem uma área maior e afastam-se mais da base de partida do que os multi-copters. Pela sua dimensão reduzida e necessidade de uma rotação contínua dos motores os multi-copters estão ainda limitados a pouca autonomia das baterias, enquanto os aviões de asa fixa estão mais limitados pelo alcance da infraestrutura de comunicações. Neste sentido as comunicações doLSTS estão também elas em desenvolvimento, procurando aumentar o alcance das comunicações que consequentemente aumenta a área onde o veículo pode operar. Em missões de reconhecimento, quanto maior a área alcançável mais rapidamente é atingido o objetivo que pode ter requisitos temporais.

Todos estes fatores tornam a estrutura de rede de comunicações doLSTSem algo mais complexo que a clássica ponto-a-ponto utilizado em projetos semelhantes, esta estrutura é detalhada na subsecção 3.4.3.1, e na última subsecção3.4.3.2 é dado um exemplo de uma estrutura de rede utilizada no projeto DroidPlanner/Tower, mencionado na secção3.2.3.

3.4.3.1 Infra-estrutura de Rede LSTS

No diagrama 3.27 é representada a infraestrutura de comunicações comum nas missões com UAVs no LSTS. Como referido nas secção3.1.4 existem no mínimo dois intervenientes humanos que interagem diretamente com equipamento: um operador e um piloto. Sendo o operador responsável pelo planeamento e acompanhamento da execução dos planos autónomos numa consola Neptus num computador portátil. A consola do operador, a consola do piloto e o veículo comunicam todos por Wi-Fi com a Manta, que é a gateway de comunicações.

De forma a aumentar o alcance e qualidade das comunicações, podem ser ligados diferentes tipos de antenas à Manta, incluindo sectoriais, NanoStations, PicoStation, Rockects ou Omni Antenna [64], e é ainda possível ligar várias Mantas numa rede do tipo mesh (usando Wireless

Distribution System (WDS)).

Os diferentes alcances e capacidades destas antenas são usados em diferentes cenários dependendo dos objetivos e natureza do local das missões. No caso das antenas sectoriais existe ainda um motor capaz de a rodar e inclinar, mudando a direção e orientação da antena. Esta rotação e inclinação permitem manter o veículo no alcance direcional da antena, e é conseguida através de software de previsão na manta, utilizando as posições e orientações da manta e do veículo, este motor é chamado de Pan and Tilt Unit (PTU).

O RCfaz a comunicação por telemetria diretamente com o veículo e serve apenas para o controlo Manual e Assistido, é um instrumento de segurança extra, caso seja necessário tomar controlo do veículo pelos motivos mencionados na secção3.1.3. A aterragem e descolagem são também da responsabilidade do piloto, e são conseguidas através do modo manual e da utilização deste comandoRC.

Figura 3.27: LSTS - Diagrama de communicações

3.4.3.2 DroidPlanner

Em Contraste, um menor equipamento é necessário para operar uma consola como o Droid- Planner/Tower (ver secção 3.2.3). No diagrama3.28 pode-se constatar a ausência de uma rede dedicada e a ausência dos papéis de operador/piloto que são ambos assumidos totalmente pelo único interveniente com uma ligação ponto-a-ponto.

Existe um componente extra ligado por cabo USB ou Bluetooth à consola Android, e esse componente chamado de MAVBridge faz a comunicação entre oUAV e a consola. Este hardware tem um menor custo e logística mas o alcance das comunicações é menor, sendo assim mais vocacionado para multi-copters e missões praticamente automatizadas com pouca interação direta durante a operação do piloto/operador [49].

Durante a maior parte das missões a consola Android é apenas usada para acompanhar a missão no mapa e/ou vídeo da câmara, não havendo qualquer interação e sendo as missões pré

3.4. Comunicações 39 planeadas e pouco ou mesmo nada modificadas durante o voo, estas missões são praticamente todas autónomas desde a descolagem até à aterragem e durante todo o voo.

Dada a menor velocidade, altitude e capacidade de manter posições dos veículos utilizados com esta consola, a garantia de comunicações em todos momentos é então menos crítica e mais simples em termos de equipamento de comunicações.

Figura 3.28: DroidPlanner - Diagrama de comunicações

Após estes exemplos e contexto sobre onde o projeto se irá integrar e com que sistemas irá interagir, serão analisadas tecnologias necessárias para o desenvolvimento e implementação do projeto nos próximos capítulos e por fim são referenciados os testes e a validação do projeto e ainda o trabalho futuro onde este projeto poderá ser útil integrado e expandido.

Capítulo 4

Tecnologias

Nesta secção são descritas as principais tecnologias utilizadas no desenvolvimento e implementação da consola deste projeto, bibliotecas externas e protocolo de comunicações.

4.1

Android

A principal tecnologia utilizada neste projeto foi a plataforma Android.

Todo o projeto foi desenhado para esta plataforma, implementando e utilizando as suas tecnologias, com o objetivo final de ser utilizado num dispositivo desta plataforma.

Esta escolha prende-se com o fato de esta ser a mais vasta tecnologia FOSS utilizada em dispositivos com as dimensões ideais para este projeto, contar com milhões de dispositivos e utilizadores [1] e ainda ser uma plataforma já utilizada em outros projetos semelhantes como mencionado nas secção 3.2.

Existe uma necessidade de conhecer esta plataforma, a sua arquitetura, as suas potencialidades e limitações, no sentido de colmatar estas últimas foram utilizadas bibliotecas externas descritas na secção4.2. A gestão, utilização e implementação destas tecnologias é detalhada no capítulo6..

4.1.1 Atividades e Fragmentos

Os principais componentes da arquitetura essenciais para qualquer aplicação são as Atividades e Fragmentos [65].

Estes dois componentes incluem diversas fases de vida, ligação entre eles e a sua correta utilização depende da sua compreensão.

De um modo simples: todo o ecrã é uma atividade que pode ou não ter fragmentos. Os fragmentos são as componentes visuais na atividade, podem eles próprios estar fragmentados em outros fragmentos, criando uma hierarquia visual.

É importante conhecer os seus ciclos de vida, este ciclo de vida está representado nos diagramas4.1. Estes ciclos de vida permitem ter atividades e seus fragmentos em suspensão e consequentemente

estarem acessíveis mais rapidamente.

Esta suspensão tem suas vantagens em termos de multi-tarefa, tornam a aplicação mais responsiva na mudança de atividade e/ou ao ser posta em segundo plano mas discutivelmente tem demasiadas desvantagens, tais como: gestão de recursos mais complexa, necessidade de prever todos estes métodos e o que fazer em cada caso, dando origem a inúmeros problemas de sincronização de recursos e acesso a recursos já inexistentes, e a desvantagem mais relevante é a representação de informação em cache já desatualizada. Esta representação de informação em cache desatualizada leva à indução do utilizador em erro, tornando assim relevante evitar que tal aconteça.

(a) Ciclo de vida de Atividades

(b) Ciclo de vida de Fragmentos

Figura 4.1: Android - Ciclo de vida dos componentes [66,67]