Modos de Operação

Os três modos de operação possíveis são: Manual, Stabilize/Assisted e Auto aqui descritos. Estes modos de operação são as principais influências na parte da arquitetura da interface que são descritas na secção 5.2.

• Modo Manual e Stabilize/Assisted: Modo em que o piloto tem total controlo ou controlo assitido do veículo através do comandoRC e telemetria direta com o veículo sem o uso de mensagens IMCnem da infraestrutura de rede do LSTS.

Neste modo a linha de visão do piloto deve ser exclusiva ao veículo sendo que o feedback auditivo ganha importância para esta aplicação e o feedback visual é menos utilizado, reduz-se a pouca informação de forma destacada sem espaço para dúvidas ou detalhes. Para este modo foram definidos três requisitos:

– CallOuts auditivos de Velocidade (IAS) e Altitude com períodos customizáveis; – Controlo de volume com botão mute;

5.1. Levantamento de Requisitos 49 • Modo Auto: Piloto não controla o veículo nem direta nem indiretamente, o controlo é

feito sob a forma de planos autónomos criados e da total responsabilidade do operador. Esta ausência de responsabilidade e funções dão uma maior liberdade, e assim sendo neste modo foram indicados diversos objetivos dividindo-se em dois aspetos:

– Informação do veículo principal:

Altitude, baterias, plano ativo, posição e orientação; – Informação do plano atual:

Posição waypoints, direção, loiters com sua orientação e altitude da próxima manobra. Posições e orientações dos outros sistemas foram também definidos como requisitos e objetivos de forma a aumentar o awareness do piloto não só do seu veículo mas da rede de sistemas globalmente.

Nestas reuniões foram clarificados os requisitos da consola para o piloto nestes modos e consequentemente criados e priorizados diversos objetivos para projeto.

5.1.2.2 Fases de Operação

Existem quatro fases de operação: pré descolagem, descolagem, modo auto e aterragem. A descolagem e aterragem têm requisitos coincidentes ao modo Manual/Stabilize, sendo esse o modo de operação utilizado pelo piloto durante estas fases.

A pré descolagem consiste numa lista de requisitos necessários para iniciar o voo. Visto já existir esta lista em formato papel ou no software Neptus, foi dado como requisito pouco prioritário e eventualmente abandonado.

Durante a fase de modo auto, o piloto está mais livre, tendo menos responsabilidade e funções, permitindo assim que esta consola possa ter mais funcionalidades e capacidades, estas funciona- lidades são priorizadas para incluir a informação do veículo atual e seu plano ativo, sendo as demais funcionalidades, requisitos e funções descartadas posteriormente por não serem essenciais e até prejudiciais aos objetivos e à eficiência da consola para os mesmos.

5.1.2.3 Funcionalidades Extra

Como descrito no inicio desta secção e na introdução capítulo 1, a direção inicial do projeto seria uma consola completa, definida como CCU ouGCS semelhante à já existente plataforma para submarinos AUV noLSTS: ACCU(ver secção3.3.3), e a outras consolas de aviõesUAV ou MAVmencionadas nas subsecções da secção3.2.

Assim sendo, diversos objetivos, requisitos e funcionalidades foram propostos numa fase das reuniões que se tornou num brainstorm de ideias e possibilidades para a aplicação, alguns exemplos destes objetivos e funcionalidades: controle remoto com joysticks virtuais, PFD, ser capaz de pré visualizar os planos e dar ordem para a sua execução, criação de planos/comandos simples

como: Go To, Go Home, ou Follow Me, capacidades de diagnóstico de erros em entidades ou comunicações, comunicação por Voice over Internet Protocol (VoIP) ou mensagens entre piloto e operador.

No decorrer do projeto, através dos testes no terreno, estas funcionalidades extra foram perdendo relevância, eventualmente abandonadas e consideradas irrelevantes ou mesmo prejudiciais e intrusivas aos objetivos do projeto.

O papel Safety Pilot (ver secção 3.1.4), tem esse nome pela sua responsabilidade pela segurança do voo. Sendo o seu papel, um papel interventivo mas não imperativamente principal. É o objetivo destes voos serem autónomos evitando que o piloto tenha um papel central, mas que este mantenha um papel de segurança e de último recurso. Para tal ser possível é imperativo que este esteja pronto em qualquer momento para tomar controlo manual no avião a fim de evitar situações potencialmente perigosas e/ou inseguras.

Dado este papel e responsabilidade, consolas complexas com demasiadas funcionalidades são algo que pode ser distrativo/intrusivo e consequentemente reduzir a prontidão do piloto para tomar controlo do veículo, ou seja, têm o efeito inverso ao aqui pretendido e prejudica a sua capacidade de cumprir as suas responsabilidades.

