ドライブレコーダの動画を使った道路情報の自動差分抽出

自動運転時代には、今よりも更新頻度の高い地図が必要です。MoTでは大手地図会社であるゼンリンとの共同開発により、ドライブレコーダの動画を元に道路情報の差分を自動で抽出し、地図更新に役立てるプロジェクトを行っています。このプロジェクトを紹介します。

技術的な紹介ポイントとしては、次のものになります。マップマッチ、機械学習（ディープラーニング）、SLAMそしてGISツール等を組み合わせた高度なアプリケーション。大量の動画データに対して分散処理するために、AWS FSx for LustreやAWS Batchを用いてシステムを構成。計算コストの高い機械学習推論処理を最適化する工夫。データサイエンティストの成果物を本番に取り込むためのフレームワーク。

Transcript

1. ドライブレコーダの動画を使った
   道路情報の自動差分抽出
   Mobility Technologies
   渡部徹太郎
   

   View Slide

2. アジェンダ
   1. DRIVE CHARTの紹介
   2. 道路情報の自動差分抽出プロジェクト
   3. 5つの工夫
   4. まとめ
   2
   

   View Slide

3. 自己紹介
   ID ：fetaro
   名前：渡部 徹太郎
   学生：東京工業大学でデータベースと情報検索の研究 (@日本データベース学会)
   職歴：
   * 野村総合研究所(NRI)
   - オンライントレードシステム基盤
   - オープンソース技術部隊
   * リクルートテクノロジーズ
   - ビッグデータ分析基盤
   * Mobility Technologies
   - データエンジニア
   エディタ：emacs派→ IntelliJ派
   趣味：麻雀、自宅サーバ
   日本AWSユーザ会
   (JAWS)
   著書
   3
   

   View Slide

4. １．DRIVE CHARTの紹介
   4
   

   View Slide

5. Mobility Technologiesの事業
   1. 配⾞関連事業
   2. 広告決済事業
   3. 乗務員向け
   ソリューション事業
   4. DRIVE CHART
   ・ドラレコ事業
   5. 次世代向けR&D事業
   5
   

   View Slide

6. DRIVE CHARTの紹介
   6
   タクシーやトラックなど商用車に向けた、
   AI活用の交通事故削減支援サービス『DRIVE CHART』
   

   View Slide

7. ２．道路情報の自動差分抽出プロジェクト
   7
   

   View Slide

8. プロジェクトの概要
   ● 課題
   ○ 自動運転時代においては、地図の更新頻度を上げる必要が
   ある
   ○ しかし、更新頻度をあげる為には、作業の効率化が必要
   ● 解決策
   ○ DRIVE CHARTを搭載した車両を動くセンサーとして道路
   の情報を収集する
   ○ 収集した情報を元に自動的に道路情報の差分を見つけ、地
   図会社に提供する
   ● ゼンリン社と共同開発。２０２０年４月にプレスリリース
   1 ヶ月で走行した道路
   （ ２３区＋三鷹市＋武蔵野市）
   8
   

   View Slide

9. システムの概要
   ドライブ
   レコーダ
   車両位置の特定
   道路上の物体を検出
   車両センサー
   ゼンリン社
   に提供
   物体位置の
   推定
   地図との
   差分抽出
   NEW
   地図
   9
   

   View Slide

10. 車両位置の特定 - マップマッチ
    GPSで記録された位置 マップマッチした位置
    道路リンク
    利用技術(1/4)
    10
    

    View Slide

11. 道路上物体を検出 – 機械学習
    利用技術(2/4)
    11
    

    View Slide

12. 12
    道路上物体を検出 – 機械学習
    利用技術(2/4)
    

    View Slide

13. 正確な位置を推定 – SLAMの利用
    利用技術(3/4)
    13
    

    View Slide

14. 地図との差分抽出 ー 地理情報技術
    14
    利用技術(4/4)
    による地理情報操作
    +
    SELECT *
    FROM map
    WHERE
    ST_Contains (area ,
    ST_Geogpoint( 139.7424, 35.6561)
    )
    

    View Slide

15. DRIVE CHART
    システム構成図
    マップ
    マッチ
    動画取得
    道路計算
    位置
    位置格納
    動画格納
    物体検出
    位置
    推定
    物体
    差分判定
    地図
    差分判定結果
    動画
    AWS Batch
    S3
    Lambda
    Lambda
    TypeScript
    CI / CD
    15
    by
    分析・開発
    

    View Slide

16. 3．5つの工夫
    16
    

    View Slide

17. システム構成図
    17
    5つの工夫は
    ここの話！
    DRIVE CHART
    システム構成図
    マップ
    マッチ
    動画取得
    道路計算
    位置
    位置格納
    動画格納
    物体検出
    位置
    推定
    物体
    差分判定
    地図
    差分判定結果
    動画
    AWS Batch
    S3
    Lambda
    Lambda
    TypeScript
    CI / CD
    17
    by
    分析・開発
    

    View Slide

