Leptonは、小型の安価な遠赤外線(LWIR)カメラモジュールで、80×60画素のLepton1.x/2.xシリーズと、160×120画素のLepton3.xシリーズのラインアップがあります。

本書は、Leptonを使ってお手軽(?)にサーマルイメージを得るPart.2になります。

図１　Leptonシリーズ

Breakout Board・PT1, PT2を用いたLeptonアプリケーション開発
Leptonの使用目的として、撮影対象の温度分布を知りたいことに加えて、実際の温度を知りたい、と、よく言われます。温度を知りたい対象に熱伝導率が良く熱抵抗が低い材質を使い、直接接触して温度を測る体温計のような接触式温度計と違い、撮影している対象が放射している赤外線を測定して間接的に温度を測る場合、しかもその撮影対象や使用する測定器つまりLeptonの付近に存在する、空気を含む物体が赤外線を放射あるいは吸収するため、精度よく撮影対象の温度を知ることは簡単ではありません。このような、非接触式温度計の精度や測定速度に関する議論は他のサイトに譲りたいと思いますが、関連してよく出される質問に、「温度（情報）はどうやったら取り出せるのか？」があります。画像が出力されていることは判るが、温度データは？ということですね。
Beaglebone BlackでFLIR Bosonを動かそうでも簡単に触れましたが、サーマルカメラは赤外線センサの集合体で、撮影対象の赤外線放射を、輝度として白黒撮影しています。すなわち、センサ出力が高い＝画として白いほど高温、ということになります。センサそれぞれの分解能は14ビットとなっており、その集合である撮影画像はraw14と呼ばれます。つまり、ラジオメトリ付きLeptonの場合は、ラジオメトリを有効にした時（TLinearを有効にした時）のraw14各ピクセルの値が、そのピクセルに対応する実際のシーンの温度を表現しています（ラジオメトリなしのLeptonの場合も同様ですが、その場合は気温や自温度による補正をされていませんので、直接、撮影対象の温度が示されてはいません。）すなわち、撮影によって対象物の温度を知りたい場合は、ラジオメトリ付きLeptonで、raw14画像を得る、それが温度データそのもの、ということになります。
一方、我々が一般的に目にする画像（写真やTV画像のような）は、8ビット階調（RGBあるいはYUV各色8ビット）で表現されており、サーマルカメラは、より高い分解能で撮影していることになります。つまり、あるピクセルにおいて、近隣ピクセルとそれほど大きな温度差が存在しない室温環境のような場合（大抵は、Leptonの場合撮影可能なシーンダイナミックレンジ-10～+140℃のうち、屋内なら気温程度～せいぜい+20℃程度が画像内の大部分）は、近隣の点との間ではっきりとしたコントラストにはなりません。図2は、LeptonではなくBosonを用いた画像になりますが、サーマルカメラの出力そのままでは、左側のように見えます。
 

図 2　左：raw　右；AGC後　カップにはお湯が入っているのだが…(データとしては400程度、20℃以上異なる)

分解能<50mKということは、1LSBの違いが0.050℃未満、ということですが、単純に、可視化のために、右詰めになっているraw14を左詰めに直して上位8ビットだけを取り出しても、かなりの温度差が無いと見分けがつかなくなることを意味しています（TLinearを有効にしている場合はraw14でも16bitデータです）。このため、「見る」ための画像では、温度の分布状況を元にして、いわゆるAGC処理（データ圧縮）を行うことでコントラストを作り、それに疑似カラー着色を行ないます。この過程で、そもそも持っていた温度情報は失われます。それが右側の画像になります。

Leptonは、自身でもAGC処理を行うことができます。しかし、画像出力は、FLIRの他のカメラと異なり1チャネルしかありませんから、AGC処理を行った画像を選択すると、ラジオメトリ付きLeptonであっても温度データを得ることはできません。従って、温度データを取得・記録などしたい場合は、raw14でLeptonから温度を取り出し、さらにその画像を「見る」必要があるならば、そのデータにLepton外部でAGC処理を施して、見るための画像を「作る」ことになります。

なお、LeptonのデフォルトではAGC処理は行わない設定となっています。LUA（Lepton　User Application）では、RawでAGC処理off、RGB888でAGC処理onとなっています。LUA上では、Rawを選択したときにはAGC処理を行った画像が表示されますが、その際の疑似カラーパレットはLUA上に用意していないのか、選択できません。

PT1, PT2の場合、Leptonからはraw14を出力させ、PT1, PT2搭載のMCUでAGC処理及び疑似カラー着色をプログラムすることも可能です。PT1, PT2用のファームウエアソースコードはGitHubで公開されていますから、そちらを確認してみてください。

Breakout Boardを用いる場合、Lepton自身でのAGC処理設定に応じたデータをVoSPIでキャプチャしますが、raw14で出力させた場合に画像として見たい場合は、ユーザーアプリケーションとしてAGC処理・疑似カラー着色をプログラムすることになります。

次の表は、それらの関係をまとめてみたものです。

組込プラットホーム、特にARM等組み込みターゲットのSoCを使っている場合、SPIやI2Cにアクセスすることが比較的容易でしょうから、Breakout Boardを使用した開発に取り組むことも比較的容易かと思います。しかし、そういった端子に空きが無かったり、そもそも存在していない、というケースもあるかもしれません。そのような場合にはft232のようなUSB – SPI, I2Cブリッジデバイスの利用を検討することができるかもしれません。そのような事例を紹介されておられるサイトもありますので、探してみてください。

