Slide 1

Slide 1 text

#IoTLT札幌 スマホの路線バス・トラッキング
 におけるGPS情報との戦い 山川広人 (@gishi_yama)
 公立千歳科学技術大学 情報システム工学科 Javaエンジニアグループ北海道 Java Do 1

Slide 2

Slide 2 text

#IoTLT札幌 公立千歳科学技術大学 情報システム工学科 専任講師 R&D: Experimental Development of ICT (ex:City-Bus Tacking System) 
 Computer in Education, Programming and Programmer's Learning 
 
 Community: Hiroto Yamakawa, @gishi_yama 2

Slide 3

Slide 3 text

#IoTLT札幌 大学の研究チームがコア部分(車両からのGPS取得、発着判定、遅れの計算、データモデル等)を担当 千歳市バスロケーションシステム:ち~なび(開発:2015, 2016) 3 • 市内全路線、3事業者の
 路線バス⾞両の位置と
 運⾏遅れを取得 • スマートフォン/PCの地図や
 デジタルサイネージに反映
 
 
 
 画面イメージ内の地図データ © 2017 ZENRIN CO., LTD.

Slide 4

Slide 4 text

#IoTLT札幌 システム構成 4 Data
 base Web
 APP 発着判定
 遅れ検知 バス⾞両
 GPS情報 スマートフォン・PC サイネージ バス事業者・市役所 運⾏情報 交番情報 路線情報 運転⼠の負担を抑える
 GPS取得の半⾃動化 複数のバス事業者の
 運⾏ダイヤと
 ⾞両GPS情報による
 運⾏遅れの算出 4 いわゆる
 スマートフォン型
 バスロケーションシステム ※最近は
   シングルボードコンピュータ
   を使う流れが良い感じ?

Slide 5

Slide 5 text

#IoTLT札幌 この発表では、このシステムの開発で起こった
 GPSにまつわる課題とその解決法について 共有したい 5

Slide 6

Slide 6 text

#IoTLT札幌 〈おことわり〉 
 2016年頃の技術・機材ベースの苦労話なので、
 (準天頂衛星みちびき第1号すら打ち上げ前)
 「いまはもっとこうできるよ!」的なのもあるはず なんとかするための情報募集中です 6

Slide 7

Slide 7 text

#IoTLT札幌 • 開発要員は「GPSや地理情報の素人」のWebシステム開発経験者(1名)と学生
 ⇒ 基板とかモジュールをなんとかしてくれる人、トラッキングの経験者・専門家もいない
 ⇒ スマートフォンとブラウザのGeolocation APIでなんとかする • 「運転士が乗車業務中にスマホを操作をしないこと」
 ⇒ 「理想は1回も触らないように」といわれる(無理難題)
 ⇒ ノータッチは不可能なので、なんとか1日1回、乗車時に限って操作することに。
    ※運転士が選んだスケジュール(交番表ダイヤ)とGPSデータで同定しつづける • 開発費は、わずか。
 ⇒ 技術検証・プロトタイプ開発からはじめ、うまくいったらそのまま使うパターン 開発時の絶対要件(戦いのはじまり) 7

Slide 8

Slide 8 text

#IoTLT札幌 1. とりあえず、精度を検証する。 価格帯、OS等でいくつかのスマホを用意。
 (1万円以下のAndroid、1〜3万円程度のAndroid, それ以上のiPhone) 2. バスの後ろを自家用車でついて行って
 Geolocation APIで取得したGPSの
 緯度軽度をプロット、想定誤差を測定  ⇒だいたい値段に精度が伴う
  載ってるGNSSチップの違いと判断し、
  当時の機種で複数のGPS(3in1GPS)
  に対応するチップを乗せたスマホを選択
  (Qualcomm IZat Gen8C) 戦い①:スマホ+Geolocation APIで十分なGPS情報をどう取得するか? 8 地図データ © OpenStreetMap contributors under ODbL 1万円以下の
 Android 1〜3万円程度の
 Android ※2019年現在では、+みちびき(QZSS)対応のスマホが良いと思う

Slide 9

Slide 9 text

