2026年01月の記事一覧 | Garage43 blog

GPSをアベレージラリーに使う話　その10

日曜日。またまた筑波に遠征です。今回は、土曜日に突然何度もジャンプした10HzのGNSS測位の対策です。GNSSの測位では、仰角15度以上が標準とされていて、実際に「公共測量作業規定」においても15度以上が基準となっているようです。仰角が低いと地上の反射物から反射した電波（マルチパス）を受信しやすく、測位誤差が出るからというのが大きな理由。今回GNSSが何度かジャンプしたのは、おそらくソーラーパネルなどの影響じゃないかと推察していますが、10HzのGNSS受信するためのアプリ「Drogger GPS」では、デフォルトで仰角15度以上を捕捉するように設定されています。が、おそらくそれでは足りなかったんだろうと思われたので、もう少し仰角を上げた状態で試してみることにしました。とはいえ、いくつまで仰角を上げればよいのか？あまり仰角を上げてしまって、測位する衛星の数が減り過ぎてしまっては、精度が低下することに繋がりそうです。そこで、測位しているGNSSをレーダーで確認します。円周の外側が仰角0度。中心が90度です。上のレーダーでは、仰角15度以下をカットしているので、15度よりも外側はグレーアウトされています。仰角を25度に設定します。レーダーで確認してみると、これくらいなら補足しているGNSSにもそれほど影響なさそうです。実際には、ラリー当日の衛星の位置によって角度を変えなければいけないと思いますが、今回はこれで試走してみます。で、結果をgpxファイルで見てみましょう。前日走行時の10Hzのデータが青、仰角補正した後が10Hzが緑のラインです。今回はジャンプしませんでした。もちろん、日にちが異なるのでGNSSの位置も異なりますから、これで解決したとは言い切れませんが、取りあえずはOKとしましょう。もっとも、カットする仰角を上げたことによって位置情報の精度が悪くなったら困るわけですが、一応、林道を走っている状態ではむしろ走行ライン（道路）に近づいている感じもします。むしろもっと仰角上げた方がいい！？調べてみると、山間部では仰角を30～40度まで上げた方が精度が上がるらしい。問題は実際にラリーを行う日のGNSSの位置がどうなっているか？ということですが、これについては衛星配置表示システムの「GNSS View」というのがありまして、緯度、経度、日時を指定するとその時の衛星の位置情報をレーダーで見ることができます。試しに開幕戦が行われる2/8の9:30、場所を伊勢崎に設定してみると、こんな感じです。仰角の設定もできます。現在は25度で設定していますが、これだとラリー中常にみちびきが3機捕捉できる状態です。しかし、仰角を30度に設定すると、10:30-11:30頃までみちびきが2機に減ってしまいます。あんまり上げ過ぎるのも良くないと思うので、どうしようか悩みどころですね。この試走時のgpxデータは、全てRally Tripmeter appの開発者と共有して、チャットでディスカッションしているのですが、「そもそもGPS測位に全く不向きなコースだ」と指摘されてしまいました。でもしょうがないじゃん、日本のアベレージラリーなんてこんなコースばかりだと思うんですよね。当然GPS測位の距離は±の誤差が大きくなってしまうので、ODチェックポイントでのキャリブレーションの意味もないとも言われました。ただ、オフィシャルのODの走行距離が本当の距離と同じなわけはないので、基準値を補正する意味でもキャリブレーションはやったほうが良いというのが私の考えです。ただし、できればスタートからODチェックポイントまでのコースの内、GNSSの電波が悪そうな部分は除外して計算した方が良いかもしれませんね。

GPSをアベレージラリーに使う話　その9

