WEBマガジン詳細

Webマガジン Vol.24- June, 2018

Column: Beaglebone BlackでFLIR Bosonを動かそう

BBBで「ネットワークサーマル監視カメラ」を構成してみよう!

Beaglebone Black

もう旬を過ぎた(過ぎ切った?)感のあるBeagleBone Black(写真参照のこと)ですが、初代がリリースされた2013年春以降、現在でも生産が続いているようです。通常、BeagleBone Blackを縮めてBBBと呼ばれます。

そんなBBBを使って、FLIR社の、かなり安価な赤外線カメラ製品である、Leptonを動かす事例がFLIR社自身のサイトでも紹介されていますが(事例がちょっと古くなってきていますので、近いうちにこちらでも試してみたいと思っています)、Bosonだったらどうか?を試してみたいと思います。

Boson自身がすでにUSBカメラとしての機能を含んでいることからか、ほとんど記事を見ることがありませんが、実際に、「ネットワークサーマル監視カメラ」を構成してみたいと思います。

赤外線とその性質

赤外線は、可視光線よりも波長が長い電磁波で、中には近赤外線を感知できる方もおられるそうですが、ほぼ、目で見ることはできません。
赤外線については、Webマガジン「赤外線カメラの初歩」の「1.はじめに」を、まずは読んでみてください。

FLIR Lepton と Boson

FLIR社は、赤外線カメラの老舗で、大きな市場シェアを持っている米国のメーカーです。ヘリコプターに搭載して捜査を行うような、製品としての赤外線カメラから、組み込み向けのモジュール製品まで、可視光寄りの近赤外線から更に波長が長い中赤外線・遠赤外線まで、それぞれに応じたラインアップがあります。ここで紹介するLepton・Bosonは、冷却機構を持たない非冷却型、と呼ばれる遠赤外線カメラに分類されます。
遠赤外線は、物質が燃焼するときの熱として良く知られています。 可視光の世界では、暗闇に紛れていても遠赤外では見ることができ、そのためにセキュリティカメラおよびその発展形として、ADAS(自動車の自動運転支援システム)における歩行者・動物検知や、機械の異常摩擦の検知に使用されます。

Lepton

Leptonは、組み込み製品向けの小型QFNパッケージのモジュール製品で、80×60、最新のLepton3では160×120(QQVGA)ピクセルの解像度です。遠赤外線、波長8μm~14μmに感応するセンサを使用しており、レンズと合わせた外形寸法は8.5×11.7×5.6mmと非常に小型です。Leptonには、撮影対象の温度測定を行えるラジオメトリモードが搭載された製品もあります(Lepton2.5)。

Boson

Bosonも非冷却型で、Lepton同様波長8μm~14μmに感応する遠赤外カメラですが、Leptonより組み込みwebカメラ的な要素を持ち、解像度も320×240 (QVGA)および、640×512(VGA)がリリースされています。
Bosonには現状温度測定機能が搭載されていませんが、赤外線放射を撮影していますから、特定の環境下では、放射を温度へと換算することができます。Bosonで温度を測定されたい場合は、別途お問い合わせください。

赤外線画像

赤外線カメラの利用に際して、撮影対象の温度がカラー階調として撮影される、と勘違いされていることがありますが、実際には、撮影対象の赤外線放射が白黒階調(輝度)として撮影されているとお考えください。つまり、赤外線放射をセンスするボロメーターという素子自身からは、撮影対象の赤外線放射が、ボロメーターから出力される電圧の高低として出力されています。

通常の可視カメラによる画像は、目で見えるようにものを映す役割を持っています。赤外線カメラによる画像は、もはやこうした役割から離れています。しかし、視認性を向上させるために、被写体の温度がより直感的に把握できるよう、通常のカラーではなく疑似カラーを用いて、温度情報の視覚化、という処理を行います。よく目にする赤外線画像は、白黒階調を視覚的に取り扱うことができるような、疑似カラー処理を施しているわけです。
その視覚化に際しては、例えば、冷たい部分は青系統の配色、熱い部分は赤系統の配色を行うなど、目的に応じた視認性向上のために有益な、いくつかの表現ができるようになっています。

尚、温度測定機能を持つカメラの場合、撮影対象が赤外線を反射するような素材である場合には、正確な温度を測定するために、反射分を差し引いてやらなければなりません。

画像イメージとしての赤外線画像

カラー画像を表現する際、色空間は様々な方法で表現されますが、その中の特定の情報の表現には8bit階調が使われています。階調が細かくなればそれだけ「リニアな」色空間上の変移を表現しますが、その結果として、ドラスティックな色の違いがないシーンでは、コントラストが低下したぼやっとした表現になります。

図116bitデータのままの画像
(図1 16bitデータのままの画像)

