Fly-by-Camera para UAV
5. TESTES DE VALIDAÇÃO 1. Software
5.1.1. Modo Piloto
A Figura 7 representa o comportamento da aeronave quando sujeita a múltiplas alterações de referência de pranchamento (control doublets). Verifica-se que o intervalo de tempo entre a alteração do pranchamento pelo operador e a aeronave começar a alterar o seu pranchamento, é de aproximadamente um segundo, o que corresponde essencialmente à taxa de actualização dos dados entre a consola de operação e a aeronave. É relevante enfatizar que, tratando-se de um ambiente de simulação, a informação que é apresentada não quantifica os atrasos nas comunicações.
Este teste permitiu também verificar que a alteração consecutiva (oscilatória) das referências de pranchamento, não induzem nenhum comportamento instável na aeronave.
Figura 8: Pranchamento de referência vs. Pranchamento real com múltiplas alterações.
5.1.2. Modo Vigilância
A presente secção pretende validar o cálculo do footprint (área no solo correspondente à capturada pela câmara) comparando a solução do sistema implementado com o seu valor expectável. Para tal, foram testadas diversas situações onde é possível prever com alguma certeza a posição dos pontos relativamente à aeronave. Neste artigo serão apenas apresentados três situações diferentes, de um total de sete, que permitiram validar o sistema.
A situação 1, ilustrada na Figura 9, representa o caso mais simples onde a câmara está apontada directamente para baixo da aeronave (eixo paralelo a e perpendicular ao plano ) e sem qualquer alteração de azimute. Desta forma é esperado que o footprint da câmara seja um rectângulo cuja projecção no solo é proporcional aos parâmetros de campo de visão (field of view) da câmara. As situações 2 e 3 representam o footprint para diferentes combinações de atitude da aeronave mas a mesma orientação relativa da gimbal, conforme ilustrado na Figura 10.
Figura 9: Teste de validação do footprint da câmara – Situação 1.
Figura 10: Teste de validação do footprint da câmara – Situação 2 e 3.
5.1.3. Modo Seguimento
Esta secção apresenta alguns ensaios que foram realizados com o algoritmo de seguimento em simulação de software. Para validar o algoritmo foram realizados 2 testes em diferentes condições. O footprint apresentado na Figura 11é correspondente ao verificado a cada 40 segundos de simulação.
Em baixo são apresentados os resultados no teste com um alvo em movimento. Denote-se também que, excepto na primeira fase, o alvo se encontra sempre dentro do campo de visão da câmara significando que o operador nunca perde o alvo de vista durante o seguimento. Tal como no caso anterior, para validação do modo de seguimento, assume-se que a posição do alvo é conhecida e que o operador identifica sempre o alvo desde que este se encontre dentro do footprint da câmara.
Figura 11: Seguimento de um alvo em movimento.
A Figura 12 apresenta dados de rumo, tanto da aeronave como da gimbal, para esta mesma simulação. Tal como foi apresentado anteriormente, a simulação inicia-se com a gimbal orientada na mesma direcção da aeronave, e como tal a diferença entre rumos é nula. Quando o azimute da gimbal ultrapassa 80º em relação à aeronave, a orientação da gimbal e da aeronave ficam acopladas. Caso contrário, à semelhança do que acontece com o modo de vigilância,
a alteração dos comandos de Joystick apenas varia a orientação da gimbal. Este modo de funcionamento tem como objectivo obter trajectórias suaves e intuitivas para o operador, de tal forma que a trajectória da aeronave só seja efectivamente alterada quando o rumo relativo entre a aeronave e o alvo é suficientemente elevado, justificando uma alteração no rumo da mesma.
Esta estratégia permite uma maior aproximação entre a aeronave e o alvo, com uma carga de esforço reduzida sobre o controlo do Joystick (menos inputs por intervalo de tempo) e sobre a atitude da aeronave (baixo workload necessário).
Figura 12: Comparação entre rumos UAV - Gimbal
5.2. Hardware
Esta secção apresenta os testes realizados para validação das comunicações entre o diverso hardware utilizado pelo sistema “Fly-by-camera” descrito neste artigo. Estes testes foram divididos em 5 fases diferentes. Dado o sistema proposto incluir o uso de um Joystick, foi necessário, na primeira fase, estabelecer comunicação entre um computador e um Joystick. Desta forma, foi implementado em código MATLAB um algoritmo recebesse e apresentasse os dados recebidos.
Para testar o controlador dos servos, implementou-se na ferramenta Simulink do MATLAB um algoritmo que enviasse as referências de orientação dos servos via USB e porta série. O controlador foi implementado em Simulink pois seria esta a ferramenta utilizada na sua versão final, para exportar o código para o computador de bordo. A informação obtida a partir do Joystick foi convertida em graus e, posteriormente, em PWM sendo finalmente encapsulada segundo o protocolo de comunicação do controlador de servos. O sucesso do estabelecimento da comunicação observou-se através da movimentação dos servos de acordo com o desejado.
A comunicação entre a consola de comando e controlo e o computador de bordo foi estabelecida via cabo de rede. Utilizou-se a livraria xPC target do software MATLAB (MATLAB, 2012) para compilar e enviar o modelo Simulink para o computador de bordo (também designado neste artigo por PC104).
Este último encontrava-se ligado a um monitor, de forma a observar e analisar a correcta recepção dos dados enviados. Após a comunicação entre o computador e o PC104 ser estabelecida com sucesso, foi testado o envio de dados através das portas de comunicação (COM) do PC104.
Para testar a comunicação entre todo o sistema, este foi montado de acordo com a arquitetura descrita na Secção 2 deste artigo. Os comandos provenientes do Joystick foram enviados via UDP (através de um cabo de rede) para o PC104. Este, por sua vez, encontrava-se conectado ao MST via porta COM. O MST controlava os servos de acordo com as referências do Joystick. Após o controlo directo dos servos pelo periférico foi iniciado o teste com todo o software (GUI e software do piloto automático) e hardware. Com esta configuração, o movimento dos servos, o cálculo do footprint e altitude da aeronave estavam coincidentes com o expectável como ilustrado na secção 4.1.