Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

fetaro
March 03, 2021

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

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

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

fetaro

March 03, 2021
Tweet

More Decks by fetaro

Other Decks in Technology

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. 1.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. 2.道路情報の自動差分抽出プロジェクト
    7

    View Slide

  8. プロジェクトの概要
    ● 課題
    ○ 自動運転時代においては、地図の更新頻度を上げる必要が
    ある
    ○ しかし、更新頻度をあげる為には、作業の効率化が必要
    ● 解決策
    ○ DRIVE CHARTを搭載した車両を動くセンサーとして道路
    の情報を収集する
    ○ 収集した情報を元に自動的に道路情報の差分を見つけ、地
    図会社に提供する
    ● ゼンリン社と共同開発。2020年4月にプレスリリース
    1 ヶ月で走行した道路
    ( 23区+三鷹市+武蔵野市)
    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からのダウンロードを1回にでき、
    システム全体の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)
    ● カスタムコンテナの分散バッチ実行環境の選択肢は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)
    ● やりたいこと
    ○ 車両からくる約5分のデータ毎に物体認識と位置推定を行いたい
    ○ 物体認識と位置推定は順序関係があるため、それを表現したい
    ○ 物体認識は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を用いた4つの物体検出タスクは「g4dn.xlarge」が最善
    28
    タイムアウト
    タイムアウト
    タイムアウト

    View Slide

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

    View Slide

  30. 開発フレームワーク (1/2)
    ● 開発チームはサイエンティスト5人、エンジニア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上の4つサービスを比較し、AWS Batchを選択
    ○ ジョブのオーケストレーション
    ■ AWS Batchの機能を活用して、開発無しでオーケストレーションを実現
    ○ 仮想マシン選定
    ■ コストパフォーマンスを計算し、処理ごとに最適な仮想マシンを選定した
    ○ 開発フレームワーク
    ■ サイエンティストが実行環境を意識せずに開発できるようにした
    33

    View Slide

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

    View Slide

  35. View Slide