UNITEC-1　UOBCコンペティション

UOBCコンペプロジェクトは2008年の12月に始まりました。研究室として初めてのコンペティションということで色々なことを一からしつつ時間をかけて勉強していきました。結果としては無事UNITEC-1に搭載され2010年5月21 日に金星に向かって旅立ちました。

 

サクセスクライテリア

ミニマムサクセス

UOBC  に必要な等時刻管理とパケットアセンブルディスアセンブルの機能を実装し通常環境で確実に動作する機能モデルを作成する。

　フル　サクセス

温度や振動真空サイズ重量などを考慮した設計を行い EM の作成を行う。地上でのふるい落とし試験に勝ち残り  UNITEC-1  に搭載されることを目標とする。
アドバンスドサクセス

衛星の姿勢を検出するプログラムの作成を行う。アルゴリズムの処理や評価をするためあらかじめ用意した姿勢とスターカタログから理想的な星画像を合成しその星画像から逆に姿勢を計算することで、地上で評価を行う。

 

振動、強度

簡易な構造で組み立てを容易にするため図 1 のような天板からねじで基板をつるす様な構造を設計しました。この構造を解析したところ 100Hz に対して十分なマージンが取れていました。基板の固定には M3のねじを使用し 60cmN 程度で締め付けています。

 

 

 

熱、真空

採用したマイコンの消費電力が高く断熱状態では 100℃を超えます。動作保証温度が-20～75℃なのでヒートパスが必要になります。基板にグランドパターンを引いているがこれだけでは放熱に不安があったためヒートシンクを用意しました。(図 2)  また尐しでも熱抵抗を減らすためアウトガスの尐ない放熱シートを使用しています。熱の発生しやすいレギュレート部分ではスイッチングレギュレータを使用し効率 92%程度でレギュレートしています。

 

放射線

ヴァン・アレン帯を通り抜けることになりますが金星に向かう軌道なので TID はそれほど見積もっていません。しかし磁気圏を抜けると言うことは太陽からの高エネルギー粒子を直に受ける可能性があるためシングルイベントの対策は必要となります。しかし  SEB  に関してはUOBC で扱う電圧が 5V 程度なので MOSFET を極力使わないといった程度の対策で十分だと見ています。

 

SEL

SEL はバルク CMOS の構造に対して起こるため SOI プロセスのような特殊なもの以外には必ず対策が必要となります。ラッチアップ時には通常の 2 倍以上の電流が流れることが想定されるので電源回路で電流監視、リセットで対応しています。突入電流でリセットされるのを避けるためスロースタータ回路付きのレギュレータを導入することで 30μs 程度でゆっくりと立ち上がります。

 

SEU

SEU は Flash や EEPROM よりも SRAM や DRAM に対して起こりやすくなります。またメモリサイズの肥大化とプロセスサイズの微細化につれてその確率が上昇します。今回の用途に画像処理が含まれるためメモリサイズの制約があります。しかしできるだけメモリを使わないようにテーブルなど、できるだけ ROM を使うようなプログラムを実装しています。また SEU は一過性なのでリセットで対応ができます。そこで WDT でプログラムの暴走を監視しています。

 

C & DH

C&DH では UOBC の基板の設計と MOBC とのインターフェース部分のプログラムを担当します。MOBC との通信はコンペで最重要のため PIC を三重冗長として一つの PIC に動作不良が起きた場合でも即座に切り替わりそのまま通信を続けることができます。またMOBC から来る画像パケットについては SH2 側でスターセンサ処理を行うため、パケットのリレーを行います。

 

ハードウェア インターフェース部は PIC と CPLD で構成しています。CPLD はプログラマブルに内部の回路を構成できるため、ピンを特に気にすることなく基板のデザインができるという利点があります。さらにFPGA のように SRAM ベースではなく Flash でルックアップテーブル(LUT)が構成されるためコンフィグレーションが必要なく、SEU に強い（と思われます）。ま<た  CPLD  は内部で論理回路を構成できるため後から多数決回路といった新しい冗長構成を組むことができます。つまり開発のスケジュールに合わせて「ソフト的」に調整を行うことが可能となります。こういった理由から CPLD を介して PICを三重冗長にすることでより柔軟な開発ができるようにしました。

