PLANEJAMENTO DE MISSÕES DE VANTS UTILIZANDO … · controladora, que atua sobre os motores do...

PLANEJAMENTO DE MISSÕES DE VANTS UTILIZANDO MODELAGEM POR SEDS E SENSORES DE DECISÃO

RICARDO FERREIRA MARTINS1, GIAN LUCAS NUNES DE ALMEIDA1, ANDRÉ BITTENCOURT LEAL1

1. Departamento de Engenharia Elétrica Programa de Pós-Graduação em Engenharia Elétrica Universidade do Estado de Santa Catarina - UDESC

Joinville/SC [email protected], [email protected], [email protected]

Abstract⎯ The planning of an autonomous mission for UAVs requires more than the description of the points to be visited along the trajectory by which a certain task must be performed. However, the way in which such missions are planned does not provide conditions for the aircraft or the ground control system to find alternative ways of carrying out the mission, in the event of a risk or other different situation from what was initially planned. In this sense, this work makes use of a complementary description of the trajectory of a UAV, specifying it through the Discrete Events Systems (DES) framework. Furthermore, it makes use of sensor information to identify situations of risk and, from this, to systematically carry out changes in the mission initially programmed in the aircraft in order to avoid undesired situations.

Keywords⎯ Unmanned Aerial Vehicle, Mission Planning, Discrete Event Systems.

Resumo⎯ O planejamento de uma missão autônoma para VANTs requer mais do que a descrição dos pontos a serem visitados ao longo da trajetória pela qual uma determinada tarefa deve ser realizada. No entanto, a forma como essas missões são planejadas não prevê condições para que a aeronave ou o sistema de controle em solo encontrem formas alternativas de realizar a missão, no caso de um risco ou outra situação diferente do que foi inicialmente planejado. Nesse sentido, este trabalho faz uso de uma descrição complementar da trajetória de um VANT, especificando-a através da estrutura dos Sistemas de Eventos Discretos (SEDs). Além disso, faz uso de informações de sensores para identificar situações de risco e, a partir disso, realizar sistematicamente mudanças na missão, inicialmente programada na aeronave, para evitar situações indesejadas.

Palavras-chave⎯ Veículo Aéreo Não Tripulado, Planejamento de missão, Sistemas a Eventos Discretos.

1 Introdução

Uma maneira comum para um veículo aéreo não tripulado (VANT) operar automaticamente é quando ele usa coordenadas disponibilizadas através de uma estação terrestre (Ground Station - GS), que envia a trajetória de uma missão predefinida para a placa controladora. Esta trajetória não determina como a aeronave deve interagir com o meio ambiente em termos de relevo e obstáculos físicos, pois apenas identifica que deve seguir de um ponto no espaço aéreo para outro. De acordo com Scaramuzza et al. (2014), para que uma missão seja concluída, a placa controladora, que atua sobre os motores do VANT, possui um firmware que, na maioria dos casos, está preparado somente para fazer uso dos sensores da IMU (Inertia Measurement Unit), que são: o acelerômetro e o giroscópio (Nonami et al., 2010). Existem ainda sensores que fornecem informações complementares, sendo que os mais relevantes são: o GPS (Global Positioning System), o magnetômetro e o barômetro (Jiong, Lei et al., 2010).

Informações de sensores adicionais para navegação autônoma são essenciais, uma vez que estas informações são processadas por algoritmos que podem, por exemplo, evitar colisões. Esta técnica é denominada see-and-avoid. Os sensores ultrassônicos e infravermelho são capazes de realizar uma estimativa da distância. As câmeras já são utilizadas em diversas aplicações e áreas para reconhecimento de padrões e também podem ser empregadas em VANTs (Lim et al., 2012; Jang e Liccardo, 2006).

Durante a execução de um voo autônomo, o piloto deixa o controle de altitude e posição para a placa controladora de voo, que por sua vez faz a

movimentação com base na missão pré-definida por meio da GS. Para que este modo de voo funcione, é necessária a utilização da GS, uma vez que junto dele, o usuário planejará sua missão, definindo os pontos (waypoints) em que o VANT irá se deslocar até chegar ao seu destino final.

Por estes motivos, é de grande interesse a modificação do firmware bem como da GS do VANT para o uso de um ou mais sensores complementares e o desenvolvimento de um modelo que obtenha maiores informações sobre o comportamento da aeronave no espaço aéreo, levando em considerações as adversidades da planta (Scaramuzza et al., 2014).

