人類が昭和以降月へ行かないのは何故？４

一つの波の振幅が一つのデジタルデータに変換されるという事に気付けないのは不憫だな。

ああ、800Hzの搬送波の一つ一つをAD変換するのか。
ノイズ載ったら大変だねｗ
で、そうやって信号を送ってるというソースはあるの？

次スレ候補

7月20日は人類が初めて他所の星に立った記念日
http://science6.2ch.net/test/read.cgi/sky/1184753222/l50
もしも。13号でアポロ計画が中止になっていたら…
http://science6.2ch.net/test/read.cgi/sky/1180908607/l50
はたして人類は月の裏面を肉眼で見れるのだろうか？
http://science6.2ch.net/test/read.cgi/sky/1187508344/l50
◆　人類の夢・宇宙飛行・・・
http://science6.2ch.net/test/read.cgi/sky/1136023570/l50

残りが多いのは3つめ

>>950
プログラムが必要な分だけ取り込めばいいと言うことに気付かないのは不憫だな

ところで、>>950　>>947
これって振幅変調なの？

>>953
レゾルバに800Hzの基準信号を与えると、その角度が電圧振幅になって出力される、
というのがどこかにあったと思うんだが…今すぐ見つからない。
まあ、普通レゾルバは電圧出力だから振幅＝回転角ということで振幅変調でいいと思うが。
800Hzの搬送波を検波すれば電圧出力の時間変化が得られるし。

ttp://www.ibiblio.org/apollo/hrst/archive/1019.pdf
に割り込みなんかのタイミングが出てる。
姿勢やなんかは10Hzで計算してたようです。
加速度計読みに行くのは2s周期。

加速度が２秒間隔なら姿勢制御の為にＲＣＳ使ったら取りこぼしてしまうね。

>>954
さんくす
うーんしかし有人宇宙船のような信頼性が必要なものに振幅変調のアナログが使われるとは思っていなかった。
アナログ使うとしても周波数変調とかパルス幅変調じゃないかと思ってた。

>>955
だからスラスタの情報も取り込んでるんでしょう。

ttp://science6.2ch.net/test/read.cgi/sky/1190385035/193

193 名前： 名無しＳＵＮ [sage] 投稿日： 2009/05/22(金) 18:28:34 ID:K9NbE8Ce
後だしジャンケンと言われないように、今のうちに言っておく。

6月に打ち上げられるはずの”ルナ・リコナッサンスオービター”は、アポロ月着陸の
遺構を撮影するはずである。

そしてアポロによる有人月探査を否定する原理主義者達は、その映像を見ても
「この映像は米国によるねつ造であり、真実では無い」
と言い張るだろう。

テンプレにして、新スレに貼っておこうか？

>956
だから、取り込む間隔が長すぎてＲＣＳの加速度情報を取りこぼしちゃうっていう指摘しているの。

遺構写真を捏造して、>957という言い訳をすると予言しておこう。

>>958
＞遺構写真を捏造して、>957という言い訳をすると予言しておこう。

まだLROは月の映像すら撮影していないんだから、フライングまでして
恥を曝さなくてもいいのでは？

と、１９３がしたフライングも擦り付けられて少々迷惑だな。

>>875
＞常にジャイロの角度は月の重力により変化するよ。

ジャイロが何か、勉強しなおした方がいいのでは？
ジャイロはいったん起動させて安定すると、その軸が空間のある1点を
常に示す物なんですが。

それが月の重力で変化するのなら、ジャイロの役を果たさないのでは？

RCSによって受けた加速は、
データが取り込まれるタイミングまで
他の動きによって打ち消されない限り、
拾えるはずでは。

いや、正確にはジャイロを積んだ着陸船と月の位置関係だな。
ジャイロは動かない。

>962
すぐに打ち消されるだろ。
加速度がゼロになるからな。

>964
>加速度が２秒間隔なら姿勢制御の為にＲＣＳ使ったら取りこぼしてしまうね。
加速度が0になるなら、取りこぼしても問題無いと思いますが。
後は船体の傾きのデータを拾って、制御に生かせばいいはず。

あのさ、宇宙でもの浮かべて、横からどつくと回転とどついた方へ飛んで行くだろ。
どつくのがＲＣＳだとしたら回転角拾うだけじゃ飛んで行く方の速度はわからんて。
その速度を求める為に絶対取りこぼしちゃならんの。

加速が残っているなら数値を計測するタイミングで
拾うことができるんじゃないですか？

>>958
２秒ごとだと、スラスタ加速の持続時間なんてまともに捉えられない。
一方でスラスタってのはどれくらいの推力があって、どれくらい噴射したか、わかっている。
噴射時間と噴射方向があれば力積がわかる。
質量がわかっていれば、加速がわかる。
ここまでいけば、わざわざ加速度として高頻度計測して積分なんかするより
よほど誤差なく、噴射前後の速度変化を計算することができる。

というか、逆に予定速度を決めて、そうなるように噴射の方をコントロールする方がメインみたいだけど。

