LightSail’s tumble rate has increased since it entered orbit May 20. It can receive certain commands and transmit data to the ground, but the data link is not stable enough for the team to log in and make software changes.
Because the primary goal of the test mission is sail deployment, the plan to apply the patch has been shelved. As a workaround, LightSail will be rebooted at least once per day to reset the contents of beacon.csv, the spreadsheet-like file that stores the spacecraft’s automated data chirps. Several successful reboots have already been completed.
ギネスとか登録できないですかね (スコア:3)
遠隔デバッグの最長記録とかで。
Re:ギネスとか登録できないですかね (スコア:1)
ハヤブサとかが最長記録になっちゃうのでは?
Re: (スコア:0)
それを言ったらボイジャーとかのほうが遠いですな
クラッシュって… (スコア:1)
Linuxカーネル使っておきながら、システム全体が飛ぶって所に開いた口が塞がらないのですが。
まさか、データ格納するストレージをケチった上に/var とか/home あたりにデータ書くようにしたんで起動しようにも起動できなくなってるんじゃないかとか。
# 真面目に考えたら、別にデータ専用のストレージを置きますよね。
# 回路コスト考えたら数百ドルも増えやしないだろうに…
で、ウォッチドッグタイマも入れないなんて、この手のシステムで考えられないですしね。
信頼性を考えたら、CPU備え付けだけじゃなくて外部にウォッチドッグ入れるとかするものですが。
Re:クラッシュって… (スコア:2)
「システム全体が飛ぶ」とはどこにも書かれてないと思いますが…
「運良く再起動することを期待する」と書かれているぐらいですから、「起動しようにも起動できなくなってる」という想像はちょっと的外れ
たぶん、Linux システムは稼働しているが、「テレメトリ情報を送信するプロセス」だけがクラッシュしているんじゃないでしょうか。
ストーリーに挙げられている「惑星協会のブログ」をざっと読んだんですが、
「運良く再起動することを期待する」理由として、
「リブートしたらbeacon.csvはクリアされる」って書いてます。
ブート時の処理でbeacon.csvを削除する処理が入っている可能性もありますが、それよりも
csvはtmpfsに書き込むようにしていて、tmpfsは容量32MBしかとっておらず、
プログラムはディスクフルを想定していない、
とかそんなとこかなーとか想像してしまいました。
#状況確認用のデバッグログを/tmpに出力するようにしておく、というのは自分にとっては「あるある」です。本番で削除するのを忘れないようにしないと…
Re: (スコア:0)
再起動指示受け付けないってあるから、他も巻き込んでるような。
mmapでファイル扱ってパンクとか。
でもcsvに15秒に一回書き込みで使わないよな。
Re:クラッシュって… (スコア:1)
今回のやつがそうだとは断定できないけどマルチタスクにおけるウォッチドッグタイマというのは結構めんどくさい
・各プロセスが正常に動作しているか監視するタスク
・監視タスクが異常を検出せず、自身が正常に動作していたら外部ウォッチドッグを叩く
監視条件に間違いや漏れがあったらアウト。経験少ないと組み合わせ爆発起きやすい実装しちゃうことも間々あるものです。
Re: (スコア:0)
最下位のidleタスクでウォッチドッグを叩く
それが止まったら再起動
単純に止まったものを再起動させるのがウォッチドッグ・タイマー
Re:クラッシュって… (スコア:1)
そうなんですが、大抵の…Linuxカーネルなんか特に…Kernel Panicになったら、WDT叩かなくなるのでWDTが起動して強制再起動云々に入るし、そこまで行かないとしたら、地上との送受信を担当するタスクまで停まるというのが何なんだろうという感じがあるんですよね。
そこら辺の対策のためのコードというのは、Linuxカーネルなら十分すぎるくらいに色々盛り込まれていますから。
とりあえず、最低でもKernelが生きていてWDTを随時叩いてるという話になりますので、そうなると、別の要因・要はハードウェアの問題なのかな。と。
Re:クラッシュって… (スコア:1)
> 最下位のidleタスクでウォッチドッグを叩く
> それが止まったら再起動
> 単純に止まったものを再起動させるのがウォッチドッグ・タイマー
昔、RFIDのリーダが機能しなくなる問題の解析をやった事がありましたが、その原因がもろにidleタスクでWDTを叩けなくなる→WDTタイムアウトによる再起動でした。WDTを叩くなんてインナーループの中でやるもんだろう、「idleタスクでWDTを叩く」なんて設計は何の冗談なんだろうか、って思いましたが。
Re: (スコア:0)
Linuxをなんだと思ってんだろ
Re: (スコア:0)
Linuxが死んだんではなく、その上で動く1プロセスに色々全てが集約されててそいつがクラッシュなりフリーズしたんではないかな。
イベントループ回ってるか程度でもいいからウォッチドック位は付けとけはホントその通りだよなぁ…
宇宙線の影響で再起動があり得るような環境なら必須じゃないのかと
運良く (スコア:0)
> 宇宙線などにより運良く再起動することを期待
今はそのほうがいいのでしょうが、平時で勝手に再起動したらそれはそれで問題のような。
Re:運良く (スコア:5, 参考になる)
ツイていたようですね。
原因不明ですが再起動されたようで。
http://japanese.engadget.com/2015/06/01/lightsail-8/ [engadget.com]
Re: (スコア:0)
普通にウォッチドッグタイマで再起動とかじゃないのかな。
Re: (スコア:0)
それなら「原因不明」とはならないでしょう。
Re: (スコア:0)
実機は手元ではなく軌道上にあるので、回線経由でしか状況をみれません。
そのテレメトリが、リブート原因をレポート項目に含めてなければ、やはり不明になるのでは。
組み込みはDIYで受け狙いガジェット作りしか経験ないので分かりませんが、
こちらからの指示なしで送りつけてくる通常運用定期通知な内容に、リブート原因とか
デバック情報的なもの含むんでしょうか。
定期通知に含まなくても、コマンド叩いたら教えてくるようになってるかもですが、
なんでもSSHのラインが不安定でログインもまともにできない、ってそうなので、
調べるに調べられないのかなぁとか。
Re: (スコア:0)
幾らガードしても、どんな高エネルギー宇宙線がシールドを突き破ってやって来るのか分からないからな。
Re: (スコア:0)
再起動されること込みでシステム構築してんじゃね。
別に可笑しなことでも問題でもなんでもない。
しかも宇宙線にさらされる環境なんだから、なおさら。
フリーズしたものの (スコア:0)
8日目で復活したそうな
Re: (スコア:0)
回復したのはタレコミで述べられている「宇宙線などにより運良く再起動」なのでしょうか?
回復したのは喜ばしいが、宇宙線の影響で数日置きぐらいにリブートが掛かるというのも、やな感じだな。
もしかして無人探査線の運用なんて、みんなそんな感じなの?
そして、回復してもバグは直って無いので、また二日後にフリーズするだろうか。
それとも通信が回復した隙を狙って、問題のプログラムを差し替えたりしたのかな。
Re:フリーズしたものの (スコア:1)
>もしかして無人探査線の運用なんて、みんなそんな感じなの?
宇宙線による不定期なリブート自体は設計仕様の内らしいです。
Re: (スコア:0)
まだ差し替えPGが用意できず、フリーズ前に手動再起動予定だそうな。
8日もあって用意できないって何? 実験機だし、根本的には送信した内容消すだけだよね?
「ファイルいくつか用意してロータリー、送信済みファイル消す(初期化)」程度の話だよね?たぶん。
それすらできない(つか思いつかないのか?)
Re:フリーズしたものの (スコア:1)
アップデートファイルが32Mを超えてしまったんだろう
Re:フリーズしたものの (スコア:1)
上から目線でコメントする前に再起動のことを書いてるブログ記事 [planetary.org]をちゃんと読もう、な?
Re: (スコア:0)
エンジニアにとっては、ムズムズするというか、かなり屈辱的な運用だなw
Re: (スコア:0)
大したことない修正でも本番機に適用ってどこの国のどのプロジェクトでも大変だから、しばらくは手動で再起動みたいな回避方法で対応って割と普通だよ。
その間にテストや手順のチェックをして、関係者が万全の体制の取れる日時に適用、みたいな流れになるんで。
Re: (スコア:0)
まぁ数週間でおっこちますし。
Re: (スコア:0)
宇宙機の通信が安定しないのはよく知られたことだけど、
上り帯域を使い切ってるわけでもないだろうから対応はできると思うんだけどなぁ…
パッチを分割して送信、チェックサム破損してれば個別に再送信、全部揃ったら結合して適用して再起動。
それすら放置する必要があるってことは相当エンジニアの数も足りてないのか、
無駄(この事態を防げなかった的な意味で)に手続きが煩雑になってる魔境なのか…
Re: (スコア:0)
私があなたの上司だったら、あなたの提出した見積もりに5倍はかけて計算し直すよ
なにか見落してないかい
Re: (スコア:0)
数週間でミッション終了なのだから、再起動運用で済むのならそれでも良いのでは?
PG差し替えのリスクの方が高いのかもしれないよ。
Re: (スコア:0)
打ち上げ前に分かってた不具合だったのに何故か修正されずにそのまま打ち上げられたとか書いてあるし
コードが相当ぐちゃぐちゃで誰も正確に中身を把握してないかまともにプロジェクト管理(不具合の管理すら)されてないか
まあ、どちらにしてもかなり酷い状態で運営されてそうですね
Re:フリーズしたものの (スコア:1)
>どちらにしてもかなり酷い状態で運営されてそうですね
重量と軌道が厳しく制限されるピギーバックで打ち上げるくらいだし、
そもそもが「本気じゃない」緩いプロジェクトだったんじゃないすか。
Re: (スコア:0)
なぜ自分が思いつく程度のことを彼らが思いつかないと考えてしまえるのだろう?
Re: (スコア:0)
再起動したのですか、それは良かった。
普段の宇宙もの実験機の失敗なら、「不具合を洗い出すためだからうんたらかんたら」と擁護の一つもするのですが、今回は正直えっ?そのトラブルは地上でも余裕で検証できたよね?と突っ込まざるえなかったので、復活してくれてほっとしました。
テストのレベルにだいぶ不安を感じますけど、とりあえず宇宙でしかできないテストを今のうちにこなしてくれることを期待です。
# 元日本惑星協会平会員なのでAC。これからはソーラーセイルの時代だ!って会報貰ってから打ち上げ成功まで15年はちょっとかかり過ぎた…
Linuxだから安全 (スコア:0)
というのが彼の口癖だった
Re: (スコア:0)
#2824199がまさにそんなこと言ってるぞ(笑)。
大家はX-37B 4回目の軌道飛行 (スコア:0)
日本では有人ロケットより、長期軌道滞在対応往還機の方が、人命リスクの点で実用的なのかも。
テスト不足としか言えない (スコア:0)
テストを軽んじる人間によく起こるトラブル
Re: (スコア:0)
コード書く時間よりデバック時間の方が時間かかりかねないからなあ・・・
イカロスくん (スコア:0)
これとイカロスってどう違うんだろう
Re: (スコア:0)
日本惑星協会のアーカイブに2009年当時の記事 [ku-ma.or.jp](LightSailも本当はIKAROSと同時期に打ち上げるはずだったので)が残ってますが、LightSailの方がより小さな実験機でかつ純粋なソーラーセイルに近い奴っぽいです(IKAROSはイオンエンジンも用いるハイブリッド型なので)。
IKAROSがやったから、うちらはもっと凄いことを…とかいうわけではなく、並行して開発されていた米国版ソーラーセイルプロジェクトって感じでしょうか。
Re: (スコア:0)
> IKAROSはイオンエンジンも用いるハイブリッド型なので
IKAROSが積んでいるスラスタはイオンエンジンではありません。
Re: (スコア:0)
ずっとIKAROSイオンエンジンも積んでるだと思ってました。あれは将来構想だったのですね。お二方ありがとうございます。
Re: (スコア:0)
イオンエンジン積むのはイカ坊じゃなくて、将来機の構想だぞ。
Re: (スコア:0)
LightSail A
軌道 地球周回 低軌道
打ち上げ NASA,USAF X-37Bミッションへの相乗り
打ち上げ日時 2015年5月20日
コンフィグレーション キューブサット(3U) 10cm x 10cm x 30cm
質量 5kg
スラスタ なし
姿勢制御 なし
セイル 4.5μ厚マイラフィルム △形 x4 総面積 32平方メートル
セイル展開方式 金属テープ状伸展ブームによる静的展開
IKAROS
軌道 太陽周回 金星遷移軌道
打ち上げ JAXA金星探査機あかつきミッションへの相乗り(バラスト重し役)
打ち上げ日時 2010年5月21日6時58分22秒(JST)
コンフィグレーション 円筒形 専用
Re:イカロスくん (スコア:1)
イカロスの姿勢制御方式としては, 他に液晶シャッタ [www.jaxa.jp]による反射率変化があります.
Re:送信し終わったら消せよ (スコア:1)
まあそう言うなよ。
作った奴のアダ名は死ぬまでbeacon.csvとか32MB君になるだろう。
十分に重い十字架だと思う。
Re:送信し終わったら消せよ (スコア:5, 興味深い)
だそうで。これは技術的なミスというより、計画が頓挫するような問題あるのに、それが一部では認識されていながら、
共有がされていなかったなどの、プロジェクトマネージメントや組織マネージメントのやり方の手落ちの方に、
より責任があるように思う。
Re: (スコア:0)
32MBもあれば、誰でも十分だろう。