Uma abordagem interessante para a solução deste problema pode ser através da utilização da teoria de Sistemas a Eventos Discretos (SEDs), no qual a evolução do sistema não se dá pelo decorrer do tempo, mas sim pela ocorrência de eventos discretos no tempo (Cassandras e Lafortune, 2008), como por exemplo, a chegada de um VANT a um waypoint.

Esses eventos discretos, por sua vez, são gerados através de ocorrências relacionadas ao sistema e podem ser associados a ações específicas, como acionar um sensor ou um conjunto de ações satisfeitas. Tais ocorrências de eventos discretos causam mudanças internas no sistema, que podem ou não se manifestar como ações externas a um observador. Estas mudanças do sistema são caracterizadas por mudanças abruptas e instantâneas em intervalos de tempo irregulares e desconhecidos, ou seja, após a percepção da ocorrência do evento, o sistema reage imediatamente e acomoda-se em tempo nulo em um novo estado.

XIII Simposio Brasileiro de Automacao Inteligente

Porto Alegre – RS, 1o – 4 de Outubro de 2017

ISSN 2175 8905 2307

Neste trabalho, o objetivo foi desenvolver uma ferramenta computacional capaz de levar em consideração a informação de sensores adicionais, embarcados ou não, para a tomada de decisões em pontos intermediários da missão principal. Esta ferramenta utiliza um modelo em SEDs da missão principal, onde é possível a adição de novas transições entre os pontos intermediários a fim de gerar pontos de decisão, particionando a missão principal em sub-missões. A partir destas sub-missões, a ferramenta gera o código compatível para o VANT. Assim, as contribuições deste trabalho foram no sentido de implementar novos recursos associados à GS - Mission Planner (Obourne, 2014; ArduPilot Dev Team, 2016) e ao firmware da placa controladora - APM 2.6 (ArduPilot Dev Team, 2016), bem como o desenvolvimento de módulos adicionais para a ferramenta Nadzoru (Pinheiro et al., 2015), para a manipulação dos modelos de SEDs, associados às missões.

O uso da técnica Hardware In the Loop (HIL) foi identificado como uma alternativa segura, visando reduzir os riscos inerentes aos novos recursos, diretamente em uma plataforma de voo físico.

A técnica HIL (ArduPilot Dev Team, 2016; Stevens e Lewis, 2003) é caracterizada pela operação de componentes reais em conexão com componentes simulados em tempo real. O processo consiste em simular parcialmente ou totalmente atuadores, sensores e processos físicos (Isermann, Schaffnit et al., 1999). Os benefícios da utilização do HIL são: • Realizar os testes do controle do hardware e

software sem a necessidade da real operação dos processos e sobre condições adversas extremas;

• Testar os efeitos causados pelas falhas dos atuadores ou sensores, reproduzindo experimentos com uma frequência de repetição;

• Economizar tempo e dinheiro no desenvolvimento, evitando possíveis avarias em ensaios físicos. Neste trabalho é utilizada a técnica HIL na forma

ilustrada na Figura 1. Assim, para a simulação do VANT será utilizado como hardware a placa controladora APM em conjunto com o seu software Mission Planner, que por sua vez estará conectado com o simulador de voo Flight Gear (FlightGear - Flight Simulator, 2017).

Figura 1. Funcionamento do HIL

A transição entre a técnica de simulação HIL e a utilização real do VANT, também é uma grande vantagem desta técnica, uma vez que só é necessária a mudança dos parâmetros do firmware para que o mesmo deixe de operar em modo HIL e passe a operar controlando o sistema real. A tabela 1 apresenta as especificações do software utilizado.

Tabela 1. Especificação do software

2 Conceitos fundamentais

Autômato Finito Determinístico (AFD)

Um autômato determinístico de estados finitos (AFD) é capaz de representar a linguagem de um SED, sendo definido por uma quíntupla:

𝐺 = {𝑋, Ʃ, ƒ, 𝑥!,𝑋!} (1) Onde:

• 𝑋 é o conjunto finito de estados do autômato; • Ʃ é o conjunto de eventos que definem o alfabeto; • ƒ : 𝑋 x Ʃ → 𝑋 é a função de transição de estados; • 𝑥! é o estado inicial; • 𝑋! ⊆ 𝑋 é o conjunto de estados marcados.

