Mitsukiの魔法実験室

　結局、おととい夜10時前から昨日朝11時ころまでつきあって、そのまま沈没。
　 松浦さんの続報 その他をごちゃまぜにしてまとめてみると、

2100：降下開始
0430：450m、垂直降下開始
0455：370m、着陸GO判断
0510：290m
0520：230m or 250m
0530：160m
0537：114m
0540：90m
0545：70m
0546：40m、ターゲットマーカー放出
0547：35m、LIDARからレーザーレンジファインダー(LRF)高度制御に切り替え
0555：17m、姿勢をイトカワと水平にするため自律制御へ。ハイゲインアンテナ(HGA)通信断、ローゲインアンテナ(LGA)によるビーコンモードへ
0609：はやぶさ上昇開始？→誤報。上昇開始しているべき時刻。
06??：10m？、30分以上ホバリング微速降下したまま？
0637：DNSゴールドストーン局から臼田局へ切り替え中
0700：上昇コマンド、セーフホールドモード移行コマンド送信
????：セーフモードへ移行？（コマンド or 自律）
0851：コマンドへの反応なし、ドップラー変位確認できず、テレメトリモードへの移行コマンドを送信
0932：LGA or ミディアムゲインアンテナ(MGA)通信回復
1212：MGAで通信中、はやぶさの回転（セーフホールドモード）、高度10数kmを確認
1455：臼田局可視終了

といった感じっぽい（時刻は機内時刻・地上時刻・確認時刻がごちゃまぜなので、かなりいいかげん）。

　何が起きたのか。一言で言えば、イトカワ地表で「何か」が起きて、そのままアボート・上昇したといった感じでしょうか。イトカワ星人に襲われた（笑）というわけでもなさそうなので、はやぶさ自体に起因する「何か」なのでしょうが、運用側にも思い当たる節がないとなると、地表の状態、スラスター噴射による不確定外力、ハードウェアトラブル、ソフトウェア不具合、安全機構の過剰反応あたりが思い当たるところですが、さて。

　着陸＆試料採取できなかったのは残念ですが、何が起きているのかすら分からない状況下で、最悪の機体ロストまで到らなかったのには一安心。とはいえ、今回の現象解析、輻射熱による装置ダメージ、残存燃料の不安、帰還開始までのタイムリミット、運用側の体力等を考えると、何をやるにしても大変な1ヶ月になりそう……。

　ISASのサイトに 着陸時の様子がドキュメンタリー風？ に紹介されてました。これに会わせてタイムテーブルを若干修正。

　JAXAの 管制室中継 見ながら実況スレにちょっかい出したりしていたのですが、高度17mでホバリングした後状況不明になった模様。なかなか上手いこといかないなあ……。

　それはそれとして、 松浦さんのblog が情報源として非常に有力だったのが印象的です。マスゴミでもオフィシャル広報でもない、本当の意味でのbloggerの姿を見たような気がする。

　 野尻ボード が チャット状態 になってるのがなんか笑える。

　某#techでたいぷちゃんが 楽しそうにしてる ので、どんなものかと 本家 とかざっくり眺めてみる。 Doom みたいなゲームや音楽・動画プレーヤーの他、 シェル のみならず エディタ(vi) もあるらしい。最後の方は実用性は微妙そうだけど……（笑）。

• ベースになっているのは uCLinux だそうなので、MMU周りの機能がサポートされていない関係で一部の機能に制限があるほかは、普通にLinuxとして使えるっぽい（mmap()は当然使えないし、メモリ保護もない。fork()も使えないけど、vfork()やexec()は使えるのでマルチタスク動作はできる）。
• 開発環境は普通にgcc-arm。 C++でSTL も（条件付きで）可。
  
• フレームバッファは液晶に内蔵されてる＆MMUがなくメモリマップされないので、アクセス方法が（Linuxとしては）若干特殊。解像度は 機種によってバラバラ 。
  
• リモートコントロール端子がシリアルデバイスとしてアサインされているので、変換コネクタを自作すれば普通のシリアルポートとして使えるっぽい。
  
• USB/IEE1394で母艦と接続した場合、母艦からはマスストレージデバイスとして見えるので、ファイルシステムに直接アクセスできるっぽい（ただし新しい機種では微妙に制限がある模様）。

　……これって、UIやメモリ保護の面を除けば、PalmOSより素性よく使えるんじゃ？（苦笑）

ちなみに、ARM自体はMMU持ってるので、その気になればメモリ保護も実装はできる。

　いよいよミネルヴァ放出だーというわけでしばらくウォッチしていたのですが、どうもうまくいかなかった模様。松浦さんのblogに 記者会見の様子 が載っていますが、分離コマンド送信中にはやぶさが設定下限の高度を割り込んだため上昇を開始し、結果として上昇中の分離になってしまったとのこと。ミネルヴァの放出速度（横方向に放出）が5cm/s、イトカワの軌道脱出速度が16cm/sくらい？らしいので、上昇速度次第では軌道にも乗れずにとんでっちゃう可能性も……。

　 こちらの写真 に「トリムΔV記録」というボードが映ってますが、分離コマンドを発行した15:08の少し後、15:14あたりに「+Z:60」という書き込みがあるのが気になります。時刻関係からすると、はやぶさの加速結果のメモというより、地上からの補正操作分の記録っぽいので、上昇加速を変更したということなのかな？？

　仕事がアレな感じでなかなか進まないながらも、 先日買った 悪魔本を読んでるわけですが、「5.3 カーネルにおけるメモリ管理」を読んで長年(?)の疑問が氷塊。もとい氷解。

　FreeBSDといいWindowsといい、ユーザープロセスで使えるメモリ空間を減らしてまで、カーネルがユーザープロセス空間の高位（アドレス値の大きい端）を占めているのかずっと不思議だったのですが、どうもシステムコールの際のユーザー−カーネル間のデータコピーのコストを下げるためらしい。
　両者が同じアドレス空間にあれば単なるメモリブロックコピーで済むところが、両者が違うメモリ空間にあると特殊な転送を行う必要があって遅くなるため……とのこと。カーネル時間の1/3はこの手のデータコピーに食われているそうなので、そりゃたしかに影響大きそうだなあ……。

　まあ、x86ならカーネル空間とプロセス空間でセグメントを分ければ（ラージモデル）、セグメント間転送で済むのでそんなにコストもかからなそうな気もするけど、やっぱり案外コストがかかるのかもしれないし、移植性は確実に低くなるので避けたのかな。初期の386べったりな頃のLinuxとかMonaはどうしてる（た）んだろう。