さて、土曜日に1Hzと10Hzの2つのサンプリングレートに設定した2つのRally Tripmeterを使って、実際にアベレージラリーのコースを走行してきました。前回までの走行で、10Hz化した方のRally TripmeterでGPS Hzが突然「Infinity」と表示されて更新されなくなってしまうという問題が発生していましたが、これについては先日アプリ側で修正したβ版をアップしてくれたので、その検証も兼ねてでございます。今回走行するのは、2025年の関東デイラリーシリーズ　第1戦で走った筑波山～土浦近辺のコースです。朝食を食べずに朝6時半に家を出て、下道で土浦方面へ。こんな時じゃないといけないと思っていたので、朝食にサンドイッチを食べようと、以前から行ってみたかった土浦の名店、「手作りサンドイッチ　つじや」さんへ。朝7時からオープンしていますが、到着したのは朝8時。昼頃にはほとんど売り切れてしまうと言われているお店ですが、流石にこの時間だと選び放題です。で、サンドイッチを大量に購入して、Stage 1スタート地点のつくば市ふれあいの里駐車場へ。準備が済んだら早速スタートです。Stage 1の設定は、1Hzも10Hzも基本的に同じで、両方ともAndroidの開発者向けオプション設定は・GNSS計測の完全実行を強制 onで、10Hzのみ「仮の現在地情報アプリを選択 → Drogger GPS」になっています。また、Rally Tripmeter appの設定では、両方とも「Legacy GPS provider」はoffにしているので、wifiやbluetoothなどの電波を使用して適宜補正が可能な状態です。10Hz化している方は精度が高いので、wifiやbluetoothなどの電波には頼らずに、単純にGPSのみで位置情報を決定するLegacy GPS providerをonにした方が良いと思うのですが、アプリの開発者的には、offにした方が良いかもって話だったので試してみることにします。今回はアベレージラリーのコースなので、コマ図間の距離が正確にアプリ上で表示されるか細かくチェックができるのが良い所。まずはODチェックポイントに向かいますが、なんかスタートした途端に2つのアプリの示す距離がどんどんずれていきます。しかも、コマ図毎に見ていると、どうも10Hzの方が大暴れしている感じです。GPS Accuracyは1Hzと比較して高いわけではないのですが、やはり山の中だと10Hzでも暴れますね・・・。（以下、青が10Hz、赤が1Hz、赤い矢印は進行方向です）でも、山を下りると綺麗に捕捉するようになります。ただ、どうも10Hzの方の距離が変な動きをしていて、突然距離が伸びたりするんです。今回もOBD2からのTripと比較しながら走っていますが、結構なズレ具合。「どうしてこんなにズレるんだろう、こんなんじゃあラリーでは使えないねぇ」なんて言いながら走っていたのですが、帰宅してgpxファイルを見てみると、なにやら突然ジャンプしています。アッチコッチで飛んでます・・・。そして林道に入ると、やっぱり1Hzも10Hzも走行ラインとは程遠い状態。続いてStage 2は、新治ショッピングセンターさん・あぴおの駐車場から、つくば市ふれあいの里に戻るコースです。Stage 2では、10HzのRally Tripmeterの設定のみ、Legacy GPS providerをonにして、GNSS測位のデータのみを使用するように変更しました。スタートして割とすぐ、信号待ちしている時に突然10Hzの方だけ走行距離が延びるという問題が発生。あとから見てみると、やはりStage 1と同様に突然ジャンプしています。その後もいろんなところでジャンプするのは変わりません。wifiなどによる補正が悪さしているのかと思ったのですが、Legacy GPS providerをonにしても変わらないので、この設定自体が悪さしているわけではなさそうです。で、この設定をonにしても、1Hzと10Hzの差は大きくて、林道でもやはり走行ラインをトレースするのは無理みたい。ただ、ここでちょっとだけ設定を弄ってみました。10HzでGNSSを測位するアプリ上の設定で、最低シグナルレベルを15dbHzから25dbHzに上げてみました。シグナルレベルが小さいものは位置測位の誤差に繋がるので切り捨てているんですが、その数値を高くすることで、より精度を上げようという試みです。それで何となく安定するようになった気もしますが、気のせいかも（笑）。そんな感じで、都合85km程走行してみたわけですが、とにかく10Hzが突然いろんなところでジャンプするのが気持ち悪くて仕方がありません。何が原因なのかなぁと思ってGoogleの地図や航空写真と睨めっこしていたのですが、どうもソーラーパネルや工事現場がある所でその影響を受けているような気がしてなりません。調べてみると、確かにソーラーパネルや機器の影響やでGNSS測位に影響があるのは間違いないようで、その影響を無くすため、通常GNSS測位では仰角15度未満のデータは除外するように設定するらしいです。10HzのGNSSを測位するためのアプリ、GPS Droggerでも、除外する仰角の設定項目があり、デフォルトでは15度に設定されています。ただ、ソーラーパネルと自車の位置関係（高度）によっては、15度では足りないケースがあるのかもしれません。という訳で、この除外する仰角をもう少し上げた状態で改めて同じコースを走ってみた方が良さそうだということになり、急遽日曜日も筑波に出かけることになったのでした。つづく。