Este autômato é dito determinístico, pois ƒ é uma função de X x Ʃ para X, ou seja, não pode haver duas transições com o mesmo rótulo saindo do mesmo estado.

Como exemplo, a missão apresentada na Figura 2 pode ser representada por um AFD, como um conjunto de estados com transições sequenciais, iniciadas pelo estado inicial (S0) que define o waypoint de partida, até o último estado (marcado) que representa o waypoint de finalização (S5).

Figura 2. Um exemplo de missão e o seu AFD correspondente

Software Versão Licença

Simulador Flight Gear 2.0 GPLv2

GS Mission Planner 1.3.10 GPLv3

Placa controladora APM 2.6 GPLv3

Firmware HIL 2.9.1 GPLv3



2308

Este trabalho visa adicionar novos sensores (através de modificações no firmware da placa controladora APM, bem como no código da GS), incorporados ao VANT ou não, permitindo que decisões sejam tomadas em pontos intermediários, com o significado de modificar a missão durante o voo. Com isto, o modo de voo automático torna-se mais flexível, ou seja, possibilitando a tomada de decisões locais para modificar a rota de uma missão predefinida, através da leitura dos sensores.

Para viabilizar a adição das informações destes novos sensores, foi adotada a criação de modelos que possam representar o comportamento dos sensores e também a missão como um todo, utilizando a teoria de SEDs.

Os sensores podem ser embarcados na aeronave ou virtuais, onde a leitura desses sensores está associada à própria GS, centralizando as decisões tomadas pelo VANT com relação à sua nova rota. Assim, diante de condições que podem descaracterizar a missão original, o sistema pode interagir com a aeronave para encontrar uma alternativa, e não apenas abortar a missão.

A Figura 3 ilustra o planejamento de waypoints na GS de uma missão com 14 pontos no mapa, destacando apenas o conceito de visitação sequencial de pontos de interesse.

Figura 3. Planejamento de uma missão

No entanto, para que o VANT possa executar uma nova rota utilizando informações dos sensores, a GS exige, por definição, que estas novas rotas sejam previamente planeadas. Assim, adotou-se a sistemática de divisão da missão principal durante o seu planejamento, transformando-a em pequenas seções (sub-missões).

Diagnóstico de falhas durante a execução de missões

O tratamento de falhas em missões de VANTs é normalmente executado de forma isolada, ou seja, em cada aeronave. Por exemplo, situações de falta de combustível e ausência de sinal de comunicação com a base são tratadas de forma a programar a atitude de resolução do problema na própria placa controladora de voo. Existem diversas aplicações nas quais a necessidade de uso de mais de um VANT, seja de forma cooperativa ou não, implica planejar as missões destas aeronaves de forma conjunta. Se as aeronaves compartilham da mesma região, ou parte dela, em termos de trajetória de voo, situações de conflito podem ser observadas. A Figura 4 ilustra tal situação.

Figura 4. Região de conflito associada a duas missões (Va, em vermelho, e Vb, em amarelo)

De fato, cada um dos dois VANTs pode ocupar uma região de conflito, desde que em momentos distintos. A falha pode ser caracterizada de forma que as duas trajetórias permitam que estes veículos se encontrem neste ponto, ao mesmo tempo, ou ainda, em situações onde o desenvolvimento da trajetória possa ser comprometido, em termos de execução no tempo, devido a fatores que não são controláveis, como é o caso da interferência do vento ou de falha de comunicação.

Sampath et al. (1995) aborda o problema da diagnose de falhas em SEDs, fornecendo técnicas e abordagens necessárias para a concepção de um sistema de diagnóstico de falhas. Assim, é possível fazer uso de modelos de sistemas à eventos discretos para missões de VANTs que permitam que sejam consideradas falhas na missão.

A Figura 5 ilustra a possibilidade de alcance de um determinado ponto na missão (x1) a partir do waypoint x0.

Figura 5. Identificação de uma falha durante uma missão

A partir do ponto inicial da missão (x0), um VANT poderia alcançar o waypoint x1, normalmente (através da realização da trajetória planejada, representada pelo evento p1). No entanto, após a ocorrência de uma falha na execução da missão (evento σ), o veículo alcançaria um ponto (representado pelo realização da trajetória representada pelo evento p1’) em uma situação que poderia causar conflito, considerando que o waypoint final (?) possa ser x1, mas sem a ocorrência do evento p1. Com isto, esta modelagem permite a observação da possibilidade de conflito, através da análise dos pontos da missão que antecedem uma região de conflito.

