はじめに
ハードウェアGpのおおひらです。 弊社は1/15(水)〜17(金)に開催されたオートモーティブ・ワールドに出展させて頂きました。 お忙しいなか足をとめてブースに立寄って頂いた皆様、大変ありがとうございました。
本記事ではブースにて初お披露目となったビデオエンコーダ試作品の開発経緯を紹介させて頂きます。
開発の背景
従来、弊社では移動体の動画計測が求められるユースケースに対して民生品のWebカメラを利用していました。特にビデオエンコーダ内蔵のWebカメラであればサーバーに送信する際の処理リソースも末端の機器側に分散できますし、そもそも民生品なので圧倒的に低コストで調達性もよいというメリットがあります。
一方、動画に加えて、車両の制御バスであるCAN(Controller Area Network)や運転者の挙動を解析するためのアナログセンサなどを含め、移動体のシステム全体のセンサデータを統合して計測するという観点では、その時系列の正確性に課題が生じます。
課題1：イメージセンサ撮像〜打刻のタイミング管理
一般に民生品のWebカメラは自動の露出モードを有する製品が多く、暗いシーンでは露出時間を伸ばしてフレームレートを落とす処理がされます。弊社が提供する産業IoTのプラットフォームであるintdashでは末端の機器群におけるターミナルとして車載コンピュータ上のソフトウェアが複数センサの打刻を一元的に管理しますが、カメラから出力される映像ストリームに対してはそれを受信したタイミングで打刻しますので、受信までの間に生じる遅延を管理することはできません。もちろんカメラの撮影設定パラメータを試行錯誤したり、実験的に種々の撮影環境における遅延時間を求めることは可能ですが、カメラ内のエンコード処理に起因する遅延時間も含めると完全に保証をすることは難しいと言えます。
この結果として、車両から計測したCANデータを可視化した結果と、同タイミングで計測した動画との間で数百ミリ秒の時間のずれが生じ、計測結果を統合的に見た際に違和感をおぼえるという問題が生じます。
課題2：複数のカメラを使用してデータ分析する際の不正確さ
一般にカメラのデバイスの源振には特性のばらつきがありますので、複数のカメラ間におけるフレームレートは完全に一致しません。仮に設定上は各自のカメラが30 fpsになっていたとしても、カメラ#1は29.7 fps, カメラ#2は30.4 fps …というように誤差が生じ、その結果、例えば1時間の計測を行ったとしてカメラ#1は106,920フレーム、カメラ#2は109,440フレーム…という具合にフレームの総数が異なる結果となります。
動画は結局のところ複数の静止画の集合体ですので、複数カメラの映像を統合的にデータ解析をしようとすると、まずこのフレームのばらつきの前処理に手間がとられます。
また、ひとつの事象とそれに紐づくデータを解析する際の正確性も課題となります。例えば道路上に飛び出してきた歩行者を前方カメラが捉えた瞬間、運転者の視線がどこに向いていたか、その後どのタイミングでどれぐらいまでブレーキを踏み込んだか、ハンドルをどう切ったか…など、特定のシーンに着目したデータ解析をする場合、30 fpsの動画の1フレーム周期は約33ミリ秒で他のセンサデータの周期に対して大きく、たった1フレームずれるだけで事象分析の正確さが失われるケースが生じることも想定されます。このように、データの利用価値を高めるという点でも解決が必要な課題が多くあります。
課題解決にむけて
下記の方針を立てました。
- 撮像のシャッタータイミングを管理できるよう、トリガ入力をもつ産業用カメラモジュールを利用する
- カメラモジュールの価格はピンキリなので極力低コストで導入できるものを選定する
- 複数のカメラの撮像タイミングを管理するためにリアルタイム性に優れた制御デバイスを用意する
- ビデオエンコード部の遅延時間を管理するため、リアルタイムエンコード処理も可能なデバイスを用意する
- 撮像タイミング信号を使ってスナップショットした時刻情報を、ビデオエンコード時にメタデータとして埋め込む
- 時刻情報は既存の弊社内製CANインターフェース機器と同様、源振となるクロックを機器間で共有して生成する
フェーズ1 : 仕様検討 & 原理試作 (3ヶ月)
このフェーズでは技術的な解決方針が機能することの見極めとして、カメラモジュールの機器選定やH.264のビデオエンコードが可能なデバイスの選定を行い、実際に評価基板を組合せて原理に問題がないか確認を行いました。技術的な実証・試行錯誤をチームメンバー2名に担当してもらい、並行して私は製品に対する要求のヒアリング・分析・対策立案→技術選定という仕様検討のサイクルをまわすことに注力しました。要求の一例をご紹介すると…
- カメラは複数とりつけたい、最低4つほしい
- バスやトラックなど商用車にとりつけたいケースもあるのでケーブル長は長くしたい、5mは必要
- 車両のペダルの撮影など、狭い場所にカメラを潜り込ませることもあるので筐体は極力小さくしたい
- カメラのレンズは広角〜望遠など、お客様のユースケースに合わせて選択肢を設けたい
- LTEの上り回線の限られた帯域で複数のカメラ映像を伝送したい
- 映像はサーバーに送信すると同時に、高画質でローカルストレージにも保存しておきたい (圧縮なしのRAWデータを解析用に保持したい)
などなど。
こだわるところと割り切るところを見極めながら落とし所を探りました(こういう地道な製品開発ループまわしは大好物😇)
ある程度の実現可能性が見えた段階で社内で開発計画を共有し、商品のコンセプトや想定顧客といったマーケティング観点と、コスト(試作/量産時の材料費・開発委託費)やスケジュールといった実際の設計観点で承認を頂きました。時期的には2019年の5月末頃で、この時点で2020年1月のオートモーティブワールドでの試作機の動展示がひとつの大きなマイルストーンであるということをマネジメントと開発チームメンバーとの間で認識合わせしました。
フェーズ2 : 設計試作 (2019/6月〜12月)
このフェーズでは実際に試作基板をつくり、デバイス選定や仕様に問題が無いか機能の検証を行います。特に電源部品や主要な半導体部品が確定できること、ソフト含めたアーキテクチャに問題がないことが重要です。開発メンバーの内訳は、電気兼メカ(私)とソフト・ロジック(FPGA)設計それぞれ1名ずつの3名体制。
基板/筐体設計
回路設計を弊社で行い、基板のアートワーク〜製造と筐体の選定(熱設計含)・部品調達を協力会社様にお願いいたしました。今回は設計スケジュールの短縮のために、主要な半導体に周辺部品が既に実装されているSystem on Module(SoM)を利用する方針にし、回路設計に約1.5ヶ月、AW〜製造で約1.5ヶ月で、試作品の納品までトータル約3ヶ月の設計期間となりました。
基板が納品されてからは基本的な電源性能の確認やペリフェラルの電気的な検証を行い、必要に応じて一部回路や部品の改修を実施してソフト・FPGAとの結合を進めました。
ヘテロコアのSystem on a chip (SoC)のソフト設計
評価ボードベースの検討から、試作機で使用するSoMを利用した検討に移行しました。まずはSoMのメーカーが提供しているキャリア基板を利用して映像入力や周辺ペリフェラル(USB, Ethernet, HDMI etc)の機能確認をしつつ、試作基板むけのピン設定ファイルなどを作成し、試作基板のハードウェアの検証がひと段落した段階で実際に結合してソフトを立ち上げるという手順です。
ソフトウェアの設計観点では、Linuxの映像ストリーム処理(GStreamer)でタイムスタンプの扱いを修正したり、リアルタイム処理に利用する小規模のARMコア上のReal-Time OS(RTOS)のソフト設計が必要だったり。過去の記事を見て頂くと分かるとおり、ひとつのチップに複数のARMコアやハードウェアアクセラレータが混在するSoCを採用しています。担当メンバーはこういったSoCを扱うのは初めてだったにも関わらず、奮闘してくれて大変ありがたく頼もしい限りでした。
FPGA設計
今回の試作品では、カメラのシャッタータイミング制御や映像の縮小・合成処理のために前段にFPGAを利用しています。こちらも評価基板ベースの検討からはじめて、主に下記の機能を実装していきました。
- カメラとの映像伝送I/F (1.8Gbpsの高速シリアル通信を4ch)
- SoCとの映像伝送I/F (パラレル変換して後段に送信)
- 映像の縮小 (簡易的なピクセルの間引き)
- フレームメモリを利用した4画面合成
- 組込みCPU (XilinxのMicroBlazeでFreeRTOSを動作させ、HostとなるSoCやカメラと制御通信する)
FPGAのメモリインターフェースを扱うのが初めてだったり、高位合成で映像処理を作ってみたりと、開発メンバーにとっては初めてづくしの業務が多かったと思いますが着実に進めて頂き大変助かりました。
事前走行テスト
これまで挙げてきた機能のインテグレーションが概ね完了してカメラからサーバーへの映像の疎通ができたのが2019年の12/20頃で、年末休みに入るまでの1週間で実際に車に積んで市街地走行をするという検証を進めました。なかなか痺れるスケジュール…ですがこれも計画通り🙃
カメラの露出タイミング制御や画質調整、4画面合成機能のバグ修正、サーバー側のソフトウェアとの疎通の問題などを順番に潰しつつ、新年明けてからは展示会用のデモ計測のために千葉県の茂原ツインサーキットをお借りして実車計測を行いました。
上のデモ映像は、サーキットにおける実車計測の結果をVisualM2Mという可視化ダッシュボードで再生したものです。本試作機で計測した動画(計5ch)や、オーディオ(エンジン音を録音するマイク)、車両のCANデータから可視化したハンドルやスピードメータを統合してWebブラウザ上で可視化しています。
特に4画面合成された左下のハンドル俯瞰映像と、ダッシュボード上のハンドルのイラストの動きに注目して頂くと完全に同期していることがわかります。これは本記事で紹介したビデオエンコーダと弊社製のCANインターフェス機器が同一のタイムスタンプを生成して打刻しているからこそ可能な計測と言えます。
おわりに
展示会で頂いたフィードバックをもとに、一旦仕様の見直しをしつつ、確実に商品化を進めてまいります。
具体的には、
- カメラの接続を取り回ししやすいケーブルに (汎用のインターフェースを採用)
- 全体の材料費低減 (一部SoMをやめてICを基板実装したり筐体を小型化したり)
- カメラモジュールの再選定 (今回は自作したものの、量産コスト観点でOEM/ODMも検討)
- 製造性の改善
- 画質(ダイナミックレンジやエンコードの画質)
- システム全体の遅延低減 (SoCのHWアクセラレータはまだまだ使いこなしの余地あり)
- 各種信頼性試験やEMC試験
などなど、まだまだやることは山積みですが、弊社メンバー皆で協力して良いモノを作っていきたいと思います。
動画と各種センサデータの時系列解析に課題をお持ちの方はぜひ弊社までご連絡下さい。よろしくお願い致します。