Leptonは、I2Cを経由して、SDKによりAGCのon/offや疑似カラーテーブルの選択などのコントロールが可能です。Software IDDというドキュメントに、バイナリで記載されているコマンドを、ハンドシェイクプロトコル（パケットプロトコル）に乗せ制御を行います。この、コマンドビット列とパケットプロトコルを組み合わせて、プログラミングしやすいようラッピングしたものが、SDKとして、FLIRサイトにて提供されています。
このSDKは、part.1で述べた通り特定の環境に依存しているため、どんな環境にもそのまま載せることができる、というわけにはいきません。FLIRのフォーラムを見ていると、buildできず、サポート情報が得られないため、そこで利用が止まってしまっているケースもあるように見受けられます。
FLIRが公式にサポートするものではありませんが、 GitHub LeptonModule に、この問題に対応した版のSDKが置かれています。すなわち、PT1に適した構成のもの、そして、Linux側に設けられているI2C・SPI界面でLeptonをコントロールできるようにしているものになります。
なお、PT1, PT2では、ファームウエアを直接変更せずとも、UVCを通じてLeptonにコマンドを送れるようになっています。詳しくはGetThermalソースコードを確認してみてください。
 
Lepton User ApplicationによるLeptonの制御
SDKにはSoftware IDDというドキュメントが付属しています。そのドキュメントには、ソフトウエアモジュールIDとコマンドIDが記載されており、かつ、SDKコマンド名も併記されています。つまり、SDKコマンドを使って関数コールとしてソフトウエア開発を行う手法と、モジュールID・コマンドIDを使いコマンドを構成して実行する方法の二通りがあることを意味します。後者の方法は、以前からFLIR社のカメラモジュールをお使いの方であればご存知かもしれません、Camera Controller GUIで、カメラに対してコマンドを与える手法と同一ですので、Lepton User Applicationでもその手法を踏襲しているということになります。お持ちの方は、Diagnostic Tools内のADVANCEDになりますのでお試しください。
SDKおよびSoftware IDDの入手には、登録を行っていただく必要がありますので、ここで詳細の説明はできませんが、コマンドには次の3種類があります。
Lepton設定値を得るGet
Lepton設定値を与えるSet
Lepton組込機能を実行するRun
例えばLeptonのシリアル番号（SYS FLIR Serial Number）を知るにはGetを用いますが、SDK Module ID = 0x0200、Command ID = 0x08で、戻されるデータ長は4ワード（32bit4語）になりますので、Commandとして0x0208、Size (WORD)には４を設定して、GETボタンを押すと、シリアル番号がResultフィールドに返されます。この値は16進数4ワードで返されていますが、それを10進数に直すと、おなじDiagnostic ToolsのDEVICE INFORMATIONに記載されているSerial Numberと一致することを確認いただけるものと思います。

図 3 Lepton User Applicationを用いたコマンド投入

この機能により、コマンド実行による機能・効果の確認を行うこともできるものと思います。

2章 Leptonを動作させるうえでの問題
Leptonはソケットに搭載して使う前提となっているわけですが、時に、この、ソケットの「座り」が問題になることがあります。Leptonとソケットは、爪で噛み合うようになっているのですが、基板を落としたりすると外れてしまうことがあります。シャッターが搭載されるようになったLepton2.0以降では、シャッターが脱落することもあります。
Leptonがちゃんとソケットに鎮座しているのかどうか、パッと見ただけでは判りづらく、「PT2でLeptonが動作しないんだけど」というお問い合わせを頂くこともあります。LUAのDiagnostic Toolsを使ってデバイス情報が読み出せないといった場合は、大抵、ソケットとLepton端子が接触していないことが原因ですので、一度、ぐっと、押し込んでみてください。（シャッター付きLeptonの場合は強すぎないように注意…）
また、Leptonを搭載した基板は、筐体に納めるなどに際し、振動や落下によりLeptonがソケットから浮かないような処置、具体的には筐体などとLepton搭載基板でサンドイッチするといった構造をとることをお勧めします。しかし、接着剤などの利用はトラブルの原因になりますし、サポートできなくなりますのでご注意ください。
そのほか、FLIRのコミュニティフォーラム、あるいは、GitHubのようなコミュニティフォーラムなど見てみると、特にLepton3.xとBreakout boardの組み合わせの場合に、数分～数時間稼働させると止まってしまうのだが、という投稿を見かけます。十分な回答が見当たらず、不満に思われているかもしれません。しかしながら、PT1やPT2で稼働させる事例では、そのような問題は聞きません。
この違いはどこから来るのでしょうか？
Part.1にて紹介した、mbed用のコードNucleo_leptonを使って、そのコード構造を保ったままLCDに画像を出してみよう等、処理を加えてみようとすると、途端に取り込めるデータ（つまり画像）がおかしくなります。この状態は、規定のタイミングでLeptonが出力するデータを取り込めずにいると発生します。そのような状態を発生させる他の例として、マルチタスクOSが走行するシステム上では、外部バスアクセスが引き延ばされたり、延期されたり、中断されたりする可能性があります。シングルタスクの場合でも、上述のようにSPIバスアクセスの合間の処理量によっては、Leptonが期待するタイミングでの動作が行われないケースがあるかもしれず、時間管理が必要になります。
 
次回へ続く・・