Considerando ainda o exemplo da Figura 4, um AFD que descreve a missão do VANT Va está representado na Figura 6, na qual o estado p4a representa a região de conflito. É possível observar que, com diferenças apenas na identificação dos eventos e waypoints de cada VANT (Va e Vb), as



2309

missões são similares. Os eventos tfa e tfb representam a ocorrência de falhas, que neste exemplo podem ser associadas a falhas de comunicação (enlace de dados responsável pela telemetria em cada aeronave), as quais podem ser observadas em regiões mais distantes da GS (neste exemplo, os pontos p3a e p3b).

Figura 6. Modelagem para a missão de Va, considerando o evento de falha

A especificação de controle pode considerar que o primeiro VANT que alcançar o ponto próximo à região de conflito (p3), terá a sua passagem pelo ponto p4 priorizada, mas sem bloquear o movimento do VANT que estiver distante desta região, ou seja, o bloqueio (suspensão da missão desta aeronave) ocorrerá somente quando o segundo VANT alcançar o seu respectivo ponto p3. A Figura 7 apresenta uma solução para o gerenciador de conflito da GS.

Figura 7. Especificação de controle das missões

Seguindo o exemplo, foi realizada a composição síncrona entre os 3 autômatos (modelos para os VANTs Va e Vb e para a especificação de controle). Utilizando a ferramenta DESUMA (Ricker et al., 2006), obteve-se o autômato diagnosticador (36 estados, 72 transições) e verificou-se que os eventos tfa e tfb são diagnosticáveis. Assim, a especificação de controle determina a ordem de ocupação da região de conflito, através da observação da aproximação da primeira aeronave que alcançar a posição 3 da sua trajetória.

A adoção de uma estratégia de controle tolerante a falhas exige relacionar a informação obtida pelo autômato diagnosticador com o controle da missão. Assim, ocorrendo uma falha, o diagnosticador pode acionar uma ação de urgência, provocando uma atitude de segurança, por exemplo, um pouso forçado de uma das aeronaves, ou simplesmente a

manutenção da sua posição, até que a região de conflito seja liberada.

A caracterização da região de conflito dependerá do tipo de missão que as aeronaves estão envolvidas, bem como o detalhamento associado ao seu comportamento durante o voo (velocidade, proximidade dos waypoints envolvidos, entre outros).

3 Desenvolvimento do software e resultados de automação

Como já citado, a proposta é proporcionar uma maior flexibilidade para as missões automáticas, sendo como proposta a implementação de módulos de geração automática de código para novos sensores que tomariam decisões no decorrer de uma missão, criando novas rotas a serem tomadas.

Foi delimitada a problemática do trabalho para que as decisões só fossem tomadas em pontos intermediários pré-definidos pelo usuário no momento do planejamento da missão (waypoints), fracionando a missão principal em sub-missões. A Figura 8 ilustra o primeiro esquema utilizado.

Figura 8. Esquema de envio de submissões

Porém, a GS utilizado não estava preparado para receber a informação de novas sub-missões, ou seja, o usuário só poderia criar uma missão principal que seria enviada de maneira integral para o VANT e executada pelo mesmo de maneira automática, executando-a até o fim. Durante a execução desta, a GS não possuía nenhum controle sobre o VANT, com exceção do comando de abortar.

Desta maneira, foi utilizada uma ferramenta que pudesse entender os arquivos gerados pela GS da missão principal, tendo assim para o usuário a possibilidade de criar sub-missões derivadas da missão principal (objetivos principais) mediante o acionamento de um sensor.

A partir desta condição, foi utilizado o software Nadzoru (Pinheiro et al., 2015). A sua utilização se dá da seguinte forma: inicialmente, é realizada a importação no Nadzoru dos arquivos gerados pela GS e então estes são transformados em ADEFs, em arquivo passível de manipulação pelo Nadzoru. Desta forma, o autômato obtido pode ser modificado de modo a contemplar novas transições entre os pontos da missão. Após este procedimento, o software Nadzoru cria as novas sub-missões gerando os arquivos de texto das mesmas, que são utilizadas pela GS em decorrência da ativação do sensor e enviadas para o VANT.



2310

Sendo assim, a aplicação possui as seguintes etapas: 1. Criação da missão principal; 2. Importação da missão principal para o software