欠点は、スラスタの調子が悪かったりすると破綻することだと思うが、
そもそもあの当時の小型コンピューターに、スラスタ噴射という短時間イベントをまともに
加速度からの慣性航法する能力はなかった（それはあなたの言うとおり）から
選択の余地なかったんじゃないかと思う。

http://klabs.org/history/history_docs/mit_docs/1687.pdf
行列演算支援機能（単なるサブルーチンかマクロかもしれん）があるみたい。
数msecかかっているようなので、毎秒数十／数百回の演算はまず無理。

>>967
RCSって純粋に加速ゼロなんだっけ？
同時に対照場所２ヶ所で噴射しないとそれは実現しないけど、必ずそうなるようにできてたっけ？

あれ、>>968外したかな・・・

>968
それだと加速度を正しく処理出来ない。
月の重力や下降エンジンのジンバルによる加速度の変化もあるからな。

>969
出来てない。

>967
加速度は残らない。
必要な時に取り込むべき情報なの。

>>970
月の重力はそう大きく変化しないんだから、それこそ２秒おきにのんびり位置→想定重力→積算
すればいいだけでしょ。
そもそもスラスタ吹かない自由落下中は、加速度計はゼロのままだけど、外の慣性系からみたら
加速度運動しまくり。天体重力は加速度計ではなく計算でやるしかない。
だから重力異常で困った（重力が計算できない）話があるんでしょう。

いろいろ読んでみたが、スラスタについては素直に加速度読んでたのかな。
ただ、このナビゲーションは、スラスタ吹いて結果をみるのではんく、
目標の速度変化を実現する噴射を計算して実行する方式もあるみたいなので、
これだと、結局噴射加速度を前もって計算してしまうことになるのではないかと思う。
どうなんだろ？

スラスタは手動でも操作されたし、加工段エンジンやそれのジンバルも忘れている。
使う頻度が少ないからって安直に計算して良いわけがない。

>目標の速度変化を実現する噴射を計算して実行する方式もあるみたいなので、
そこで地上のコンピュータの出番。
通信記録を見ると、地上から、噴射ポイントにおける数値が知らされて、
飛行士が入力する様子が出てくる。
http://history.nasa.gov/ap12fj/12day5_prep_landing.htm

だから、どこで航法計算しようが、着陸船そのものがきちんと座標更新していないとあらぬ方向へ誘導されるだけ。

ttp://en.wikipedia.org/wiki/Reaction_control_system
The Apollo thrusters were configured to allow "coupled" RCS firings (where thrusters on opposite sides of the spacecraft fired together),
which allowed adjusting the vehicle attitude without affecting the critical accuracy of their orbital, trans-lunar and trans-earth trajectories.
とあるからペアで噴射する。
例外もあって、機体下向きについているピッチ、ヨー系のRCS4基はアーリッジモーター
（液体燃料をタンク下側にある出口に押し付けてからメインエンジンに燃料を送り出す）
にも使われた。
また、LMの上昇中にメインエンジンが停止した場合、ある高度以上であればピッチ・ヨー系の
4基を噴射して何とか軌道まで上昇する、という運用も想定されていた。

ttp://history.nasa.gov/alsj/LM-intro.pdf
見るとHand ControllerとIMUからの入力がGuidance Computerを通って
RCS含めたエンジンのOn-Off信号を作るようになっているので、
飛行士による手動入力及び制御コマンドによる加速度発生分は
ちゃんと考慮されている。

Mission Reportの9.6.4 Attitude Controlにも
This maneuver was performed manually using the proportional rate
output of the rotational hand controller.
とある。

IMUがステーブルプラットフォーム方式なので、ジンバル角が慣性空間に対する
機体の姿勢角を直接出力するから、所定姿勢角とジンバル角のずれ分から
レートコマンドを作って、そこから飛行士のHand Controller入力を引いて
RCSコマンドを作ってたようだ。

使　徒　信　条

我は【USA航空宇宙局】の創り主アメリカ人民
全能の科学集団NASAを信ず。

我はその偉業、人類の有人着陸を信ず。
ケネディー故大統領の演説によりてやどり、当時の新大統領ニクソンより生れ、
マリリンモンローの呪縛苦しみを受け、
発射台につけられ、第一大気圏外にほりだされ
サターンV 型ロケットで、ケネディ宇宙センターから発射され
1969年7月20日20:17:40（UTC）に月面に着陸し、よみがえり、月天に昇り、
スノー・コーン（かき氷司令船）に発見され給えり、
7月24日かしこより帰って来れて太平洋上に無事帰還給わん。

　我は人類月面歩行を信ず。
聖なる公同の常識、グローバルな人類の交わり、
罪の赦し、心のよみがえり、永遠伝説の命を信ず。

　　　　　　　　　　　　　　　　　　　　冷メン。
冷戦時代の
http://ja.wikipedia.org/wiki/アポロ11号　

