Anais do 12O Encontro de Iniciação Científica e Pós-Graduação do ITA – XII ENCITA / 2006
Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, Outubro, 16 a 19, 2006
SIMULAÇÃO EM TEMPO REAL DE VEÍCULOS AÉREOS NÃO
TRIPULADOS
Emilio A. F. Albuquerque Filho1, Benedito C. O. Maciel2, Emilia Villani3, Luiz C. S. Góes3
1,3 - Instituto Tecnológico de Aeronáutica
12.228-490 São José dos Campos – SP
1- Bolsista PIBIC-CNPq
[email protected], [email protected], [email protected]
2- Flight Technologies
Incubadora Aeroespacial – CTA, Alameda Urupema, s/n, Sala 1
Pça. Mal. Eduardo Gomes, 50 – Vila das Acácias 12228-900 São José dos Campos – SP
[email protected]
Resumo. Este trabalho aborda a utilização do software MatLab para simulação em tempo-real do comportamento de
Veículos Aéreos Não Tripulados (VANT, ou UAV – Unmaned Aerial Vehicle). A simulação em tempo real tem como
objetivo auxiliar o projeto e desenvolvimento de sistemas de controle e piloto automáticos embarcados em VANTs. A
montagem consiste basicamente de um controlador (hardware), por uma aeronave em bancada e por um computador
no qual é executada a simulação em tempo-real da dinâmica de vôo. Todas as comunicações são via RS-232. Foi feito
um estudo dos recursos disponibilizados pela plataforma MatLab para que o sistema pudesse funcionar em tempo real
e o controlador pudesse ser testado em bancada, eliminando-se a necessidade de ensaio em vôo.
Palavras chave: Controle, VANT, Tempo real, Real Time Workshop, xPC Target
1. Introdução
Este trabalho aborda a utilização do software MatLab para simulação em tempo-real do comportamento de
Veículos Aéreos Não Tripulados (VANT, ou UAV – Unmaned Aerial Vehicle). A simulação em tempo real tem como
objetivo auxiliar o projeto e desenvolvimento de sistemas de controle e piloto automáticos embarcados em VANTs.
Para este propósito, utiliza-se uma bancada de testes composta pelo controlador (hardware), por uma aeronave em
bancada e por um computador no qual é executada a simulação em tempo-real da dinâmica de vôo. O controlador é
responsável tanto pela implementação da lei de controle como pelo envio dos sinais dos sensores para a simulação. Ele
recebe dos sensores o posicionamento das superfícies de controle e, da simulação, a atitude do avião e o sinal de
referência do Joystick, em um determinado instante. Aplica então uma lei de controle e envia o sinal de atuação tanto
para os atuadores no avião em bancada, como para a simulação. A simulação é responsável unicamente pela dinâmica
de vôo do avião, que está na realidade em bancada.
Para que essa bancada de testes trabalhe adequadamente, a simulação deve não somente corresponder à própria
dinâmica do avião, mas também deve realizar o processamento e responder às entradas obedecendo a restrições no
tempo do sistema. O objetivo deste trabalho é, portanto, o estudo dos recursos disponibilizados pelo MatLab para a
implementação do simulador de vôo em tempo real.
2. Equações de movimento
O entendimento da dinâmica de um avião é importante no estudo das qualidades de vôo e para o projeto de um
piloto automático. Para o trabalho desenvolvido, o conhecimento dessa dinâmica é fundamental, pois sem a qual não é
possível a obtenção do modelo e a conseqüente construção do modelo de simulação. O equacionamento aqui
apresentado é baseado em Nelson (1989).
As equações de movimento de corpo rígido são obtidas da segunda lei de Newton, que estabelece que o somatório
de todas as forças externas atuando em um corpo é igual à variação temporal da quantidade de movimento linear. Da
mesma forma, o somatório dos momentos externos atuando no corpo é igual á variação temporal da quantidade de
movimento angular. As variações temporais das quantidades de movimento são adotadas de acordo com um referencial
inercial. Em muitos problemas de dinâmica de um avião, um referencial fixo a Terra é adotado como inercial.
Escrevendo as equações da segunda lei de Newton e decompondo os vetores que nelas aparecem em suas
respectivas componentes, obtemos equações escalares excitadas pelas forças e momentos resultantes da aerodinâmica,
da propulsão e da ação da gravidade. Foi então considerado um elemento de massa em relação a um referencial inercial,
sendo δF a resultante de forças, δM a resultante de momentos e δm sua massa. Escrevendo a velocidade desse elemento
de massa em relação ao centro de massa do avião e substituindo nas equações escalares provenientes da segunda lei de
Anais do XII ENCITA 2006, ITA, Outubro, 23-26, 2006
,
Newton, tanto para o movimento linear quanto angular, e desenvolvendo, obtém-se as equações para as quantidades de
movimento linear e angular.
Pode ser mostrado que a derivada de um vetor arbitrário A, em relação a um sistema de coordenadas preso a um
corpo em rotação com velocidade angular ω, pode ser escrito da forma:
r
r
r r
dA
dA
=
+ω× A
dt I dt C
(1)
Os subscritos I e C se referem aos referenciais inercial e do corpo respectivamente, conforme apresentado na Fig. 1.
Figura 1. Referenciais fixo e do corpo.
Aplicando essa identidade às equações da quantidade de movimento linear e angular, tem-se:
r
r
r r
dvc
+ m(ω × vc )
F =m
dt C
r
r dH
r r
+ω× H
M=
dt C
(2)
Desenvolvendo-se, obtém-se as equações de força:
Fx = m(u& + qw − rv)
Fy = m(v& + ru − pw)
(3)
Fz = m( w& + pv − qu )
em que Fx, Fy e Fz são as componentes da resultante das forças F, m a massa do avião, u,v e w as componentes da
velocidade linear e p, q e r as componentes da velocidade angular do avião, todas em relação a um referencial preso no
corpo. Obtém-se também as equações de momento:
L = I x p& − I xz r& + qr ( I z − I y ) − I xz pq
M = I y q& − rp( I x − I z ) − I xz ( p 2 − r 2 )
(4)
N = − I xz p& + I z r& + pq( I y − I x ) + I xz qr
em que L, M e N são as componentes do momento resultante M e os Ix, Iy, Iz, Ixy, Ixz e Iyz são os momentos e
produtos de inércia do avião.
Anais do XII ENCITA 2006, ITA, Outubro, 23-26, 2006
,
As equações de movimento apresentadas anteriormente foram derivadas a partir de um referencial fixado no corpo.
Entretanto, o posicionamento e a orientação de um corpo não podem ser descritos por um sistema de coordenadas preso
nesse corpo, sendo estes então descritos com base em um referencial fixo, a partir do uso dos ângulos de Euler. Tendo
definido os ângulos de Euler, pode-se determinar as componentes das velocidades de vôo relativamente ao referencial
fixo. Assim, obtém-se a velocidade do avião de acordo com o referencial fixo em termos dos ângulos de Euler e das
componentes da velocidade no referencial do corpo:
⎡ dx ⎤
⎢ dt ⎥
⎢ ⎥ ⎡Cθ Cψ
⎢ dy ⎥ = ⎢C C
⎢ dt ⎥ ⎢ θ ψ
⎢ ⎥ ⎢⎣ − Sθ
⎢ dz ⎥
⎢⎣ dt ⎥⎦
SΦ Sθ Cψ − CΦ Cψ
SΦ Sθ Sψ + CΦ Cψ
SΦ Cθ
CΦ Sθ Cψ + SΦ Sψ ⎤ ⎡ u ⎤
CΦ Sθ Sψ − SΦ Cψ ⎥⎥ ⎢⎢ v ⎥⎥
⎥⎦ ⎢⎣ w⎥⎦
CΦ Cθ
(5)
onde ψ é o ângulo de guinada, θ o ângulo de arfagem e Φ o ângulo de rolamento e onde adotou-se a notação Cα =
cos(α) e Sα = sen(α). A integração dessas equações resulta na posição do avião em relação ao referencial fixo . Assim,
com certo desenvolvimento, obtém-se as velocidades angulares do corpo em termos dos ângulos de Euler e suas
derivadas temporais:
& −ψ& S
p=Φ
θ
&
q = θ CΦ + ψ& Cθ SΦ
r = ψ& C C − θ&S
θ
Φ
(6)
Φ
3.Simulação Tempo Real
Sistemas que funcionam em tempo real são ditos aqueles em que imposições de funcionamento de acordo com
restrições no tempo são obedecidas. Ou seja, o bom funcionamento do sistema não depende apenas se o seu resultado
está correto ou não, mas também do tempo em que o processamento é realizado. Uma operação realizada após os
limites de tempo, falhou ou está incorreta por definição.
Tais imposições tão restritas são requisitos de sistema para os quais se não houver uma reação em tempo hábil,
haverá uma perda de algum tipo. Essa perda pode ser a de estabilidade, como no caso do movimento de aviões. Pode
ser também resultado de riscos potenciais caso uma resposta não for dada em tempo hábil, como no caso de airbags e
sistemas de segurança de centrais de energia (hidrelétricas, usinas nucleares).
No que se refere a simulação, para as necessidades do sistema de bancada de testes do controlador, deve-se ter uma
simulação em tempo real. Esta deve, portanto, fornecer as saídas (as que são relevantes de acordo com o modelo
construído) da planta simulada dentro de uma janela de tempo suficientemente pequena para que a dinâmica da planta
real seja reproduzida e que uma certa margem de erro/atraso seja respeitada. Essa janela de tempo deve ser determinada
a partir da própria freqüência de amostragem dos inputs, coincidindo ou sendo um múltiplo inteiro da mesma.
4. Real Time Workshop e Real-Time Windows Target
Com o problema de se ter simulações funcionando em tempo real, para que assim o controle do avião possa ser
testado e aperfeiçoado, foi estudado o Real-Time Workshop (RTW) do Simulink. Esta é uma ferramenta que possibilita
a rápida criação de softwares com funcionamento em tempo real para uma variedade de sistemas. Juntamente com
outras ferramentas e componentes da MathWorks, permite a geração de código para diversas plataformas.
O Real-Time Windows Target (RTWT), por sua vez, é um ambiente para prototipagem e teste de sistemas em
tempo real. Nele, o computador é ao mesmo tempo o host e o target. Computador host é aquele no qual está instalado o
MATLAB, o Simulink, o Real time Workshop, o Real-Time Windows Target e/ou o xPC Target para executar e
visualizar uma aplicação em tempo real. Um target é aquele para o qual é montado o código no RTW e será nesse
ambiente ou sistema que se executará a aplicação em tempo real. No caso do RTWT, o computador sendo o host e o
target ao mesmo tempo, este pode ser um computador de mesa, um laptop ou um notebook.
Assim, após a criação de um modelo em Simulink, pode-se gerar um código por meio do RTW, tendo como
aplicação alvo o RTWT. Em seguida, executa-se esse código em tempo real com o Simulink em modo externo.
O modo externo do Simulink permite que dois sistemas separados, um host e um target se comuniquem. Como já
mencionado, o host é o computador em que está o MATLAB e o Simulink, o target é aquele no qual o executável
criado pelo RTW é executado. No modo externo, o host (Simulink) transmite mensagens requerendo que o target aceite
Anais do XII ENCITA 2006, ITA, Outubro, 23-26, 2006
,
mudanças ou transmita dados de sinais. O target responde executando a ordem. No menu, escolhendo Simulation, podese ativar o external mode. Então, basta conectar-se ao target para controlar e executar o programa em tempo real. No
caso do Real-Time Windows Target, o modo externo consiste de uma interface de comunicação em que parâmetros
podem ser alterados e pode haver aquisição de dados.
4.1. Resolução do problema usando o Real-Time Windows Target
Para a comunicação entre o computador em que está sendo realizada a simulação e o hardware escolheu-se que
fosse via RS-232. Portanto, para que a comunicação seja implementada, é preciso que seja criada uma S-Function. Mas
o RTW não trabalha com M-File S-Functions, ou seja, S-Functions escritas em código MATLAB. Deve-se assim ser
criada uma C Mex-File S-Function, escrita em C e atendendo a determinadas restrições de sintaxe e nome de variáveis.
Para minimizar a preocupação com restrições no formato final da S-Function, pode-se utilizar o S-Function Builder,
uma ferramenta gráfica na qual apenas se insere o código em campos próprios e se configura particulares a serem
atendidas: ele gera o código final.
Mas a construção da S-Function não termina nesse estágio. Para que o código final gerado pelo RTW atenda
requisitos de desempenho, é necessário otimizá-lo. De acordo com o nível de complexidade do modelo Simulink e da
exigência de seu desempenho quando rodando em tempo real, diferentes tipos de S-Functions para trabalharem
conjuntamente com o Simulink e o RTW devem ser desenvolvidas. Em ordem de exigência, elas podem ser classificadas
em:
1. Noninlined S-functions
2. Wrapper S-functions
3. Fully Inlined S-functions
A Noninlined S-Function é a forma menos otimizada e menos eficiente das três: todas as chamadas de rotinas
intermediárias estão presentes. A Wrapper S-Function consiste de uma implementação do código da S-Function no
código final de forma mais acoplada e cinegética, em que etapas na chamada de funções são eliminadas. A Fully Inlined
S-Function constrói seu código no Simulink e no RTW de tal forma que ele fica indistinguível de um bloco do próprio
Simulink, eliminando a chamada de funções intermediárias e tornando o processamento bem mais eficiente. Devido à
complexidade do Six-Simulator, provavelmente seria necessária a implementação de uma Wrapper ou Fully Inlined SFunction.
Tipicamente, uma Fully Inlined S-Function requer a implementação de seu algoritmo duas vezes: uma para o
Simulink e outra para o RTW (arquivo TLC), com o uso do Target Laguage Compiler (TLC). A complexidade do
arquivo TLC depende da complexidade do algoritmo a ser transformado em S-Function e do nível de eficiência
requerida para o código gerado. Para a criação de Wrapper S-Functions, também é necessário o uso do Target
Language Compiler.
O Target Language Compiler é parte integrante do RTW e permite que código gerado pelo RTW seja
customizado. Ele existe para um propósito, que é o de gerar código para um determinado target, ou alvo.
5. xPC Target
xPC Target é um ambiente para a prototipagem, teste e desenvolvimento de sistemas que funcionem em tempo
real para computadores padrões. Ele utiliza um computador target, separado do computador host, para rodar aplicações
em tempo real. Um computador target pode ser praticamente qualquer computador com um Intel 386 ou Pentium 486
ou AMD K5 ou K6/Athlon. Também deve conter um drive para disquete, uma porta serial livre ou um Ethernet adapter
card. Pode ser um computador de mesa ou um computador industrial. Maiores detalhes e especificações, procurar no
HELP do xPC Target, em Hardware Enviroment.
A partir de uma simulação criada normalmente, pode-se gerar um código executável a partir do RTW, tendo
como alvo o próprio xPC Target. O código executável é então gravado do computador host para o target executando o
xPC Target real-time kernel. Em seguida, pode-se testar a aplicação em tempo real, com possível variação de
parâmetros do modelo.
5.1. Resolução do problema usando o xPC Target
O comando xPCexplr abre o xPC Target Explorer. Trata-se de uma ferramenta gráfica de interface que facilita
o uso do xPC Target. O uso desta ferramenta foi o método escolhido para se utilizar o xPC Target. Outros meios seriam
via comandos no MATLAB e no modo externo do Simulink.
No ambiente do xPC Target Explorer, configura-se o computador host e o target para uma determinada
aplicação. Para nossa aplicação, escolheu-se que essa comunicação seria via comunicação serial, mas também pode ser
feita via rede. A partir dessa configuração é gerado o disco de boot a ser inserido no computador target, para que ele
inicialize no ambiente de simulação. Também por meio do xPC Target Explorer, grava-se o modelo para o computador
Anais do XII ENCITA 2006, ITA, Outubro, 23-26, 2006
,
target, ao mesmo tempo que é gerado o código pelo RTW, para em seguida executar a simulação. Pode-se alterar o
tempo de parada e o tempo de amostra, sem a necessidade de se gerar novo código executável e pode-se também
acessar as informações de desempenho durante ou depois da última execução da simulação. A ferramenta permite
também a alteração de parâmetros do modelo em tempo de execução e a aquisição de dados através de diferentes tipos
de blocos scope.
Como já mencionado, a partir do momento em que se configura o computador host e o target, pode-se gerar
um disco de boot para essa combinação de computadores. Faz-se então a conexão do computador target para o sistema
xPC Target do computador host. Em seguida, gerar-se o código executável via RTW com opção do mesmo ser gravado
automaticamente para o computador target, configurando-se para tanto os parâmetros da simulação. A partir desse
passo, a simulação pode ser rodada no computador target.
5.2. Comunicação serial pelo xPC Target
A sessão anterior descreve em linhas gerais os passos a serem seguidos para a geração de código com o RTW.
Ela visava o uso do xPC Target Explorer em um computador host para gerenciamento de uma simulação em tempo real
em um computador target. De acordo com o problema abordado, o computador que realiza a simulação deve estar
conectado ao hardware, que por sua vez estará trocando informações com os atuadores e sensores do avião. Essa
comunicação computador-hardware é via RS-232. Foi então estudado como o xPC Target facilita esse tipo de
comunicação.
Para ser possível a comunicação via RS-232, a biblioteca do xPC Target possui diversos blocos relacionados a
RS-232. Para os drivers convencionais, temos os seguintes blocos:
•
•
•
•
RS-232 setup: É necessário um bloco desses para cada porta serial em uso no modelo. Esse bloco não possui nem
entradas nem saídas, mas envia as mensagens de inicialização e término para cada porta.
RS-232 Send/Receive (Modo Síncrono): Esse bloco possui entradas e saídas para o modelo e espera respostas para
mensagens de enviado e recebido.
RS-232 Send (Modo Assíncrono): Esse bloco possui entradas do modelo e espera respostas para mensagens de
enviado.
RS-232 Receive (Modo Assíncrono): Esse bloco possui saídas do modelo e espera respostas para mensagens de
recebido.
A comunicação ocorre via uma série de mensagens enviadas e recebidas entre o computador alvo e o
dispositivo RS-232. Para tal, tais mensagens devem estar em formato que possa ser compreendido por ambas as partes.
Portanto, o xPC Target se utiliza de MATLAB structures para criar mensagens e mapear as portas de entrada e saída dos
blocos RS-232 para os dados escritos e lidos nos dispositivos RS-232. O bloco RS-232 setup envia as mensagens na
estrutura de inicialização após o download da aplicação. Os blocos RS-232 de Send e/ou Receive repetem o envio das
mensagens cada vez que informação é trocada durante cada intervalo. Quando a aplicação pára de rodar, o bloco RS232 setup envia uma mensagem de término.
6. Prosseguimento do trabalho
Em prosseguimento ao trabalho, é necessário dar continuidade ao estudo dos blocos do xPC Target
responsáveis pela comunicação serial com um outro hardware. Isso envolve principalmente o domínio das MATLAB
structures para a boa comunicação dos drivers. Deve-se também decidir quanto ao uso dos blocos de comunicação
síncrona ou assíncrona. De modo geral, utiliza-se o modo síncrono quando se precisa receber uma resposta antes de se
prosseguir com o processamento dos dados. Desse modo, dados são enviados para o ambiente externo e o bloco driver
espera por uma resposta, parando a aplicação target até a resposta ou até que se atinja um tempo limite. Já quanto ao
modo assíncrono, pode-se utilizá-lo quando não há necessidade de uma resposta para se prosseguir com o
processamento. Taxas de amostragem mais rápidas podem ser atingidas dessa forma, uma vez que nem os blocos de
Send nem de Receive não esperam por uma resposta. Como resultado, não há bloqueio da simulação como no modo
síncrono.
Provavelmente a decisão entre o modo síncrono e o assíncrono é realizada via testes de desempenho da
simulação. Esses testes consistiriam da comparação dos resultados depois da implementado em tempo real com os
obtidos de uma simulação trabalhando em pseudo real-time com uma dll obtida na Internet e já em funcionamento na
empresa Flight Technologies. Outra comparação importante é quanto aos resultados do síncrono e do assíncrono via
osciloscópio, por exemplo.
Aprendendo-se mais sobre o funcionamento desses drivers e escolhendo-se o tipo de comunicação, de acordo
com os conhecimentos adquiridos até agora, imagina-se que seja necessário apenas identificar e destacar do diagrama
de blocos do Six Simulator (modelo de simulação da dinâmica do avião em que se foi trabalhado na empresa Flight
Technologies) os sinais que devem ser enviados e aqueles que devem ser recebidos do hardware. Como o bloco do
Anais do XII ENCITA 2006, ITA, Outubro, 23-26, 2006
,
joystick já faz parte do Virtual Reality Toolbox do Simulink, não é preciso nenhuma manipulação para seu
funcionamento. Aplicando-se o procedimento descrito nas sessões anteriores, o controle e execução da simulação
poderão ser realizados via xPC Target Explorer. Executadas essas atividades propostas, ter-se-á o Six-Simulator com
Joystick funcionando em tempo real.
O xPC target também oferece outras possibilidades pelo xPC Target Embedded Option, com outros modos de
aplicação. O modo StandAlone, por exemplo, em que é eliminada a necessidade do computador host para a realização
de aplicações em Real time, se mostrou interessante para as necessidades da Flight Technologies. Este seria um passo
provável na sucessão das atividades.
7. Comentários e Conclusão
Entre as dificuldades encontradas, destaca-se a dificuldade de aprendizado das ferramentas de tempo real do
Simulink, tais como o Real time Workshop, o Target Language Compiler, o Real-Time Windows Target e o xPC
Target, para citar apenas as mais estudadas nesse trabalho. Estas ferramentas não são de conhecimento e uso da maioria
dos usuários do MatLab e muitas vezes apresentam documentação pouco clara. Tal limitação exigiu um trabalho de
descobertas e aprendizados, via comunidades e fóruns na Internet e pelo uso do HELP do MATLAB: esforços próprios
de um trabalho de pesquisa.
Os erros levaram a novas experimentações de outras ferramentas do Simulink, assim como a melhor
compreensão das utilizadas. À medida que foram sendo estudadas ferramentas tais como o Real time Workshop, RealTime Windows Target e do xPC Target, se obteve noção da vastidão de conhecimento e das possibilidades ainda a
serem exploradas. A criação do próprio conhecimento de acordo com esse processo foi bastante interessante e tornou
extremamente válido o trabalho desenvolvido.
8. Agradecimentos
O autor agradece o apoio financeiro do CNPq para o desenvolvimento deste trabalho. Agradece também a
estrutura e o apoio fornecido pelo IAE (Instituto de Aeronáutica e Espaço) e pela empresa Flight Technologies.
9. Referências
Nelson, Robert C., 1989, “Flight Stability and Automatic Control”, McGraw-Hill, Inc
http://www4.in.tum.de/~pretschn/teaching/testsem02-ausarb/koenig-embsys-folien.pdf. Acessado em 05/08/2006
http://en.wikipedia.org/wiki/Real_time. Acessado em 05/08/2006