開幕戦は2月8日です。

さてさて、いよいよ2月8日に開催される2026年関東デイラリーシリーズの開幕戦、ツール・ド・大山が迫ってきました。何やらヘリテージカーの展示もあるらしいです。先日エントリーも済ませて、スタートラインで行われるインタビュー用のコメントも提出しました。あとはこちらの準備がどんなもんかというところですが、先日来ゴチャゴチャ書いてるGNSS測位のアレコレについては、今朝アプリの開発者から連絡があって、「GPS Hz」が途中で「Infinity」と表示される問題ついて対策したβバージョンをGoogle Playに申請したとのこと。昼頃チェックしてみたら、アップされてました。今回は1Hzと10Hzの両方で測定した時のgpxファイルを共有して検証してもらっていましたが、10Hzの方が精度が高いことを認めてくれました。当初は精度アップのための10Hz化に懐疑的だったので、まずは一安心。これまでも親身になって色々と対応してくれましたが、これでこっちの優先度を上げてくれそうな感じです。同時に要望として出しておいた「Tripの1mオーダーでの表示」については、次回アップデートする時に設定項目の中に入れるとの回答がありました。理想はGNSS測位と、OBD2の車速データから算出した走行距離の両方を選べることですが、まずは1mオーダー化ですね。今回のβバージョンは急いで作ったので、先方で検証できていないとのことですので、今週末は予定通り検証走行です。先日はOBD2からの車速データを元にしたtripも参考として使用しましたが、アレもログを出力できることが分かったので、週末の検証後に開発者に送って、OBD2対応の説得材料にしようかな、と（魔笑）。

GPSをアベレージラリーに使う話　その8

