ARLISSに参加した話
本記事はJAXA 学生 Advent Calendar 2020の18日目の記事です．
私は学部4年次（2019年度）に東京理科大学の木村研究室に所属し， 同期とARLISSという大会に参加しました． 本記事ではその経験談をお話ししたいと思います．
ARLISSとは
ARLISS（A Rocket Launch for International Student Satellites）は学生向けの衛星開発コンテストで，
活動を通じて衛星開発やプロジェクトマネージメントの能力を培うための大会です．
例年9月ごろにアメリカネバダ州のブラックロック砂漠で開催されます．
ブラックロック砂漠
参加チームはCanサイズ 1 の模擬衛星（Cansat）を作成し，それをロケットにのせ上空約4kmまで打上げます2． 最高点付近に到達すると自動的にCansatが放出され， その後各チームが定めたミッションをCansatが自律的に行います． コンテストとしては各チームが定めたミッションの独創性や技術力等を競います．
ちなみに3つの部門があり，行うミッションに対応した部門に出場します．
- ランバック部門 ：着地後，指定されたゴールまで走行する
- フライバック部門：飛行して指定されたゴールまで走行する
- ミッション部門 ：上記以外のミッション
私はランバック部門に参加しました．下図はランバックの流れです．
ランバックの流れ
大会までの流れ
当研究室は 4月配属のため，4月から活動を開始します．
大会までの大雑把な流れは下表に示す通りです．
| 月 | 内容 |
|---|---|
| 4月 | チーム結成，ミッション策定，要件定義 |
| 5月上・中旬 | レビュー・予算会 |
| 5月下旬 | BBM検証，各種試験 |
| 6月 | 組合わせ試験，EM 作成 |
| 7月 | EndToEnd試験 |
| 8月 | FM作成，審査書提出 |
| 9月 | 大会本番 |
開発したローバ
下図は開発したローバです．
作成したローバ：APO
直径16.5cm3，横幅24.0cm，重量1040g です．
前面にベッタベタに貼ってある養生テープは色々と訳があります．
「大会当日」の節で詳述します．
処理系
処理系はRaspberry Pi Zero Wに一本化しています．
安価で画像処理が可能，ネット上の情報量が豊富であることから採用しました．
SSHでリモートアクセスできるのもありがたいです．
センサ系
センサとその用途を表にまとめます． 括弧で括られている項目はシステムを冗長とするためのバックアップ用途です．
| センサ | 用途 |
|---|---|
| GPS | 位置推定 |
| 9軸センサ | 姿勢推定（，着地判定） |
| 気圧センサ | 放出判定4，着地判定 |
| 照度センサ | 放出判定（，パラシュート検知） |
| カメラ | パラシュート検知，ゴール検知（，着地判定） |
通信系
ローバからのテレメトリを確保するために通信モジュールIM920を載せています．
もちろん地上局側にも同じ通信モジュールを用意しています．
駆動系
ホイール用にモータを2個載せています．独立2輪制御です．
電源系
Lipoバッテリーを2個載せています．
処理系・センサ系に3.7Vを1つ，駆動系に7.4Vを1つです．
シーケンス
ランバックの場合，打上げからゴールまでの流れが一方通行です． そのため基本的には表の上から下へシーケンスが流れます．
| # | フェーズ | 詳細 |
|---|---|---|
| 1 | スリープフェーズ | ロケット搭載から打上げまで待機 |
| 2 | 放出判定フェーズ | 打上げ後，ロケットから放出されたか判定するフェーズ |
| 3 | 着地判定フェーズ | 着地したか判定するフェーズ |
| 4 | パラシュート分離フェーズ | パラシュートを本体から切り離すフェーズ |
| 5 | パラシュート回避フェーズ | 分離したパラシュートを回避するフェーズ |
| 6 | 走行フェーズ | GPSを用いてゴール付近まで接近するフェーズ |
| 7 | ゴール判定フェーズ | 画像航法によりゴールに接近するフェーズ |
各フェーズの詳細は以下の通りです．
-
スリープフェーズ
打上げ前の諸々の準備を待機するフェーズです． 判定等は一切行いませんが，センサログは常に保存しています． -
放出判定フェーズ
ロケットから放出されたかどうかを照度センサ，気圧センサ，または GPS高度計で判断します． 誤って判定してもクリティカルではないため”OR”判定となっています． -
着地判定フェーズ
着地したかどうかを気圧センサ，GPS高度計で判定します． 着地判定の偽陽性は非常に危険なため，”AND”で判定しますが， センサが壊れている場合に備えて放出判定から十分な時間が経過した場合は強制的に「着地」と判定します． -
パラシュート分離フェーズ
パラシュートとCansat本体を固定しているテグスをニクロム線で溶断します． -
パラシュート回避フェーズ
前方にパラシュートがあるかを確認します． ある場合は後進，ない場合は前進し着地地点から約5m離れることでCansatがパラシュート絡まることを防ぎます． -
走行フェーズ
GPSと地磁気センサを用い，ゴール5m付近まで走行します（ゴールの位置はあらかじめGPS座標で与えられています）． 確かP制御でした． -
ゴール判定フェーズ
画像航法でゴールへ接近します． 搭載コンピュータの処理速度的に動画でのトラッキングができないため，定期的に静止画を取りゴールのほうへ移動します． ゴールは赤いコーンですが，画像中の赤い領域が閾値以上になったとき，0mゴールと判定します．
開発と試験
プロジェクト体制
私のチーム（チーム名：B-TUS）は計12名で，以下の4つの役割に分担しプロジェクトを進めました．
- プロジェクトマネージャー(PM)：1人
プロジェクト全体の取りまとめを行い，進捗管理・渉外を担当します． - 構体班：3人
機体の設計・製作を担当します． - 回路班：4人
回路およびアンテナの設計・製作を担当します． - C&DH班：4人
コマンド＆データハンディングの略です．
ミッションシーケンス，プログラム作成，テレメトリ管理を担当します．
ちなみに私はC&DH班のリーダーを務めました．
ミッション決め，要件定義レビュー会・予算会
4月，研究室配属当日から打合せを始めます． 最初はどんなミッションをやりたいか，どの部門に参加するかを決めます．
次に要件定義です． ミッションを行うのに必要なものを洗い出すWBS(Work Breakdown Structure)， ミッションが失敗する原因の洗い出しをするFTA(Fault Tree Analysis)， 何かが故障した結果，どのような事象が起こりえるかを分析するFMEA(Failure Mode and Effect Analysis)などを行います （プロジェクトマネージメントの定番ですね）．
ただこの部分，あとから振り返るとかなりガバガバでした． 形としてはやったものの，本質を抑えていない中途半端なものでした．
例えば足回りの部分． ランバックミッションの場合，「走行できなくなる」という事象は非常にクリティカルであり何としても避けなければなりません． しかし私たちはコストを優先し，耐久性はあまりなく性能はお世辞にも良いとは言えないモータを選びました． 後にバッテリー試験を行った際，半分も容量を減らさないうちにモータが焼き切れ， またEndToEnd試験の際も何度もモータが壊れ，そのたびに交換作業が必要となりました．
5月のゴールデンウィーク直後にレビュー会をし，先生や先輩方からフィードバックをいただきます． 研究室としては例年参加しているので，参加経験のある方からのアドバイスは結構心強いです．
BBM(BreadBoard Model)
部品が届き次第，検証を行います．
センサやモジュールは正しく動作するか，要求を満たしているかなどを確認します．
名前の通り，ブレッドボード上でテストします．
ある程度作業が進むとEM用のプリント基板が完成するので，それを用いて試験確認もしました．
BBMが終わるころからEM(Engineering Model)を製作します． EMが試験に使う機体になります．
各種試験
ミッションを成功させるために要求を満たしているか試験します． どのような試験をすべきかはミッションによって変わります． 私のチームの場合は，例えば以下のような試験を行いました．
- 落下試験
「落下」という状況を作り出し，パラシュートが展開するか，安全に着地するか，シーケンシャルに動作するかなどを検証します．
落下試験の様子@野田キャンパス講義棟
写真のようにCansatをつるし，落下させる
- 振動試験
打上げ時や走行時の振動を想定し振動を与え，どれほど劣化するかを測定します（壊れないかどうかを調べるわけではありません）． またパラシュートの開傘時の衝撃も同様に測定します（衝動試験）．
振動試験@東大中須賀研
中須賀研の方々，ありがとうございました
- EndToEnd試験
最初から最後まで通しでミッションを行えるかを試験します． 打上げの状況は再現できないため，基本的には落下してからという形になります．
EndToEnd試験@理科大野田キャンパス中庭
一通り試験を終えたら FM(Flight Model)を製作します． FMが本番機になります．
審査書の提出
ARLISSに出場するためには審査書を提出し， レギュレーションを満たしていること，ミッションが一通り行えること，Cansatが安全であること，などを証明しなければなりません．
審査書はARLISS(UNISEC)に関わっている大学の先生方が確認し，認可または却下します． 却下されても渡米前までに指摘された項目を修正すれば大会に出場できます．
これが結構厳しく，私のチームも色々な項目で指摘をいただいました．
大会当日
9/7にアメリカに入国しました．
9/8が大会準備日，9/9~12が競技期間，9/13が表彰式という流れでした．
準備(9/8)
大会前日から砂漠に入り本番環境で調整しましたが，想定外のことが起こりました．
画像の白飛びです．
下の写真はローバに搭載されているカメラで撮影したゴール（赤いコーン）の画像です．
 何とか確認できるゴール画像 |
 完全に白飛びしたゴール画像 |
