índiceitem superior

item anteriorpróximo item

 

6 – Simulação de equipamentos

 

Adotou-se certos procedimentos no processo de modelagem dos equipamentos para simulação de atitude. Em primeiro lugar, admite-se que a simulação em computador jamais será tão fiel quanto o sistema ou equipamento real. Isto implica que, por mais sofisticado ou complexo que sejam os modelos matemáticos, ainda assim permanece um erro com relação ao sistema real. Por outro lado, a simplificação em demasia pode tornar a simulação distante da realidade. O ponto de equilíbrio adotado será, portanto, aquele que permita uma certa confiabilidade da simulação ainda retendo o modelo num nível de complexidade adequado (sem comprometer, por exemplo, a execução da simulação em tempo-real). Infelizmente, critérios que permitam definir qual é o nível de complexidade adequado são difíceis de se estabelecer e de se medir. Um pouco de “sensibilidade”, ou de “bom senso”, neste caso, é inevitável. Outros procedimentos que orientam a modelagem devem garantir uma certa generalidade no modelo e a possibilidade de configuração para permitir, entre outros, a simulação de modos de falha e análise de pior caso. 

 

Nesta primeira versão não se levou em conta os efeitos de amostragem caracterizados por eletrônica “sample and hold”. Isto significa que as medidas referem-se ao instante de tempo corrente, e atrasos eletrônicos são simplesmente descartados. O cabeçalho referente às funções apresentadas aqui está disponível em sensors.h.

 

Os modelos apresentados aqui seguem um padrão: utiliza-se uma função para efetuar a configuração dos sensores (número, desvio padrão do ruído, direção de medida, etc.) e outra para efetuar a leitura. Obviamente, a função de configuração deve ser vista como integrante do ambiente de simulação, porém a leitura está associada ao controlador de atitude. Isto significa que estas funções devem ser executadas em processos independentes numa implementação futura que envolva tempo-real. Por processo independente entende-se dois programas executados numa mesma máquina (em tempo compartilhado), ou em máquinas diferentes comunicando-se entre si para troca de informações. Os sensores, ao contrário dos atuadores, podem ser posicionados em qualquer parte do satélite, até mesmo em apêndices articulados. De fato a PMM prevê a utilização de sensores solares analógicos fixados ao painel solar giratório. Para dotar o simulador de atitude de um caráter de generalidade, decidiu-se que tais sensores podem ser fixados quer no corpo principal ou em qualquer um dos apêndices, portanto solidário a este em seu movimento relativo ao corpo principal.

 

Os sensores (e também atuadores) estão sempre sujeitos a ruídos. Estes ruídos raramente constituem um ruído branco (gaussiano), mas tampouco se conhece sua real natureza e distribuição. Portanto a melhor alternativa é modelá-los por meio de um ruído branco. Porém, os recursos disponíveis na linguagem C para modelar ruído são em geral limitados e diferem de compilador para compilador. Um outro problema que tais recursos apresentam refere-se à impossibilidade de se criar diversas variáveis aleatórias independentes, como seria desejável para que se pudesse dispor de uma variável aleatória para cada medida simulada. A vantagem de tal recurso torna-se evidente quando se verifica que duas simulações idênticas no tocante às condições iniciais, podem resultar diferentes caso seja retirado ou inserido um sensor a mais, mesmo que o resultado desta leitura não influa na propagação nem no controle da atitude. Computacionalmente falando, trata-se de uma limitação nas funções capazes de gerar variáveis aleatórias, que não requerem argumento para gerar um novo valor. Este processo pode ser explicado por meio de duas situações distintas. Na primeira delas, duas variáveis s1 e s2 recebem valores aleatórios por meio da função rand, que por sua vez foi iniciada pela função srand (função gérmen ou semente):

 

...

srand(3452);

s1 = rand();

s2 = rand();

...

s1 = rand();

s2 = rand();

...

 

gerando os valores, por exemplo, 0.392, 0.872, 0.466 e 0.592, e tendo o primeiro sensor recebido o primeiro e o terceiro valor. Caso seja removido da simulação o segundo sensor, então s1 receberia o primeiro e o segundo valor da função rand ou seja, 0.392 e 0.872. As simulações seriam, portanto, diferentes. Um exemplo de uma função capaz de gerar mais de uma variável aleatória seria:

 

...

n1 = srand(3452);

n2 = srand(5981)

s1 = rand(n1);

s2 = rand(n2);

...

s1 = rand(n1);

s2 = rand(n2);

...

 

Neste exemplo, n1 e n2 recebem valores que permitem selecionar duas (ou mais) seqüências de valores aleatórios, e são depois utilizados na identificação da variável aleatória a ser gerada. Assim a remoção completa de s2 não altera a seqüência de valores aleatórios gerados para s1. É desnecessário dizer que a função rand da linguagem C não suporta este tipo de configuração.

 

Torna-se então imperioso a construção de uma interface para padronizar o acesso e o uso de variáveis aleatórias que permita, futuramente, a incorporação de novos recursos numa revisão ou num aperfeiçoamento das funções descritas aqui. Esta interface será descrita a seguir, e, logo em seguida, as implementações dos sensores e atuadores.

 

As funções descritas e modeladas aqui são portanto:

 

·        geração de variáveis aleatórias

·        magnetômetro

·        sensor solar analógico

·        sensor de estrela

·        sensor GPS

·        unidade inercial (giros)

·        bobinas magnéticas

·        propulsores

·        rodas de reação

·        mecanismo de rotação do painel solar – BAPTA