Lunar Landerを舐めすぎでは？

この移植版みたいに、「ここが平坦で着陸できますよ」というマークは実地にはありませんからね。

Lunar Landerのコントローラもなめんなよ

実際のスラスターは吹き出しのタイミングが数十ms以上ずれるでしょうし、姿勢そのものも遅れて取得されます。MEMSでも数msずれます。

いくら、制御ループを1ms未満でぐるぐる回しても、指令とフィードバックにむだ時間要素がたっぷりあったら、そもそも姿勢を安定できるかどうかもあやしくなるのです。

まずそこをエンジニアリングでギンギンに詰めていく場合、バルブやセンサーメーカーを抱き込まないと難しいでしょう。納入仕様書であーだこーだ仕様を詰めることは「すり合わせ」でもなんでもありません。それはただの購買です。

安定性は運動方程式のレベルで解析できますが、むだ時間の評価はそう簡単ではありません。

次に、実装です。上記のむだ時間は、プログラム上は全く見えません。スラスターのバルブへの出力は設計通りに時刻tにオンできますが、実際にスラストが発生するのはt+Δです。

センサーについても同様です。6DoFセンサーが返してくる加速度、角運動量は、t-Δの情報です。

Δがあっても、安定に制御する手法というのはたぶん星の数くらいあると思いますよ。ただ、それだと運動方程式を解くサンプルの実装がそのまま使えないというイミフな理由で、「Δを無視してエイヤッ方式で実装」し、実機で動かしてみると想定していたゲインをまったく上げられず、ダルダルのモーションしか実現できない、というのがニポーンの制御屋の実態でしたよね。今もそうかな。希少なバッテリーも、高価なパワー半導体も、一品もののセンサーも、アクチュエータも何もかもがオーバースペックに見える、不思議な（間抜けな？）制御です。

つぎに、そういった事情を理解したうえで物理まで含めた（月面なら気体抵抗を無視できるのである程度は可能なのですかね？）シミュレータをつくって、実際の制御装置（ここ重要、ここをPC上で動かしたりしている組織は、制御工学実習からやり直した方が良いきがする）と接続してテストします。

当然、シミュレータは、バルブ開閉の電圧を受けて、センサーそっくりのアナログ信号を出すハードウェアとセットとなるでしょ。

たぶん昔ながらの航空宇宙産業だと、装置ごとに、シミュレータを発注して、セットで納入させていたんじゃないですかね。で、肝心の「全部結合したシミュレータ」を端折るんですよね。ロケットエンジンでそんなことできないのはみな知ってますが、制御装置全部なら、可能なはずです。それをやらないのはただの手抜きですよ。ワイヤー１本ゆるんでいるだけで、全部パーですから。

ちなみにごみためが、幼少の頃に体験した「月面着陸ゲーム」は７セグLED３桁x3行表示くらいのワンボードマイコン機で、DECやAtariのようなグラフィックはありませんでした。つまり、高さや速度が数値でステップごとに表示され、次のステップでなにをするかをコマンド入力するタイプです。ランダーの位置と速度と、目標位置から、軌道を計算して、コマンドを入力するという物理学のゲームですね。

その計算をリアルタイムに暗算できる人が3桁人数くらいいて、アポロ計画は成立したんだろうと思います。（制御装置の出す結果を先回りできる）

知らんけど。

アポロ13(4K ULTRA HD＋ブルーレイ)【4K ULTRA HD】 [ トム・ハンクス ] 価格：3,294円（税込、送料無料) (2023/8/27時点)