18. 5つの工夫
    1. 動画キャッシュファイルシステム
    2. 分散処理サービスの選定
    3. ジョブのオーケストレーション
    4. 仮想マシン選定
    5. 開発フレームワーク
    18
    

    View Slide

19. 動画キャッシュファイルシステム(1/2)
    19
    標識検出ワーカ
    信号検出ワーカ
    停止線検出ワーカ
    動画
    ストレージ
    S3
    ダウンロード
    ダウンロード
    ダウンロード
    ● やりたいこと
    ○ 同じ動画に対して、複数のワーカーで異なった物体認識処理をする
    ● 問題点
    ○ ワーカ毎に同じ動画をローカルにダウンロードする必要がある
    

    View Slide

20. ● 解決策
    ○ FSx for Lustreを使うことにより、S3からのダウンロードを１回にでき、
    システム全体のIOスループットを向上できる
    動画キャッシュファイルシステム(2/2)
    20
    S3 標識検出ワーカー
    信号検出ワーカー
    停止線検出
    ワーカー
    FSx for
    Lustre
    動画
    ストレージ
    動画
    キャッシュ
    初回アクセス時に
    S3からダウンロード
    以後はS3から
    ダウンロード不要
    

    View Slide

21. 分散処理サービスの選定 (1/4）
    ● 典型的な機械学習推論のワークロードはこんな感じだが
    21
    推論
    処理
    S3
    推論
    処理
    {label = "猫"}
    S3
    {label = "犬"}
    ・・・
    ・・・
    

    View Slide

22. 分散処理サービスの選定 (2/4)
    ● 物体検出は典型的な機械学習推論のワークロードではない
    22
    フ
    レ
    ｜
    ム
    間
    追
    跡
    処
    理
    す
    る
    動
    画
    の
    検
    索
    状態
    管理
    DB
    結
    果
    格
    納
    メ
    モ
    リ
    上
    で
    画
    像
    に
    分
    解
    不
    要
    な
    画
    像
    の
    フ
    ィ
    ル
    タ
    物
    体
    検
    出
    自由度の高いカスタムコンテナが必要
    FSx for
    Lustre
    

    View Slide

23. 分散処理サービスの選定 (3/4)
    ● カスタムコンテナの分散バッチ実行環境の選択肢は４つある
    23
    SageMaker
    batch transform jobs
    + カスタムコンテナ
    AWS Batch ECS EKS
    概要 機械学習の推論サービス。
    それをカスタムコンテナで
    動かす
    コンテナベースのバッチを動
    かすサービス
    汎用コンテナ実行環境。
    オンラインもバッチもできる。
    Kubernetesベースの汎用コ
    ンテナ環境。
    運用 インスタンス管理不要 インスタンス管理不要 GPUを使う場合は、Fargate
    が使えず、インスタンスの管
    理が必要
    Kubernetesの学習コストが
    高い
    開発・運用工数：小
    制約：強
    開発・運用工数：大
    制約：弱
    運用工数のかかるECSとEKSは外した
    

    View Slide

24. 分散処理サービスの選定 (4/4)
    SageMaker batch transform jobs
    + カスタムコンテナ
    比較 AWS Batch
    並列実行
    の制御
    △
    ・自動で入力データの分割可能
    →DBを検索して処理対象を選ぶ必要があるため、今回は利用できない
    ＝ △
    ・自前で開発が必要
    推論処理
    の実装
    ×
    ・システム構成が複雑
    ・HTTPの推論エンドポイント公開が必要だが、推論の入力には使わない。
    ・ファイルシステムの利用ができない。
    < △
    ・システム構成がシンプル
    ・ファイルシステムが利用できる
    推論コンテナ
    SagaMeker batch transform jobs
    推論コンテナ
    ダミー
    入力
    S3
    推論の
    入力
    HTTP
    HTTP 推論コンテナ
    推論コンテナ
    AWS Batch
    ファイルシステム
    推論の
    入力
    24
    SageMakerのフレームワークを活用できないため、AWS Batchを選択した
    S3
    

    View Slide

25. ジョブのオーケストレーション(1/2)
    ● やりたいこと
    ○ 車両からくる約５分のデータ毎に物体認識と位置推定を行いたい
    ○ 物体認識と位置推定は順序関係があるため、それを表現したい
    ○ 物体認識はGPUマシン、位置推定はCPU(※)マシンで動かしたい
    25
    標識
    検出2
    位置
    推定2
    信号
    検出2
    停止線
    検出2
    標識
    検出1
    位置
    推定1
    信号
    検出1
    停止線
    検出1
    0:00~0:05の処理 0:05~0:10の処理
    ・・・
    on
    CPU
    on
    GPU
    on
    CPU
    on
    GPU
    ※)SLAMの内部で行っている最適化計
    算がGPUの並列処理に向かないため、
    CPUの計算となる
    

    View Slide