さて、GNSS測位実測検証の2回目。前回はほぼ直線のバイパスを28kmほど走行して、以下の通りでした。OBD：22.28km1Hz：23.83km10Hz：22.29km1Hzの方が距離が伸びているのは、トンネルでGNSSをロストした後、トンネル出口で計測結果が暴れたから。この結果、平均速度やIdeal timeも10Hzと比較して大きな差が生まれました。さて、今回はその後の田舎道の走行です。ホントは林道が走れれば良いのですが、近隣にそのようなところが無いので、比較的速度の乗る山間の道や、小高い丘陵、古墳や城跡が多く存在するエリアでそれらの間や田んぼの側道などを走行してみました。（下記オレンジ色の部分が古墳や城跡群）gpxファイルを確認すると、このエリアに行くまでの道のりでは、10Hz（青）と比較してやはり1Hz（赤）の方が道を踏み外している所が多くありますが、信号待ちからのT字路左折では、こんな感じ。1Hzの方がアウトに膨らんでいますが、10Hzもインカットしていて完璧という訳ではないですね。この後、周囲が木に囲まれたエリアに入ると、10Hzの方も暴れだして、大胆なカットを行っています。ここは1Hzの方が道路に沿ってますね。さらに周囲を気に囲まれた細い道に入っていくと、道路をトレースできていません。左から右に向かって進んでいるところですが、この時車の左側は田んぼ、右側がちょうど城跡があるような台地になっていて、右側からの電波が届きにくい状態です。どうやら片側だけでも開けていれば、10Hzの方がきちんと測位するようです。しかし、ちょうどここを走っている時、ふとタブレットを見ると例の「Infinity」の文字が現れました。この時OBD2：10.69km1Hz：10.72km10Hz：10.59kmを指していました。Infinityを表示したのは、もう少し前だったのかもしれません。直線道路ではOBD2の方が計測距離が長い傾向にありましたが、この時点では1Hzの方が距離が伸びていて、10Hzの方はショートカットしているのか距離が短い感じです。そして、Ideal timeは20秒の差がついてしまいました。あとでgpxファイルを確認しても、やはり10Hzも大きく道を外しています。ただ、Infinityと表示されている状態であっても、距離と速度はちゃんと動いていて、しかも更新頻度も0.1秒刻みで問題なく動いているっぽい。とりあえずここで10Hzの方のTripを一旦リセットして改めて走行を続けます。走行中、画面を見ても問題なく計測は行っているようです。gpxファイルを確認しても、という感じで、やはり周囲が木々で囲まれると辛そうですが、1Hzの方よりは精度が高そうな感じ。で、20km程走行したので、ここで計測を終了しました。OBD2：20.15km1Hz：20.21km10Hz：19.99km（リセット後9.39km）奇跡的に、OBD2と比較すると、1Hzの方は+60m、10Hzの方は-60mという成績です。Ideal timeとの誤差は36秒の差がついてしまいました。こうなるとＣクラスでもペナ3が付くほどの大きな差です。原因はやはり走行距離と平均速度のズレですね。さて、ここで直線走行時の計測結果を元に、自車OBDに対する補正係数を計算してみると、1Hz：23.83/22.28=1.069610Hz：22.29/22.28＝1.0004田舎道走行時の結果を補正係数で割ってみると、1Hz：20.21/1.0696=18.8910Hz：19.99/1.0004=19.98田舎道走行時のOBD2の計測結果は19.99でしたから、やはり10Hzの方が正確だったという結果になります。ただ、1Hzの補正はトンネル通過後に数値が暴れたという問題があります。暴れる前の数値として、OBD2：22.02km1Hz：21.98km10Hz：21.97kmを利用して補正係数を出してみると、1Hz：21.98/22.02=0.9981810Hz：21.97/22.02=0.9977320.21/0.99818=20.246819.99/0.99773=20.0354なので、OBD2の示した20.15に近いのは1Hzの方ということになります。さて、今週末にはラリー前の最後のチェックとして、コマ図毎の補正をしていきながらどうなるのかチェックしてみたいと思います。

GPSをアベレージラリーに使う話　その7

終わったと見せかけて、もう少し続くよ、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.02km1Hz：21.98km10Hz：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.28km1Hz：23.83km10Hz：22.29kmなんと、1Hzの方が突然距離を1.6kmも伸ばしました。いったい何が起きたのか、帰宅してからgpxファイルを確認したところ・・・大暴れしてました（爆）という訳で、このバイパスが終点を迎えた時点で一旦計測をストップ。計測の結果は先程示した通りです。OBD：22.28km1Hz：23.83km10Hz：22.29km長くなったので、田舎道の方は次回。

GPSをアベレージラリーに使う話　その6

