Histórias do computador lunar. Parte 3

Apollo 11 na lua

Cinco meses depois, a Apollo 12 sobreviveu a um raio durante a aceleração e sentou-se na lua. Graças ao novo "substantivo 69" que adicionamos ao programa, a fim de permitir que a equipe mudasse de posição com base nos dados de rastreamento do solo, os astronautas Pete Conrad e Alan Bean conseguiram pousar o módulo lunar a uma curta distância a pé dos não tripulados. o navio Surveyor, que aterrissou na lua em abril de 1967. O desembarque preciso da Apollo 12 abriu o caminho para pousos em um terreno mais complexo.

Somente após a Apollo 12 começamos a entender outros problemas sérios.

Comecei quando Clint Tillman, da Grumman Aerospace (empresa de construção de módulos lunares) notou vibrações do acelerador enquanto simulava o estágio final de pouso quando o impulso do motor era de cerca de 5%. Isso levou Tilman a estudar os dados de telemetria da Apollo 11 e 12, onde notou flutuações no estágio final de aterrissagem, com uma amplitude de 25% de pico a pico (veja a Fig. 12). Foi um período em que o comandante do navio poderia usar simultaneamente a chave ROD para controlar a velocidade de descida e o joystick para manobrar o navio. Como os gráficos desses dados se assemelhavam às muralhas e torres do castelo (ou castanha do castelo), esse problema era chamado de "fortaleza do acelerador".



Fig. 11: Relatório do primeiro acelerador

Clamp em Cambridge descreveu uma fonte de excitação de oscilações para um fenômeno desconhecido, que ele chamou de "IMU bob" [18]. A IMU estava localizada acima e a um metro e meio da frente do centro de massa do navio. Manobras pequenas, mas rápidas, como durante o pouso final, lançaram o navio, de modo que os acelerômetros interpretaram isso como uma mudança na velocidade vertical do navio. Isso, por sua vez, influenciou o cálculo da velocidade vertical e a avaliação da tração necessária.

Mas essa teoria explica apenas parcialmente o comportamento do acelerador observado nos dados de voo.

Motores de foguete com aceleração eram e continuam sendo uma raridade, mas era necessário um motor de aceleração para um pouso suave na lua. Um motor de impulso fixo e equações muito simples de movimento podem pousar um navio além do ponto desejado na superfície lunar. Mas, para sentar de cabeça para baixo, movendo-se suavemente, mantendo o local de pouso na zona de visibilidade e com a possibilidade de pairar sobre o local de aterrissagem, precisávamos de um motor que pudesse equilibrar a gravidade lunar, alterando a tração à medida que a massa do veículo diminui e ao alterar o vetor de empuxo durante as manobras e quando os astronautas queriam mudar a velocidade da descida.

As equações de movimento determinam qual aceleração deve ser dada ao aparelho, com que magnitude e em que direção. O piloto automático faz manobras para que a força de tração corresponda a uma determinada direção. A tarefa do programa de controle do acelerador é controlar a tração. O controle da limitação começa calculando a massa do módulo lunar. Conhecendo a massa, determinamos a quantidade de correção do acelerador necessária para alterar a aceleração do navio em relação à medida por acelerômetros para o valor necessário para cumprir as equações de movimento e convertemos o valor resultante em unidades usadas pelo conjunto do acelerador (cerca de 2,8 libras por pulso), e envie-os para a interface de hardware.

Os acelerômetros na IMU, na verdade, não medem a aceleração, eles medem o incremento de velocidade em relação à última leitura. Como as mudanças de estrangulamento durante a iteração anterior ocorrem em algum momento entre as leituras dos acelerômetros, o delta-V medido não mostra o efeito total da mudança mais recente.



Fig. 12: Alterações no estrangulamento durante a fase P66 do voo da Apollo 12 [19]

O controle do acelerador deveria compensar esse efeito. Uma série de compensações dependia de quando o comando do acelerador era enviado durante o período e também da velocidade com que o mecanismo executava os comandos de aceleração. Estudos experimentais estabeleceram que a limitação tem um atraso de 0,3 s.

Isso permitiu ao autor programar e testar o programa de controle do acelerador. Nos gráficos de simulação do modelo DPS exato usando um atraso de 0,3 s, observei oscilações no impulso real que ocorreram após uma grande mudança na posição do acelerador, sem compensar o atraso do acelerador. Quando liguei a compensação por 0,1 s, vi como as oscilações diminuíam. Quando defino a compensação para 0,2 s, as oscilações quase desapareceram. Isso acabou. Klump lembrou como eu disse: "é como um remédio, você não precisa dar mais compensações do que o necessário".

