2018.06.21
【Webマガジン Vol.24- June, 2018】Column: Beaglebone BlackでFLIR Bosonを動かそう
WEBマガジン
- この記事の監修者
- コーンズテクノロジー編集部
- コーンズテクノロジーでは先進的な製品・技術を日本産業界へ紹介する技術専門商社として、通信計測・自動車・防衛セキュリティ・電子機器装置・航空宇宙・産業機械といった技術分野のお役立ち情報を紹介しています。
-
ネットワーク画像配信の試験
上記の通り、画像だけはUVCで送られていますから、制御と画像は分離して取り扱うことができます。従って、まずはffmpeg、ffserver、ffplayを使って、ネットワーク画像配信を実現してしまいます。この辺りは改めて説明するまでもなく、USBカメラを使っての配信事例が数多くありますのでそちらを見ていただくこととし、説明は割愛します。
- BBB上
BBBにBosonを接続し、まずBosonが認識されてUVCが開いていることを確認します。これにはVideo4Linuxが使われます。”/bin/dmesg| grep uvc”あるいは”grep uvc /var/log/syslog”などによって、次のようなログがあることを確認して下さい。
[****(時刻)] uvcvideo: Found UVC 1.00 device Boson (<Bosonのusb ID>) …
[****] usbcore: registered new interface driver uvcvideo
[****] USB Video Class driver (1.1.1)
- ffserver
BBBで配信を行うために、ffserverを必要とします。/etc/ffserver.confにデフォルトで用意されているfeed1.ffmを使い、次のような<test.mjpeg>を記述します。
<test.mjpeg>
Feed feed1.ffm
Format mjpeg
VideoSize vga
VideoFrameRate 9
NoAudio
</Stream>
配信設定としてはVGAでキャプチャし、Motion JPEGへエンコードするようにします。オーディオはBosonに無いし、マイクも用意していないので今回は無し、画像だけ、という設定とします。/usr/bin/ffserver自体は特に引数なしで実行します。
- ffmpeg
BBBでUVCをキャプチャし、ffserverへ渡します。
> ffmpeg –f v4l2 –i UVCdevice http://serveraddress:port/feedingname
“UVCdevice”はビデオデバイス名(/dev/video*)、後ろのURL、”serveraddress”はffserverを実行するホストのIPアドレス、”port”はffserver.confで設定しているHTTPPortの値、”feedingname”はfeed1.ffmとなります。”-f v4l2”は省略可能です。
- ffmpeg/ffplay
動画像受け側で実行します。
> ffplay –i http://serveraddress:port/streamname
URLは配信サーバー側の設定です。”serveraddress”はffserverを実行しているホストのIPアドレス、…です。
配信を受けられると、画像viewerが開き、Bosonデフォルト設定で画像が表示されます。Windows7上で稼働するVirtualboxクライアントのLinux向けに配信を行ったケースで、大体9fps、ビットレートは770k程度、という感じですが、ブロックノイズが気になりますので実際に運用するシステムとするためには調整が必要でしょう。
サンプルアプリケーションの検討
Bosonに標準添付されているBoson applicationを使ってみると、アプリケーション開発を行う上で、サンプルとして実現できたら分かり易そうな機能がいくつかあります。ここでは、今制御しているカメラのS/Nは一体何か、画像擬似カラー着色パレットを切り替える、画像のデジタルズームを行う、この3点を取り上げてみたいと思います。
しかしアプリケーション開発をするためのSDKドキュメントで、該当する機能をすぐに特定して使い方がわかるかというと、残念ながらそうはなっていません（簡単な説明書きは当社で準備しております）。
SDKの中をクローリングしてみると、C言語用のSDKの中に、Example.cというアプリケーション例があります。この例はなかなかよくできていて、①カメラデバイスのオープン方法、②製品パート番号、シリアル番号の取り出し、③カメラ設定値が保存されているフラッシュメモリの読み書き、といった機能が実装されています。それを参考に、Pythonで作成したコンソールプログラムを実行している状況が以下のスクリーンショットになります。先に述べた通り、そもそも画像はUVCでインターフェースされているので、アプリケーションがどうあれ、UVCをキャプチャして表示することができるアプリケーションがあれば、画像表示だけは単独で実現できます。それに、CDCによる制御を追加している、そういう構成になります。
#! /usr/bin/env python
# -*- coding: utf-8 -*-
# test program
import sys
import ClientFiles_Python as pySDK
def main():
# initialize camera
(以降はお問い合わせください)
図６ Linux上での画像表示とサンプルアプリケーション実行の様子
サンプルアプリケーションの機能的分割
さて、ここまでの説明では、Bosonが接続されたホスト上で、CDCを通してBosonに対してコマンドを送る構成になっていました。しかし、webカメラとして使うには、このままだとBBBからコマンドを投入するため、BBBを端末として使えるよう、外部のホストからtelnet/sshなりteratermなり、端末を開いて、そこからコントロールしなければならなくなってしまします。
ネットワークカメラと言えばカメラ内にwebサーバーが稼働していて、ネットワーク上からwebブラウザを使って設定する、というのが一般的かと思います。それと同じ機構を実現するため、BBB上に、Pythonによる簡易webサーバーを導入し、python webスクリプトを作成してやります。Pythonによるwebサーバーについても情報は数多くあると思いますので、ここでの説明は省きます。
先ほどのコンソールプログラムと等価な機能をwebで実現し、実行するとこんな感じになります（画面は開発中画像ですので、開発用端末内でシステムは閉じています。このためwebおよびffplay画像はローカルIPで表示されています、念のため…）。Webスクリプトをここに示すことができませんが、大体、総計200行程度のpythonスクリプトです。
制約もあり手近な場所を映しているので、監視画像としてはイマイチですが、Boson（とBosonを接続しているBBB）を適切な位置に設置すれば、ネットワークカメラとして、ここまでの仕掛けで機能できそうだ、というイメージを持って頂けたのではなかろうかと思います。
図７．ネットワーク配信実験の様子
最後に
さて、以上から、Bosonに元々組み込まれている機能を利用するだけでも、「ネットワークサーマル監視カメラ」を構成できそうだ、しかも、SDKを使ってがしがしアプリケーションを書く必要があるわけでもないのでそれほど難易度も高くない、と感じていただけたのではないかと思います。
本格的な監視カメラとするためには、今何が写っているのか、写っているものは活動しているのかいないのか、等を組み込んでいく必要があるものと思います。
ここでは、画像を見ることを前提として、AGC処理後の画像をストリーミングしましたが、オブジェクト認識等を利用するためAGC処理前の画像を扱う、それをOpenCVで処理する、マシンラーニング/ディープラーニングを組み込む等、取り組んでみていただければと思います。
図８．試験装置構成（BBBとPCをつないでいるUSBは電源として使用