Alguns exemplos de como uma CCU/GCS pode entrar em conflito com alguns dos objetivos propostos:

• Dado o tamanho reduzido da consola, a edição e/ou visualização de planos que não o ativo limita a capacidade de acompanhar e verificar que o veículo está na rota certa;

• Demasiada informação pode tornar a sua leitura menos imediata atrasando o processo de diagnóstico do piloto que se quer o mais imediato possível procurando reduzir o tempo de reação;

• Considerando a velocidade a que o veículo se desloca, estes atrasos provocados por demasiada informação embora sejam unitariamente pequenos, em conjunto podem se tornar críticos, principalmente em situações reais a uma velocidade maior.

Nesse sentido, foram priorizadas as funcionalidades necessárias para providenciar Situation Awareness e de informação critica do veículo e seu plano atual e posteriormente descartadas as demais funcionalidades tornando assim a consola numa SATafastando-se dos conceitos de GCS e CCUpensados inicialmente.

5.1.3 Mockups

Das reuniões com stakeholders mencionadas na secção anterior saíram as ideias e saiu também um mockup inicial 5.1, ainda que bastante diferente do resultado final, foi o ponto de partida. Este mockup 5.1 é representativo do PFD que contém as informações do veículo essenciais à operação, a partir deste mockup foram deduzidas e definidas mensagens IMCa analisar como é descrito na secção 6.1.

5.1. Levantamento de Requisitos 51 Posteriormente e como forma de validação e clarificação dos objetivos e de os visualizar graficamente foram criados mockups utilizando a ferramenta Pencil Project [75]. Estes mockups representam ambos modos Auto nas imagens 5.2c e 5.2de Manual na imagem 5.2b, e alguns alertas de exemplos nas imagens 5.2ce 5.2d.

A parte do modo Auto nas imagens 5.2ce 5.2dfoi baseada na consola DroidPlanner, consola referida na secção 3.2.3, todos ecrãs foram criados, modificados e aprovados pelos pilotos e utilizados como ponto de partida para o desenho da interface.

Figura 5.1: ASA- Mockup - Reunião com Stakeholders

(a)ASA- Mockup - Listagem de Sistemas (b)ASA- Mockup - Modo Manual

(c) ASA- Mockup - Alerta Low Fuel (d)ASA- Mockup - Alerta Out of Route

5.2

Arquitetura

Nesta secção é descrito a arquitetura definida para a aplicação, analisando as três componentes mais abrangentes do projeto: Android, Código Java e Customização. Em cada uma destas três componentes são apresentados objetivos, funções, referências de motivação e inspiração, são também dados alguns exemplos práticos e concretos da aplicação dos conceitos da arquitetura na consola.

5.2.1 Android

De acordo com fases e modos de voos definidos nos requisitos do projeto, foram definidas as componentes Android correspondentes. Tendo assim a aplicação quatro atividades principais: SystemList, Settings, Manual e Auto.

• SystemList: Consiste num ecrã com listagem de sistemas/nós da rede, permite saber informações básicas e selecionar um sistema como ativo. Baseado noACCU, na imagem3.26 e no mockup 5.2a.

• Settings: Definição de opções de customização e adaptação da aplicação às preferências do utilizador, baseado no SharedPreferences [68], detalhada na secção 5.2.3.

• Manual: Atividade utilizada durante descolagem e aterragem e durante modo de voo manual/assited/stabilized, focada no áudio CallOut e stream de vídeo, baseado no mockup 5.2b.

• Auto: Atividade usada durante o modo voo autónomo, focada no mapa e estado do veículo atual.

Foram também definidos diversos fragmentos, sendo alguns deles utilizados em ambos modos Manual e Auto sempre que possível. Desta forma evita-se a utilização de código repetido o que reduz consequentemente fontes de problemas e facilitando a sua atualização e modificação posterior.

Como descrito na secção4.1.2foram utilizados serviços para tarefas em segundo plano: CallOut áudio, receção e tratamento de mensagens IMC e processamento da stream vídeo da câmara. Estes serviços comunicam as mudanças no estado dos veículos a outras componentes através da biblioteca Otto (ver secção 4.2.3).

5.2.2 Java

A arquitetura do código procurou seguir as arquiteturas das atuais ferramentas Java noLSTS: IMCJava, Neptus e ACCUmencionadas nas secções 4.2.1,3.3.2e 3.3.3respetivamente, não se prendendo às mesmas e procurando inovar e melhorar as mesmas e portando esta inovação e

