RTK22のメインは、M9Nの速度を積分して、２５Hzの位置補間をするテーマとなってますが、
「速度を積分して変位を得る」方法についての精度がどのくらいかを検証してみました。
今回その１として、F9P単独で速度を積分して変位値を計算した場合と、F9P緯度経度からの変位値と比較して精度を検証してみました。結果として、基準として緯度経度からの変位にしたのですが、実は、緯度経度からの変位は、近似式でしか出ないので、正確な
変位にならないため、緯度方向変位と経度方向の変位で誤差が全然違ってしまいました。これでは、数％で変位誤差を求める計測にならないので、システムを作り直すことにしました。スキーシーズンまで２か月しかないので、STA22のシステム作りを始めないといけなので、速度積分機能を含めてSTA22のシステムでM9Nの精度確認を含むという方針でいきます。松本から長野へ引っ越しとサイトの整備で開発活動ができなかったので、６か月の空白を埋める形で頑張ります。
●STA22新システムの特徴は
①基線長解析で、変位精度を0.1mm分解能まで向上させる。
基線長解析については、以前の記事に解説してます。
②M9N速度積分機能追加で、F9Pの１０Hzデータを25Hzデータで補間して、ターンの高速化対応します。
これまでの開発成果として、M9Nローパスフィルタ、F9Pと同期のために120msec周期で統一します。F９P-F９Hシステムを使う
③スキーのベンドセンサの初搭載します。右スキーだけでも、ひずみゲージ式のベンドセンサを使います。
右スキーだけF9P-F9Pのシステムにして、Lengthとスキーのたわみもみます。
④実装用で３Dプリンタで実装ケースを作成しようと思います。上記①②③が優先ですが、余裕がでたらやります。
⑤実験測定フィールドの変更
この２年間は、小谷村の白馬コルチナスキー場でしたが、２０２２からは、長野市の飯縄リゾートスキー場にします。新実験サイトから３０分の距離となりますので、測定実験の回数が飛躍的に増えますので、開発が進む見込みです。
●F9PのLon,Lat,gSpeed,velN,velEの関係をグラフで比較してみました。
①測定データ
ロードバイクで、信州スカイパークの北部を周回走行したデータを使います。
縦４２１ｍｘ横３４７ｍの範囲を周回走行して、3ｋｍｈ～２８ｋｍｈで走ってます。
見たいポイントを拡大して、元データを見ながら考察できるツールになってます。２か月かけて制作しました。
②データ処理方法
ログデータ：マイコンTeensy4.1で、F9PとM9NのPVTを受信ログして、速度データを同期補間します。
周期がF9P10Hz(100msec) M9N25Hz(40msec)と合わないので、最小公倍数の20msecで
直線補間して、データを送信してPCに取り込んでます。全とログはSDカードで保存してます。
Teensy4.1のソース：
PC上Pgm処理：上記データで１７０００行もあるので、Excelで積分処理すると重くなって、仕事になりません。
そこで、C#のグラフィックプログラム内で、各種処理を行って、軽くしてからExcelに渡します。
このグラフィックプログラムは、走行データ全体を眺めながら、観察したい部分を詳細に拡大して、データを考察できるように各種機能をプログラムしてあります。
C＃のソース：https://gist.github.com/dj1711572002/0a1a2229cd87fd46b5eeef33edd0b214
処理１：M9Nの速度ノイズをローパスフィルターで平滑化
処理２：20msec単位で台形積分計算します。線形補間してあるので、20msec積分ｘ５個で100msecのＦ９Ｐの台形積分値と同値になります。20msecだと変位が小さい（5-15cm/20msec)ですが、積分単位時間が長くなると誤差が大きくなりますが、%で見れば、同じになります。
処理３：上記フィルター、積分処理した計算値をDataGridViewに書き込んで、ＣＳＶファイルで出力してExcelで読み込みます。
処理４：Excelで、各データ列を使ったグラフを作成して、観察します。
Excelが１万７千行あるので、セル内で台形積分するとメモリー不足で重くて使えないので、別プログラムで積分処理してから、Excelに渡す方法がスムーズです。
③結果グラフ
Ａ：F9P測位変位とgSpeed積分変位の比較
測位変位は、latとlonの変位ベクトルの長さとしてます。
（latとlonを距離に変換するのは簡易的に１．１倍しているだけですので、本当の距離ではありませんが、比率で比較しているので、 傾向がわかります。１２月以降、STA本システムで、基線長ベースのシステムにしますので、その時に高精度で測定します。
結果A１：左半分の1-6000data範囲で相関％の乱れ大きい。
結果A２：速度変化が急な部分で相関が落ちる。
結果A３：速度が10cm/20msec(5m/sec_18kmh)以上で相関が良くなる傾向。
結果A４：相関がフラットな範囲でも±１０％くらいのばらつきがみられる。
B：F9P_gSpeed値とvelN-velE合成ベクトル値の比較
F９P内部で、velNとvelE、velDからgSpeedを演算していると思うのですが、単純な処理はしてないと思いますので関係を検証しました。
結果B1:速度3000mm/sec以上の範囲なら、gSpeedとvelN-velE合成ベクトル長の値は一致する。
結果B2:合成ベクトル値のばらつきがどうしても大きくなる。
C：F9P測位N軸lat変位とvelN積分変位の比較
latから距離変位への変換は、簡易的に1.1倍しているだけなので、比率で相関だけをみてます。
結果C1：速度変動が急な部分で、相関がわるくなる。
結果C2：左半分1-6000data範囲で、相関が全体的に悪い。
結果C3：相関が安定している範囲内でも位置精度相関は、±10％以内でばらついている。
D：F9P測位E軸lon変位とvelE積分変位の比較
上記N方向と同様のE方向をみたのですが、随分悪化してました。これが何故なのかを追求していく必要があります。
結果D1:E軸では、全体的に相関が悪い。
結果D2:速度範囲がN方向より小さいのが原因なのか、コースXYグラフを見ながら考察する必要あり。
E：F9P velN積分とvelE積分の相関の違い考察
結果E1：上記N軸、E軸でのグラフをならべて観察した。
F:XYグラフのコース図から上記のデータ範囲を観察
観察F1：1-3000data範囲の走行グラフをみると、ここは、スタートしたばかりで、速度が２０ｋｍｈ以下でした。
観察F2：白い点は、ニュートラルポイントで、headMotの方角の変曲点ですので、カーブとかハンドルをふらつかせているときにでます。それが、１－３０００dataでは、多く発生してます。スキーではきれいにターン間に１か所しかでないのですが、自転車のハンドルにアンテナをつけているので、ころころでます。
観察F3:3000-6000data範囲では、２０－２４ｋｍｈまで速度が上がっていて、1-3000dataよりは相関がよくなってきてます。
観察F4：6000-9000data範囲で6400-6900data範囲でE軸相関が飛んでしまっているので、みてみると真北に進んでいる範囲です。
gSpeedは17kmhですが、E方向の速度が2-3cm/20msec(1m/sec_3.6kmh)と歩いているような速度になっている場合が相関が悪いといえそうです。しかし、グラフAでの6400-6900data範囲では、相関は良好なので、ベクトルとして相関をみたほうがいいのではないかと思います。速度が遅いベクトル成分の相関が悪くても、合成した場合の相関がよくなれば、いいのです、成分で比較しないで、
gSpeedとheadMotで位置を計算したほうがいいかもしれません。
観察G：lonlat-gSpeed積分値の比較で１２０％以上誤差が発生している走行軌跡を追ってみました。
発生個所は、E方向に走行している場合です。E成分が多いと誤差が増えます。これは、特徴的なのは、lon値を１．１倍しているのが
問題ではないかと思います。緯度経度から変位を求めるのは、すべて近似式になるので、精度的に数％の誤差を判定するには、適しませんので、基線長解析データをもとに、変位比較しないとダメな感じです。
●考察結果
１：F９P単独でも、速度を積分して変位としてみる場合、測位位置の精度と大きく異なる場合があることが分かった。
主な原因は、速度が遅い10kmh以下の範囲で、速度ベクトル成分の誤差が大きくでる点とみられる。
GPSドップラの原理からしても、速度が遅いとドップラの差異がノイズと区別がつかなくなるので、一般には30kmh以上と
いわれている通りだと思います。
２：今回は、位置精度の基準を緯度経度にしましたが、緯度経度を変位に変換する計算が１．１倍しているだけなのが、間違いで
緯度は、１．１倍で合ってますが、経度は１．１倍だと違ってました。Hubeney式でやれば少しは、よくなるとおもいますが、
所詮近似計算なので、誤差を数％まで求めるには、計算自体で１０％くらい誤差がでる方法では無理なので、
測定システムを緯度経度から基線長から変位を求める方法に改良していきます。
