2021.08.19 立松 郁也・島越 直人 株式会社 Mobility Technologies kaggle Outdoorコンペ振り返り

2 はじめに

3 自己紹介 ● 氏名 ○ 立松 郁也 ● 経歴 ○ 2017年3月　大学院入学 ■ ナーススケジューリング問題の研究 ○ 2019年4月 電機メーカー入社 ■ 需要予測モデル開発 ■ 最適在庫の分析 ○ 2021年3月　MoT入社 ■ DRIVE CHARTの分析業務 ● SNS ○ twitter : https://twitter.com/monnu0621 ○ kaggle : https://www.kaggle.com/fuumin621

4 自己紹介 ● 氏名 ○ 島越 直人 ● 経歴 ○ 2019年4月 DeNAに新卒入社 ■ お客様探索ナビ関連の開発 ○ 2020年4月 Mobility Technologies 出向 ■ アルゴリズムGでGO事業に関する幅広い業務 ● SNS ○ twitter : https://twitter.com/nt_4o54 ○ kaggle : https://www.kaggle.com/shimacos

5 本日の内容 kaggleのoutdoorコンペにshimacosさん含む4人チームで参加し6thでした。 本日はコンペの概要や解法について共有したいと思います。 shimacosさん祝GM🎉🎉 tatematsuはようやくmaster

6 項目 01｜コンペ概要 02｜公開カーネルの解法 03｜自チームの解法 参考｜上位陣の解法

7 01 コンペ概要

8 コンペ概要| コンペの目的 AndroidスマホのGNSSデータから位置情報を予測することが目的 ● 自動車に搭載したAndroidスマホで測定したGNSSデータを利用 （右画像参照） ● 得られたデータから位置情報(緯度、経度)を予測するコンペ ● 予測位置と真の位置の誤差が小さいほど良いスコア ● 成功すると例えば以下が嬉しい(コンペサイトより) ○ 車線レベルの位置情報の推定 ○ 位置情報を使ったゲームのUX向上 ○ 交通安全の問題の解決 https://www.kaggle.com/c/google-smartp hone-decimeter-challenge/overview

9 コンペ概要| 提供データ 大きく分けて予測に使うデータ３種類 + GroundTruth GNSSの生ログデータやホスト作成のbaseline予測などが与えられる ● 生GNSSログデータ ○ 各衛星から受信した生のGNSSログデータ ○ 扱うにはかなりのドメイン知識が必要 ● baseline予測 ○ ホストが生ログデータから算出した予測位置 ● 中間処理データ ○ 生ログデータからホストが作成した中間処理データ ○ 生ログデータよりは扱いやすい ● GroundTruth(trainのみ) ○ 正解の位置情報や速度情報

10 コンペ概要| 評価指標と提出形式 評価指標は予測位置と真の位置との距離が少ないほど良いスコア 評価指標 ● 予測位置と真の位置の距離誤差をすべてのスマホ,時刻にて算出 ● スマホごとに距離誤差の50%点および95%点の平均を算出 ● 全てのスマホでの上記の平均が最終的な評価指標 提出形式 ● 各スマホのtimestamp毎に緯度、経度を提出 sample submission

11 コンペ概要| コンペの特徴① 提供されるbaseline予測値が既にそこそこ高精度だった。 生ログデータを使うのではなく、baselineの後処理に注力する参加者がほとんどだった baselineが既に高精度 ※baseline_locations_train.csvの一部を描画 ● 運営が生のGNSSログデータから計算した baseline予測がそこそこ高精度 ● 自力で生のGNSSログからこれを超える予測 を求めるのがかなり大変 ● 多くの参加者がbaseline予測の後処理に注力 していた。

12 コンペ概要| コンペの特徴② 大きく分けて３種類のエリアが存在(参加者により分類の仕方は異なる) エリア毎に傾向や予測難易度が大きく異なる highway tree downtown baseline CV : 3.452 引用:https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/245160 baseline CV : 6.173 baseline CV : 19.43

13 02 公開カーネルの解法

14 公開カーネルの解法 | smoothing baseline予測をsmoothingすることにより精度改善するカーネルがいくつか公開された。 カルマンフィルタやgauss smoothing等が利用された。 ● カルマンフィルタ(KF) ○ Demonstration of the Kalman filter ● gauss smoothing ○ Adaptive_gauss+phone_mean KF前(CV:5.287 ) KF後(CV:4.551)

15 公開カーネルの解法 | スマホ間での予測の平均 同じ車両の別のスマホの予測位置も活用することで精度改善していた 同時刻のスマホ間で予測位置の平均をとり、その平均を予測位置とする 概要 ● こちらのカーネル等で公開された手法 ○ GSDC phones mean prediction ● 同じ車両に搭載した他のスマホの予測位置も活用することが狙い ● 同じ車両で同時刻のスマホにて、それぞれの予測位置を平均をとる。 ● スマホ毎に微妙に時刻にズレがあるため、線形補間することでより多くのスマホの 情報を使っていた

