「コースのどこにいるか」を、GPSの点だけで決めない¶
テックノート No.9
勾配ナビは、「この先、上り5パーセント、300メートル」と、坂の手前で知らせる機能です。先回りして知らせるには、今いる場所が地図のどこか、ではなく、登録したコースの、始点から何メートルの地点かを知っている必要があります。この記事では、その「コース上の位置」を、Dailythm Runがどう決めているかを紹介します。
9-1. 「いちばん近い点」では足りない¶
まず思いつくのは、今のGPSの位置にいちばん近い、コース上の点を探す方法です。道が1本で、同じ場所を通らないコースなら、これでうまくいきます。
ところが、次のようなコースでは取り違えが起きます。
- 八の字のように、コースが途中で交差する
- 同じ周回コースを何周も走る（1周目の坂と2周目の坂は、同じ場所にあります）
- 往復で、同じ道を行って戻る
交差点の真ん中では、2本の道は同じ距離にあります。GPSには数メートルのぶれがあるので、どちらが「近い」かは、ぶれ方しだいで入れ替わります。すると、アプリは「いま上り坂の途中」から「あと数百メートルで上り坂」へ、突然飛んでしまいます。勾配ナビで致命的なのは、間違ったタイミングで、間違った坂を知らせてしまうことです。
どのくらい起きるのか¶
実際にどれくらい起きるのかを、作り物のコースで確かめました。全長約1,050 mの八の字（中央で直角に交差）を、秒速3 m（1 km 5分33秒ペース）で3周走り、1秒ごとの測位にGPSのぶれ（正規分布、標準偏差4 m）を加えた走行を、乱数を変えて20回ぶん作りました（合計約2万回の測位）。
| 方法 | コース上の位置を40 m以上取り違えた割合 |
|---|---|
| いちばん近い点だけで決める | 約1.3%（約75回に1回） |
| Dailythm Runの方法（次節） | 0%（最大の誤差は約23 m） |
1.3%は小さく見えますが、取り違えは交差の付近に集中し（交差の40 m以内の測位では、約8.5%）、取り違えたときのずれは、数百メートルにもなります。交差を通るたびに、1割弱の確率で別の地点に飛ぶ、ということです。
9-2. 3つの手がかりを組み合わせる¶
そこで、Dailythm Runは、GPSの点の「近さ」だけでなく、次の3つを組み合わせて、コース上の位置を決めています。
① 走った距離で、位置を前へ進める。 アプリは、GPSの記録から、走った距離を数えています。コース上の位置は、前回の位置に、その間に走った距離を足した付近のはずです。つまり、GPSの点を見る前に「今はこのあたりのはず」という予測があります。
② 探す範囲を、予測の前後に絞る。 「いちばん近い点」は、コース全体ではなく、予測した位置の前後だけから探します（初期値は前後50 m）。交差の反対側の枝は、コース上では数百メートル離れているので、探す範囲に入りません。同じ場所を何周もする場合も、同じです。
③ 進んでいる向きを見る。 GPSの直近の動きから、進んでいる向きを求め、コースの向きと比べます。向きが大きく違う候補は、点数を下げます（初期値は、45度を超えた分から）。
3つの手がかりは、互いの弱点を補います。①の距離は、GPSの位置が飛んでも影響を受けません。②は、予測が外れていなければ、取り違えを防ぎます。③は、予測が少しずれたときに、すれ違う逆向きの道や、近くを通る別の道との区別を助けます。
地図照合という考え方
GPSの点を道路や線路などの地図に合わせる処理は、地図照合（マップマッチング） と呼ばれ、カーナビなどで古くから研究されています。点の近さだけでなく、前後の点とのつながりや、移動の整合性を使う点は同じ考え方です 1。Dailythm Runの方法は、それよりずっと単純な、「走った距離で予測して、近くだけを探す」という実装です。
9-3. はじまりと、外れと、戻り¶
追跡には、「始める」「外れる」「戻る」という場面があり、それぞれで、取り違えを避ける工夫をしています。
始めるとき。 走り出した場所は、コースの途中かもしれません。この段階では予測がないので、コース全体から、近くて向きの合う点を探します。ただし、1回合っただけでは決めません。約30 m進む間、「進んだ距離と合う場所」が続いて見つかったときに、はじめて追跡を始めます。一瞬だけ近くを通った、別の道に引きずられないためです。
外れたとき。 ルートからの距離が許容範囲（初期値30 mに、GPSの精度を足したもの）を超えた状態が、5回続いたときに「外れた」とします。1〜2回のGPSのはね上がりでは、外れにしません（作り物の走行で、3秒だけ80 mずれる場面を入れて、外れにならないことを確かめています）。外れている間も、走った距離で予測の位置は進め続けます。
戻ったとき。 外れている間は、コース全体から、近くて向きの合う点を探し直し、予測にいちばん近い候補を選びます。始めるときと同じく、進んだ距離と合って、3回続いたときに「戻った」とします。
逆走。 コースと、ほぼ逆向き（135度を超える）の候補は、どの場面でも除きます。このため、コースを逆向きに走ると、外れとして扱われます。
GPSのぶれによる後戻り。 位置は、前へ進む向きにだけ更新します。ぶれのせいで、位置がわずかに戻って見えても、動かしません。これで、坂の「手前」を通ったのに、何度も知らせてしまう、ということを防ぎます。
9-4. 周回は、一周で「巻き戻る」¶
周回コースは、始点と終点が同じ場所です。位置を「始点からの距離」で表すと、終点（たとえば1,400 m）のすぐ先は、始点（0 m）です。そこで、周回コースの位置は、コースの長さで一周するものとして扱い、差を測るときは、近いほうの向きで測ります（1,390 mと10 mの差は、1,380 mではなく20 mです）。
周回数は、追跡を始めてから前へ進んだ合計の距離から数えます。このため、何周でも続けて数えられます（作り物の長方形コースで、3.8周ぶん走って、2周目・3周目・4周目と数えられることを確かめています）。
9-5. 試してわかったこと、うまくいかなかったこと¶
上の八の字の走行で、GPSのぶれを大きくして、同じ確認を繰り返しました。
| GPSのぶれ（標準偏差） | 追跡している割合 | 追跡中に、40 m以上の取り違え | 追跡を始めるまでに走った距離（中央値） |
|---|---|---|---|
| 4 m | 100% | 0% | 33 m（最大84 m） |
| 8 m | 97.9% | 0.015% | 177 m（最大537 m。30回中1回は600 mまで始められず） |
| 15 m | 4.0% | （追跡できた時間が短く、比べられません） | ほぼ始められない |
- ぶれが4 mのときは、始めるまでの距離も短く、取り違えもありませんでした
- ぶれが8 mになると、取り違えはほぼ出ませんが、追跡を始めるまでに時間がかかります。始めるときは、向きの合う点が3回続かないと決めないため、ぶれが大きいと、なかなか決まらないのです
- ぶれが15 mでは、ほとんど始められませんでした。これは「間違えるより、決めない」という選び方の裏返しです
つまり、この方法は、間違った位置で知らせるよりも、位置が決まるまで黙っているほうに倒してあります。勾配ナビでは、知らせないことより、間違って知らせることのほうが、走りを乱すと考えたためです。
9-6. 限界¶
- ここでの数字は、作り物のコースに、正規分布のぶれを加えた走行で測ったものです。実際のGPSの誤差は、高いビルのそばなどで、特定の方向に偏ったり、数十秒続いたりするので、同じ数字になるとは限りません。実際の走行での判定の細かさは、これからも調整していきます
- 交差する角度がとても小さいコースや、2本のルートが許容距離より近くを並んで通るコースでは、向きでも距離でも区別しにくく、場所を取り違えることがあります
- 位置を前へ進める①は、アプリが数える走行距離に頼っています。予測は、測位のたびに、見つかった位置で置き直すので、距離の誤差はたまりません。一方、外れている間は、走った距離だけで予測を進めるため、長く外れると予測がずれ、戻るときの候補選びに響きます
- 登録したルート以外の道（枝道）に入ると、外れとして扱われます
- 標高は、地形のデータの値です。高架や橋の上でも、路面の高さではなく、下の地面の標高になります
9-7. 設定との関係¶
この記事の考え方に出てきた数字の多くは、設定の「音声ガイド」の中の「コースガイド」で変えられます。
| この記事の内容 | 設定の項目 |
|---|---|
| 外れと見なす距離 | ルートからの許容距離 |
| 外れと判定する、続けて離れた回数 | 外れと判定する連続回数 |
| 向きの許容 | 進行方向の許容 |
| 予測の前後で探す範囲 | 探す範囲（予測位置の前後） |
「外れた」の誤判定が多いときは、許容距離を広げるか、連続回数を増やしてみてください。
9-8. 関連ページ¶
- マイコースと勾配ナビ — 使い方と、細かい設定
- 音声ガイド（記録中の読み上げ）
- GPSのノイズとどう戦うか — 記録の距離を数えるときの、GPSのぶれへの対処
-
Newson P, Krumm J. Hidden Markov map matching through noise and sparseness. Proc. 17th ACM SIGSPATIAL Int. Conf. on Advances in Geographic Information Systems. 2009: 336-343. doi:10.1145/1653771.1653818 ↩