PCO推定アルゴリズムの改善

[ShingoNishimoto]

Summary （概要）

PCOの推定が初期値に応じてうまく行かないときがあるので改善する．

Detail （詳細）

現状，不定性解除できた時だけ推定に移る．という実装にしているが，初期のずれが大きいときには，不定性解除に失敗し続けることになるので推定がうまく行かない & 不定性解除にも失敗してしまうことになる．そのため，初期はfloatの状態である程度まで追い込んで，その後fixした解を用いて最終的なPCOとして推定するということができればいいのかもしれない．

Impact （影響範囲）

大

Priority （重要度）

中

Note （補足）

何かれば

[ShingoNishimoto]

changed due date to December 23, 2022

[ShingoNishimoto]

現状は，初期の誤差が小さいときだけうまく行っている．以下の設定で実施した時はY軸以外はある程度の精度で推定できている．アンテナのY軸は現状Along track方向を向いているが若干誤差が出てしまう原因はわかっていない．

undefined

undefined

一方で，初期のPCOをすべて0にして始めたときはZ方向でRangeへの感度がでかいのでNのfixに失敗して，うまく行かず，CDGPSの推定としても途中から発散してしまう結果になったので，整数不定性解除の前にPCOを推定しておくことが大事なのかもしれない？ただ，DDCPの残差においても不定性部分とPCOは残ってきてしまうのでPCOの初期誤差が波長以上あるとそもそもしんどいのかもしれない．ここは要調査．

[ShingoNishimoto]

PCO推定ありとなし（両方PCOの初期誤差は与えた状態）で相対位置精度を比較すると，なぜか推定しない方が精度が良くなった．

相対速度も比較するとPCO推定ありの方が良い結果になっているが，相対位置が悪くなっている．PCOの推定が終わった後に何かしらの更新をそのステップ内でかけるようにしてないのが原因か？推定が終わって更新が入った時点で整数不定性は再度求めなおすようにした方がいいのかもしれない．

undefined

[ShingoNishimoto]

これは色々見ていると，相対位置の誤差の傾向としてバイアス的なものになっており，推定を入れない方だと与えたPCOの誤差がちょうど良い方向にバイアスとして乗ってくるため精度が向上したように見えていた．誤差の与える方向を逆にすると，PCO推定を入れている方は精度が変わらないのに対して，推定を入れてないと逆方向にバイアスが発生し，精度が劣化した．

一旦状況は見えたが，R成分に出ているバイアス的な誤差の原因を特定しない限り次へ進むのは厳しそう．あと，PCOの水平成分の推定結果は初期値をどの値にもっていってもあの値に落ち着いてしまうのが若干気になる．時にy方向．これは推定誤差を吸収してしまっている可能性があるので確認する．

[ShingoNishimoto]

R成分に出ているバイアス的な誤差の原因

これは結局加速度のずれが影響していることがわかった．加速度推定精度が悪いのでそれが速度，位置へと伝搬し，非観測時の伝搬制度が悪くずれていってしまっているのが現状．加速度推定精度を向上しない限りいろいろ無理そう．

[ShingoNishimoto]

と思って経験加速度のパラメタをチューニングし，相対的な加速度精度は上がったが，ある時間になると大きくなるバイアス誤差の挙動に変わりはなかった．よく確認すると，伝搬の時に蓄積する誤差も大きくなっているが，そもそもの観測更新時に誤差が乗っている形になってしまっている．これの原因がわからない．クロックバイアスの相対的な誤差が同時にずれているけど，クロック起因のものなのか他原因で結局クロックがずれているのか不明．．いずれにせよタイミングとしては整数不定性が解けていて誤差共分散が落ちているようなタイミング．

[ShingoNishimoto]

PCO推定に使用する観測情報のマスク角の効果に関して

最初適当に30°にしていたが実際どれくらいの角度にすればいいのかを確認する．