Nadzoru transformando-o em ADEF; 3. Adição de novas transições entre os waypoints

(pontos intermediários da missão); 4. Criação das sub-missões e geração automática

dos arquivos de texto das mesmas para utilização pela GS;

5. Utilização dos arquivos de texto das sub-missões pela GS, mediante o status do sensor.

Com isto, o principal objetivo desta aplicação é criar um modo de voo automático com o controle da missão na GS, ou seja, dependendo do status dos sensores envolvidos, a GS enviará uma sub-missão, e quando esta sub-missão chegar ao fim, realiza um teste para verificar se existe uma decisão neste ponto (caso contrário, a missão chegou ao fim).

Todo este processo de particionamento da missão principal em sub-missões foi realizado no software Nadzoru, onde foram criados os módulos de importação de missões do Mission Planner e os módulos de exportação de sub-missões.

O módulo de importação tem o objetivo utilizar o arquivo de texto, gerado pela GS da missão principal, com os waypoints e suas respectivas coordenadas geográficas, e transformar o mesmo em uma representação gráfica de um AFD. Esta importação transforma os waypoints da missão em estados no autômato, mantendo o rótulo deste estado compatível com o número do waypoint, utilizando um prefixo “WP_”. Feito isto, as informações de coordenadas geográficas dos waypoints são mantidas em uma variável interna do programa. Após estes procedimentos, ocorre a interligação dos estados automaticamente, com o evento Done, simbolizando que a transição entre um waypoint e o outro ocorreu.

Esta importação toma como estado inicial do autômato o waypoint inicial da missão principal, já o evento final (marcado) é obtido como o último waypoint da missão.

Uma vez criado o modelo, o usuário pode criar novas transições entre os estados, assim impondo que nos estados de origem das novas transições, sejam adicionados pontos de decisão, em consequência de que por padrão os arquivos vindos da GS, existem somente uma transição de saída em cada ponto da missão. Estas informações de transições de saídas são muito importantes, uma vez que as mesmas são utilizadas no módulo de criação de sub-missões.

O módulo de criação de sub-missões, denominado neste trabalho de “CSM” (Create Sub-Missions), faz a utilização do ADEF gerado anteriormente, concebido da importação da missão principal. Através deste ADEF é feito o uso das informações dos rótulos dos estados que representam os waypoints e também é utilizada a informação das transições de saída existentes no estado, como citado anteriormente.

Estas informações são cruciais para a criação de novas sub-missões, uma vez que por padrão só existe uma transição de saída entre os estados, ou seja, se existir mais de uma transição de saída, aquele waypoint será tratado com ponto de decisão, assim fracionando a missão principal até aquele ponto. A partir destes pontos de decisão são criadas duas novas sub-missões, a sub-missão D1 e D2, que levam o prefixo do nome do waypoint com decisão. Por exemplo, se no waypoint 3 existir um ponto de decisão, ou seja, duas transições de saída, serão criadas as sub-missões “3_D1” e “3_D2”.

Neste trabalho optou-se por utilizar a sub-missão D1 como a sequência da missão principal e que deve ser tomada mediante a não ativação do sensor, e a sub-missão D2 como a sub-missão que deve ser tomada mediante a ativação do sensor. A sub-missão D1 é constituída com a sequência do waypoint seguinte à decisão, até o próximo ponto de decisão ou fim da missão. Já a sub-missão D2 é constituída pela sequência do waypoint destino da transição criada no ponto de decisão, até o fim da missão ou até o próximo ponto de decisão.

Para que toda a missão principal seja contemplada pelas sub-missões, quando existe a primeira ocorrência de ponto de decisão, o sistema cria uma sub-missão com o prefixo “H_” seguido do ponto de decisão, indicando que o voo ocorrerá até aquele ponto, partindo da origem. Feitas as transições no modelo e utilizada a operação “CSM”, citada anteriormente, o software Nadzoru transforma estas sub-missões em arquivos de texto, no mesmo formato utilizado pela GS, podendo assim ser enviadas para o VANT. A implementação também realiza a criação de um arquivo denominado “fullmission” apenas para ser utilizada como controle na utilização das sub-missões na GS.

Figura 9. Arquivos criados pela operação CSM

