Zivid SDK 2.18：大規模環境での信頼性、高速化されたキャプチャ、そして開発者への配慮

このところ Zivid では慌ただしい日々が続いていたが、ついに SDK 2.18 をお届けできることを嬉しく思う。今回はアップタイム、信頼性、そして開発者への配慮に焦点を当てている。現場でのカメラの状態を監視し、レイテンシを削減し、コードをデプロイする前に仮想カメラでテストできるようにする内容だ。早速見ていこう。

本リリースの内容：

• 大規模展開を安全に行うためのカメラヘルスチェック
• GPU への直接アクセスによる高速キャプチャ
• Nvidia ユーザー向けの CUDA インストーラー
• 独自のファイルカメラを作成
• その他のアップデート

大規模環境での信頼性：カメラヘルスチェック

大規模な導入を運用している人なら誰でも知っていることだが、本当の難しさは1つのセルを構築することではなく、それがサイト全体に散らばった50台になり、そのすべてが確実に稼働し続けることを求められたときに生じる。新しいカメラヘルスチェックは、まさにそれを保証するための機能だ。

カメラヘルスは API としても Zivid Studio 上でも利用でき、カメラから温度や最大ネットワーク速度といったメトリクスを読み取ることができる。これにより、(1) 展開済みのカメラの経年劣化を監視し、(2) セルに何か問題が起きた際のトラブルシューティングを行うことができる。既存の監視ループの中で好きなだけポーリングしても、キャプチャのスループットへの影響がほとんど、あるいはまったく測定されないよう、軽量に設計している。

カメラヘルスチェックの例。

内部的には、このヘルスチェックはいくつかの個別の測定値を集約したものである。

• 最大転送速度： カメラとホストコンピュータ間のエンドツーエンドのリンク速度
• 温度： カメラ内部の温度（摂氏）
• ファン： ファンの状態
• メモリ： カメラのメモリが破損していないか
• 現場検証： 前回の検証から1年以上経過しているかどうか。

上記のすべてのチェック結果は、個々のチェック項目の中で最も悪い状態を反映した総合ステータスに集約されるため、一目で特定のカメラに注意が必要かどうかがわかり、さらに詳細を確認すればその理由もすぐに把握できます。

具体的な例として、データケーブルの故障が挙げられます。 10 ギガビットから 100 メガビットへと突然速度が低下したリンクは、ケーブルの損傷による典型的な症状であり、手作業で診断するには数時間を要する可能性のある、まさにこの種の断続的なキャプチャ障害です。回線の速度が低下してからケーブルの破損を発見するのではなく、ダッシュボードですぐにそれを確認することができます。

GPU への直接アクセスによる高速キャプチャ

これまで、カメラからポイントクラウドや RGB データにアクセスするには、パフォーマンスを犠牲にする迂回が必要だった。まず各フレームを GPU から CPU にコピーし、それを自前のパイプラインに取り込むために再び GPU へ戻す、という手順だ。この往復がレイテンシを追加し、サイクルタイムを遅くする可能性があった。

SDK 2.18 では、この迂回をスキップできるようになった。Zivid Frames に GPU メモリ上で直接アクセスできるようになり、CUDA のデバイスポインタ、あるいは OpenCL の cl_mem オブジェクトとして公開される。2D の RGB 画像と3Dのポイントクラウドデータを、CuPy や PyTorch といったフレームワーク上の把持検出モデルやセグメンテーションモデルへ直接渡すことができる。もう CPU を経由してデータを行ったり来たりコピーする必要はない。

その効果はレイテンシの低減だ。この往復による遅延をなくすことで、エンドツーエンドのキャプチャ時間から測定可能な分だけ削減でき、CPU と PCIe の帯域も解放される。これはピースピッキングや小包処理のセルのように、サイクルタイムが厳しい環境で特に効果を発揮する。

Nvidia ユーザー向けの CUDA インストーラー