• 0°にしてすべての情報を使用するようにした場合 undefined 低仰角の観測量にはPCVの影響が大きいのでうまく行かない．
• 20°にした場合 undefined 時間はかかっているが，うまく行っている．ただ，やっぱりy軸の情報はうまく抽出できないのか2mmくらいずれた解に落ち着いてしまう．
• 40°にした場合 undefined 30°の時とほぼ同じような結果になってy軸に関してはまだ誤差が乗っている．ただ，収束時間はかなり早い．
• 50°にした時 undefined 全然違う解になっていき，解が発散してしまった．条件を満たす観測量を得るのに時間がかかっていそうだが，なぜこれだとうまく行かないのかはわからない．方向に対する感度がなく，最大仰角となる衛星との角度差が小さな衛星ばかりになってしまうからその影響で悪化するのか？であれば実際に観測衛星を選択するときは参照衛星との仰角角度差がTBD以上のものを選択する，という風にした方が精度が向上したりする？

結論としては30°のままで問題なさそう． もう少し最適な角度は詰められる可能性はあるがそこまで重要ではないので30°で行く．

使用する観測量数をどうするか

現状は11個そろった段階で開始している．増やした方がいいのか，減らした方がいいのかに関して検討する．

• 5（約半分）にすると，精度は変わらないが収束時間が長くなってしまった．
• 22（2倍）にすると，若干収束が早い．解は変わらない． undefined
• 33（3倍）にすると，一回たまるまで時間がかかるのでちょっと収束までの時間が伸びてしまう．

結論としては，11のままでひとまずよさそう．

[ShingoNishimoto]

ここに書いてある通り，main衛星のPCVを真値にするとPCOの推定結果が劣化してしまって，以下のように割と違う結果になってしまった．．．（特にZ方向）

undefined

この状態でもう一度，どのパラメタ設定（マスク角，観測量数）がいいのか実験してみることにする．

ただ，もしかしたらPCO→PCVをやった後に再度推定しなおすなどのイタレーションが必要なのかもしれない．

[ShingoNishimoto]

マスク角を高くして高仰角のものしか使用しないように変更したけど，ダメそう．

このずれの原因として，今まではPCVによる寄与分がmainとtarget両方に対して共通だったので打ち消せていたという状況で，今回直したことによってより現実的になりtargetの方のPCVのずれがPCO推定精度に影響を与えているということなので，データ数をより多くとってPCVによる影響を消せればいいのでは？ただ，使用するデータに偏りがあると推定がうまく行かない気がするので，DOPなどを考慮した選択アルゴリズムを本格的に検討しなければいけないかもしれない．

データ量を増やしてみたときの結果．

• 以前までと同様で謎の結果になってしまう．つまりうまく推定できていない ．最終的に落ち着いているわけではなくて推定時間が長くかかっていそうな印象． →と思って長時間回してみたが，結果が落ち着くことはなく変な結果になってしまう．．．

undefined

[ShingoNishimoto]

傾向としては，多くの観測データを使用すると補正項がその分大きくなってしまって変動が激しくなる．その結果推定結果としては良い結果になっていない．なぜ？

一旦出た推定結果をもとにPCVを推定して，その結果をもとにPCOを再度，という感じにした方がいいのかも？ →と，考えたが普通に最初がずれていると，PCVも影響を受けるのでその結果で再度天頂方向が0になるように推定しなおしても意味がない．やはり最初の時点でPCOをある程度の精度で推定できるような方法を検討する必要がありそう．PCVをSH使ってやる時みたいに天頂方向残差を0にするような制約をかけてやるのがいいのか？

[ShingoNishimoto]

結局データ数に関しては少なめ（11とか）にした方が収束までは早いことがわかった（結果が大きくずれているのはあるが．） ただ，z方向のずれが特に大きめになってしまっているのでそこをどうするかは注意．

undefined

相対位置の推定精度は上がった．ということはPCCで評価すればうまく推定できているということになるのかもしれない．

[ShingoNishimoto]

PCVをSH使ってやる時みたいに天頂方向残差を0にするような制約をかけてやるのがいいのか？

そもそも，使用している残差情報が二重差分なので天頂方向にある衛星に関する成分が抜けてしまっている気はする．だから定式化の中で天頂方向が0になるように，という制約を掛けるのはむずい気がする．．．

[ShingoNishimoto]

PCCで評価すればうまく推定できているということになるのかもしれない．

と思ったが，PCCのずれもかなり大きかった．なぜ推定精度が上がっているのか．．．？シンプルにクロックのずれとかまで吸収してしまっているのかな？

undefined

[ShingoNishimoto]

DOPなどを考慮した選択アルゴリズムを本格的に検討