Bosonの場合16bit階調、Leptonの場合14bit階調で赤外線をセンスしますが、そのデータを画像として表現した場合、大きな温度差が存在しない画像、つまり自然な環境を撮影した場合は、ぼやっとしたモノクロ映像になります(図1)。
そこに何か赤外線を放射している物体があることを知ることができるかもしれませんが、画像としてみた場合は、視覚としてその差は感じづらくなります。そのため、16bitデータを、8bitデータへと圧縮して、画像として物体を認知し易くする処理を行います(図2)。 この処理は一般に”AGC”(Auto Gain Control)と呼ばれますが、この処理方法には様々な技術があり、赤外線カメラメーカーの特色が出る部分になります。

図2 前図と同じ画像に、ImageJによりAGCを施したもの
(図2 前図と同じ画像に、ImageJによりAGCを施したもの)

 

なお、圧縮、とした通り、16bitデータから8bitデータへと、規程の手法に基づいて変換が行われます。そのため、元の16bitデータが、撮影対象の赤外線放射量を取り込んでいて、正しく温度データを表現していたとしても、AGC処理後の8bitデータからは、それらを知ることはできなくなります。これは、Boson固有の現象ではなく、温度測定機能を持っているLeptonやTau2カメラでも同様の現象です。

 

次のページ

BBBの準備

BBBの準備

BBBとは、1GHzで動作するARM社Cortex-A8をコアにしたTI社のSitaraプロセッサを搭載したホビーユースをターゲットとした組み込みボードです。尚、Raspberry Pi3はBBBよりもっと高速なマルチコアSoCを搭載しており、Raspberry Pi2は近い性能を持っています。

このボードを新規に入手した場合でも、プリインストールされているOSが最新版とは限りません。「すでに組み込んだほかのアプリと共用なので」ということがなければ、最新OSへと更新したほうがよさそうです。

BBBは、当初はTi SoCベースの組み込みに強いAngstrom Linuxでサポートされましたが、eMMCが4GBになって以降はDebianが公式となっています。BeagleBone Black Supportに従って更新しておいてください。しかし、クロス開発を行える環境が揃っていない場合、BBB上にソフトのインストール,コンパイルが必要になりますから、最低8GBytes 程度のストレージ(eMMC + 4G microSDや8Gbytes以上のmicroSDをシステム全体として使う等)を確保してください。

このようなボードを、いきなり、何のPC環境もなく使う方はまずおられないだろうと思いますが、ここでは、キーボードやマウス、ディスプレイなどの「ヒューマンインターフェース」は使わずに、ホストとなるPCと、シリアルターミナルあるいは有線・無線ネットワークで接続する前提で使っていきます。スタンドアロンで進めることももちろんできますので、「ラズパイにキーボード、マウス、ディスプレイなどのヒューマンインターフェースは揃えてある」、という環境でも、以下確認可能です。

Bosonハードウエア

Bosonは、カメラモジュール単体ではCMOSイメージセンサ類似の信号線が取り出せるようになっています。それだけでは画像を取り出すために一つのシステムを必要とすることになり、赤外線カメラを利用するアイデアを実現するために大きなコストが必要になってしまいます。そのため、BosonにはUSB VPCという、カメラのサイズに合致したモジュールがあり、その名の通りUSBでホスト装置とインターフェースできるようになっています。

BosonとUSB VPC

図4 BosonとUSB VPC

たいていのPCにはUSBポートがありますから、それによってBosonの機能の確認や、アプリケーションシステムのリファレンス開発を検討することができるようになっています。すなわち、電源を入れれば(=USBケーブルを使ってホストに繋げば)、即UVCカメラとして動作しますので、特別BosonのAGC制御を切り替えるなど画像調整を必要としなければ、もうそのままで稼働させることができてしまいます。
UVCの他、オプションでアナログビデオ出力を取り出すこともできます。

BosonにはFLIRのボロメータに加えて、今までのFLIR製品にはない画像処理エンジンが組み込まれており、Bosonのアドバンテージを確認することができるWindowsアプリケーションソフトが標準搭載されています。従って、トータルシステムの外観構成が自由であれば、BosonとPCが一台あれば、それだけで遠赤外線を撮影するシステムを構成することができてしまいますが、この記事を読まれる方はたぶんそれでは満足されないであろうと思います。

Bosonソフトウエア

ソフトウエア観点でBosonを使用するときに知っておきたいことは、Bosonからは画像をUVC(VPCを用いない場合はUVCまたはパラレルデータ)で取り出すことができる、ということです。
Windowsの場合はDirectShow、Linuxの場合はVideo4Linux、というマルチメディアフレームワークがありますから、それらを使うことでUVCストリームをキャプチャし、画像として表示することができます。
次は、WindowsにインストールしたVLCを使って、DirectShowを経由してBoson画像をキャプチャした例になります。
Bosonには、既に述べた通りAGCを使ったり、その結果の、疑似カラー着色方法を設定するなどの制御があります。それには、USB CDCを用いて、Bosonに組み込まれている機能を制御します。
なお、Bosonが出力できる16bit生データの画像フォーマットは、Windowsでは直接サポートされていません。Windowsを用いてソフトウエア開発し、且つ16bit生データを必要とする場合はお問い合わせください。