アポロ11号の月面着陸40周年を記念した特別番組をスター・チャンネルで放送
http://blog.television.co.jp/entertainment/entnews/2009/06/1140.html

何度言ったかわからないが、加速度をリアルタイムで拾えないから位置情報もあさってになってしまう。

＞加速度をリアルタイムで拾えないから
しかし、それでは慣性航法装置の意味が無くなるな。

慣性航法装置の意味以前にシステムとして機能しません。

なら、>>980の思考過程の方に
どこかミスがあるんじゃね？

>月の重力はそう大きく変化しないんだから、それこそ２秒おきにのんびり位置→想定重力→積算
>すればいいだけでしょ。
この2秒というのは地上で計算する都合上、どうやっても2秒の間隔が出来てしまうからではないでしょうか。
2秒間隔でも、所定の軌道からずれていることは計測でき、補正をすることは可能でしょう。

どこにミスがあるの？

加速度取り込みタイミングと地上からの指令値のタイムラグは直接関係無い。
タイムラグを言いたいなら着陸船から送られる情報全てを検討しないと駄目。

どちらにしても
>2秒間隔でも、所定の軌道からずれていることは計測でき、補正をすることは可能
だと思うのですが。

>>982
いや、実際G&Nの計算速度などの資料を見ると、レーダーなど他のことをしながらだと
せいぜい毎秒１回くらいしか計算できないんじゃないかとは思うよ。
姿勢など一部のデータは高頻度に計算しているようだけど。
慣性航法じゃないけど、大気圏再突入時のカプセル姿勢を２秒に１回制御なんかしたらそりゃあ焼け死ぬわな・・・
地上での計算は、軌道変更などのイベント時、慣性航法ではなく、通常の軌道変更計算として
及び噴射後の軌道計測・慣性航法装置の誤差修正として行うものだと思うよ。
月面だと往復２秒じゃなく２．６秒だし、地上での計算時間も多少はあるし、アポロには月面裏面での噴射もある。

>>980
「システムとして機能しない」と言うところにミスがあるんじゃない？
なぜ「システムとして機能しない」と思うのか？
センサーの出力を取りこぼせばシステムとして機能しないとも言っていたよね。

システムとして機能するには、システムの目的を達する頻度で情報を取り入れ、
目的を達する精度と頻度で結果を出せばいいだけ。
センサーがどれくらいの頻度でデータを吐けるかは関係ない。

プログラム見る気力がないからｗ　勝手な推測だけど、
加速度の平均くらいまでは高頻度にやっているかもと思う。
加速度データを姿勢データで回転処理したものを足し合わせることだけは毎秒１０回やって、
後の積算とかレーダーによる位置補正などは２秒に１回ゆっくりやるとか。
実数の行列演算が5msec程度、加算は0.5msec程度らしいので、これを毎秒１０回やっても
毎秒55msecで終わるから。

平均なんかとっても無駄だな。
（何かと言うとすぐ平均で逃げるｗ）
加速度→速度→距離と積分して位置情報を更新しないと正確な位置情報にならない。

>>988
いつもそうやって、印象論で逃げるよね。

>985
無理。前述したように軌道上で平行移動しても位置情報更新しそこなうから。

加速度など数値の取り込みはできるのだから、
現在位置での数値と比べることでわかるはずですよ。

加速度を現在位置と比べても無意味。
それ以前に位置情報が不正確なので現在位置は不正確。
不正確なものを基準にした演算結果も不正確になるだけ。

>加速度→速度→距離
上記の値は計測出来るのだから
>積分して位置情報を更新
できるし
>正確な位置情報
は求まるとおもうのですが。

>993
>990

ループさせる発言は答えにはなりませんよ。

指摘の無視は答えになりませんよ。

>>986 ：名無しＳＵＮ：2009/06/28(日) 10:14:56 ID:b/AVL7Rn
>いや、実際G&Nの計算速度などの資料を見ると、レーダーなど他のことをしながらだと
>せいぜい毎秒１回くらいしか計算できないんじゃないかとは思うよ。

たぶんレーダ入力と慣性装置出力（他にもあるかも）を組み合わせてカルマンフィルタ回すのが大変なんだと思う。

>>993 ：名無しＳＵＮ：2009/06/28(日) 11:43:43 ID:uinAQH1f
>>正確な位置情報
>は求まるとおもうのですが。

加速度計のサンプリング間隔である2秒の間にいきなり加速度が発生したりしたら別だが、
そうでなければ月の重力なんてゆっくりとしか変化しないし、エンジンのON-OFFによる加速度は
On-Offコマンド自体が誘導計算機から出力されてわかっている。
結局は重力分だけがゆっくり積分されてるから問題ない。

そもそも上のほうで書かれてたとおり、月軌道上では月の重力加速度は感知できないから、
そんなに高速でサンプリングしても仕方ないし、地球軌道を出て月軌道に入るまでの間は
「節電のため」慣性装置止めてたのだが。
（これで燃料電池の活物質を20kg減らせたとの見積もりだそうで。r500.pdf）