A Figura 9 mostra os arquivos gerados mediante o uso desta ferramenta, utilizando um exemplo de missão, com pontos de decisão representados pelo autômato da mesma figura, onde os mesmos estão sendo destacados. É possível tomar o exemplo do estado referente ao waypoint 3 onde existem duas transições: uma transição padrão “Done” que leva ao



2311

waypoint 4, e outra transição “S1_on” que leva ao waypoint 13. Neste caso são geradas duas sub-missões referentes a este ponto: 3_D1 que é sub-missão referente à transição “Done” e 3_D2 referente à transição “S1_on”.

Como o processo de missão automática na GS não previa mais de uma missão, foi necessário criar um novo modo automático, de forma a possibilitar a escolha entre as sub-missões, indicando qual deveria ser enviada para o VANT mediante a leitura dos sensores. Assim, neste trabalho foi desenvolvido um modo denominado de AutoWD (Automatic With Decisions), o qual foi integrado a GS.

Além disso, foi criado um sensor virtual. A escolha inicial deste trabalho era que o sensor estivesse embarcado o que foi substituído durante o desenvolvimento por um sensor virtual na GS. A ideia da utilização deste sensor é a possibilidade de substituir o mesmo por qualquer tipo de sensor: embarcado na aeronave ou estar em solo próximo de alguma região de interesse, o qual enviaria as informações do seu status. Neste trabalho, optou-se por utilizar um sensor que possui três posições, sendo elas: On (Ativado), Off (Desligado) e Hold (espera).

Quando ativado o modo AutoWD, a GS inicia uma rotina de repetição buscando pelos arquivos das sub-missões. Primeiramente, esta rotina procura pela sub-missão inicial, que possui um formato contendo no inicio de seu título “H_”, como citado anteriormente, e envia a mesma para o VANT.

Após o envio desta sub-missão, o mesmo entra em modo de voo automático padrão para que a mesma seja executada. Junto com a informação da sub-missão inicial, existe também qual será o primeiro ponto de decisão, informação esta que está subsequente aos caracteres “H_”.

Quando o VANT realiza a primeira sub-missão e chega ao ponto de decisão, o mesmo entra em modo de voo Loiter (estabilizado na posição ocupada no espaço), permanecendo neste modo até que o sensor seja lido e ocorra a tomada de decisão mediante a sua posição, sendo elas: • Decisão 1 (envio da sub-missão D1) – Sensor

desativado; e • Decisão 2 (envio da sub-missão D2) – Sensor

ativado. Estas decisões são similares aos demais pontos

de decisão. Após a decisão ter sido tomada, é enviada para o VANT a sub-missão seguinte, sendo que em seguida ao envio o VANT entra em modo de voo automático para que seja realizada a execução desta sub-missão. Similar ao primeiro caso, quando o VANT chega ao fim da sub-missão o mesmo entra em modo de voo Loiter e analisa se existem arquivos das sub-missões naquele determinado waypoint. Caso estes arquivos existam, o sensor é analisado e a decisão é tomada, entretanto se estes arquivos não existirem significa que a missão principal chegou ao seu fim. A Figura 10 ilustra um fluxograma desta nova funcionalidade.

Figura 10. Fluxograma da estrutura da função AutoWD

4 Resultados experimentais

Os resultados experimentais que são apresentados neste trabalho não envolvem o planejamento de mais de uma missão, bem como o tratamento e diagnose de falhas. Além disto, a execução da trajetória entre dois waypoints ocorre através do uso de controladores PID que visam uma atitude de voo em linha reta, mas sofrendo interferência da ação do vento.

A GS possui um registro da posição que o VANT se locomove durante a missão, porém este registro é limitado, pois mantém um número pequeno de pontos, e apresentou problemas gráficos durante a representação dos dados de trajetória. Diante desses fatos, foi criada uma função na aba de simulação que habilita que os pontos de latitude e longitude possam ser salvados em um arquivo de texto, periodicamente a cada 500 milissegundos. Estes pontos podem ser utilizados para serem enviados a uma API do Google Maps possibilitando traçar a rota que o VANT executou durante o teste sem os problemas gráficos.

A Figura 11 mostra um comparativo dos registros da GS (a) e dos registros adquiridos via arquivo de texto e enviados para a API do Google Maps (b).

Sendo assim, todos os resultados mostrados neste trabalho serão os registros obtidos através dos valores de longitude e latitude salvados durante a execução do voo e representado na API do Google Maps.

Validação do HIL