#IoTLT札幌 GPSをとれるようにして、停留所の座標も登録して、トラッキング開始!
 ⇒ バスの位置はとれるが、「停留所前をバスが通過した判定」のトラッキングミス頻発...! ⇒  運行遅れが発生した際の、折り返し路線のガード条件が十分ではなかった 戦い②:その場でGPSを取得することと、トラッキングの違い 9 バス停の重複が ない路線は、
 遅れがあっても
 だいたい発着の
 判定は成功 折り返しが存在する
 路線で、遅れが大きく なると、復路の停留所 の発着をとりちがい ? ? プログラム上で対処できる話なので、停留所の通過順を考慮したガード条件を整備
 (停留所を即通過してしまった時にすり抜けないように、いくつかあり得る候補だけに絞る) ※始発後すぐに終着と判定され、運転士の運行スケジュールの同定も崩れる
 ※運転士は運行中触らないルールで、問題発生時の手動リセットも無理 注:GPSとの戦いというより、条件の想定漏れの感も

Slide 10

Slide 10 text

#IoTLT札幌 ガード条件も直して、トラッキング開始!
  ⇒たまに、画面上でバスのマークが動いていないといわれる  ⇒散発的に、Geolocation APIが、一定時間GPSを更新できていない問題が発生 戦い③:GPS(Geolocation API)の更新異常 10 約20分、GPSが同じ場所の
 緯度経度を示す(右表黄色部分)
 ※実際のバス車両は正しく移動している ここでGPSが正常化するが、
 赤線の部分の停留所は発着も
 記録できないままになる !

Slide 11

Slide 11 text

#IoTLT札幌 2017年10月頃、2019年2月頃からそれぞれ急増し高止まり 戦い③:GPS(Geolocation API)の更新異常 11 本格運用開始 2017年10月より増 2019年2月から急増 ! ※2分間以上、更新異常が続いたもの。多いときで、1台あたり1日36回も発生している計算に。

Slide 12

Slide 12 text

#IoTLT札幌 〈不具合の外観〉 • geolocation.watchPosition()が非同期に緯度経度を更新しない(とても時間がかかる) • 端末ごとの発生数には偏りはありそうだが、どの端末・どの路線地域でも散発的に発生する • 更新異常の事象数は
 2017年10月頃、2019年2月頃に急増し高止まり⇒ 〈原因の推測と対応策の考察〉 • 機種は統一しているので、機種依存?経年劣化? • APIコールをTimeoutなどでリトライした方がよい? • システムや手法に大きな更新はしていない...
 GPSシステムの何らかの変更が影響している? ⇒ DGPSの停波? GPS週数ロールオーバー? 課題③ GPS(Geolocation API)の更新異常 はまだ未解決... 12 2017/11月(9月)の情報。偶然だとは思うが... 注:どちらもスマホへの影響を示す情報はない...

Slide 13

Slide 13 text

#IoTLT札幌 1. スマホできるだけ正確なGPSトラッキングを行うには、利用するスマホのGPSチップ
 (受け入れ可能なGNSS信号)を確認した方がよい 2. 路線バスの様な、チェックポイントの通過等をトラッキングの機能に組み込むためには、
 通過パターンなどのガード条件を確認する 3. GPSの取得自体にエラーが発生すると苦しい...
 特に2019年春から謎の習得エラーが頻発している
 (GPSモジュールを搭載した回路を組んだ方が何が起こってるかわかりやすそう) まとめ 13 後日、解決編に続く...?

Slide 14

Slide 14 text

#IoTLT札幌 • 中村嘉明,溝上章志(2017), όスロケーションシステムの導入・運用の実態と課題, 第 55 回土木計画学研究発表会・講演集, pp.1-7 (2017) • 千歳市バスロケーションシステム「ち〜なび」, https://info.chi-navi.net • ダイヤ編成支援システム「その筋屋」@Sujiya_System 2017年11月8日のツイート,
  https://twitter.com/Sujiya_System/status/928013851978813441 • 「To Be Continued」素材ジェネレーター,
 https://comic-mode.com/useful/detail/257#midashi 参考文献 14