滅多にないことだが、時にはうまい話もある。現在、2つの GPU バックエンド、OpenCL と CUDA をサポートしている。CUDA パッケージは Nvidia のハードウェア向けに専用に構築されており、最適化された処理により、OpenCL 版と比較してキャプチャ時間を短縮する。Nvidia の GPU で稼働している場合は CUDA インストーラーを選べば、コードを変更することなく、より良いパフォーマンスが得られる。

GPU 計算バックエンドを選択する際の新しい画面。

独自のファイルカメラを作成

ファイルカメラ、すなわちキャプチャ済みのデータを、あたかも実カメラが接続されているかのように再生する「仮想カメラ」は、これまで長らく Zivid の社内ツールだった。「自分たちでも作れないのか？」という当然の質問を、多くの人から寄せられるようになった。SDK 2.18 では、それが可能になる。

ファイルカメラ機能が一般公開され、Zivid Studio と API を通じて、保存したデータから仮想カメラを作成できるようになった。これにより、物理的なカメラを接続することなく自動テスト、リグレッションチェック、CI を実行できるようになり、開発者間で一貫した仮想カメラを共有することで、全員が同じデータに対して作業できる。コードを開発・保守するチームにとっては、変更のたびにリリース前に検証し、顧客のラインではなくコミットの段階でリグレッションを発見できることを意味する。

Zivid Studio でファイルカメラをアップロードして表示できる。

その他のアップデート

Studio 上で再キャプチャなしに関心領域を調整

Zivid Studio 上で、再キャプチャなしに ROI を簡単に調整できるようになった。「re-processing（再処理）」を有効にして ROI を調整するだけでよい。どの点がボックスの内側に入り、どの点が外側に出るかを確認するために、新たにキャプチャを取り直す必要はない。ボックスの外側にあるすべての点は無効（NaN）に設定される。

ROI ツールの調整機能を改善。

ハンドアイキャリブレーションの信頼性チェック

ハンドアイキャリブレーションに、便利なガードレールが加わった。新しいハンドアイステータスの列挙型により、実行したキャリブレーションが実際に信頼できるものかどうかが分かるようになり、次の3つの状態のいずれかを報告する。

1. OK：キャリブレーションが成功した場合

2. InsufficientMotion：データセット内の動きが不足しているために、算出された解が十分に定まっていない場合

3. InsufficientDataQuality：算出された解の残差誤差が大きく、データ品質が低いことを示している場合
   

このステータスは、フィデューシャルマーカーによるキャリブレーションとチェッカーボードによるキャリブレーションの両方で報告される。

バーコード読み取り API の拡張

バーコード読み取り API をより柔軟なものに作り直し、開発者から要望のあったいくつかの機能を追加した。主な変更点は次のとおりである。 

• 検出とデコードを別々のステップとして扱えるようになった。バーコードの読み取りを2つのフェーズに分割でき、それぞれが専用の結果クラスを持つ。検出は画像内の候補領域を見つけ、デコードはその候補を読み取る。
• すべてのバーコードにバウンディングボックスが付与される。すべての検出結果・デコード結果は、ピクセル単位の x、y、幅、高さを含むバウンディングボックスを公開するようになった。これを使えば、コードを3D空間上で特定し、グリッパーをその上に置いてしまうのを避けられる。
• ITF バーコードのサポート。ITF インターリーブド 2 of 5 のリニア形式に対応した。

Zivid Studio におけるバーコード読み取りの例。

まとめ

まとめると、SDK 2.18 は信頼性、速度、そして開発者への配慮がテーマである。カメラヘルスチェックは、展開済みのシステムを稼働させ続け、ラインが止まる前にトラブルを発見する助けとなる。GPU への直接アクセスと CUDA インストーラーは、カメラからのデータをより速くパイプラインへ届ける。顧客自身が作成できるファイルカメラは、テスト・CI・コラボレーションの負担を大きく軽減する。

今回私たちが用意したものを気に入っていただけたなら幸いだ。それでは、また次の SDK をお届けするために、仕事に戻るとしよう。