16 03 自チームの解法

17 自チームの解法 | 停止中のマルチパス対策 停止中ではマルチパスという現象の影響を受けやすく、精度が低下しやすい。 対策として停止中と予測される場合、付近の中央値で埋める等 マルチパスとは ● 建物の反射等により１つの衛星からの電波を複数回受信すること ● 位置推定の精度が低下する原因のひとつ ● 特に停止中はマルチパスが発生しやすいことが知られている 対策 ● 前後の時刻との距離などから速度を求め、しきい値以下(=停止 中)は付近の予測位置の中央値で埋める ● 速度をLightGBMで予測し、同様に停止中の区間を平均埋め https://www.septentrio.com/en/company/septentrio-gnss -technology/apme-multipath-mitigation-technology

18 自チームの解法 | 相対位置予測 Ground Truthに対する相対的な緯度、経度を予測することで、精度改善 特徴量は「付近のGroundTruthとの相対位置」や「同一時刻の他のスマホの情報」等 ねらい ● 真の位置との相対的な緯度、経度をMLで予測し、baselineを補正したい 概要 ● model : LightGBMでarea毎に相対緯度、経度を予測 ● CV : collection(車両)でGroupKFold 主な特徴量 ● 付近のGroudTruthの相対的な緯度、経度、距離 （trainではリーク防止のためその車両を除いて算出） ● 同じ時刻の他のスマホの相対的な緯度、経度等 ● 前後の時刻での相対的な緯度、経度等

19 自チームの解法 | 相対位置予測 LightGBMのFeatureImportanceを確認すると、 他のデバイスとの相対位置や付近のGroundTruthとの相対位置などが寄与度高かった LightGBMのFeatureImportanceの一例

20 自チームの解法 | ADRの活用 ADRを使うと相対距離が高精度で得られることが分かっていた。 GoogleのGNSSアプリを使うことでADRを取得し、予測に活用 AccumulatedDeltaRange(搬送波位相) ● 一般的に測位の方法として「擬似距離」による測位と「搬送波位相 (ADR)」による測位の２種類がある ● baselineは「擬似距離」による測位だが、「搬送波位相」の測位は 擬似距離」よりも相対位置が高精度に求まることが運営ヒントより 分かっていた (運営ヒントのnotebook) ● GNSSログデータからADRを求めることは困難だったが、Googleの アプリを使用することでADRを使った推定位置を取得 GoogleのGNSSアプリ

ADRの活用 ● Hatch filter (Carrier smoothing) ○ ADRの高精度な相対位置予測を利用して、予測位置を順にsmoothingする ○ forwardとbackwardの両方で行いaveragingすることでより改善幅増 ● アンサンブルの種 ○ 絶対位置予測の精度はADRはbaselineよりやや劣る ○ ただしbaselineとADRそれぞれを後処理し、アンサンブルすることでCV向上 21 自チームの解法 | ADRの活用 相対位置によるsmoothingやアンサンブルの種として活用し、精度向上 hatch filter algorithm

22 自チームの解法 | Snap To Grid downtownエリアではindoorコンペ等で使われたSnap To Gridが有効だった。 GroudTruthの位置情報を使い、付近の点にシフトさせる。 Snap to Gridとは ● indoorコンペでも使われた手法 ○ Indoor Navigation - "Snap to Grid" Post Processing ● 推定位置の候補として信頼できる点をGridPointとし、予測位置を最も近いGridPointへシ フトすることで精度向上を狙う(自分の理解) 本コンペでの活用法 ● downtownエリア は「精度が悪い」かつ「どれも似た経路を走行」という特徴があった ● 近くのGroundTruthをGridPointとしてSnap to Gridすると精度向上した

23 自チームの解法 | Snap To Grid 使用するGrid pointはGroundTruthとの距離含めて4つの評価指標を使い、加重平均で評価。 phoneごとに貪欲法を使って順にGrid pointを決定した。 ● 単純にやると最も近いGround TruthをGrid pointにするが、それをやると経路が飛んで しまう場合がある ● 直前との距離等を考慮して以下の4つの観点でGrid pointの候補を評価 ○ 予測位置とGrid pointとの距離をなるべく小さくする（最もシンプル） ○ 直前のGrid pointと予測位置までの距離は、予測された相対距離となるべく一致させる （LGBMによる速度予測を使用）。 ○ 前のGrid pointと予測位置の距離と次のGrid pointと予測位置の距離をなるべく一致 ○ 前のGrid pointで使った車両となるべく同じ車両を使う ● 上記4つの加重平均でコストを計算し、貪欲法で順にGrid pointを決定 ● リーク防止のためtrainデータは対象のパスを除いたGroundTruthのみ利用