Klump sabia que não era "como uma cura", mas ele nunca insistiu em que eu programe o valor correto. Explicando sua motivação após 15 anos, Klump escreve:

“Eu pensei que era importante criar autoconfiança, permitir que colegas tomassem decisões sobre pequenos problemas, mesmo que não fossem ótimos. Por isso, retive meus pensamentos e apoiei a decisão de Don em vigor, pelo menos até que ele a revelasse por conta própria ”[20].

Explicando meus próprios motivos, acredito que fiquei irritado com a compensação no programa de limitação já sobrecarregado, e isso pode ter resultado no desejo de tornar a compensação a menor possível. Seja como for, o Apollo 11 e o Apollo 12 voaram com uma compensação de 0,2 s com um atraso no acelerador de 0,3 s.

Mas agora a análise de Klump [21] e um relatório independente preparado por JA Sorensen na Bellcomm [22] concluíram que "a natureza oscilatória do comando de estrangulamento P66 era obviamente devido ao fato de o valor real a constante de tempo do motor de pouso é menor que o esperado ”(Sorensen). Klump verificou novamente os dados. Os parâmetros do mecanismo de pouso foram aprimorados, mas as alterações correspondentes não foram feitas na documentação. O atraso real para o mecanismo de pouso foi de cerca de 0,075 s. Descobrimos que até a compensamos demais. Como resultado, o acelerador estava à beira da estabilidade.

A análise de Clampp deu um resultado ainda mais impressionante. Ele mostrou que se o software Apollo 11 compensasse 0,3 s, o acelerador seria instável. As vibrações do acelerador, em vez de se acalmarem, aumentariam. Após a aceleração no P63 ou, possivelmente, no P66 quando a IMU era energizada, o mecanismo DPS oscilava rapidamente entre o impulso mínimo e o máximo. Sem dúvida, o controle de vôo associaria logicamente o comportamento do acelerador aos alarmes 1202, que tinham causas completamente independentes.

Um acidente seria inevitável. Na minha humilde opinião, se o autor tivesse codificado o valor "correto" no programa de controle do acelerador, a Apollo 11 nunca teria se sentado. Convido alguém que não tem interesse pessoal e é bem versado em matemática a checar essa teoria.


Aterragem manual da lua

* * *

Ajustamos o atraso do acelerador e a simulação mostrou que a instabilidade da posição do acelerador desapareceu. Foram feitas alterações no software da missão Apollo 13, mas essa missão não pousou na lua.

É curioso que uma alteração no software Apollo 13 tenha sido feita antes que o problema do acelerador se tornasse conhecido, poderia fornecer uma opção de backup se a automação do controle do acelerador não funcionasse. Um novo "substantivo 92" foi definido, que a equipe poderia escolher para ver o nível do acelerador que o sistema de controle produz. A lógica que interromperia o controle automático se o acelerador alternasse para o modo MANUAL foi excluída. Essas mudanças [23] permitem que o astronauta controle o acelerador durante as fases P63 e P64, enquanto o sistema de controle continua a controlar o movimento do navio. Não sei se esses procedimentos complexos já foram usados.

Os alarmes executivos de sobrecarga foram abordados várias vezes.

O interruptor do radar de proximidade estava na posição LGC durante a decolagem. Nas missões subseqüentes, a lista de verificação foi alterada. Adicionamos lógica ao LUMINARY para verificar o modo de operação do radar de proximidade e, se não fosse LGC, os contadores de radar de proximidade foram redefinidos para zero.

Alan Clump estudou Executivo de uma perspectiva diferente. Ele descobriu que, quando o TLOSS de um computador ocorre periodicamente, ou o nível de atividade do computador muda na presença de TLOSS, e a tarefa SERVICER não foi concluída e foi interrompida quando os comandos de cálculo de posição foram executados para enviá-los ao piloto automático, não foi limpo pela reinicialização do software para para ser restaurado mais tarde - nessas condições, havia uma chance de um cálculo incorreto da posição para o piloto automático. Para o vôo da Apollo 13, a Klump desenvolveu uma solução na qual todo o trabalho do SERVICER foi reiniciado para recuperar o atraso, se necessário.



Fases de pouso na lua

Porém, no futuro, nenhuma dessas mudanças nos libertou das limitações de um período fixo de dois segundos do sistema de orientação. Para aterrissar em terrenos difíceis, foi necessário adicionar um modelo de terreno ao programa de radar. Modificações no sistema de orientação foram deixadas para mais tarde. Não tivemos tempo para tudo.

