ドライブレコーダの動画を使った道路情報の自動差分抽出
•Transferir como PPTX, PDF•
3 gostaram•5,522 visualizações
自動運転時代には、今よりも更新頻度の高い地図が必要です。MoTでは大手地図会社であるゼンリンとの共同開発により、ドライブレコーダの動画を元に道路情報の差分を自動で抽出し、地図更新に役立てるプロジェクトを行っています。このプロジェクトを紹介します。 技術的な紹介ポイントとしては、次のものになります。マップマッチ、機械学習（ディープラーニング）、SLAMそしてGISツール等を組み合わせた高度なアプリケーション。大量の動画データに対して分散処理するために、AWS FSx for LustreやAWS Batchを用いてシステムを構成。計算コストの高い機械学習推論処理を最適化する工夫。データサイエンティストの成果物を本番に取り込むためのフレームワーク。
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a ドライブレコーダの動画を使った道路情報の自動差分抽出
Semelhante a ドライブレコーダの動画を使った道路情報の自動差分抽出 (20)
Mais de Tetsutaro Watanabe
Mais de Tetsutaro Watanabe (19)
Último
Último (11)
ドライブレコーダの動画を使った道路情報の自動差分抽出
- 2. アジェンダ 1. DRIVE CHARTの紹介 2. 道路情報の自動差分抽出プロジェクト 3. 5つの工夫 4. まとめ 2
- 3. 自己紹介 ID ：fetaro 名前：渡部 徹太郎 学生：東京工業大学でデータベースと情報検索の研究 (@日本データベース学会) 職歴： * 野村総合研究所(NRI) - オンライントレードシステム基盤 - オープンソース技術部隊 * リクルートテクノロジーズ - ビッグデータ分析基盤 * Mobility Technologies - データエンジニア エディタ：emacs派→ IntelliJ派 趣味：麻雀、自宅サーバ 日本AWSユーザ会 (JAWS) 著書 3
- 5. Mobility Technologiesの事業 1. 配車関連事業 2. 広告決済事業 3. 乗務員向け ソリューション事業 4. DRIVE CHART ・ドラレコ事業 5. 次世代向けR&D事業 5
- 8. プロジェクトの概要 ● 課題 ○ 自動運転時代においては、地図の更新頻度を上げる必要が ある ○ しかし、更新頻度をあげる為には、作業の効率化が必要 ● 解決策 ○ DRIVE CHARTを搭載した車両を動くセンサーとして道路 の情報を収集する ○ 収集した情報を元に自動的に道路情報の差分を見つけ、地 図会社に提供する ● ゼンリン社と共同開発。２０２０年４月にプレスリリース 1 ヶ月で走行した道路 （ ２３区＋三鷹市＋武蔵野市） 8
- 10. 車両位置の特定 - マップマッチ GPSで記録された位置 マップマッチした位置 道路リンク 利用技術(1/4) 10
- 14. 地図との差分抽出 ー 地理情報技術 14 利用技術(4/4) による地理情報操作 + SELECT * FROM map WHERE ST_Contains (area , ST_Geogpoint( 139.7424, 35.6561) )
- 15. DRIVE CHART システム構成図 マップ マッチ 動画取得 道路計算 位置 位置格納 動画格納 物体検出 位置 推定 物体 差分判定 地図 差分判定結果 動画 AWS Batch S3 Lambda Lambda TypeScript CI / CD 15 by 分析・開発
- 16. 3．5つの工夫 16
- 17. システム構成図 17 5つの工夫は ここの話！ DRIVE CHART システム構成図 マップ マッチ 動画取得 道路計算 位置 位置格納 動画格納 物体検出 位置 推定 物体 差分判定 地図 差分判定結果 動画 AWS Batch S3 Lambda Lambda TypeScript CI / CD 17 by 分析・開発
- 18. 5つの工夫 1. 動画キャッシュファイルシステム 2. 分散処理サービスの選定 3. ジョブのオーケストレーション 4. 仮想マシン選定 5. 開発フレームワーク 18
- 19. 動画キャッシュファイルシステム(1/2) 19 標識検出ワーカ 信号検出ワーカ 停止線検出ワーカ 動画 ストレージ S3 ダウンロード ダウンロード ダウンロード ● やりたいこと ○ 同じ動画に対して、複数のワーカーで異なった物体認識処理をする ● 問題点 ○ ワーカ毎に同じ動画をローカルにダウンロードする必要がある
- 20. ● 解決策 ○ FSx for Lustreを使うことにより、S3からのダウンロードを１回にでき、 システム全体のIOスループットを向上できる 動画キャッシュファイルシステム(2/2) 20 S3 標識検出ワーカー 信号検出ワーカー 停止線検出 ワーカー FSx for Lustre 動画 ストレージ 動画 キャッシュ 初回アクセス時に S3からダウンロード 以後はS3から ダウンロード不要
- 21. 分散処理サービスの選定 (1/4） ● 典型的な機械学習推論のワークロードはこんな感じだが 21 推論 処理 S3 推論 処理 {label = "猫"} S3 {label = "犬"} ・・・ ・・・
- 23. 分散処理サービスの選定 (3/4) ● カスタムコンテナの分散バッチ実行環境の選択肢は４つある 23 SageMaker batch transform jobs + カスタムコンテナ AWS Batch ECS EKS 概要 機械学習の推論サービス。 それをカスタムコンテナで 動かす コンテナベースのバッチを動 かすサービス 汎用コンテナ実行環境。 オンラインもバッチもできる。 Kubernetesベースの汎用コ ンテナ環境。 運用 インスタンス管理不要 インスタンス管理不要 GPUを使う場合は、Fargate が使えず、インスタンスの管 理が必要 Kubernetesの学習コストが 高い 開発・運用工数：小 制約：強 開発・運用工数：大 制約：弱 運用工数のかかるECSとEKSは外した
- 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
- 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の計算となる
- 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を使いこなす
- 27. 仮想マシン選定 (1/3) ● やりたいこと ○ 最も少ないクラウドコストで、日次処理を行いたい ● 考え方 ○ 一枚の画像の処理速度は重要ではない ■ 理由：24時間のバッチウインドウにおさまればよいため ○ 一枚の画像をいくらのお金で処理できるかのコストパフォーマンスが重要 27 コストパフォーマンス = 処理画像数(枚/h) インスタンスコスト($/h) 例：処理速度だとp3.2xlargeが最も速いが、コストパフォーマンスはg4dn.xlargeがよい
- 29. 仮想マシン選定 (3/3) ● CPUを用いた位置推定タスクは「c4.xlarge」が最善 ○ CPUを多く搭載しても、処理速度は速くならないため、最小のc4.xlargeがよい 29
- 30. 開発フレームワーク (1/2) ● 開発チームはサイエンティスト５人、エンジニア２人のチーム ● サイエンティストには実行環境を意識すること無く、開発できるようにしたい ● フレームワークを作った ○ データサイエンティストは以下のような成果物を作るだけで良い 30 ROOT / ├── Pipfile # 必要なPythonライブラリを列挙 ├── Pipfile.lock ├── install.sh # Pythonライブラリ以外のインストールコマンド ├── lib / # フレームワークから実行される処理を実装 │ ├── logic.py └── test / # テストを実装 └── test_logic.py サイエンティストはピュアなPythonのコードを書くだけで良い
- 31. CloudWatch Logs 開発フレームワーク (2/2) 31 ロギング 物体認識処理 サイエンティスト の成果物 Python データ構造 に変換 計算資源提供 出 力 の 格 納 Aurora 動画 Aurora S3 SQS ファイル システム として アクセス 位置 速度 加速度 フレーム ワーク 入 力 の 提 供 引数として 提供 FSx for Lustre AWS Batch マウント
- 32. 4．まとめ 32
- 33. まとめ ● プロジェクトの概要 ○ DRIVE CHARTからとれるタクシーやトラックの情報から、物体を検出して、地図を更新するた めの情報を地図会社に提供 ● 5つの工夫 ○ 動画キャッシュファイルシステム ■ FSx for Lustreを導入しS3のキャッシュとして利用 ○ 分散処理サービスの選定 ■ カスタムコンテナを利用できるAWS上の４つサービスを比較し、AWS Batchを選択 ○ ジョブのオーケストレーション ■ AWS Batchの機能を活用して、開発無しでオーケストレーションを実現 ○ 仮想マシン選定 ■ コストパフォーマンスを計算し、処理ごとに最適な仮想マシンを選定した ○ 開発フレームワーク ■ サイエンティストが実行環境を意識せずに開発できるようにした 33
- 34. エンジニア募集中！ 34
Notas do Editor
- 25MIN 自動運転時代には、今よりも更新頻度の高い地図が必要です。MoTでは大手地図会社であるゼンリンとの共同開発により、ドライブレコーダの動画を元に道路情報の差分を自動で抽出し、地図更新に役立てるプロジェクトを行っています。具体的には、深層学習やSLAMの技術を用い、AWS上でそれを実現しようとしています。それを紹介します。