本記事は、2021年4月26日、27日、28日に開催したオンラインセミナー「物体検出を応用した忘れ物検知システムを作ってみよう 〜アルゴリズム選定編、Jetson実装編、デプロイメント編〜」で計71件のご質問をいただき、その中からお客様からよく頂くご質問を厳選し回答をご紹介します。

 

イベント全体の様子をご覧になりたい方はこちら

 

Jetson実装編では45件のご質問をいただきました。本セミナーではNVIDIA Jetson Xavier NXを題材にアプリケーションの構築をしたため、Jetsonの基本的な動作についてのご質問や、NVIDIA社が提供するDeepStreamSDKやTensorRTに関するご質問を多く頂きました。

デプロイメント編では26件のご質問をいただき、既にDockerやCUDAを用いた開発に着手されている中でお困りだったことをご質問いただいた印象でした。

 

本ページにすべてのご質問に対する回答を書ききれませんでしたが、今後のご開発の一助となれば幸いです。

Jetson実装編

AGX XavierとXavier NXではどれくらいのパフォーマンスの差になるのでしょうか? 

モデルによっても異なりますが、AGX Xavierの方がXavier NXに比べおおよそ2倍のパフォーマンスになります。

下記リンクのJetsonのベンチマークをご参考にして頂ければと思います。

https://developer.nvidia.com/embedded/jetson-benchmarks

すでに過去のバージョンのSDKをインストールしていた場合、今回教えていただいたバージョンのSDKに更新することは可能でしょうか?

dockerに対応しているバージョンであれば、dockerを使用することで可能と考えます。

ただし、実際にはトラブルを避けるため、古いJetPackのバージョンをご使用になられている際には、新しいJetPackのバージョンのものを再度インストールすることをお勧めします。

奥行方向の距離を測るための方法は具体的にあるのでしょうか?どのような方法でどの程度の精度がだせるのでしょうか?

ステレオカメラを用いてステレオの画像から奥行きを推定したり、ミリ波レーダーなどの距離を測定できるセンサーの情報とカメラ画像を組み合わせたりすることは可能ではないかと考えます。

ただし、ご使用になるカメラやセンサー、測定する物体までの距離などによって精度なども変わりますので、PoCを通じた検証などが必要です。

今回採用したアルゴリズムをJetson Xavier NXで動作させる場合、カメラのストリームは4本程度という話がありましたが、4つのカメラからの画像を同時に処理できるという意味でしょうか?

はい。ご認識の通りです。

TensorRTに変換した場合と、しない場合では、処理速度はどのぐらい違うのでしょうか?

今回の忘れ物検知システムでは、TensorRT形式に変換したもののみを使用しており、恐れ入りますが変換しない場合の動作確認はおこなっておりませんでした。

参考情報としましては、下記のリンク先の表に単純なPyTorchとTensorRTの比較がありますのでご参照いただけますでしょうか。

https://github.com/NVIDIA-AI-IOT/torch2trt

Jetson上で動くモデルはTensorRTでないと動作しない認識なのですがあっているでしょうか? また、TensorRTに変換が可能であれば物体検出以外でも基本的にどのようなモデルも動作するのでしょうか?

TensorRT形式に変換をしていないモデルでもJetson上で動作します。

TensorRT形式にモデル変換をする理由としては、Jetson向けにモデルを最適化して高速に動作をおこなうためです。

また、TensorRT形式に変換が可能なモデルであれば、どのようなモデルでもJetson上で動作すると考えています。

GPU等で学習したモデルを利用してJetsonで推論するかと思いますが、x86とARMの違いで動作しないといった難しさはありますか?

特に問題ないと考えています。TensorRTのAPIのところでx86とJetsonで違いがないためです。

ただし、パフォーマンス不足などの要因で動作しないケースも考えられますので、動作確認を十分に実施して頂く必要があると考えます。

YOLOV4は下のソースのようなDeepStramSDKを使って高速化などされていますか?https://github.com/NVIDIA-AI-IOT/yolov4_deepstream/tree/master/deepstream_yolov4

今回はDeepStramSDKを使用しておらず、TensorRTを使用してモデルの最適化をおこなって高速化をしています。

ONNXからTensorRT変換は実機で必ず行う必要があるのでしょうか?

はい。ONNX形式からTensorRTへの変換は、実機でおこなわなければいけないものです。

理由としては、ONNX形式からTensorRTに変換する際に、各プラットフォームごとにフォーマットが少し異なるためです。

今回はYolo → ONNX → TensorRTの変換をJetson上で実施しました。

デプロイメント編

以前は、Docker,nvidia-Dockerというのがあって、後者がGPU対応とのことでした。今は、DockerでGPUも対応できるとのことを聞いたことがありますが、ハードウエア(GPU自体)が対応していれば、コンテナごとに異なるバージョンのCUDAやCuDnnを導入できるのでしょか?

今回のセミナーでは、Jetsonの場合に限定して説明しました。
Jetsonの場合と、NVIDIA社製GPUカード(NVIDIA dGPU)の場合で、それぞれ状況は異なります。

 