24 自チームの解法 | Snap To Grid ground truthにsnap to gridすることでdowntownエリアのスコアは大きく改善 Snap to Grid前(CV:12.42 ) Snap to Grid後(CV:9.66 )

25 自チームの解法 | その他 downtownエリアがPrivateには1つしかないということがLB Probing から分かっていた ● downtownエリアは訓練データ内には多くある + baselineの精度が低いため、リソースを割き がちだが、downtownに限らない改善が重要だった。 ● ( downtownエリアの改善でLBを伸ばしていた人はshake downしたかもしれない) データの性質上、各処理でパラメータをarea毎にチューニングなどを行うと精度が伸び ることが期待されたが、スモールデータなので適当にやると訓練データやPublic LBに過 適合してしまう恐れがあった ● パラメータチューニングする際もKFoldで分割し、「訓練データに対して最小となるパラメータ を検証データにも用いた際に精度が改善していれば、テストデータにも用いる」など気を遣っ た。

26 まとめ ● 公開カーネル ○ smoothingや他デバイスの活用はシンプルだが強力だった ● 自チームの解法 ○ 停止中処理、相対位置予測、ADR、Snap to Gridなどで改善 ○ 特にADRによる高精度な相対位置は重要だった ● 実務への応用 ○ 特にMoTではautomotive領域でサービス展開しているので、位置推定で得た技術 や知見はどこかしら使えそう。 ○ 使える部分を見極めてプロダクトに活かしていきたい

27 参考 上位陣の解法

28 上位陣の解法 | 1st place solution ● 衛星の位置や速度・異常値などの複数の非線形な制約条件を同時に最適化 ● Switch Anchorと呼ばれる、そのFactorをどの程度使用するか決定する 0 - 1の変数も同 時に最適化している Factor Graph Optimization (gtsamというライブラリを使用)

29 上位陣の解法 | 1st place solution ● Accumulated Delta Rangeによる速度推定 (Doppler / ADR Factor) ○ Cycle slipなどでADRを用いることができない箇所は、ドップラーシフトから速度を 推定した ● 位相の二重差を用いた絶対位置の推定 (Pseudorange Factor) ○ 正確な位置が分かる基地局のデータを用いて、基地局の観測データと スマホの観測データの差分を取ることでマルチパス誤差以外の誤差を 無視することができる。 ● downtownのデータにはGround Truthを使った条件も追加 (Pseudo-Position Factor) Factor Graph Optimization に用いた重要な制約条件 https://www.maizuru-ct.ac.jp/civil/shikura/GPS/GPS7.pdf

30 上位陣の解法 | 2nd place solution 複数の処理を各パラメータを調整しながら行っている (ADR部分の貢献がでかい) ● 擬似距離をXGBoostを用いた巨大なモデルで 予測しているとことがユニークだが、 10-40 cm程度の貢献しかなかったらしい ● ドップラーシフトによる速度推定 ● Varianceの逆数で重み付けして、スマホ同士 の位置を平均 ● 停止部分の平均 ● ADRを用いて相対距離を算出し、それをスマホ ごとに平均した後、相対距離が描く軌跡に沿う ように予測結果をsnap ○ 弊チームと同じくアプリを使用して算出

31 上位陣の解法 | 3rd Place Solution 多くを語られていないため、詳細は不明だが Tensorflow を用いた最適化を行っている ● 他の上位者と同じくAccumulatedDeltaRangeを使用 ● ある時刻の擬似距離とその次の時刻の擬似距離は、ADRで推定されつ相対距離と以下のよ うな物理法則に則っていることを利用。 ○ 車両が静止している時は、衛星の移動のみがADRに反映される ○ 車両が動いてる時は、擬似距離の変化とADRの変化にbiasが生じる ● 上記のbiasと車両の位置を予測するパラメータとして、予測した位置から計算される相対 移動距離と観測された相対移動距離との差分をLossとして学習させる。 ○ ( ADRが取得できない場所でどうしているかは謎 )

32 上位陣の解法 | まとめ 上位陣の解法から見る上位に入るポイント ● 生ログを解析してbaselineを改善している参加者が上位にいる ○ ドメイン知識が必要だった ● AccumulatedDeltaRangeの活用 ○ 8位までのチームが使用していた ■ The only thing I could trust was ADR. Thank you so much, ADR. (1位のコメント) ○ 最適化に利用 ○ Smoothing ■ 擬似距離や推定結果に利用 ( Carrier Smoothing ) ● 機械学習はそこまで重要でない ○ スモールデータ かつ テストにしか存在しないデータがあるため、使い所を見極める