SDK

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が期待するタイミングでの動作が行われないケースがあるかもしれず、時間管理が必要になります。

 

次回へ続く・・