図4 DirectSlowを使いVLCでチャプチャ
購入いただいた方には、Bosonを利用したシステム開発を行えるよう、SDKが配布されます。そのSDKを使うと、Boson Applicationと同等の機能を実装することができます。つまり、画像はUVCで流れる制御はCDC経由でSDKを用いて行なう、ということになります。

まず最初に、SDKを用いて、Boson Applicationが実現している機能のごく一部を実装してみようと思います。

Boson SDK

Boson SDKは、C、C#、Pythonによる開発に対応できるようになっています。どの言語を用いていただいても構いませんが、ここではデバッグが容易なPythonを使ってみたいと思います。 尚、このSDKは、もともとWindowsでの開発に対応している関係で、Linuxでの開発を行うためにはある程度修正が必要です。しかし、それほどOSそのものには依存していませんので、アプリケーションソフト ソースコードを入手して、自分でbuildする経験をお持ちであれば、十分対応できるものと思います。C#を除きパッチは用意していますので、必要であればお問い合わせください。
SDKは、(開発)言語依存部と、それぞれの言語で共通で使用するインターフェースライブラリの2つのブロックで構成されています。

システム構成のプラン

BBBにはUSB2.0 HSのOTGがありますから、そこにBosonを接続して画像を取り込み、Ethernet経由でネットワークに送出することができれば、いわゆるネットワークカメラとして機能させることができそうです。もし、無線LANが必要であれば、BBBのUSBポートにhubを接続することになりそうです。その場合、Bosonのキャプチャへの支障がないか、若干、気になります。

BosonのUVC

今回使っているBosonはQVGA、9fpsでの撮影となっています。FLIRの他製品のご多分に漏れず、AGCを施した画像の場合は、QVGAをVGA(640×512)へと拡大した画像が送られています。また、Bosonのピクセルデータは、AGC前・後を問わず16bitで表現されていますから、1フレーム送るためには約5Mbit(640x512x16bit)必要です。一秒あたり9フレーム(実際には8.6フレーム)ですので、約45Mbit/secondとなり、USB2.0HSであれば、よくある150Mbps対応の11n Wi-Fiでも、帯域的には対応できそうです。

システム構成

以上をまとめると、無線LANで構成した場合で、こんな感じでしょうか(図5)。ここでは、たまたま無線APがなく、開発用のWindows7 PCがあり、且つそれをSoftAPとして稼働させられましたので、この試験では、無線APの代わりにPCがAPを務めることになりました。これで、BBB上でUVCをキャプチャし、それをストリーミングサーバーを通してやれば、ネットワークカメラとして機能してくれそうです。
更に、SDKを通じてBosonを制御するため、BBBにSDKを実装する必要があります。

 

ネットワーク配信(図5 ネットワーク配信)

Pythonのインストール

BBBではDebian GNU Linux/stretchが稼働していますから、Pythonは2.7が標準でインストールされています。しかし、システム標準設定で要求される依存関係などを壊す可能性があるやもしれず、ここではpyenvを導入し、この時点で最新の3.6.2をビルドさせました。大体2時間コースだったでしょうか…。が、自動的にこの環境に合わせセットアップされるのは助かります。

ffmpegのインストール

動画像コーデックとしてはよく知られているffpmegを、Debianパッケージを使ってインストールすることにしました。ffmpegの良いところは、エンコーダ, ストリーミングサーバー,デコーダを同一のツールグループで実現でき、ツール間での齟齬が生じづらいこと、且つ、歴史のあるツールですので、トラブルも少ないだろう、との想定です。

ネットワーク画像配信の試験

上記の通り、画像だけは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上での画像表示とサンプルアプリケーション実行の様子
図6 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)を適切な位置に設置すれば、ネットワークカメラとして、ここまでの仕掛けで機能できそうだ、というイメージを持って頂けたのではなかろうかと思います。

ネットワーク配信実験の様子
図7.ネットワーク配信実験の様子

最後に

さて、以上から、Bosonに元々組み込まれている機能を利用するだけでも、「ネットワークサーマル監視カメラ」を構成できそうだ、しかも、SDKを使ってがしがしアプリケーションを書く必要があるわけでもないのでそれほど難易度も高くない、と感じていただけたのではないかと思います。
本格的な監視カメラとするためには、今何が写っているのか、写っているものは活動しているのかいないのか、等を組み込んでいく必要があるものと思います。
ここでは、画像を見ることを前提として、AGC処理後の画像をストリーミングしましたが、オブジェクト認識等を利用するためAGC処理前の画像を扱う、それをOpenCVで処理する、マシンラーニング/ディープラーニングを組み込む等、取り組んでみていただければと思います。

図8.試験装置構成(BBBとPCをつないでいるUSBは電源として使用

 

前のページ

BBBの準備

123
ページトップへ戻る