Desenvolvemos um conceito que chamamos de “variável SERVICER”, no qual o período do programa de orientação poderia ser estendido, se necessário. O receio de que o intervalo de dois segundos esteja embutido no software se mostrou infundado. Só era necessário medir o período de operação do sistema de orientação e usar esse valor em vez do valor de dois segundos, usado apenas em algumas fórmulas. Implementamos a versão de trabalho do SERVICER na versão offline do LUMINARY e demonstramos sua resistência muito alta ao TLOSS [25].

A liberdade do limite de dois segundos permitiu que outras idéias fossem consideradas. O astronauta John Young propôs uma melhoria, que chamamos de P66 LPD. Mas, a essa altura, o P66 era um programa muito mais flexível do que no voo Apollo 11. de Armstrong. Um dos novos recursos era que, se a equipe mudasse o modo ATT HOLD para AUTO, o sistema de orientação resultaria em velocidade horizontal zero. A idéia de Young era que o LGC exibisse o ângulo do LPD (como na fase visível), o que mostraria ao comandante o ponto sobre o qual o módulo lunar voa se naquele momento o piloto automático estiver em AUTO [26].

Para garantir a precisão na execução dessa função, o software teve que responder instantaneamente quando o astronauta mudou para AUTO, mais rápido que dois segundos e ainda mais rápido que o segundo período permitido, com o qual algumas partes do P66 trabalharam. Desenvolvemos uma versão na qual a tarefa foi iniciada a cada quarto de segundo, verificamos a alteração do modo de piloto automático, enviamos comandos de orientação e aceleração e respondemos o mais rápido e precisamente possível à entrada do comutador ROD. Em uma simulação tripulada em execução no simulador de módulo lunar (LM Mission Simulator, LMS) em Cape Canaveral, com seus fabulosos modelos de terreno visíveis nas janelas, mostramos que esse sistema facilita um pouso muito preciso.

Nem a “variável SERVICER” nem o P66 LPD foram corrigidos. A NASA decidiu que a Apollo 17 será a última. Com tão poucas missões restantes, o conselho de governo tomou uma decisão conservadora - não deve haver mudanças significativas no software de pouso. Ao sincronizar os dados recebidos do radar de pouso com a leitura dos acelerômetros, Robert Covelli liberou tempo suficiente para comprimir o modelo de terreno para Apollos 15, 16 e 17 lá.



Módulo inercial (IMU) no MIT Lab

Apolo 14 trouxe fama de curto prazo ao autor. O interruptor de interrupção do painel enviava um sinal periódico que impedia Alan Shepard e Ed Mitchell de se sentarem. Eu escrevi um código que monitora esses casos. Essa “muleta” simplesmente mudou vários registros, o primeiro a induzir o monitor de interrupção da missão a pensar que a interrupção já havia ocorrido e depois se exclui para que o pouso pudesse continuar sem consequências. O patch foi transmitido pelo ar e colocado em ação pelos astronautas na perfeição, este procedimento incluiu 61 pressionamentos de tecla no DSKY. Talvez a parte mais interessante do incidente da Apollo 14 tenha sido o número de versões diferentes dessa história. Mas a Apollo 14 é outra história.

Em dezembro de 1972, fui a Cabo Canaveral para lançar o navio Apollo 17. Este voo espacial foi incrível. O escritor Tom Wolfe, juntamente com a fotógrafa Annie Leibovitz, escreveu um conto em quatro partes para a revista Rolling Stone, que foi o precursor de "The Right Stuff" [27]. Foi o único lançamento noturno do Apollo. O céu nublado da Flórida queima laranja de horizonte a horizonte, quando o enorme Saturno V sobe em uma coluna de chamas de 400 metros que balançava no final como uma chama de maçarico.

Passei vários dias testando algumas das funções do LMS que chamamos de “programação de memória apagável”. Esses eram patches que deveriam usar VACs não utilizados e corrigir alguns bugs, o legado do incidente com a Apollo 14. Então eu voei para Cambridge para observar o pouso.

Depois disso, gostei de ouvir Gene Cernan e Jack Schmitt, um geólogo treinando, explorando a Lua em um veículo espacial lunar, tendo viajado mais de 5 quilômetros fora da vista da espaçonave. E essa foi a última vez que alguém andou na lua.



Fig. 13: Alguns dos participantes.

Ótima foto, primeira fila: Vince Megna, "Doc" Charles Stark Draper, autor, Dave Moore, Tony Cook; Fila de trás: Phil Felleman, Larry Berman, Allan Klumpp, Bob Werner, Robert Lones e Sam Drake. Pequena foto, primeira fila: Larry Berman, Peter Volante, autor; fileira de trás: Sam Drake, Bruce McCoy. Também participaram dos eventos Steve Copps, Romilly Gilbert, Ken Goodwin e Russ Larson.