26. ジョブのオーケストレーション(2/2)
    AWS Batchのdependencyを用いて順序を制御
    GPU
    ジョブ
    キュー
    CPU
    ジョブ
    キュー
    GPUマシン
    AWS Batch
    Compute
    Environment
    CPUマシン
    AWS Batch
    API
    CPUマシン
    CPUマシン
    …
    GPUマシン
    …
    GPUマシン
    標識
    検出2
    位置
    推定2
    信号
    検出2
    停止線
    検出2
    ジョブ
    標識
    検出1
    位置
    推定1
    信号
    検出1
    停止線
    検出1
    位置
    推定1
    位置
    推定2
    標識
    検出1
    信号
    検出1
    停止線
    検出1
    標識
    検出2
    信号
    検出2
    停止線
    検出2
    AWS Batch
    Job Queue
    dependency
    AWS Batch
    Job Queue
    ・・・
    ・・・
    ・
    ・
    ・
    26
    設定だけで、異なるインスタンス間でのジョブオーケストレーションが可能
    ● 解決策：AWS Batchを使いこなす
    

    View Slide

27. 仮想マシン選定 (1/3)
    ● やりたいこと
    ○ 最も少ないクラウドコストで、日次処理を行いたい
    ● 考え方
    ○ 一枚の画像の処理速度は重要ではない
    ■ 理由：24時間のバッチウインドウにおさまればよいため
    ○ 一枚の画像をいくらのお金で処理できるかのコストパフォーマンスが重要
    27
    コストパフォーマンス =
    処理画像数(枚/h)
    インスタンスコスト($/h)
    例：処理速度だとp3.2xlargeが最も速いが、コストパフォーマンスはg4dn.xlargeがよい
    

    View Slide

28. 仮想マシン選定 (2/3)
    ● GPUを用いた４つの物体検出タスクは「g4dn.xlarge」が最善
    28
    タイムアウト
    タイムアウト
    タイムアウト
    

    View Slide

29. 仮想マシン選定 (3/3)
    ● CPUを用いた位置推定タスクは「c4.xlarge」が最善
    ○ CPUを多く搭載しても、処理速度は速くならないため、最小のc4.xlargeがよい
    29
    

    View Slide

30. 開発フレームワーク (1/2)
    ● 開発チームはサイエンティスト５人、エンジニア２人のチーム
    ● サイエンティストには実行環境を意識すること無く、開発できるようにしたい
    ● フレームワークを作った
    ○ データサイエンティストは以下のような成果物を作るだけで良い
    30
    ROOT /
    ├── Pipfile # 必要なPythonライブラリを列挙
    ├── Pipfile.lock
    ├── install.sh # Pythonライブラリ以外のインストールコマンド
    ├── lib / # フレームワークから実行される処理を実装
    │ ├── logic.py
    └── test / # テストを実装
    └── test_logic.py
    サイエンティストはピュアなPythonのコードを書くだけで良い
    

    View Slide

31. CloudWatch Logs
    開発フレームワーク (2/2)
    31
    ロギング
    物体認識処理
    サイエンティスト
    の成果物
    Python
    データ構造
    に変換
    計算資源提供
    出
    力
    の
    格
    納
    Aurora
    動画
    Aurora
    S3
    SQS
    ファイル
    システム
    として
    アクセス
    位置
    速度
    加速度 フレーム
    ワーク
    入
    力
    の
    提
    供
    引数として
    提供
    FSx for Lustre
    AWS Batch
    マウント
    

    View Slide

32. 4．まとめ
    32
    

    View Slide

33. まとめ
    ● プロジェクトの概要
    ○ DRIVE CHARTからとれるタクシーやトラックの情報から、物体を検出して、地図を更新するた
    めの情報を地図会社に提供
    ● 5つの工夫
    ○ 動画キャッシュファイルシステム
    ■ FSx for Lustreを導入しS3のキャッシュとして利用
    ○ 分散処理サービスの選定
    ■ カスタムコンテナを利用できるAWS上の４つサービスを比較し、AWS Batchを選択
    ○ ジョブのオーケストレーション
    ■ AWS Batchの機能を活用して、開発無しでオーケストレーションを実現
    ○ 仮想マシン選定
    ■ コストパフォーマンスを計算し、処理ごとに最適な仮想マシンを選定した
    ○ 開発フレームワーク
    ■ サイエンティストが実行環境を意識せずに開発できるようにした
    33
    

    View Slide

34. エンジニア募集中！
    34
    

    View Slide

35. View Slide