5.2. Arquitetura 53 melhorias de volta às mesmas, principalmente à consola ACCU por ser também um projeto Android com algumas capacidades e funcionalidades comuns.

A estrutura sofreu diversas refatorações no decorrer do desenvolvimento de forma a melhor dividir diferentes componentes em diferentes camadas providenciando uma estrutura mais hierárquica com melhor organização para futuros desenvolvimentos, deteção e depuração de problemas, alguns conceitos utilizados no desenvolvimento do código são descritos na página do projeto no Github [76].

Um dos principais conceitos aplicados ao código é a redução do tamanho e funcionalidades dos métodos, também conhecido por Short Methods, reduzindo as funcionalidades e capacidades de cada método e aumentando a quantidade de métodos por classe/ficheiro [77]. Procurando também utilizar nomenclaturas consistentes sendo elas próprias descritivas da sua funcionalidade [78], aplicada a variáveis, métodos, campos, classes e pacotes. Este aumento de ficheiros, métodos acompanhado de uma nomenclatura descritiva facilita a leitura do código e posteriormente beneficia também a capacidade de fazer refatoração do código ou depuração e correção de erros/problemas.

Os pacotes Java dividem-se de forma muito semelhante ao ACCU, descritos na página do Github [79] e detalhados na tabela 5.1, onde se podem ler o nome dos pacotes e uma breve descrição do seu objetivo.

ASA- Pacotes Nome do Pacote Objetivos

activities Atividades que estendem a classe Android: FragmentActivity [80]. fragments Fragmentos que estendem a class Android: Fragment [81].

comms Classes relacionadas com comunicaçõesIMC.

feedback Classes e serviços relacionados com feedback ao utilizador. handlers Classes responsáveis por lidar com eventos específicos.

managers Inclui managers de várias classes Java para lidar com componentes do dispositivo e externos.

listeners Classes responsáveis por receber eventos de diferentes componentes internas e externas.

settings Classes relacionadas com perfis e configurações do utilizador. subscribers Diversos subscritores de diversos eventos.

sys Classes relacionadas com a listagem e informação dos nós na rede. ui Componentes da Interface Visual.

util Diversos utilitários divididos hierarquicamente. Tabela 5.1: ASA- Pacotes

5.2.3 Customização

Motivada pelas reuniões com stakeholders mencionadas na secção5.1.2, foram definidos requisitos de customização de forma a adaptar a aplicação ao utilizador. De acordo com esses requisitos é

definida uma arquitetura que permita a fácil adição de novas opções para funcionalidades futuras e um esquema organizativo flexível e prático.

A solução encontrada começa por utilizar uma tecnologia Android: SharedPreferences [68] mencionada na secção 4.1.3. Esta tecnologia oferece uma plataforma global persistente de preferências consistindo em tuplos com: String identificativa e um valor que pode ser dos tipos: Integer, Float, Boolean, String ou StringSet; inclui também um ChangeListener capaz de ser reativo a mudanças nestas preferências. De forma a providenciar organização estas preferências devem ser divididas em categorias e são apresentadas organizadas pelas mesmas e conter uma descrição sobre o seu propósito.

Esta plataforma apresenta algumas limitações, que levaram a utilização de um ficheiro externo no formatoCSV. Este ficheiro tem por objetivos permitir a criação dinâmica interna e externa de perfis e organizar de forma expedita as preferências. Este ficheiro e as implementações associadas são especificados na secção6.4.

No capítulo6são detalhados aspetos técnicos e as escolhas tomadas na implementação dos conceitos definidos neste capítulo. Implementações essas motivadas pelas reuniões aqui descritas, modificadas e atualizadas para satisfazer os objetivos definidos, sendo posteriormente a sua validação e testes descritos no capítulo 7.

Capítulo 6

Implementação

Neste capítulo são detalhados as implementações dos conceitos, objetivos e requisitos mencionados no capítulo anterior 5. São mencionados aspetos técnicos de obtenção de informação incluindo filtragem e processamento de mensagens e comunicações entre componentes dentro da aplicação. São detalhadas algumas implementações feitas fora desta aplicação mas relevantes e com consequências neste projeto. É descrito a aplicação dos conceitos da arquitetura definida no capítulo anterior 5. São justificadas escolhas de interface, desenho e design e todo o processo de escolha por detrás da imagem final. Esta imagem e este desempenho aqui implementados são analisados estatisticamente e qualitativamente no capítulo seguinte 7.

6.1

Comunicações

Nesta secção são detalhados os processos de filtragem de mensagensIMC e descrito o processa- mento das mesmas, informações extraídas e a sua utilidade no contexto desta aplicação. São também detalhados os processos de comunicação entre diferentes componentes da aplicação.