現状で観測衛星数がどれくらいになっているかを見てみると26とか23とかになっているので圧倒的にch数よりは多い．なので，うまく選択すればよいDOPにすることができそう．

[ShingoNishimoto]

見えていたものを優先的に選択するというのは一旦それでいい気がしてるけど，新規で選択するときに精度良くなる組み合わせにしたい．

[ShingoNishimoto]

一旦受信機のch制約をもっと大きくして改善しないかを見ようとしたら，普通にLAMBDAのfixに失敗することが発生した．

PCOなどの誤差が残っている状態だとそもそも正確にfix解を出せることが少ないのかも？

→false fixした時に雑に全Ambiguityをfalseにして分散を初期化したら，急に飛んで精度がかなり劣化してしまう現象はなくなった．ただ，そこまで良い精度は得られない．そもそもこれは衛星数を増やしたことが原因なのか？

[ShingoNishimoto]

衛星数が増えると相関が強くなって解きにくいとかはあるのかもしれない．ちょっと調べてみる必要はありそう．なんせ状態量増加による計算コストが高くなるのは避けられないが，実は探索空間が広がることによる原因などもあるのかもしれない．

ただ，20chとかに増やしただけでそうなるとは考えにくいし，いきなり数100のバイアス誤差が出るのはなんか実装をミスってそうな気がする．．．

[ShingoNishimoto]

PCO→PCVをやった後に再度推定しなおすなどのイタレーション

これは効果がないように感じているが，やってみる価値はありそう．特に，PCOのずれによって天頂方向の残差がなくならないままPCVを推定することになるが，PCOの誤差は低仰角の方向には感度がないので，低仰角の観測情報の精度が上がった状態でPCOを再度推定すればよくなる？みたいなことはありそう．

[ShingoNishimoto]

PAR(Partial Ambiguity Resolution)の確率を0.8から0.7に下げたら衛星数15のときは推定がうまく回るようになった．逆に0.9にして厳しくすると無理だった．なぜ....?

• これはよくわからんが，下で書いてあるindexのずれとRの補正方法の部分が影響している気がする．

あと20に増やしたらうまくいかない． 衛星数だけ見るとかなり埋まっていてDOPとか考えてもよいのでは？という気がしたがそうでもないみたい．． undefined

一つ関連してそうなバグは発見．観測モデルを格納するvectorのindexずれが発生していた．これは修正．←このバグを直したら20でも発散することはなくなったので，直ってそう．ただ，fix解をほぼ得られなくなってしまった．

AKFを無効にしたらfalse integerがなくなったのでAKFが悪さしているのかもしれない．とくにRが微妙なことをしていそう？精度は微妙だが，普通にfix解は出ている．ただPCOとかの推定は全く落ち着いていない．

[ShingoNishimoto]

とくにRが微妙なことをしていそう？

Rの更新をやめて定数にしたらバグ直った．ここの定式化を再度見直す & ない方がいい説もある．

Rの更新をなくすのが正解そう．

これはこの論文に書かれているように，差分処理などによって高精度な観測量が得られているときにRを更新する必要がほぼないからというのでよさそう？

[ShingoNishimoto]

AKFにおけるRの更新を止めると12chにした場合で，mainのPCVを真のものとしたときにも推定がある程度うまく行った．

undefined

この時，同様にPCVの推定もある程度良い結果が得られている（以下はPCCで評価した時の精度）．これを使って再度PCO推定を行えば今乗っているバイアス的な誤差もなくせそう．

undefined

[ShingoNishimoto]

あと，このバグを直した後で機数を増やすと精度が向上したのでやっぱり，DOPが向上して精度が上がっているということは言えそう．あと整数不定性の閾値を変えたらバグるというのはやっぱりRの部分のミスが関係してただけっぽく，Success Rateは高い方が信頼性の高い解が得られるというのが正しいと思われる．

ただ，シミュレーション期間中に観測衛星数が変化してしまう20chでは精度が劣化してPCOの推定が完了せず，変化しない最大ch数15では向上したという状況なので，まだバグがありそう．
考えられる原因

• ch数が多いと衛星機数の変化が激しい & 少しだけしか見えない衛星も取り込むことになるので整数不定性解除できている時間が短くなる．→今の方法だとPCO推定が完了しているときだけの情報を使用するので，使える時間が少ない．→PCOの推定が終わらず，精度が悪くなってしまう．