Para realização dos testes foi planejada uma missão com 15 waypoints. A missão principal foi importada para o Nadzoru e adicionada uma transição do waypoint 3 para o 7 e uma transição do waypoint 14 para o 10, totalizando 5 sub-missões.



2312

(a)

(b) Figura 11. Comparação entre registros do Mission Planner (a) e

API do Google Maps (b)

Após o início da simulação o sensor foi ajustado para a posição “On” e como previsto, a GS tomou a decisão D2 enviando para o VANT a sub-missão 3_D2. Ao chegar ao próximo ponto de decisão (14), o sensor foi posto novamente na posição “On” de modo que foi enviada para o VANT a sub-missão 14_D2, fazendo com que o mesmo retornasse para o waypoint 10. Como a sequência levava novamente para o waypoint 14 e este é um ponto de decisão, o sensor foi colocado para posição “off”, levando a GS a enviar a sub-missão 14_D1. Como nenhum ponto de decisão foi encontrado e o VANT chegou ao waypoint final, a missão principal foi finalizada.

A Figura 12 ilustra o deslocamento do VANT no decorrer desta missão, sendo a linha vermelha o trajeto realizado pelo VANT e as linhas laranja (H_3), azul (3_D2), verde (12_D2) e preto (12_D1) as sub-missões utilizadas neste ensaio.

Os resultados da simulação podem ser vistos no link http://ricardofm.com/sbai2017/hil-results.mp4, no qual foi disponibilizado o vídeo do voo simulado com algumas informações adicionais.

Figura 12. Ensaio utilizando a função AutoWD

Validação através de voos reais

Durante o período final do trabalho foram realizados ensaios reais em um aeroclube da cidade de Joinville, respeitando a legislação vigente sobre VANTs. Nestes ensaios, foi utilizado um modelo de seis motores que pode ser visualizado com mais detalhes na Figura 13.

Figura 13. VANT utilizado para testes

Para facilitar a criação da missão e verificar se os pontos que o VANT transitava eram os mesmos pontos definidos na estação terrestre, foram utilizados marcadores no chão do local.

Foi proposto um cenário com 7 pontos intermediários (waypoints), sendo que em dois destes pontos (3 e 6) ocorria a análise do sensor para determinar a decisão a ser tomada. No ponto 3 o VANT tinha a possibilidade de ser enviado diretamente para o ponto 5 se o sensor estivesse ligado, ou continuaria sua trajetória original. Já no ponto 6 o VANT poderia retornar ao ponto 2 caso o sensor estivesse ligado, caso contrário, o mesmo seguiria até o último ponto (7). A Figura 14 ilustra o modelo da missão principal importada no Nadzoru, com as transições adicionais nos estados WP_3 e WP_6.

Figura 14. Missão real importada para o Nadzoru

Diante deste cenário foram impostas as seguintes condições. Na primeira passagem no ponto 3 o sensor seria ligado (o que é feito na GS) e seria enviado a sub-missão “3_D2”, deslocando o VANT até o ponto 5, já na primeira vez que o mesmo atingisse o ponto 6 o sensor também seria ligado forçando o VANT a voltar até o ponto 2, enviando a missão “6_D2”. Na segunda vez que o ponto 3 fosse atingido, seria desligado o sensor, forçando o envio da sub-missão “3_D1”, e o VANT se movimentaria sequencialmente até o próximo ponto de decisão. De maneira similar, na segunda vez em que o VANT passasse pelo ponto 6, o sensor seria desligado novamente e o VANT



2313

seria encaminhado para o ponto 7, último ponto planejado da missão.

O trajeto desta missão foi adquirido pela própria ferramenta Mission Planner, sendo que nestas circunstâncias o mesmo não apresentou erros gráficos no registro da movimentação do VANT. A Figura 15 ilustra a trajetória percorrida pelo VANT com os pontos definidos no início do ensaio, baseados nos marcadores do solo. Para uma melhor visualização da trajetória, a sequência de waypoints percorridos pelo VANT durante o teste real foi a seguinte: {1,2,3,5,6,2,3,4,5,6,7}.

Figura 15. Registro dos movimentos do VANT

Durante a utilização da abordagem real, o VANT não apresentou nenhum erro gráfico que era observado na técnica HIL. Além disso, é importante salientar que a precisão dos pontos foi de aproximadamente 1 metro tendo em vista que a distância entre os pontos eram de aproximadamente 15m, onde as condições de vento estavam em torno de 5 km/h. Mais detalhes podem ser vistos no link http://ricardofm.com/sbai2017/flight-results.mp4, no qual foi disponibilizado o vídeo do voo com algumas informações adicionais.