等時刻管理

UOBC は 1000ms 間隔で MOBC に対してパケットの送信を行います。リアルタイム OS の検討もしたがタスクの数が多くならないことやソフトウェア故障を増やす原因にもなり得るのでタイマー割り込みで 1000ms を作り割り込み内でパケットの送信を行っています。通常、割り込み内で（inline 展開したとしても）関数を呼び出す処理をさせることは好ましくありません。しかしフラグ管理のみでイベントループのようなものを作った場合に正確に 1000ms の間隔でパケットを送信させることは難しくなります。CPU の処理がタイマー割り込みに取られて困る部分は通信の受信の際の取りこぼしだが今回は 57600bps で通信を行うため 139us 以内でタイマー割り込みを抜ければよいとしました。また受信関連の割り込みはタイマー割り込みに比べ優先度を高くしています。この場合、受信割り込み内での処理はバッファリングさせるだけなのでタイマー割り込みの遅延は 5.4us となりました。正確には割り込み時にスタックへの待避などがはいるため概算だがこれに 20us 程度の誤差が出ます。またシステムクロックについても 100ppm の誤差を含み、タイマーに関しても正確に 1000ms ではなく 984us で割り込みをかけています。さらに uart で 57600bps を作る際にエラーレートを 3.3%含みます。これらを累計すると 1000ms±50us 程度の間隔でパケットを送信できる見積もりとなっています。

 

ハンドシェイク

MOBC と PIC のハンドシェイクは uart 上に Xmodem のようなプロトコルを設定して行われます。PIC から MOBC に対して送信パケットを送る際にタイマー割り込みが掛かるとパケット中にパケットが入り、パケットの構造が崩れてしまうためタイマー割り込みを禁止にしています。パケットの最後に CRC を付けることになっていますが、CRC の計算を単純なアルゴリズムで実装した場合 CPU にとって重い処理となります。PIC にはハードウェアで CRC 計算用のモジュールがついているためハードウェアで高速に計算をさせたかったのですがCRC の入力バッファにデータを連続的に用意できずソフトウェアでの実装を行いました。しかし 1Byte に対してルックアップテーブルを用意することで高速に CRC の計算ができました。

 

CRC 計算時間

アルゴリズム 処理時間
ソフトウェア（ビットシフト） 33us
ソフトウェア（テーブルジャンプ） 61us
ハードウェア 56us

 

パケットの受信は、ステートマシンの様な状態遷移を考えるとわかりやすいです。しかし byte 単位で見ると意味をなさないことが多く、ある程度バッファにため、バッファから固まりとして読み出すことで初めて意味があります。バッファリングは受信割り込み内で行い、1 パケットの最大 byte 数まで格納します。読み出しのタイミングは、受信割り込み内でパケットのヘッダとフッタを監視しています。1 パケットが受信完了と同時に main 関数内でのイベントループに通知してパケットデコードのタスク内で読み出しが行われます。パケットデコードではバッファリングされたデータを取り出しながら、状態を遷移させてパケットの解釈を行っていくきます。途中でデータ抜け、もしくはデータ化けが起きた場合には状態が進まなくなるため、パケットのデコードは完了しません。その際にプログラムが止まらないように、タイムアウトとバッファの中身を監視することで、デッドロックを防ぐことができます。

 

スターセンサ

>スターセンサでは PIC 側から送られてきた星画像データから衛星の姿勢を計算します。コンペの制約条件から連続した画像などは得られないので動的な絞り込みなどは行えません。制作したスターセンサは画像にノイズや誤差を含んでいることを前提としたアルゴリズム選択しました。

 

 

 

スターセンサはコンペ中の制約があるため相対的に重要度が低いこと、さらにはシステムの簡略化を重視し単一でシンプルな構成としています。しかしスターセンサアプリケーションは画像処理とテーブル参照などの処理があるため外部に ROM と RAM を拡張しています。

 

アルゴリズム

スターセンサの処理は、次のようなフローとなります。