[ShingoNishimoto]

y軸がずれてしまうことに対する考察

アンテナのy軸は進行方向に対応している．つまり，azimuth 90°もしくは270°方向から来た衛星に対して感度がある量になる．GNSS衛星はLEO衛星の速度の都合上，90°方向付近から入射し，すぐにはfixしないのでPCOの推定に使われ始めるときには天頂付近に来ている可能性がある．そして抜けていくときまでPCOの推定に使われる可能性があるが，この時には-y方向からの情報のみしか得られない．ここでPCV誤差による残差が乗ってきて，PCO推定誤差となっていると考えられる．逆にxの推定精度が割といいのは，この衛星の動き方に関係してそう．

[ShingoNishimoto]

これに対する対応策として，

• イタレーションを掛けることで直るか
• ある程度推定できた段階で姿勢を90°回転させるか

などがありうるが，前者で解決できるといいな．

[ShingoNishimoto]

34 に引き継ぐ．

[ShingoNishimoto]

changed due date to December 31, 2022

[ShingoNishimoto]

初めから90度回転させて実施した場合もalong-track方向のずれが大きかったので，この考察は正しいと考えられる．この対策としてイタレーションを #34 で実施しているが改善はしていない．

この仮説を確かなものにするために途中から90°回転させて推定させるのは良いかもしれないが，普通にやると結局along-track方向に向けた軸の値が再度更新されてしまってその誤差がでかくなるというオチな気はする．こうならないようにalong-trackに置いてた軸以外は動かさないという制約を与えるとうまく行く？

[ShingoNishimoto]

PCOの初期誤差が波長以上あるとそもそもしんどいのかもしれない

L1の波長は19cmほどなので，このアンテナのPCO的には初期値をすべて0と置いていても波長以上になることはない．ので，この仮説は関係なさそう．ただ，ある程度近い値から始めないとうまく行かないというのはありそう．

[ShingoNishimoto]

ここで書かれている誤差の原因はPCVの誤差によるものが主だった．

[ShingoNishimoto]

おそらく↑で書いている仮説が正しい．衛星数を多く使えることに越したことはないので， #39 が実装できればch数を増やしてmultiにしているメリットを享受できると思われる．

[ShingoNishimoto]

34 で実施．

[ShingoNishimoto]

undefined

初期値をすべて0にして実施しなおすとある程度はうまく行った．なので，これまでは別の原因でうまく行ってなかっただけと考えられる．ただ，このアンテナのPCOサイズがそれほど大きくないというのもあるかもしれないので，わざと誤差を大きくした場合にどうなるかも見てみる．

-> 関係なく推定できたので初期値がどうなっているかによって結果が変わることはなさそう．

[ShingoNishimoto]

changed due date to January 08, 2023

[ShingoNishimoto]

PCOが推定できたとみなす閾値に関して

今は，適当に0.1mmとかにしていて，DDCPの残差のRMSが更新前も更新後もこの値以下になっているときには収束しているとみなしてfixしている．受信機の観測精度に依存するものなのでここはもう少し丁寧に議論すべきなきがする．

これってRMSで議論すべきなのかな？実は平均ですべきな気もする．そうすれば受信機の観測誤差に依存せずに評価することが可能．

[ShingoNishimoto]

平均で評価する場合，どれくらいの閾値にすべきか？

• 求めたい精度にすればいい気もする．mmオーダーを目指しているので，それくらい？その10%とかがいいのかな？→であれば今の設定0.1mmというのはあっている．

やっぱりRMSで評価した方がいいのかもと思い始めた．

• RMSで評価して，誤差が目標精度の10%以下になったら収束判定するというのでいい気がする．1%とかを目指してもそもそものGNSS受信機の観測ノイズに埋もれてしまうので満たせない．

[ShingoNishimoto]

平均ですると精度めっちゃ悪くなった．当たり前かもしれん．．．

• 各ずれは大きいけど平均0付近になるときをとってしまうため．

[ShingoNishimoto]

途中で90°回してするというのは，どう考えても現実的ではないし優先度低いのでissue登録だけして放置する． #41

[ShingoNishimoto]

一通り議論できて，別issueに切り分けたのでcloseする．

[ShingoNishimoto]

removed due date