Garage43 blog

終わったと見せかけて、もう少し続くよ、GPS測位の話。


飯能を走っていた時、GNSS測位のサンプリングレートを10Hzに設定していたタブレットの表示がおかしくなりました。






っ！！！







サンプリングレートを表示している部分、数字こそパラパラとかなりの速度で変化しているものの、基本的にずっと10Hz以上を表示していたんです。

それが、突然「Infinity」になりました。


無限ですかっ∞！？

なんだか良く分からないけど、普通じゃないのは確かです。

測位の段階で何かエラーが出たのは間違いない。



このままでは安心してラリーに使用することができません。



帰宅した後、どのようなことが考えられるかGeminiに訊いてみたところ、

「GNSS測位（GPSなど）のサンプリングレートが「Infinity（無限大）」やそれに類する表示（「MAX」「Raw」など）になる主な理由は、データ収集がリアルタイムな定周期更新ではなく、機器の最高性能で連続して信号を取り続ける設定（スタティック測量や生データ記録）になっているためです。」

とな。

この表示になった後は、それまでのように数字が表示されることはなく、一度アプリを閉じないと復旧しない状態でした。

特に問題なければよいと思ったのですが、気になったのでアプリの開発者にチャットしました。

先方はエストニアなので、返信にはいつも半日待たされますが、いつもサポーティブな対応をしてくださるのでホントに助かってます。

で、「可能性があるのは、使っている外部GPSデバイスが、時々位置情報更新を前回と同じタイムスタンプで出力しているのではないか？」ということでした。

同じタイムスタンプが続くと、2つの連続更新の時差がゼロになるので、「無限」と処理されてしまうとのこと。

10Hzということは、単純計算で0.1秒毎の更新ということになります。

普通であればタイムスタンプが2つ連続で同じ数値を示すことはあり得ないと思いましたが、例えば、受信機が0.01オーダーで出力したものを、アプリ側で0.1オーダーに変換する場合、四捨五入などをしたら小数点第1位が揃ってしまうことはあり得るかな？と思いました。

という訳で、今度はDG-PRO1Sのメーカーのサポートに問い合わせてみました。

すると、

「同じタイムスタンプが連続することはあり得ない。受信機はミリセカンド単位で出力し、これをアプリ側でナノセカンドにしている。むしろGNSS測位に失敗した時に、ラリコンアプリ側でのゲート処理がエラーを起こしているのではないか？」

とのこと。
なるほど、そういう処理をしているのなら、四捨五入なんてことは起こらないので、受信機や専用アプリDrogger GPS側でのエラーではないということですね。

一応、その情報をRally Tripmeterの開発者に報告したのですが、すると、「そもそもなんでサンプリングレートを上げたいの？」と。

そこで、「可能な限り車が走行したラインをトレースして距離を算出したいんだ」と回答したのでした。
合わせて、「GNSSじゃなくて、OBD2アダプタを介して車からTripデータを読み込むのが一番だと思ってる」とも伝えました。


先日ブログを書いた後、MATさんから「OBD2アダプタのtripデータが使えたら一番いいですね」というようなコメントをいただきましたが、実はおっしゃる通りなのです。

関東デイラリーシリーズのクラス分けでは、OBD2からデータを取ることで、ラリコンと同じ扱いになるのですが、現在私が参戦しているクラスＣは「ラリコンでも、そうじゃなくても（GPS測位）でもどちらでもよい」というクラスなので、影響はありません。

で、実はラリコンアプリでOBD2のデータを使うものがないか？と言えば、実はあるんですよ。

それが、Android appの「Reg.Mate」というアプリ。

無料版はGPS測位なのですが、有料版を使えばOBD2アダプタからのデータをTripに活用することができるようになります。

料金も3,800円と、そこまでお高くありません。確か買い切りだったハズ。

ただこのアプリ、とても使いにくいんです（涙）。

事前にセクション毎の距離と指定速度を保存しておいて、ラリースタートと同時にそれを再生させ、理論値との差を掲示してくれるというのは、現在私が使用しているRally Tripmeterと共通なのですが、

途中でTripの補正やリセットができないし、一度スタートしてしまったら途中のCPやパスコンでの速度変更指示にも対応できません。


