GPSラップタイマー「KLAP」の開発を始めてから、これまで数多くの失敗を経験してきました。
現在はGPSを使ったラップ計測や走行解析ができるようになったKLAPですが、最初から安定して動作していたわけではありません。
GPSモジュールの選定、1Hzと10Hzの違い、Bluetooth通信、バイク特有の電装ノイズ、ラップ判定のロジックなど、実際にサーキットで走行してみなければ分からなかった問題がいくつもありました。
この記事では、KLAPを実際に開発・走行テストする中で経験した失敗を5つ紹介します。
単に「失敗しました」で終わらせるのではなく、何が起きたのか、なぜ問題になったのか、そしてどのように改善したのかまでまとめました。
これからGPSラップタイマーを自作してみたい方や、10Hz GPS、外部GPS、GPS走行解析に興味がある方の参考になれば幸いです。
失敗① スマホ内蔵GPSだけで十分だと思っていた
KLAPの開発を始めた頃、私は、
「最近のスマートフォンならGPS性能も十分高いのではないか」
と考えていました。
スマートフォンにはGPSが内蔵されているため、専用のGPSモジュールを用意しなくてもラップタイマーを作れます。
実際に複数のGPSラップタイマーを試しながら、自分でもスマートフォンのGPSを利用して計測を行いました。
しかし、サーキットで実際に走行してみると、いくつか問題が見えてきました。
- ラップラインを通過しても判定されない
- 周回によって計測タイムがばらつく
- 実際の走行ラインとGPS上の軌跡がずれる
- 公式ポンダーなどの計測結果と差が出る
特にミニバイクのような比較的コンパクトなコースでは、GPSの位置誤差がラップ判定に影響しやすいことが分かりました。
GPSでは、実際にはラインを通過していても、取得された座標がラインの反対側に出てしまうことがあります。
そのため、
「GPSがある」＝「正確なラップ計測ができる」
とは限りません。
1Hz GPSでも改善できることがあった
ここで興味深かったのが、1Hz GPSでもプログラム側の工夫によって改善できる部分があったことです。
1Hz GPSでは1秒に1回程度しか位置情報を取得できません。
しかし、GPS座標だけを単純に比較するのではなく、直前の位置や移動方向などから次の通過位置を予測することで、ライン通過判定を補う方法を試しました。
この経験から、GPSラップタイマーの精度は、
GPSモジュールの性能だけで決まるわけではなく、取得したデータをどのように処理するかも重要
だと分かりました。
これが後にKLAPへ「予測通過」の考え方を取り入れるきっかけになりました。
失敗② 10Hz GPSなら何でも高精度だと思っていた
スマートフォン内蔵GPSだけでは限界があると感じた私は、次に外部GPSモジュールを使うことを考えました。
そこで注目したのが10Hz GPSです。
10Hzなら1秒間に10回程度の位置情報を取得できます。
1Hzよりも細かい間隔で位置を取得できるため、
「10Hz GPSにすれば、これですべて解決するだろう」
と考えていました。
ところが、実際に複数のGPSモジュールを試してみると、そう簡単ではありませんでした。
同じ10Hz対応をうたっているGPSモジュールでも、
- 走行ラインが大きくずれる
- GPSログ上でコース外を走っているように見える
- ラップラインの通過位置が安定しない
- 走行中に更新レートが安定しない
といった違いがありました。
「10Hz」という数字だけでは判断できない
GPSモジュールを比較していく中で分かったのは、更新レートだけを見てもGPSの性能は判断できないということです。
実際には、
- GPSチップ
- アンテナ
- 受信環境
- 測位処理
- 出力設定
- シリアル通信速度
- 省電力設定
など、複数の要素が関係します。
例えば、設定上は10Hzにできても、GPSチップ側の処理能力や設定によっては、安定して10Hzのデータを出力できないケースがあります。
また、MediaTek系のGPSモジュールでは、省電力に関係する設定によって動作状態が変わり、更新レートが下がったり、状況によってはGPS出力が止まったりする問題にも遭遇しました。
サーキット走行では、直線だけを一定速度で走るわけではありません。
加速、減速、低速コーナー、停止に近い状態など、GPSにとって条件が大きく変化します。
そのため、机上でGPSを動かしているだけでは分からない問題が、実走すると見えてきました。
この経験から、
「10Hz対応」というスペックだけでGPSモジュールを選んではいけない
と考えるようになりました。
KLAPでは、GPSモジュールの比較だけでなく、実際にバイクへ搭載して走行テストすることを重視しています。
失敗③ Bluetoothは簡単につながると思っていた
外部GPSやセンサー類をスマートフォンと接続するため、KLAPではBluetooth Low Energy（BLE）も利用しています。
開発を始めた頃は、
「Bluetoothならスマートフォンと接続するだけなので、それほど難しくないだろう」
と考えていました。
しかし、実際にバイクへ搭載すると予想以上に苦労しました。
開発中には、
- 接続できない
- 接続しても通信が安定しない
- 一度切断すると再接続できない
- エンジン始動後に通信状態が変化する
- 机上では正常なのに車両へ搭載すると不安定になる
といった問題を経験しました。
特に難しかったのが、エンジンが動いている状態と机上テストでは環境が大きく違うことです。
バイクでは点火系や電源系など、電子機器にとってノイズ源となるものが近くにあります。
そのため、
パソコンの机の上では正常
↓
バイクへ搭載
↓
エンジン始動
↓
通信が不安定
という現象が発生しました。
電子工作では「動いた」だけでは不十分
この経験から、電子工作では、
「回路が動いた」ことと「実際の車両で安定して動く」ことは別
だと学びました。
配線、電源、アース、ノイズ対策、通信処理などを見直し、実車環境で確認する必要があります。
KLAPの開発では、この経験が後のバイク電装ノイズ対策やESP32を利用したモジュール開発にもつながっています。
失敗④ ピットでラップを誤計測してしまった
GPSラップタイマーを作る上で、最も分かりやすく、そして重要だった失敗の一つがラップの誤計測です。
開発初期のKLAPでは、
「GPS座標がスタートラインを通過したらラップ」
という比較的単純な判定からスタートしました。
ところが、実際のサーキットではそれだけでは不十分でした。
例えば、
- ピットロードを通過する
- ピット付近でGPS位置がずれる
- コースアウトする
- 低速走行する
- 停車中にGPS位置が移動する
- 同じライン付近を短時間に複数回通過する
といった状況が発生します。
その結果、本来は1周なのに2回カウントされるなど、ラップタイマーとしては致命的な問題が発生しました。
「ラインの近くにいる」だけでは判定できない
ここで考え方を変えました。
単純に、GPS座標がラインの近くにあるだけで判定するのではなく、
- 走行方向
- GPS位置の変化
- ラインに対する移動方向
などを組み合わせて判定するようにしました。
KLAPでは、二重計測を防ぐため、逆走などによる誤判定を減らすための方向判定などを実装しています。
この部分は、GPSラップタイマーを実際にサーキットで使ったからこそ見つかった問題でした。
失敗⑤ GPSだけ見ていればいいと思っていた
KLAPの開発当初は、
「正確なラップタイムが表示できれば、それで十分」
と考えていました。
しかし、自分でサーキットを走って使ってみると、次第に別の問題に気付きました。
例えば
「前回より0.3秒速かった」
ことは分かっても、
「なぜ0.3秒速くなったのか？」
まではラップタイムだけでは分かりません。
逆にタイムが悪かった場合も、
「どこでタイムを失ったのか？」
が分からなければ、次の走行に活かすことができません。
そこでKLAPでは、ラップタイムを記録するだけでなく、
- GPXログ保存
- 走行ライン表示
- セクタータイム
- 速度情報
- 走行データの解析
など、走行後にデータを振り返るための機能を追加していきました。
その結果、KLAPは単純なラップタイマーから、走行データを確認するためのツールへと少しずつ発展していきました。
この流れから開発したのが、GPXデータを利用して走行ラインや速度差などを確認できる「KLAP Analyzer」です。
開発して分かったこと
ここまでの失敗をまとめると、次の5つになります。
| 失敗 | 分かったこと |
|---|---|
| スマホGPSだけで十分だと思った | GPSの測位誤差と更新頻度を考える必要がある |
| 10Hzなら何でも高精度だと思った | GPSチップ・アンテナ・設定なども重要 |
| Bluetoothは簡単だと思った | 実車では電源・ノイズ・通信環境が変わる |
| GPSラインだけでラップ判定した | 方向や時間など複数条件が必要 |
| ラップタイムだけで十分だと思った | 走行解析まで行うと改善につながる |
実走テストをして初めて分かったこと
机上で正常に動くことと、サーキットで使えることは違う
ということです。
パソコンにつないでGPSデータが取得できても、実際にバイクへ搭載して走行すると別の問題が発生します。
例えば、
GPSの位置が一時的にずれる。
↓
ラップラインの判定が不安定になる。
↓
判定条件を変更する。
↓
今度は別の場所で誤判定する。
↓
実走する。
↓
また問題が見つかる。
KLAPはこの繰り返しで少しずつ改善してきました。
だからこそ、現在も実際の走行環境で確認することを大切にしています。
GPSラップタイマーは「GPSをつなぐだけ」ではなかった
開発を始める前は、GPSラップタイマーは、GPSから位置情報を取得して、ラインを通過したらタイムを計測する。
という比較的単純な仕組みだと思っていました。
しかし実際には、
GPS
＋
更新レート
＋
GPSモジュールの性能
＋
通信
＋
電源・ノイズ
＋
ラップ判定ロジック
＋
走行解析
という複数の要素を組み合わせる必要がありました。
そして、それぞれの問題は実際に走行してみなければ分からないことも多くありました。
まとめ
スマートフォンのGPSだけで十分だと思ったこと。
10Hz GPSなら何でも高精度だと思ったこと。
Bluetooth通信で苦労したこと。
ピット付近でラップを誤計測したこと。
そして、ラップタイムだけでは走行改善につながらないと気付いたこと。
これらはすべて、実際に作って、バイクへ搭載して、サーキットで走行したからこそ分かったことです。
KLAPは現在も開発を続けています。
今後も実走テストを行いながら、GPSの精度、ラップ判定、走行解析などを改善していく予定です。
この記事では失敗した内容を中心に紹介しましたが、それぞれの問題については、別の記事でより詳しく解説しています。
GPSモジュールの選び方、1Hzと10Hzの違い、GPSのラップ判定、GPXによる走行解析などについても、実際の開発・検証結果をもとに紹介しています。
Kfactoryでは、これからも「実際に作る・走る・測る・改善する」を繰り返しながら、GPSラップタイマー「KLAP」の開発記録を公開していきます。
0 件のコメント:
コメントを投稿