【Jetsonの場合】
DockerはJetPackで自動的にインストールされるものを、そのままお使いください。
現時点(JetPack 4.5.1)では、Dockerコンテナ内から、ホスト側のCUDA やcuDNNを参照する仕組みのため、ホスト側JetPackに含まれるCUDA, cuDNNのバージョンのみ、コンテナ内から利用可能です。
なお、この仕組みは、あくまで現時点のものですので、変更になる可能性もあります。

 

 

【NVIDIA社製GPUカード(NVIDIA dGPU)をLinux/AMD64(x86-64) 環境でご利用の場合】
Dockerは、バージョン19.03から、GPUにネイティブに対応しています。この公式Dockerをインストール後に、NVIDIA Container Toolkitをインストールすることで、NVIDIA社製GPUカードをDockerコンテナ内から利用可能になります。

インストール方法の詳細は、NVIDIA Container Toolkit:Installation Guideをご覧ください。

複数のバージョンのCUDA, cuDNNの導入は、NVIDIA NGCで公開されているCUDAイメージをご利用ください。バージョンの組み合わせを示すタグで分類された複数のコンテナ・イメージが存在します。

1つのJetsonで異なるバージョンのCUDAやCuDNNを利用できるのでしょうか?

上記のとおり、現時点(JetPack 4.5.1)では、ホスト側にインストールされているCUDA, cuDNNのバージョンのみ利用可能です。

Nanoなどのメモリーが少ない環境でも使用できますか?Dockerによってメモリーが使用されてしまいモデルを動かせなくなることはないでしょうか。

Jetson Nanoでも動作します。Jetson Nanoを推奨プラットフォームとするJetson AI基礎コース Section 1 - NVIDIA Deep Learning Institute’s Getting Started with AI on Jetson Nano course
もDockerを利用して、教材の環境をセットアップします。ぜひお試しください。

docker runで動かしているのはイメージ?コンテナ?でしょうか?

指定したDockerイメージからDockerコンテナを生成し、そのDockerコンテナを起動します。

ネットワークに繋がないと使えないのでしょうか?

Dockerイメージをレジストリから取得するとき、あるいは、Dockerベースイメージにインターネットから取得したライブラリーをインストールして、Dockerイメージをビルドするときにはネットワーク接続が必要です。

公開されている多数のイメージの中から、自分がやりたいことに適したイメージを見つける方法・コツはありますか?

まずは、NVIDIA NGCのカタログからお探しください。Jetson向けのDockerイメージは、キーワード「L4T」で検索すると見つかります。

データベース、ウェブサーバー、各種ミドルウェアは、Docker Hubで多数公開されています。ダウンロード数やスター数の多いものが人気の高いものです。人気の高いものが、インターネット上に使い方の情報が多く、使いやすいと思います。

Dockerイメージ内にCUDAを導入しても、システムのCUDAを壊すことはないと考えて大丈夫でしょうか? Jetsonではしないほうがいいということは理解しましたが、他のマシンでは実施してもよいものか不安がありまして。。

NVIDIA GPUカード(NVIDIA dGPU)をLinux/AMD64(x86-64) 環境で使用する場合を想定し、回答します。
ボリューム・マウントにより、ホスト側のCUDA関連ディレクトリーを、Dockerコンテナと共有する設定になっていないのであれば、ホスト側のCUDA環境を破壊することはありません。CUDAの場合に限らず、ボリューム・マウントは、誤ってホスト側のファイルを上書きや削除するリスクがありますので、注意してご利用ください。
複数バージョンのCUDA環境を導入する場合は、Dockerコンテナ内で、CUDAをインストールするよりも、NVIDIA NGCで公開されているCUDAイメージのご利用をお勧めします。

公開されている多数のイメージを基にして、そこに自分の独自の設定を加えたものを新たなイメージとして保存しておき、それからコンテナを生成できるものなのでしょうか。

はい。そのようにもお使いいただけます。
docker commitコマンドでコンテナをイメージ化し、それをdocker saveコマンドでファイル保存することができます。

オールインワンの構成なのでDockerでいろいろなサービスを動かしていると思いますが、もう少し本番に近い構成を考えた場合は、Jetson上では推論のみさせるのがベターでしょうか?

CPUにも負荷のかかる推論処理を行うアプリケーションの場合は、おっしゃるとおり、Jetsonを推論のみに使用する方が良いと思います。また、複数の場所にJetsonを配置して、それを一つのダッシュボードで一元管理したい場合も、ダッシュボード・サービスは別のコンピューターで実行する方が、管理が容易と思います。

今回のセミナーで紹介したアプリケーションは、1台のJetson上ですべてのサービスを実行させたので、Docker Composeで管理できましたが、複数台のコンピュータにサービスを分散させる場合は、Kubernetesなど分散環境に対応したプラットフォームが必要と思われます。

セミナーを振り返りたい方にはオンデマンド動画もあります。

質疑応答の一部を厳選しご紹介しましたが、いかがでしたでしょうか。セミナー本編はオンデマンド動画も準備しています。ぜひ今後の参考にしていただければ幸いです。

GitHubへサンプルコードを掲載中です

GitHubリポジトリーにて、本セミナーでご紹介したアプリケーションの詳細を掲載しています。
https://github.com/MACNICA-CLAVIS-NV/abandoned_object_detection

リンク先からサンプルコードをダウンロード可能となっており、これから開発を始められる方はぜひ参考にしていただければ幸いです。