今使っているRally Tripmeterは、当初CPなどでの速度変更指示に対応していませんでしたが、開発者にお願いして改良してもらったという経緯があります（一応、βテスターをやってます）。

なので、Rally TripmeterがOBD2アダプタ対応してくれたらいいなぁ・・・というのが密かな願いです（笑）。

一応、Infinity問題は修正してくれるようなのですが、現在別の開発案件で立て込んでるので、もう少し待ってくれってことでした。




さて、そうなると、自分にできることは何かないかな？という訳で、本日再びテスト走行に行ってきました。

今回はOBD2アダプタからTrip情報をぶっこ抜いて、それとも比較してみようかなと。

そうそう遠方までいけないので、今回は比較的近場で直線主体のコースと、田舎道の2通りを走ってみました。


前回同様、左のタブレットが10Hz、センターのディスプレイオーディオが1Hzです。
その上にスマホでOBD2からのデータとして速度とTripを表示しています。







まずはほぼ直線で交通量がそれほど多くない制限速度70km/hの片側2車線バイパスを走ります。

赤が1Hz、青が10Hzですが、直線だと比較的2つの線が重なっていますが、







1Hzの方はたまに道路から外れたりしています。







道路の下をくぐる時に、意図的に車線変更（左→右→左→右）とかやってみましたが、10Hzの方はしっかり追従している印象です。





また、下の写真の位置では、

OBD：22.02km
1Hz：21.98km
10Hz：21.97km

と、OBDのTripの方が若干距離が出ている感じですが、1Hzと10Hzでは10mの差となっています。







この差はそれほど大きくないと思うのですが、ここで気になるのは平均時速が0.1km/h異なること。

画面を見ていると、1Hzの方は速度計が1秒毎に切り替わりますが、10Hzの方は0.1秒毎に速度の数字が切り替わりますので、非常にシームレスに動いている印象です。

その影響からか、平均速度にも違いが出ているんです。
平均速度の0.1km/hって、結構大きな差なんですよね。

それを表すのが、それぞれの画面左側にあるIdeal Time（理論値との誤差）の表示。

どちらも「Slow Down」の表示が出ていますが、これは予め設定しておいた距離と指定速度から導き出される理論値に対して、「今いる場所は早すぎるから速度落とせ」ということです。

もちろんどちらのデバイスも同じ距離と速度を設定しています。


で、問題はどれくらい速度を落とせばよいかということなのですが、

10Hzの方は「25分20秒分減速しろ」と言っているのに対し、1Hzの方は「25分24秒分減速しろ」と言っています。

その差4秒。

アベレージラリーでは通常1秒1ペナ。

私が参加しているCクラスは10秒1ペナですので、4秒差は許容範囲ですが、通常ならペナを食らうことになります。

直線を20km程度走っているだけで4秒のペナ食らうって、結構痛いですよね。

今回はOBD2アダプタとの差での係数補正なども行っていませんので、実際には補正したらどちらも同じような値を示す可能性もありますが、これはちょっと気になる状態です。




なお、この直線道路の最後の最後、トンネルの中で渋滞するという事態が発生しました。


当然、どちらもGNSSを完全にロストしました。







トンネルにいる間はどちらも動きませんでしたが、停止している画面に差が出ました。

1Hzの方はトンネルの中で渋滞している間、速度は0km/hでしたが、10Hzの方はトンネルに入る直前の速度が表示されたまま止まっていました。

この状態がトンネル出口にどれだけ影響するのか気になりましたが、1つめのトンネルの時は特に大きな問題はなし。



ただし、2つ目のトンネルを抜けた時事件は起こりました。







OBD：22.28km
1Hz：23.83km
10Hz：22.29km

なんと、1Hzの方が突然距離を1.6kmも伸ばしました。

いったい何が起きたのか、帰宅してからgpxファイルを確認したところ・・・















大暴れしてました（爆）





という訳で、このバイパスが終点を迎えた時点で一旦計測をストップ。
計測の結果は先程示した通りです。

OBD：22.28km
1Hz：23.83km
10Hz：22.29km


長くなったので、田舎道の方は次回。