さて、Android用高精度外部GNSSユニットのDG-PRO1Sを利用して、10Hz化したタブレットを利用して、一般的な1HzのGNSS測位と比較走行をしてみたいと思います。2つを比較するだけだと、どちらが正しいのか分からないので、本来なら正確に「この区間の距離は〇.〇〇km」と判明している区間を走った上で、どちらのサンプリングレートで測位したほうが良いかを検討するのが良いのですが、10ｍ単位で正確な距離を表明しているコースが思いつかないので、基準として異なる測定方法で距離が判明しているドライブラリーのルートを使用することにします。というわけで、今回はSAQR番外編/ぐるグルドライブクイズ、SAQR17として公開されている埼玉県飯能を舞台とするドライブラリーのルートを走行してみました。助手席側のグローブBOX部分に10Hz化したタブレットを設置し、センターコンソールには1Hzのディスプレイオーディオ。スタート地点の段階で、10Hzの方がGPS Accuracy（GPS精度m）が1m、1Hzの方が3mとなっており、10Hzの方が精度が高いことが分かりますが、DG-PRO1Sを読み込んでいる専用アプリのDrogger GPSでもう少し細かい情報を見てみると、みちびきは1つしか即位していないものの、電波の強度は非常に良好。20の衛星を使用できています。また、測定精度は、水平方向に0.604m、垂直方向に1.027mとなっており、水平方向の精度が1Hzの3m前後と比較して1m未満と精度が高くなっていることが分かります。また、DOP（精度低下率）も、H（Horizontal）＝水平方向の精度低下率 : 0V（Vertical）: 垂直方向（高さ）の精度低下率 : 0P（Position）＝位置（3次元）の精度低下率 : 1.5と、いずれも低値（3.0以下が良好の指標）となっており良好です。気になるのは、タブレットの方が時間が8秒ほど遅れている点です。おそらくBluetooth接続による誤差なのではないかと思うのですが、移動に対して位置情報の反応が遅れているわけではないので、とりあえず無視します。さて、今回走る飯能のドライブラリーのコース、実際に開催されたのは2019年4月だったようですが、それから7年近い歳月が経ち、今回走ってみると、コマ図の目印となる看板が無くなってたり、場所が変わってたり、（おそらく）道路自体もレイアウトが変わっていたと思われ、オフィシャルが設定した距離と比較するのが非常に困難な状態となっていました。実際、ラリー中何度もコースをロストして元のCPに戻って測定しなおしたりを繰り返すことになり、クイズもできないものが色々出てきたので、途中でクイズ実施は断念しました。そんな状態でしたので、コース設定時と距離が変わっている可能性があることも留意が必要です。で、距離の計測結果は下記のようになりました。まず第一に、「10Hz化によって走行距離は伸びる」と予想していたのですが、全てのCPにおいて10Hzの方が距離が短いという計測結果になりました。これはホントに意外で、走りながらずっと首をかしげていました。なにせ、ほとんど直線ばかりのODチェックポイントまでの距離も、10Hzの方が短いのです。高サンプリングレート化によって正確な距離が出るのはコーナーの誤差が補正されるからですので、コーナーが多い方が差が大きくなると予想していました。が、直線ばかりでここまで差が出るか?しかも距離が伸びる方向に補正されると思っていたのですが、結果は逆。どうしてこのような結果になるのか色々考えましたが、やはりこれは測位精度の差の方が勝ったと考えるのが自然のような気がします。走行中、10Hzの方は常にAccuracyが1~3m、1Hzの方は2～5mと、明らかに10Hzの方が精度が高く表示されていると見受けました。つまり、10Hz化によってコーナー中の距離の精度が上がって走行距離が長く計測されたとしても、それ以上にGNSS受信精度によって距離が短めに計測された影響の方が大きかったということなのだろうと結論付けました。で、2つ目の問題は、オフィシャルとの誤差です。表を見れば明らかなように、全体的にオフィシャルの計測距離の方が長い傾向がありました。3CP～4CP間のみ我々の方が距離が長く出ているのですが、実はこの区間も4CPを探す際の目印が無くなっていて、2度ほど通り過ぎたため、計算で導き出したものなので、正確なものではありません。さて、そうなるとどうしてオフィシャルのものと比較して走行距離が短くなったのか？という問題になります。このままだと、オフィシャル > 1Hz > 10Hzということになり、1Hz測位の方が正確な（というか正解に近い）値を示したということになります。ドライブラリーの場合、CP間の距離を解答しますが、ここでの正解は「正確な距離」というよりも、「オフィシャルカーが示した（と思われる）距離」です。自車で走った時に示したtripを参考に、オフィシャルカーが測定した距離を答えるということですね。つまり、自車とオフィシャルカーのtripの差がどこから生まれたのか考える必要があります。ここで、逆転の発想で、「自車が10Hzで測位した距離が、本当の正しい距離である」としましょう。この場合、オフィシャルカーが実際の距離よりも長く走ったと誤認していることになります。そんなことあるんでしょうか？オフィシャルの車は、AE86レビンで、計測した時のタイヤは、サイズ：185/70R13種類：DUNLOP WINTERMAX（スタッドレスタイヤ） 6分山空気圧：前後2.1kg/cm2だそうです。AE86の純正タイヤは、185/60R14もしくは、185/70R13です。これらのタイヤの標準的な外径は、185/60R14：578mm185/70R13：589mmです。また、AE86のトリップメーターは、ミッションでのシャフトの回転数から算出する方式です。2つのタイヤサイズで外径におよそ1cmの差がありますが、これらのタイヤを使用して走行した時に、正しい距離、速度が出るようになっているはずです。一方、前述の通り今回のオフィシャルの車には、6分山の185/70R13サイズのWINTERMAXが装着されています。このサイズのWINTERMAXは外径が594ｍｍですので、半径94.6mmです。一般に、スタッドレスタイヤの溝の深さは10mmですので、6分山のタイヤということは、溝の深さは6mmになっているということです。つまり、半径は90.6mmになっているので、外径は569ｍｍになっています。外径578ｍｍ～589ｍｍのタイヤで正常なtrip表示ができている場合、タイヤの外径が569mmに下がっていたら、どうなるでしょうか？同じ距離を走るのにより多くのタイヤの回転が必要になるので、車のtripメーターが示す距離は実際の走行距離よりも長くなるのです。仮に578ｍmの夏タイヤと比較した場合で、101.6%、589mmのタイヤと比較した場合で103.5%も長い距離が表示されていることになります。つまりこういうことです。便宜的に、計算上で算出した13インチタイヤと14インチタイヤの夏タイヤ10分山の場合の平均値を正解とした場合と比較すると、なんとなく1Hzの方が正解に近い感じがしますね。こうやって見てみると、アベレージラリーの場合は時間換算になるし、コマ図毎に距離の補正ができるので、実は1Hzだろうが10Hzだろうがあんまり関係ないのではないかと思いますが、理論的には正確なのは10Hzの方のハズなので、とりあえず開幕戦は10Hzでの測位でチャレンジしてみたいところです。一方、ドライブラリーのラリークラスに参加するには、自車がGNSSで測位した距離が正確であると仮定した上で、オフィシャル車の測定距離に合わせるために、ODチェックポイントでの補正係数に加えて、タイヤなどの補正係数を算出し、自車の計測距離にそれらの係数を乗算して解答する方法を取る必要があります。それでも現状GNSS測位ではCP毎に現状数百メートル単位でオフィシャルとの誤差が出ていること、それをさらに補正してオフィシャルカーのtripを推算する論理的な計算手段が思いつきません。GNSS測位はやはりドライブラリーのラリークラスには不向きのような気がします。