1.    イメージセンサ上での星像から背景から星を抽出して星の中心位置を計算し星の配列を作成する。  (preparation)

2.    イメージセンサ上での星を赤道座標上での星と対応づけ（matching）、星方向ベクトルを算出する。

3.    複数の星方向ベクトルから星画像の中心方向ベクトルを割り出すことで衛星の方向ベクトルが得られる。

4.    同定した星の赤経、赤緯から、逆にイメージセンサ上での星像を計算し撮影された画像と比較することで姿勢角を算出する。

またこのほかに前処理としてマッチング用のスターカタログの作成も行います。

 

preparation

matching を行うまえに画像から星を抽出して星の座標配列を作ります。背景と星を分離するには輝度値が用いられることが多いようです。しかしノイズも輝点となって現れるためこれらを区別する閾値が重要となります。

 

matching

一枚の画像で星とノイズを区別するには輝度値以外を用いることは難しくなります。しかし輝度値だけで完全に除去するのは困難なのでノイズに対してロバストな星の同定アルゴリズムが必要となります。採用したアルゴリズムは、マッチングの特徴として離角を利用します。注目する星と、所定範囲に<ある星との離角を算出し、その離角に対する星の数をマッチングに用います。画像上の星の数自体をマッチングに使うため星の数に比べてノイズの量が小さければ問題なく同定できます。また離角に対してもある程度、裕度を設けて正規化することで多尐の誤差を吸収できます。画像上から離角はカメラの画角(FOV_V)と解像度(HIGHT)を用いて（図  4）計算できます。これを注目している星からカメラの対角画角の半分(PR)までの星について離隔を出します。さらに離隔を対角画角を最大として 64 諧調に離散化する。64 諧調に離散化する際に VGA<の画像では 6px 程度の裕度を設けることになるため星の輝点の中心はある程度曖昧でも十分です。こうして離散化された離隔を合成したものを 64 ビットのパターンで表し、これを注目している星の特徴量とします。

 

一方、スターカタログについては５等星までの星について同様に PR までのビットパターンを生成しておきます。生成したビットパターンと赤径、赤緯を一つのレコードとして配列を作成します。

星の同定は画像上から作成したビットパターンとスターカタログ上のビットパターンを比較しもっとも近いものを選び出します。比較方法はそれぞれのビットパターンについて何ビットマッチしているかを計算しマッチビット数の最も多いものが同定する星となります。これは画像上に多尐ノイズが乗っている場合にも対応ビットの合計としてマッチングを行うため同定できる可能性が高くなります。このようにして画像上のすべての星についてカタログ上の星と対応付けを行います。

 

方向計算

画像の中心方向を計算するためには最低 3 個対応付けのとれた星が必要となる。そこで画像上のすべての星にマッチングを取った後にマッチビット数で順位をつける。マッチビット数の高いものがより正確に同定ができている可能性が高いため上位から選ぶことで正確に中心方向を出すことができる。それぞれの星と画像の中心座標を慣性座標系で(X 1 ,Y 1 ,Z 1 ), (X 2 ,Y 2 ,Z 2 ), (X 3 ,Y 3 ,Z 3 ), (α,β,γ)とする。ただし方向のみでよいので単位球上に投影したものとして考える。一方画像の中心と 3 つの星の離角はマッチングの時と同様にして求めることができる。これをθ 1 θ 2 θ 3 とする。これら座標と離隔の間には下式の関係がある。これを連立して解くことで(α,β,γ)が求まる。

姿勢角度計算

方向に対して回転が決定できれば姿勢が決定される。基準となる座標系に対して Z 軸を上方とし、姿勢角が 0 度の場合は画像の上方向が Z 軸方向となる。このような基準に対して画像が何度傾いているかを計算する。計算方法は姿勢各 0 度のときの星の位置を逆にカタログ上から作り出すことによって現在の画像と比較する。このとき生成する画像は方向計算で出した画像の中心方向を向いている必要があるため、あらかじめ画像データとしてメモリに蓄えておくことは困難であり計算負荷の軽い方法を選ぶ必要がある。具体的な画像生成方法としては姿勢角  0  度の時は画像の中心(F)から上方向（または下方向）に極(P)があることを利用して画像上での赤経、赤緯軸を決める。それらの軸に対して極座標で星と画像の中心の赤経、赤緯の差を用いることで 0 度時の星の位置（X x ,X y ）が決まる。

 

