ロケットのシミュレーション

@ina111さんのMatRockSimで生成したM-3Sロケットの軌道から，
ベースバンド信号を作ってみます．

　（クリックで拡大）

スプライン補間も試してみたのですが，発射時など位置が急に
変化するところで，補間した速度や加速度が振動してしまいます．
加速度プロファイルを見ると，最大でも4Gということなので，
おとなしく0.1秒間隔の軌道を線形近似するだけにしました．

　（クリックで拡大）

手抜きで作ったベースバンド信号ですが，シミュレータの動作は上々．
天頂に位置しているPRN17衛星は，発射時の加速度の影響が大きく，
信号のQiが低下していますが，その他の衛星は加速中も問題なく
信号追尾が出来ています．

　（クリックで拡大）

OpenMPで並列化できる時間間隔が0.1秒と短くなったものの，
まだ実時間より速い処理速度でベースバンドが生成できます．

次はリアルタイム化だ！

移動体のシミュレーション

静止したアンテナであればスムーズにベースバンド信号の
生成ができるようになったので，次は移動体に挑戦です．

単純に時速30kmで半径30mの円を描く軌道の位置情報を
1秒間隔で読み込み，その間の速度は静止のときと同じように，
線形補間で試してみました．

生成したベースバンド信号で，測位は成功するのですが，
受信信号のQiに5が目立ち，航法メッセージのデコードが
安定しません．

　（クリックで拡大）

やはり，単純な線形補間では，受信機側のダイナミクスが
正常にモデル化できないようです．速度や加速度も考慮して
補間する必要がありそうです．

測位結果は円に見えますが，南東方向にオフセットが生じています．
これは，シミュレータ側で，大気遅延や電離層遅延をモデル化して
いないためかと思われます．

　（クリックで拡大）

処理速度を上げるために，1秒間隔で疑似距離を補間していましたが，
受信機側のダイナミクスも入ると，この間隔での線形近似は難しそうです．
スプライン補間にしてみるか．

最終的にはロケットなど，高速度，高加速度なプラットフォームの
シミュレーションをしたいので，処理速度はあきらめないといけないかも．

【追記】線形補間の間隔を0.1秒に変更．2G以下の加速度であれば，
十分にダイナミクスを模擬でき，受信信号のQiも7になりました．
車であれば，これで十分かな？

　（クリックで拡大）

受信機の測位頻度も5Hzにアップ．綺麗な円が描けています．

　（クリックで拡大）

これで，機能的にはLabSatのSatGen Softwareと同じことが
できるようになります．とりあえず，NMEAファイルは読み込める
ようにしました．後は，Google Mapsに移動体の軌跡を描くと，
その位置情報がシミュレータに取り込めるようにしたい．

コード位相計算の簡略化

受信機が静止しているのであれば，ある時刻の疑似距離とrange rateから
1秒後の疑似距離を線形近似しても，5cm以下の誤差しか発生しません．

疑似距離の精度としては無視できるレベルなので，OpenMPで並列化したループの中の
コード位相および搬送波位相は，range rateに応じた位相の進みを積算するだけにしました．

擬似距離とrange rateはループの外で毎秒アップデートするだけなので，
計算負荷の高い衛星位置の計算などは，低頻度に抑えられます．

　（クリックで拡大）

この簡略化で，処理速度が随分と改善されました．
90秒分のデータの生成に50秒程度と，リアルタイム化も見えてきたかな？

【追記】こんな製品を発見．

Skydel Solutions: Software-Defined GNSS Simulator

【追記2】1秒間であれば，delta rangeをrange rateの代わりにして
位相を積算することで，1秒後の疑似距離の近似誤差はゼロになります．
range rateに誤差が生じますが，受信機側の信号追尾では問題にならない程度です．

これで速度の計算が不要になり，計算負荷がさらに低減．
実時間の2倍の処理速度でベースバンド信号が生成できるようになりました．
これは快適！

OpenMPによる並列化

シミュレータの実行速度が遅いのは，単純にサンプル毎に必要な演算が
多いのが原因のようです．