GPSをアベレージラリーに使う話　その5

さて、少し間が空いてしまいましたが、GNSSの受信精度を上げるための取り組みとして、前回、下記2つの内、【GNSSの受信精度を上げる】1. 受信電波の強度を上げる2. 複数の周波数帯を受信する【GNSSの受信頻度を上げる】3. サンプリングレートを上げる 2を試してみましたが、見事に失敗しました。ということで、今回は3を行いたいと思います。以前にも書いた通り、スマホやタブレットを使用する限り、一般的にGNSSとの更新頻度は1Hzです。つまり、1秒間に一回GNSSと位置情報をやり取りしているということです。これをより高頻度にすることにより、例えばコーナー中の実際の走行ラインに沿った測位が可能になるため、距離の精度が上がるだろうということです。コーナー中のGNSS測位による誤差については、コチラに書いた通りですが、例えば、測位頻度を1Hzから10Hzにすることによって、そこから導き出される走行ラインは実際の走行ラインに非常に近くなるということは、下記の図からも分かる通りです。1Hzで測位した場合、その計測距離は実際の走行ライン（上図の点線）と比較して短くなりますが、10Hzにすればより点線に近いラインになるという訳です。じゃあ、どうやって10Hzにすれば良いんだ？ということなのですが、結論から言うと専用のBluetoothアンテナとアプリを使用します。という訳で、今回用意したのはBiz Stationが発売しているAndroid用高精度外部GNSSユニットの「DG-PRO1S」。サーキット走行などで走行ラインのログを取る時に使用するアイテムです。Androidのスマホを使っている方なら、「開発者モード」というのを聞いたことがあると思います。設定画面にある「ビルド番号」を7回タップすると現れるモードで、これを有効化するとAndroidのさまざまなウラ設定を弄ることができます。その中に、通常内部GPSを利用して測位する位置情報を、疑似的に他のアプリに委ねるように変更することができる項目があります。それが、この「仮の現在地情報アプリを選択」というもの。今回導入するGNSSユニットをBluetoothでAndroidに接続し、専用アプリのDrogger GPSでデータを読み込みつつ、その情報を位置情報として使用するように設定するんです。なお、アンテナ自体はモバイルバッテリーなどから電源を得て動作します。DG-PRO1Sは、最大10～18HzでGNSS測位を行うことが可能なので、移動時の位置情報がより正確になるというわけです。このアンテナを通常のGPSアンテナのように車のダッシュパネルやフロントガラスに貼り付けても良いのですが、公式サイトによると、より精度を上げるための設置の仕方というのがあるらしい。それが、「スチールやアルミ板で直径10cmのグランドプレーンを作成し、そこにL字型ステーを使ってアンテナを立てて設置する」というもの。という訳で、年末年始の間に工作。 1mm厚のアルミ板を買ってきて・・・丸く切り出したら、100円ショップで買ってきたアクリルケースをぶった切って、L字ステーに加工。両面テープでL字ステーを取り付けたら完成です。で、あとはディスプレイオーディオに専用アプリをインストールして、DG-PRO1Sを認識させればOKとなったのですが、ここでまさかの問題発生。ディスプレイ上でペアリングはできるのに、何故か専用アプリ上でアンテナにBluetooth接続できない。スマホやタブレットでは問題なく接続できるのですが、何故かディスプレイオーディオだけダメ。ディスプレイオーディオが対応していないBLE接続なのかと思って調べてみましたが、ペアリングはできるし、普通のBluetoothっぽいのに、何故かアプリ上で繋がらない。さて、困った・・・（涙）。色々調べたり、試行錯誤で冬休みが終わり、結局、タブレットなどでは問題なく繋がり、肝心のRally Tripmeterアプリ上でも10Hzで測位していることが分かったので、こうなったら関東デイラリーシリーズではディスプレイオーディオじゃなくて、タブレット使ってやりますか、と決断。んじゃ、折角だから10Hz測位のタブレットと、1Hz測位のディスプレイオーディオを同時に使用して、実際にどれくらいの誤差がでるのか走ってみましょう、ということになりました。つづく。

