2020年5月7日木曜日

スタートラッカ

 久しぶりにスタートラッカっぽやつ作って遊んでる。前にやったときのデータの流用、コードはその後で別件で作ったやつをコピペしたり。



 初期姿勢の誤差を大きめにして誤差を修正しながらループさせている。1回目にかなり大きめの修正が入ってオーバーシュートし、2回目にかなりいい修正量を得て、以降は細かく収束していく感じ。
 光軸方向の回転が影響してそうな感じ。原因はなんとなく予想できるので、そこを修正すれば1回目でかなり正しい位置に寄せられるはず。

 解像度がそこそこ高めなので処理にも時間がかかる。輝点ピクセル捜索に600ms、データセットの構成に300ms2組、が一番負荷高そう。スターカタログのマッピングはあまり負荷は大きくない。マッチングは、適切な領域で行われている限りは、ほぼ無負荷ですぐに終わる。データセットの効率が悪いと、様々なパターンを探すので計算量が増える。
 輝点探索は思ったほどの負荷じゃない。データセットの構成は予想以上に高負荷。

***

 使ってるアルゴリズム、いわゆるOptimistic Pattern Matchingというタイプなんだけど、このブログ的にはSTM32のタイマについてるOne Pulse Modeも同じOPMなので、ブログ内検索でOPMを探すとスタートラッカの話題とマイコンの話題が出てくる。。。

 OPMアルゴリズム、計算自体は浮動小数点のベクトル演算を繰り返すだけなので、STM32でも実装できそう。
 スターカタログが結構重そうだけど、固有運動を無視する(or運用時期に合わせた位置に補正した値を与える)のであれば、Ra, Dec, Vmagの3要素があれば十分なので、1万恒星あたり128KiB程度。上図が3万恒星なので、1万でも足りそう。データをVmagでソートしておけばVmag情報自体も不要か。結構コンパクトにおさまりそう。

 DCMI乗ったQFP100クラスのSTM32F4であれば、ROMが0.5-2M程度、RAMが256K程度あるので、カメラで撮影して画像処理、マッチング、姿勢推定、はオンボードで動きそう。

 姿勢制御は不要としても、あまり角速度が高すぎると恒星の撮影ができないので、せめてレートダンピングできる程度の姿勢制御機構は必要。プリントパターンでコイル作って磁気トルカ作るか? 2次元平面の磁気トルカで3軸のダンピングってできるんだろうか? コイルの巻数によってはRFも一緒に出せないかな。さすがに周波数帯違いすぎるか。
 片面のパターンでループ作れば1軸のコイルしか作れないけど、ビアで基板の裏表方向に回せば、平面パターンと合わせて3軸のコイルが作れそう。凄まじいビア数になるな。。。
 50kgの小型衛星で、100ターンのコイルに0.1A流すと5rpmが24時間で収束するらしいので、1kg未満の板衛星ならもっと小さなコイルでもタンブリングできそう。電流が100mA未満のオーダーで済むならマイコンのGPIOで直接制御できるので便利。

 そーいえば、プリント基板のレジストの有無で模様作れるんだな。板衛星であり痛衛星でもあるわけだ…… 緑のレジストならネギっぽい色になるし。
 H8マイコンのワンチップ構成、表面に緑のレジストではちゅねが書かれた板衛星。面白そう。だっ、誰がまな板だ!!

 H8ってほとんど触ったことないけど、どーなんだろう? 初音ミク関係の衛星ならH8での制御が必須だろうなーという気はするけど。

***

 スイスキューブという1Uのキューブサット、2009年打ち上げで、スイスとしても初めての衛星らしい。
 電源系はTIの16bitコントローラ、データハンドリングはアトメルのARM、らしい。STじゃないんだ……

0 件のコメント:

コメントを投稿