歩行でのFix落ち、根が深そうなので４年前に戻って、MovingBaseの基本構成に戻して、バー式ＭＢを作って
手持ちで振り回して、Fix落ちとＩＭＵ値の関係を実験することにしました。
４年前との違いは、IMUと同期させて測定できる点と、位置精度が０．１mm分解能になっている点
データが統計的に管理できるようになっている点で、より正確に現象を把握できるようになってきてます。
●基本構成
①配線のノイズ除去
・Baseのケース、Roverのケースをしっかりと棒にねじ止め
・ＲＴＣＭ３通信線は、短くして、片ＧＮＤシールドにして、揺れないようにケースで抑える
・アンテナ線、電源線ともにテープでしっかり止めて、揺動でずれないようにした
②アンテナを基準のUblox MB00に戻す
ヘリカルアンテナとパッチアンテナでは、パッチのほうがゲインがあ３．５ｄBとヘリカルの２ｄBより良いので
今回は、パッチをつけてみました。後日、全条件評価が終わってから、パッチからヘリカルに替えてみます。
④BaseLine
VCBLでなく６２ｃｍ間隔まで広げてあります。以前からＭｏｖｉｎｇＢａｓｅの評価では、５０ｃｍ以上
１ｍ以下で使ってきました。
⑤MovingBase設定条件
Ardusimple社のFW1.32用ＭＢ設定ファイルを120msec周期で駆動してます。
これは、IMUの周期20～40msecと同期させるためです。
Ardusimpleの設定ファイルでは、Baseの出力が元々なかったのですが、私の設定では、BaseのUART2のＯＵＴからＵＢＸを出力してます。これによって、NTRIPの基線長測定ができるような仕様になってます。
●初期実験 ＝＞実験の条件と水準が決まってないので、様子見してみました
庭から道端まで出ると視界が良くなる場所があるので、そこで、バーを振り回してみました。
左右水平と上下をまぜて適当に振り回してログしました。
ログは、ＰＣを手持ちだと邪魔なので、タブレットの自前ログソフトでログしました。
左手で、タブレットをもってFｉｘ具合を観察しながら右手のバーを持って振り回します。
①振り回した軌跡
Rover座標で、プロットするとBaseが原点になるので、判り易いです。実際はBaseも併進していますので絶対座標でプロットすると回ましているのがわかりにくいです。
②Ｆｉｘ率
このデータでBaseのFix率は、95%でしたが、RoverのFix率が６５％と悪かったです。
③時系列で、Ｆｉｘ落ちと各パラメータの関連をみたグラフ
手で振りながらタブレットをリアルタイムに眺めているとどうも、勢いよく振った直後に
ガタっとFix落ちが発生してました。そこで、IMUのLinear加速度（重力加速度を除外してある加速度のlaX,laY,laZをsqrt(laX^2+laY^2+laZ^2)とトータル加速度としてプロットに
加えてみました。Gを１００倍してプロットしてあります。
うすい青：トータル加速度
黄土色：Fix値(flagsR) 131がFixで６７以下がNORTK
濃い青：Rover Ｎ座標
茶：Rover Ｅ座標
灰：Rover Ｄ高さ
FIX ＯＫな領域を黄土色の四角で囲ってあります。
結果１：トータルGがある一定以上の領域で、FIXが落ちがみられる傾向があるが一概ではない。
＝＞一旦落ちると落ち癖がつくというかすぐ落ちやすくなる感じがあります。
結果２：D方向の動きが大きい場合にFIX落ちしやすい傾向がありそう。
結果３：Gが上がらないような動きなら、速い動きでもFIXは正常である。
●考察と推定
０：BaseがFix率良い理由
Baseは、NTRIPからのRTCM3を受信して、RTK計算しますが、NTRIPからのデータ周期が１秒前後と遅いのでそんなに忙しくないからNORTKになりにくいとおもいます。それに比べRoverがBaseから受信するRTCM3は
120msec周期で４６０８００ｂｐｓで入ってくるのでRoverの計算負荷はＢａｓｅの何倍も多いと思います。
１：加速度が大きいと変位量が多くなるので、RoverのRTK計算の負荷が大きくなって、周期内に処理ができなくて NORTK（６７以下）になるのではないかと想定すると、RTK計算処理を軽減してあげればNORTKが減るのではないかと想定して、下記対策を試す。
１－１：周期を120mseから遅くする（200msec等）に落として計算時間に余裕をとる
１－２：データ出力が115200bpsなので、460800bpsにして、出力する時間を節減して計算時間を稼ぐ
１－３：RoverにF9Pを使っているが、単機能のF9HでHeading角だけ計算するチップに変更
１－４：RoverがSimpleRTK2B liteですが、たまにファームが壊れておかしくなっている場合もあるので
新しくファームと設定ファイルを入れなおしてみるのも可能性としてはあるかもしれません。
２：スキー滑走では、通常のFIX率は、９０％以上確保できているので、あまり激しい動きをしてないからだと思われます。モーグルとか激しい滑りをすれば、ダメになることは想像できます。
Ｆ９Ｐのような遅いチップは、遅い現象用ということかなと思います。IMUでも性能の悪いチップと同様なことが言えると思います。とすれば、高性能のSeptentrioのＭＯＳＡＩＣチップなら、歩行でもきちんと計測できるのか試してみたいですが。１粒１０万円のチップは、なかなか手が届きませんので、別の補間方法を考えます。
3:グランドプレーンつけてなかった
パッチアンテナでもグランドプレーンは必須なので今回つけてなかったので次回から付けます。
●以後
IMU値が役立ちますので、RTK諸データとIMU値を比較しながらFix落ちを解析していきます。
Fix率は、ハード、ソフトが絡んだ結果として得られる値なので、原因を求めるのが大変手間がかかります。
RTK計算負荷を定量化できれば、上記推定が定量化できるので、調べてみます。