本日のDIY（自転車の空気入れの修理）

自転車に空気を入れようとしたら、空気入れが壊れた、と、ウチのかみさん。1,000円くらいの安い空気入れだった気がしますが、すっぽ抜けたらしい。すっぽ抜けた先端を見てみると、ネジが切ってあるので、どうやら何かが嵌まってたようなのですが、空気入れを何度も使っている内にクルクル回っちゃって外れちゃったんですな。写真だと分かりにくいですが、確かに中には何かが残っています。もう一度ピストン棒を差し込んで回してみたら、中に残っているパーツが上手く嵌まるんじゃないかと思いましたが、奥までピストン棒を押し込み切れないので、中に残っているパーツを掴み切れません。よくよく考えてみると、通常空気入れを使う時は、ピストン棒が抜けることはありません。ってことは、この先端のパーツがピストン棒が抜けるのを防いでいるはずなんですな。試しに回してみたら、取れました。この状態なら、中に残っているパーツを取り出すことができるんじゃないかと思い、本体を逆さにして地面に何度か叩きつけてみたところ・・・やはり出てきましたね。先端にゴムのパーツが付いていて、それで密閉した空気を圧縮する仕組みですね。順番を間違えないように、外したパーツをピストン棒に通しておいて、中に残っていたパーツをピストン棒の先端に嵌め込みます。あとは、ピストン棒を本体に入れて、ロック用のパーツを閉め込んだら修理完了です。