実験および結果

システム稼働試験

 

 

 

全体を通してシステムで動作しない部分がないか確かめました。電源部は消費電力が 2.9W 程度になるとリセットが掛かることが確認できました。また突入電流はなく 20us 程度でゆっくりと立ち上がっています。システムの堅牢性を確かめるため、24 時間連続稼働テストおよび実験中に PIC の電源を順次落としていきました。その結果 PIC2 機が動作しなくなった場合でもMOBC と通信を行うことが確認できました。また等時刻管理についてパケットのばらつきを計測しました。しかし計測する側で20ms の誤差が出てしまったため、正確な測定はできませんでしたが、尐なくとも 20ms 程度には抑えられているため十分な精度でパケットを送信できています。

平均 標準偏差 最大 最小
995.2[ms] 8.27[ms] 1012[ms] 980[ms]

 

環境試験

 

 

環境試験として熱真空試験と振動試験を行いました。熱真空では 0°～-50°また 10 -5 [Pa]程度で実験を行ったが特に問題なく動作しています。SH の温度もおおむね 65°程度に収まっていたため動作範囲内です。また振動試験ではモーダルサーベイと QT ランダム試験を行ったがこちらも特に問題ありませんでした。しかし蓄積についての見積もりは行って居ないたので時間があれば調査を行いたいと思います。

今回製作したアルゴリズムの調査として模擬画像を使って試験をしました。模擬画像のパラメータとしてカメラの水平画角を 15°25°35°、感度を 4 等級まで 5 等級まで 6 等級まで、収差が理想的として星の数を見積もります。PoleStar アルゴリズムは画像上の星の数が精度に深く関わるため、あらかじめ画像上に予想できる星の数を計算ています。

 

 

 

 

計算によると感度が 6 等級まで水平画角 25°もしくは感度が 5 等級まで水平画角が 35°程度であれば polestar が使えそうであることが分かります。一般的に画角と感度はトレードオフとなりますが、収差の影響を考慮した場合は画角が狭くて感度が高い方がスターセンサに好ましいです。ここでは水平画角 35°5 等級までとして精度を測りました。28 枚の模擬画像について調査したところ正確にマッチングがとれているものが 27 枚あり、姿勢計算がほぼ正解しているものが 26 枚でありました。マッチングがとれているのに計算が合っていないものは極方向を向いていたため姿勢角軸と赤経軸が重なっていたため赤経と姿勢角が大きく異なったが姿勢としてはほぼ正解しています。しかし 1 枚はマッチングがとれず全く異なる姿勢を示しています。画像中の星の数は 22 個でありましたが 17 個でも正解している画像があるため星の数以外に原因があると思われます。マッチビット数を調べていくと姿勢計算には使われませんでしたがマッチングがとれている星がいくつかあり計算に使われた星のマッチビット数と比較するとその差は 1 しかありませんでした。つまり原因としてはビットパターンとして似通っているものがあるためどうしても最後の比較でマッチングしきれない星があると考えらます。また赤経赤緯の誤差が 30”以下なのに対して姿勢角の誤差が 5°以下と精度が悪いです。これは単純に姿勢角を計算するアルゴリズムが簡易的なものであるためだと思われます。

 

まとめ

8 月の中旬に九工大の方でふるい落とし試験と称して環境試験と機能試験を行ってきました。どちらも奇跡的に全くミスがなく、結果としては優勝することが出来ました。またスターセンサの実装と評価を行い。スターセンサの作成が可能であることを示しました？ミッションの達成度としほぼ達成できたといえる（とおもいます）。その一方でマッチング精度の向上や姿勢角精度の向上といった課題があり研究を行っていきたいと思います。プロジェクトを通して実際にものを作っていくことは、非常に大きな意味を持っています。今後もこのような実際の開発を通して実感が得られるプロジェクトに参加していきたいと思います。

2010/06/04