まず，コンパイラオプションをDebugからReleaseのデフォルト値に
するだけで，実行速度が倍になりました．それでも実時間の4倍ほどの
処理時間が掛かります．このときのCPU使用率は12%と，余裕があります．

　（クリックで拡大）

さらに，マルチコアを有効に使うために，OpenMPを試してみました．
受信信号の生成は，各衛星で同じ処理なので，ここを並列化します．

　（クリックで拡大）

サンプル毎に衛星間で並列化を行うと，スレッドの生成コストが高く，
並列化の効果がありません．そこで，衛星毎のforループを並列化し，
その中である一定時間分のサンプルを生成します．その後，それらを
足し合わせて，まとめてファイルに書き込むという構成にしました．

この並列化で，8コア全部が有効に使用され，平均して50%程度の
CPU使用率になっています．

　（クリックで拡大）

実行速度も，Core i7-3770，3.4GHzでほぼ実時間となりました．
快適というほどではありませんが，ストレスなくシミュレーション
ファイルの生成ができます．

GPS信号シミュレータの完成

ubloxの受信機をパッチアンテナに繋げて，ライブのGPS信号を受信しながら
航法メッセージを眺めていると，サブフレーム4と5のページ番号に51や57など，
明らかに大きな数字が出力されていることに気づきました．

ICDを読み直してみると，サブフレーム4と5には，ページ番号そのものではなく，
それに対応したSV IDというものが挿入されているようです．RTFM！

シミュレータではページ番号を25に固定していますので，この場合のSV IDは
サブフレーム4では63，サブフレーム5では51になります．

また，サブフレーム1の送信時刻は，30秒の整数倍のGPS時刻に揃っているようです．
つまり，サブフレーム1のHOWに含まれるTOWのmodulo 30は，常に6秒となります．

この2つの修正で，30秒ごとの受信機リセットも解消され，LEA-6Tでも
スムーズに測位できるようになりました．



　（クリックで拡大）

まだベースバンド信号ファイルを生成するだけのオフラインのシミュレータですが，
とりあえず動作するものが完成です．

bladeRFにはLE数の大きなFPGAが搭載されているので，これを上手く使って
リアルタイム化したいな．

【追記】fwriteでサンプリング毎にファイルに書き込んでいるのが遅いのかなと
思い，setvbufで内部バッファを大きく取って数十MBをまとめて書き込んだり，
openやwriteなどの低水準関数を使ってみたりしたのですが，まったく改善なし．
どこがネックになっているのだろう？

3D FIXの成功

疑似距離の生成にバグを発見．
やっと3D FIXまでたどり着けました！

　（クリックで拡大）

しかし，相変わらず30秒ほどすると受信機がリセットしてしまいます．
サブフレームをすべてデコードしたタイミングでもあるので，
ephemeris以外のコンテンツに不具合があるのかもしれません．
サブフレーム4と5で，別のページを試してみよう．

あと，ubloxの受信機が自動にリセットする条件も知りたい．
シリアル通信の接続ごと切れるので，Hardware Resetなのか？

【追記】試しに受信機をLEA-4Tから6Tにしてみたら，
Qiが3から先に進まず，航法メッセージがデコードできない．
受信機内部で航法メッセージのvalidityをどのような条件で
チェックしているのか不明ですが，いずれにせよサブフレームの
生成には問題がありそう．

一進一退

年明け早々，足首を痛めてしまい，自宅で療養していたらすっかり引きこもりに．
やっとテンションが上がってきたので，GPS信号シミュレータを細々と改修．

　（クリックで拡大）

全衛星の信号捕捉から航法メッセージのデコードまでスムーズに進むように
なったものの，相変わらず疑似距離残差が大きく，測位結果はINVALIDのまま．
しばらくすると，受信機側で自動にリセットしてしまう．

航法メッセージのエンコードにバグがあるのか，コード遅延の計算にミスがあるのか，
切り分けが難しい…

【追記】参考までにRAWデータ．Dopplerが大きな衛星で残差も大きな傾向？

　（クリックで拡大）

【追記2】どうも処理が重いのでプロファイラで評価したいけれど，
Visual Studioでプロファイラが使えるのは2010までだとPremium以上，
2012ではProfessionalから．手元にあるのは2008のProfessional…