5 Conclusões

Este artigo apresenta uma nova forma de planejamento de missão para VANTs operando automaticamente. A estratégia implementada consiste em estruturar o modelo de missão através do uso de AFDs, que representam o comportamento da aeronave, associando o conceito de sensores de decisão, cuja informação pode desencadear a modificação da missão a ser executada.

Com a estação de controle em solo (GS) que acompanha a evolução da missão, é possível escolher, com base em planos alternativos pré-elaborados, a melhor modificação a ser feita, observando uma ou mais condições que não garantem a execução da missão original, de forma segura.

O uso da técnica Hardware in the Loop (HIL) permitiu o desenvolvimento do sistema de forma

segura, garantindo testes iniciais através de um ambiente simulado.

Referências

3DRobotics (2015) APM 2.6 Set, [Online]. https://store.3drobotics.com/products/apm-2-6-kit-1

ArduPilot Dev Team (2016) APM 2.5 and 2.6 Overview, [Online]. http://ardupilot.org/copter/docs/common-apm25-and-26-overview.html

ArduPilot Dev Team (2016) Hardware in the Loop Simulation Setup, [Online]. http://ardupilot.org/copter/docs/hil-quad.html

ArduPilot Dev Team (2016) Mission Planner Overview, [Online]. http://ardupilot.org/planner/docs/mission-planner-overview.html

Cassandras, C. and Lafortune, S. (2008) Introduction to Discrete Event Systems, Springer Science & Business Media, 2nd edition.

FlightGear - Flight Simulator (2017), [Online]. http://www.flightgear.org

Isermann, R., Schaffnit, J. and Sinsel, S. (1999) 'Hardware-in-the-loop simulation for the design and testing of engine-control systems', Control Engineering Practice, pp. 643–653.

Jang, J.S. and Liccardo, D. (2006) 'Automation of Small UAVs using a Low Cost Mems Sensor and Embedded Computing Platform', IEEE/AIAA 25th Digital Avionics Systems Conference, pp. 1 - 9.

Jiong, Y., Lei, Z. and Jiangping, D. (2010) 'GPS/SINS/BARO Integrated Navigation System for UAV', IEEE International Forum on Information Technology and Applications (IFITA), July, pp. 19 - 25.

Lim, H., Park, J., Lee, D. and Kim, H.J. (2012) 'Build Your Own Quadrotor', IEEE Robotics & Automation Magazine, September, vol. 19, no. 3, pp. 33 - 45.

Nonami, K., Kendoul, F., Suzuki, S., et al. (2010) 'Autonomous Flying Robots: Unmanned Aerial Vehicles and Micro Aerial Vehicles', Springer Publishing Company.

Obourne, M. (2014) Mission Planner Ground Control Station, [Online]. https://github.com/diydrones/MissionPlanner

Pinheiro, L.P., Lopes, Y.K., Leal, A.B. and Rosso, R.U.J. (2015) 'Nadzoru: A Software Tool for Supervisory Control of Discrete Event Systems', IFAC - PapersOnline, vol. 48, pp. 182-187.

Ricker, L., Lafortune, S. and Genc, S. (2006) 'DESUMA: A Tool Integrating GIDDES and UMDES', 8th International Workshop on Discrete Event Systems.

Sampath, M., Sengupta, R., Lafortune, S., et al. (1995) Diagnosability of discrete-event systems, IEEE Transactions on Automatic Control, vol. 40, issue 9, September, pp. 1555-1575.

Scaramuzza, D., Achtelik, M.C., Doitsidis, L., et al. (2014) 'Vision-Controlled Micro Flying Robots: from System Design to Autonomous Navigation and Mapping in GPS-denied Environments', IEEE Robotics & Automation Magazine, vol. 21, no. 3, August, pp. 26-40.

Stevens, B.L. and Lewis, F.L. (2003) Aircraft Control and Simulation, 2nd edition, John Wiley & Sons.



2314

PLANEJAMENTO DE MISSÕES DE VANTS UTILIZANDO … · controladora, que atua sobre os motores do...

Documents

Transcript of PLANEJAMENTO DE MISSÕES DE VANTS UTILIZANDO … · controladora, que atua sobre os motores do...