0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

3Dカメラもあるし物体検出もあるし、あとは使うだけなんでしょ

Last updated at Posted at 2024-06-11

「3Dカメラの品質も上がってきているし、物体検出の検出率もあがっているから、
あとは使うだけなんでしょ」

そう簡単ではないことを示すために、この記事を書く。

3Dカメラでの物体検出の動画例

この動画は、ZED2iをZED-SDKでの物体検出を用いて実行した結果のようである。

以下の本家のサイトにある動画に類似している。
検出対象物に対する3Dのbounding box を表示しながらtracking IDを表示している。

検出精度の問題

  • 未検出が多すぎる。
  • 乗用車以外の車種の検出率が低い
  • 高い頻度での未検出を生じやすいクルマの向きがある。
    反対車線を走行中のクルマの検出率が低すぎる。
    バスが正面に見えても未検出。
    追突の可能性の高い場所にある乗用車が、未検出から検出に変わるまでの距離が近すぎる。
    隣の車線を走っている自動車が未検出。
    バイクを未検出
    あまりに未検出が多すぎる。
    これは車載用の学習をしていないモデルを実行しているためである。
    このソースコードのある場所
    github zed-sdk のリポジトリ

検出結果の描画とのズレが大きい

  • 物体検出の処理時間が無視できない。
  • そのため、物体検出結果を、最新のフレームに重ね書きすると、検出枠が、その対象物と位置がずれている。

動画で気づいてもらえたと期待する点

  • ZED2iカメラでのユーザーによるデモ動画で、上記のように課題があることに気づいてもらえただろう。
  • 「あとは使うだけなんでしょ」といかない状況がわかってもらえただろうか。

ほかにも不足している機能

  • 検出結果の追跡
    • (この例では追跡を含んでいるが、一般に検出だけでは追跡を含んでいない)
  • 検出結果の3Dとしての安定な解釈
    • 検出枠が不安定に大きくなったり小さくなったりすることが起こりやすい。
    • 検出枠の大きさを元に距離を評価しようとすると、距離を間違えやすい。
  • 対象物の空間としての移動速度の算出
    • 対象物が、地面(床面)にあるなどの仮定が必要な場合がある。
    • 対象物との相対速度の算出には、ドップラー効果などを使うほうがいいだろう。
  • 対象物の姿勢検出
    自動車や人がどっちを見ているのかって重要だよね。
    - 対象物の大きさの検出
    自動車の大きさがわからないなんてないよね。

遅延時間の軽減策

その1:検出処理の高速化

  • 利用できるデバイスでの検出処理を高速化する。
  • 高速なアルゴリズム・軽量なモデルへの置換え
  • 利用できるデバイスへでの固定小数点化

その2:データのCPU-GPU間のデータの転送を減らす。

  • 一連の処理の中で、CPU-GPU間のデータの転送があると遅くなる。
  • 一連の処理を極力GPU上で簡潔するようにすること。

CPUの処理をシングルスレッドではなく、複数のスレッドやパイプライン構成に置き換える。

  • Gstreamer などのパイプラインに書き換える。

その5:並行処理を使う

  • 並行処理を使わないシングルスレッドのコードでは、マルチコアのCPUを活かしきれていない。
  • 並行処理可能な部分を並行処理で別々のCPUに処理を割り当てられるようになると遅延時間を低減できる。

その3:描画を高速化する。

  • matplotlibのように描画時間のかかりすぎるライブラリを描画時間の短いライブラリに置き換える。
  • ライブラリによっては、描画にかかる時間が違いすぎる。
  • 描画も2重のfor文を使ってしまうと遅くなってしまう。

その4:遅延時間の内訳から描画・表示時間を除外して計測する。

  • 遅延時間の内訳から描画・表示時間を除外して計測することで、本当の遅延時間を把握できる。

検出したあとに何をしたいの?

  • ほとんどの検出タスクは、検出は中間目標にすぎません。
  • 検出した後に、したい処理があるはずです。
  • その処理の内容を伝えてください。
  • そうすれば、よりよい使い方を提案できるはずです。

付記:

この例では、自動車の検出についてのある実装を例にあげましたが、
車載の自動車・歩行者・信号・障害物検出・レーン検出などをされている方にとっては、
なんで不十分すぎる実装を紹介したのかと思うでしょう。
私が伝えたいことは、それ以外の実装での「〇〇検出」を期待されている方々が、暗黙に期待していることが実際には簡単じゃないと、ビジネス上で成功するための必要な部分を明確にエンジニアに伝える必要があることを主張したいのです。

例:信号機検出は、自車の進行にあたって読み取る必要がある場所にある信号機を特定できないと意味がないのです。ただ単に、見えた信号機を全て検出すればいいわけではありません。そういった技術的な要求仕様へのブレークダウンが適切になされていないからこそ、開発が失敗しやすいのだと感じています。

現場のエンジニアにとっては、要求仕様が間違っているなんて口に出せないからこそ、このブログを書いています。
ここに書いてあることを、言いたい人は、自分の意見としていうと角が立ちますから、「世の中にはこんなことを言っている人もいるよ」として、この記事を活用していただければ幸いです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?