Simulação do Modelo Dinâmico de Atitude da Plataforma Sub Orbital - PSO – Acoplamento Entre o Modelo Dinâmico e o Software De Bordo
Ulisses Thadeu Vieira Guedes Hélio Koiti Kuga
Instituto Nacional de Pesquisas Espaciais – INPE Divisão de Mecânica Espacial e Controle – DMC Av. dos Astronautas, 1758, S.J.Campos – SP, 12227-010, SP
Resumo
A missão da PSO exigiu apontamento inercial e baixa velocidade de rotação nos três eixos para garantir o nível de microgravidade desejado. O software de controle de atitude desenvolvido buscava nos sensores (giros e acelerômetros) as informações necessárias para o acionamento dos atuadores (sistema de propulsão – hidrazina) para garantir os requisitos da missão de rotação. O computador de bordo interagia com os sensores e atuadores através de canais digitais e analógicos. O software de bordo básico e lei de controle foram desenvolvidos numa primeira fase e seria submetido aos testes de validação. Para simular o ambiente da missão desenvolveu-se rotinas de acoplamento entre o software de bordo e um software auxiliar, composto por módulos correspondentes aos simuladores dos sensores, atuadores e propagador de atitude em 3-eixos. Os primeiros módulos emulavam atrasos de resposta, tempos de acionamento e comportamento dinâmico, tentando uma aproximação mais fiel dos dispositivos reais. O modelo dinâmico da atitude considerava os efeitos do campo gravitacional, forças e torques do sistema propulsivo (atuadores) e distribuição assimétrica de massas. Este conjunto foi usado para testes da lei de controle e validação do software de bordo. O vínculo para estes testes era acoplar o software auxiliar ao software de bordo, sem modificar as características funcionais deste último. Os simuladores dos sensores e atuadores consideram os atrasos de resposta e atuação aproximados da condição real. Este trabalho vem mostrar os resultados obtidos de um conjunto de simulações.
INTRODUÇÃO
Para atender os requisitos de microgravidade, a missão da Plataforma Sub-Orbital exigiu baixa velocidade de rotação nos três eixos. O sistema de controle projetado basea-se em informações adquiridas dos sensores de atitude representado por girômetros e acelerômetros. O sistema de controle é representado por um sistema de jato de gás frio (hidrazina) e atuava no controle de rotação da plataforma. Sensores e atuadores estavam interligados ao computador de bordo através de interface para canais digitais e analógicos. O software de bordo era o responsável pela aquisição e acionamento do sistema de propulsivo segundo leis de controle desenvolvidas por Canesin (1999). As questões eram testar e validar, em solo, o software sem interferir na sua funcionalidade e condições de operação, e responder pendências tais como: funcionalidade da lei de controle, atrasos no acionamento, quantidade de combustível, parâmetros sensíveis de inicialização, tempos de manobras e condições críticas de lançamento.
O SOFTWARE DE BORDO
O software de bordo foi desenvolvido em linguagem C para um computador com CPU 386. O produto desenvolvido junto ao hardware da PSO, se apresentava conforme a figura 1.
Fig. 1 – Blocos de identificação do software e hardware da PSO.
As interfaces digitais e analógicas estavam associadas à portas de I/O distribuídas sequenciamente. Dispunham-se de rotinas de conversão dos valores lidos pelas interfaces para rotação (dados dos girômetros e acelerômetros) que seriam submetidos aos procedimentos de controle. O programa previa 8 fases críticas: 1) pré-lançamento, 2) separação, 3) manobras de controle para redução grosseira, 4) manobras de controle refinada, 5) manobras de manutenção em regime de microgravidade, 6) manobras de esvaziamento de hidrazina, 7) abertura de pára-quedas e 8) desligamento do computador de bordo. Ao entrar ou sair das fases, o programa envia aos canais da telemetria valores que representam sinais e identificação de cada fase. Os parâmetros da lei de controle eram ajustados para as fases (3) à (5), cujas tolerâncias diminuiam com a redução da velocidade de rotação e com as fases. Os testes preliminares observavam a operacionalidade do produto quanto à comunicação em hardware, mas não quanto à dinâmica do movimento.
Descrição das Fases da Missão
a) Pré-lançamento. Esta fase considera que a PSO está na rampa de lançamento em contagem regressiva. O sofwatre de bordo caarega os parâmetros de inicialização, configuração das portas de
I/O dos canais anlógicos e digitais e entra em loop de espera para a separação do umbilical, que sinalizará o lançamento. O sinal vem através de uma porta digital. Enquanto está nesta fase, é enviado, via telemetria, sinal de identificação da fase.
b) Separação. O looping anterior é interrompido e um novo looping aguarda o sinal de separação. A telemetria é informada com um novo sinal de identificação da fase. Ao ocorrer a separação entre o último estágio e a plataforma, a telemetria é novamente informada e inciam-se as manobras de controle.
c) Manobras de controle para redução de velocidade. É a primeira fase de atuação da lei de controle. A ação é individual em cada eixo, começando pela rotação do eixo longitudinal (eixo z) e continuando nos eixos (x) e (y) (axiais) até que a velocidade alcance valores adequados. Os sinais de telemetria informam a fase em andamento.
d) Manobras de controle para ajuste fino. Conseguido o nível de rotação desejado, a lei de controle é ajustada para trazer as rotações aos níveis da missão, que permitirá microgravidade da ordem de 10-4g. A ação poderia ocorrer simultanemaente em dois eixos. Perturbações podem induzir modificações da velocidade de rotação em algum eixo, ultrapassando os níveis aceitáveis da fase e exigindo um retorno à fase anterior.
e) Manobras de manutenção em regime de microgravidade. Uma vez região operacional, o sistema comanda o fechamento das válvulas de acionamento do sistema de hidrazina. A PSO estará em microgravidade. Um temporizador é disparado. É enviado o sinal de fase pela telemetria.
f) Manobras de esvaziamento dos tanques de hidrazina. Com o acionamento do alarme, abrem-se todas as válvulas do sistema propulsivo. Os tanques de hidrazina serão esvaziados. O procedimento de alarme sinaliza a fase, via telemetria. A condição de tanque vazio também será sinalizada adequadamente.
g) Abertura dos pára-quedas. Com a condição de tanque vazio, o sistema entra em fase de espera pela abertura dos pára-quedas. As vávulas de segurança e de acionamento do sistema propulsivo são desligadas. Agora um ciclo de espera pelo sinal digital da abertura.
h) Desligando o Computador de Bordo. O sinal de abertura dos pára-quedas habilita o desligar do computador de bordo e de todo o sistema elétrico.
Todas as fases principais e intermediárias geram sinais de telemetria diferentes. A passagem de uma fase para outra também poderia ser realizada pela ação de temporizadores (timeouts) de operação. Para se certificar sobre o status do funcionamento do Computador de bordo e das passabens entre fases, o software de bordo alternava os valores da fase transmitidos para o sistema de telemetria. Este tipo de sinalização poderia traduzir eventuais comportamentos anômalos da PSO. Todas estas passagens também eram gravadas em memória para análise posterior.
O SIMULADOR DE ATITUDE
Para validar as leis de controle torna-se necessário um simulador de atitude (neste caso, mais correto dizer é propagador de atitude) onde o modelo dinâmico considera efeitos do campo gravitacional, forças e torques do gerados pelo sistema propulsivo e assimetria da distribuição de massas. Dada a duração da missão (alguns minutos), considera-se o modelo gravitacional de Terra esférica (Guedes, 1997), juntamente com as forças e torques gerados pelo sistema propulsivo. As equações diferenciais são integradas numericamente usando um Runge-Kuta 7/8, passo fixo, porém ajustável conforme o regime de rotação. As equações diferenciais refletem as equações de Euler (Wertz, 1978, Wertz&Larson, 1991), escritas em coordenadas retangulares, considerando o acomplamento. Basicamente, dada por:
[ ]
(
I
w
)
w
T
T
w
P Gr
v
r
r
&
v
×
−
+
=
onde: PT
r
eT
Gr
são os torques do sistema propulsivo e do gradiente de gravidade;
w
r
é o vetor velocidade de rotação; e[ ]
I
é a matriz de Inércia.O Modelo do Sistema Propulsivo.
A PSO era dotada de 4 bicos de propulsão distribuídos simetricamente em relação aos eixos axiais e inclinados de 60 graus em relação aos mesmos. Localizados distantes do centro de massa e nesta
configuração, a ação propulsiva atua na orientação ou na rotação de qualquer um dos 3 eixos, através do acionamento combinado dos propulsores (Figura 2). Conforme a identificação dos propulsores naquela figura, o acionamento combinado dos propulsores 1+4 geram torque no sentido contrário ao sentido do eixo “y”, pois os propulsores estão acima do centro de massa. Para um torque no sentido contrário (mesmo sentido do eixo y) acionam-se os propulsores 2+3. Para torques na direção do eixo “x”, acionam-se os propulsores 3+4, para o mesmo sentido de x, e 1+2 para o sentido oposto. Em relação ao eixo “z”, acionam-se os propulsores 1+3 e 2+4, no mesmo acionam-sentido de z e acionam-sentido oposto, respectivamente.
Fig. 2 – Localização dos Propulsores
O nível de microgravidade alcançado depende das características deste sistema (pulso propulsivo mínimo). O tempo mínimo médio emulado para ligar ou desligar é de 20 mili-segundos. O modelo incluído ao propagador considera que neste período há a produção de 50% de capacidade (variação linear) (Figura 3).
A força de propulsão máxima, fpMAX, varia com a pressão no tanque de hidrazina, através da
equação:
c
b
.
p
a
fp
MAX=
+
−
onde: a,b e c são constantes; p é a pressão do reservatório. A força propulsiva aplicada, fp, varia proporcionalmente com o tempo, ao ligar ou desligar os propulsores:
ld MAX
t
t
fp
fp
=
∆
para tld = 20 milisegundosFig. 3 – Curvas do sistema propulsivo (hidrazina).
O ACOPLAMENTO ENTRE O SOFTWARE DE BORDO E O PROPAGADOR DE ATITUDE. Conforme o cenário exposto, qual seria a melhor forma de acoplamento entre os produtos (software de bordo e propagador) sem que houvesse modificações sensíveis no software de bordo? A solução adotada foi gerar um novo produto de software que emulasse o software da interface analógica e digital. Por outro lado o software de bordo também apresenta decisões baseada no tempo disponibilizado pelo relógio do sistema. Os ganchos utilizados para o acoplamento foram: Tempo e Interface. Desenvolveu-se, então, procedimentos inertes sob o ponto de vista do SWB (Software de Bordo) e atuantes sob ponto de vista do Propagador. Tais procedimentos consideram o tempo de processamento do código entre chamadas e passam tais informações para o propagador e vice-versa. Este levará as condições de atitude de um instante para outro, considerado aquele intervalo informado, introduzindo um fator de correção do intervalo. Isto permitiu a aceleração ou retardo da dinâmica envolvida, o que tornaria todas as aplicações independentes da velocidade da plataforma onde os testes seriam realizados. Ou seja, o tempo fornecido era o tempo gerado pelo propagador e não mais pelo relógio do sistema.
O acoplamento (Figura 4), também exigiu o desenvolvimento de procedimentos que transformam os dados de atitude do propagador para os valores fornecidos pelas interfaces analógica e digital. Tais procedimentos emulam: atrasos de acionamento e resposta das interfaces, erros de leitura e escrita, e eventos tais como condições de lançamento e abertura dos pára-quedas. O comportamento das interfaces emuladas foram adquiridas diretamente da plataforma montada e não nas especificações do projeto o que recorreu em revisão de ambas as partes.
Fig. 4 – Acoplamento entre blocos do Software de Bordo e do Simulador
Outras opções de acoplamento envolviam processamento paralelo e/ou processamento distribuido. Tais opções foram invializados por falta de recursos e, pincipalmente, tempo de implementação. Existe uma frente de pesquisa em andamento aplicando o processamento distribuido em redes TCP/IP.
Primeiros Testes
O acoplamento permitiu a identificação e correção de problemas tanto na lei de controle quanto nos tempos de realização das fases, conforme as condições de injeção, e atuação correta dos propulsores (seqüência de acionamento e duração), detalhes que não eram percebidos nos testes indivuais da lei de controle e dos procedimentos de aquisição de dados do software de bordo.
Questões operacionais, tais como, emissão de sinais alternados ao longo das fases permitem a verificação do funcionamento do computador de bordo.
Simulação de inicialização em vôo também foram realizados. Nestes testes contatou-se a necessidade de ajustes nos valores de timeout de cada fase perante as condições operacionais de lançamento.
Resultados de Simulações
O produto completo foi submetido a testes exaustivos e stress. Após isto, realizaram propagações para uma análise de Monte-Carlo, onde foram testadas as várias condições críticas de injeção e resultados gerados pelo produto final.
Os resultados apresentados aqui consideram condições críticas e ótimas de lançamento, conforme informações obtidas junto ao CTA, entidade responsável pelo lançador.
Fig. 5b - Comportamento da componente Y do vetor rotação em função do tempo.
Fig. 5c - Comportamento da componente Z do vetor rotação em função do tempo e detalhe
As Figuras 5 mostram o comportamento da rotação, em rad/s, em função do tempo (segundos). As condições iniciais usadas para estes resultados foram: 0.0418 rad/s (2.4 graus/seg) para as componentes “x” e “y”e 240 RPM (1440 graus/seg) para a componente “z”. Em torno de 140 segundos, é percebido a ação contínua dos propulsores reduzindo a componente “z” da rotação, perturbando os outros eixos dado o acoplamento entre eles. A partir daquele instante até 175 segundos observa-se a ação conjunta de redução de rotação nos outros eixos. Após este período já se observa uma estabilização do eixo “z”, mas, novamente, o acoplamento entre eixos induz variações de até 0.1 rad/seg. Finalmente, a partir dos 175 segundos, o controle alcança a faixa de rotação aceitável para a missão.
CONCLUSÕES
A missão PSO evidenciou um conjunto de procedimentos. Normalmente as Leis de Controle exigem ajustes de parâmetros (ganhos, compensadores, valores de transição) considerando modelos dinâmicos acoplados, porém isolados do sofware de bordo. Tais parâmetros são calculados, ou determinados, por algum processo. Embora este procedimento esteja correto sob o ponto de vista acadêmico, o cálculo daqueles valores não consideram efeitos de atraso, e perturbações ou não sentidas pelo modelo isolado, mas presentes quando se inclui o software de bordo. Embora os resultados apresentados aqui não enfoquem esta condição, este detalhe é importante para o sucesso de uma missão. Muitos dos problemas foram detectados em fases de testes após o acoplamento. São pequenos problemas, muitas vezes da implementação dos procedimentos, que passam completamente desapercebidos em testes isolados.
A técnica adotada, além de flexível, motivou pesquisas tanto na área computação aplicada (processamento paralelo e processamento distribuído), quanto na área de dinâmica de vôo para produtos aplicáveis às missões espaciais, além de usar uma forma de acoplamento entre software de bordo e simuladores auxiliares.
Apesar do empenho de todas as equipes que particuparam direta ou indiretamente da missão, não foi possível recuperar a PSO e, com ela, o histórico de toda a missão.
6. Referências Bibliograficas
Guedes, U.T.V; Cap.4 – Modelagem Dinâmica, IN: Análise de Dispersão da Trajetória de Reentrada em relação ao ponto de pouso, utilizando sistema Geocênctrico Inercial e manobras Laterais, Tese de Doutorado, Agosto de 2001 http://www.dem.inpe.br/~ulisses/doutorado.htm
Wertz, J.R; Spacecraft Attitude Determination and Control, The Netherlands, D. Reidel, 1978.