完全にホワイトアウトしています．
その場でカメラパラメータを色々変えてみても全く改善されませんでしたが， 何とかなくサングラスを被せてみたら，思いがけなく結構いい．
 サングラスを被せたときの画像（近距離） |
 サングラスを被せたときの画像（遠距離） |
というわけで急遽サングラスをカメラに取り付けました．
もちろん取付穴等は用意できなかったので養生テープでベッタベタにして取り付けたというわけです．
ちなみに取り付けたサングラスは指導教官が「これ使いな」と渡していただいたもので，丁重に割らせていただきました．
第1射(9/9)
大会初日の正午に打上げ予定でしたが，準備やセッティングに時間がかかり午後3時に打上げました．
結果からを先に言うと失敗です．大失敗です．
打上げは無事成功，放出後にテレメトリが届きましたが，しばらくしてから通信途絶しました．
その後2時間ほど探し回り，打上げ地点から約3km離れた地点で発見されました．
ログ解析
ホテルに帰りログを解析したところ，途中ですべてのデータが途切れていることが分かりました．
下の図は気圧センサの実際のデータですが，降下中にバッサリ切れています．
第1射：気圧センサのデータ
青：スリープフェーズ，橙：放出判定フェーズ，灰：着地判定フェーズ
途中で処理が止まっていることは分かりましたが， ラズパイが処理落ちしたのか，電源が落ちたのかは分かりません（エラーでプログラムが停止した，というのは候補から除外できました． エラーが発生した場合，エラーログを保存しリブートしますが，その記録はありませんでした）．
そこで翌日，再現実験を行ったところ，画像の取りすぎでメモリが圧迫され処理落ちしていたことが判明しました． 「取れるデータは取ろう」ということで3秒間隔で撮影していていたのですが， どう考えても画像取りすぎだったし，長時間運用試験を行っていなかったことが悔やまれます．
第2射への修正
まず失敗の直接的な原因だった撮影ですが，3秒に1回から15秒に1回に変更しました．
もちろん長時間（3時間以上）動作させても正常に動作するかの試験も行いました．
また打上げ前後の流れに関して打合せを念入りに行い各々の動きを確認しました．
これは打上げ後に目視でローバの方向を確認するのですが，
第1射の時は全員がローバを見失い位置を確認するのに時間がかかったためです．
失敗に終わった第1射ですが， 打上げから着地判定まで問題なく動作したことは安心材料でした． この部分は試験の段階で十分に再現できなかった項目だからです．
第2射(9/12)
第2射は大会最終日の朝8時打上げ目標としました（朝のほうが天候のコンディションが良い）． 朝6時には会場で最後の調整をはじめ，予定より30分遅れて打上げました．
打上げ～着地
着地判定までは完璧で，すべてが正常に処理されました．
打上げの様子
気圧センサのデータが美しいです（下図）．
第2射：気圧センサのデータ
橙：放出判定フェーズ，灰：着地判定フェーズ
パラシュート回避
着地後，パラシュートを切り離し絡まらないように離脱しなければなりません． もしパラシュートに引っ掛かるとほぼ確実に復帰できません．
パラシュート回避は写真を用いて行います．前方にパラシュートがあれば後進，なければ前進というシンプルなシーケンスです． パラシュートが覆いかぶさっているかどうかは照度センサで判断し，被さっていた場合は風で飛ばされることを期待しそのまま待機します．
下の画像の通り，パラシュートはないため正常に離脱しました．
パラシュート確認の画像
ゴール付近へ走行
ここからはGPSを用いてゴールまで走行します．
方位のキャリブレーションが一部うまくいかなかったため走行に時間がかかりましたが，
順調にゴールへ走行していきます．
下の画像のようにローバの後ろをついていくこと約1時間…．
走行中はひたすらローバを尾行
画像右側から出ているのは八木宇田アンテナ
ゴール接近
ローバがゴール3m付近で停止しました．GPSではこれ以上の精度は期待できないため画像航法に切り替えます． （あまりにも順調で，メンバー全員大興奮）
ローバが撮影したゴール画像
赤いコーンがゴールで，ぴったりくっつけることができたら0mゴールとなります．
画像航法では，画像中の赤い領域の位置を取り出し， 左にあれば左回転，右にあれば右回転，中央にあれば前進しゴールへ近づきます． 画像中の赤い領域の範囲が閾値以上になるとゴール判定となります．
ゴール画像解析
左から，元画像，ターゲット，赤い部分の領域
見にくいですが背景のターミナルに分析結果が出力されています
渡米前2週間は毎日のように検証し試行錯誤していたパートなので，メンバーの興奮とは裏腹にローバは淡々とゴールへ近づきます．
ゴールに近づきながらローバが撮影した写真
そして・・・
0mゴール達成！
※僕のプロフィール写真です
驚くほどスムーズで，まるで練習かのように0mゴールを達成しました．
第2射のまとめ
研究室創設以来初の0mゴールという快挙を達成することができました．
第2射のシーケンスと全体経路は以下のようになりました．
| # | 経過時間[s] | シーケンス |
|---|---|---|
| 0 | プログラム開始 | |
| 2.55 | メイン処理開始 | |
| 1 | 2.69 | スリープフェーズ開始 |
| 2 | 905.7 | 放出判定フェーズ開始 |
| 3 | 1103.3 | 放出判定完了，着地判定フェーズ開始 |
| 4 | 1808.8 | 着地判定完了，パラシュート分離フェーズ開始 |
| 1830 | パラシュート分離フェーズ終了，以降 5 分待機 | |
| 5 | 2134.8 | パラシュート回避フェーズ開始 |
| 6 | 2363.4 | 走行フェーズ開始 |
| 7 | 5316.1 | ゴール判定フェーズ開始 |
| 5405.4 | ゴール判定 |
全体経路
青：スリープフェーズ，橙：放出判定フェーズ，灰：着地判定フェーズ，黄：走行フェーズ
スリープフェーズで移動しているのはローバをロケットに搭載後，射点へ移動したため
またランバック，フライバックに出場するチームは制御履歴の提出が義務付けられています． 私のチームが提出した制御履歴はこちらです．
余談
第2射のあと，ローバが上空で撮影した画像を確認したところ，驚きのものが写っていました．
パラシュート開傘直後に撮影した写真
打上げに使用したロケットの部品です． 右側にロケット本体？（円柱型のもの）と左側にフェアリングが写っています．
落下中にもかかわらずここまではっきり写っていたことは衝撃でした．
打上げをしていただいたAeropackの方にも写真をみせたところ，一言”WOW, COOL!”
個人的には地平線が見れるようにカメラを取り付けたほうが良かったかも…，と思っていましたが下向きに取り付けておいて良かったです．
良かったこと・悪かったこと
0mゴールという結果を残せたわけですが，裏では色々とあったわけで・・・．
プロジェクトマネージメント面
プロジェクトメンバー間では良くも悪くもお互いをサポートできていました． 班同士の連携はかなり密に取れていたので，作業されていない項目があればある班が自主的に行うといったことがよくありました． ただ裏を返せば役割分担がしっかりできていなかったわけで，そのせいで大会当日に混乱を招きました．
また「開発と試験」の章でも書いたように，要件定義が形だけだった部分も反省点です． 何がクリティカルで何にコストを賭ければ良いか，までを考えていませんでした． 今後へのフィードバックとしたいと思います．
技術面
第2射の際，実は2つの部分が上手くいきませんでした．
地磁気センサのキャリブレーション失敗
1つ目は地磁気センサのキャリブレーション． ローバは着地後，数回転スピンしその際取得した地磁気センサのデータでキャリブレーションを実行し，正しい方位を得られるようにします． しかしその処理が正常に行われなかったため正しい方位が得られずローバの走行に時間がかかってしまいました．
原因は明確で，打上げ直前に地磁気センサを本番用に変えたことです． キャリブレーションの際，外れ値除去のため閾値以上の値は処理から除外する設定にしていました． 練習用のセンサでは外れ値の領域が本番用のセンサでは正常な値の領域となったため， その領域がバッサリ切り落とされ正しい方位を得られなくなった，という訳です．
本番でセンサを変えることを失念していた，外れ値除去のプログラムがロバストではなかったこと，が反省点です．
通信モジュールの故障
2つ目は通信モジュールの故障です． 走行中にテレメトリが届かなくなりローバの状態が分からなくなりました． 結局最後までテレメトリは復活せず，ゴールしたかどうかもすぐには分かりませんでした．
後に確認して分かりましたが，走行中にローバ側の通信モジュールが故障したことが原因でした． 故障の原因はおそらく劣化です．本来，本番用の機器と練習用の機器は分けて使用していたのですが，なぜか通信モジュールだけは区別せずに使っていました． これもプロジェクトマネージメントに関わる部分ですが，部品の管理に関してわきが甘かったと感じています．
また通信モジュールに関連して，衛星は衛星だけで成り立っていないことを強く感じました． 宇宙開発といえば衛星や探査機そのものが注目されることが多いですが，衛星単体でシステムとして成り立っていることは全くなく， 地上局の設備も含めて初めてシステムとして完成します． 衛星は通信ができて初めて価値のあるものとなり，通信ができないと単なるゴミに過ぎません． 衛星において通信がいかにクリティカルか痛感しました．
だからホントは通信モジュールにもコストをかけなければいけなかったんですよね…．やり残したこと
私が担当していたC&DHの部分は，必要最低限+αはプログラムとして実装することができました． ただ，実装が間に合わなかった部分や可能であれば実装しておきたかったという部分があります．
-
スタックした場合の処理
ローバが砂に埋もれ身動きが取れなくなった時の対応コードを実装していませんでした． 形的には実装しましたが完璧からは程遠く形だけのものです． EMを使った試験を重ね，完成度の高いプログラムを実装したかったです． - 地磁気センサが故障時のバックアップ
センサが壊れたときのバックアップは必要です．特に衛星は壊れたら修理できないので冗長にできるのであればそうすべきです． 放出判定，着地判定の部分は十分に冗長にできましたが，走行の部分のバックアッププログラムは全く実装できませんでした． 地磁気センサが壊れた場合，GPSから得られた位置情報から移動方位角を求めゴールに接近する，というアルゴリズムを考えていましたが実装が間に合いませんでした． - GPSが故障時のバックアップ
これも前の項目と同じです．GPSが壊れた場合の対策も本来は取るべきです． あまり詳しくは考えていませんでしたが，この場合はカメラ画像から地平線を読み取り地図情報と比較する スカイラインマッチングとかを実装する形になると思います．いや，でもこれができたら1つの論文になる
ARLISSに参加して
私は中学時代からロボカップジュニアや缶サット甲子園などの，いわゆるロボコンというものに参加してきました．
どの大会でも色々と大変なことが起き，そのたびに苦労した覚えがあります（おかげでそこそこの結果は残せました）．
ただ，今回参加したARLISSほど過酷な大会はありませんでした．
技術的に大変だったことはもちろんのこと，未知の環境でローバが動くことを想定しなければいけない点，人間が作業するような環境ではない点など，
これまで参加した大会とは全く違う難しさがありました．
ある時，指導教官が「ARLISS はロボコンではない」と仰っていましたが，一通り参加してみて確かにその通りだと実感しました． 大会に参加するためにロボットを作り，製作したロボットで技術力を競い合うのがARLISSではありません． 大会を通じてプロジェクトマネージメントと衛星開発とは何たるかを学ぶ，これがARLISSの真の目的です．
私自身，衛星開発やプロジェクトマネージメントについてはまだまだ勉強が必要です． ただこの大会を通してそれらの本質を抑えることができるようになったと思いますし， 新しい視点で宇宙開発をみることができるようになりました．
衛星開発について学びながら技術的に困難なことにチームで取り組む面白さと難しさを経験できる，これこそARLISSの醍醐味です．
過酷ではありましたが，参加してよかったと思える大会でした．
皆さんも，宇宙工学を志す方は，是非参加してほしいと思います．
