はじめに
当サイトでは現在、オンセミ社様のPYTHON300というイメージセンサーと Spartan-7 FPGA を組み合わせて、KV260 向けにグローバルシャッターの高速度カメラモジュールを開発中です。
ようやく少し動き始め、撮影を行ったものが下記です。
ようやく、研究開発目的などでは使えそうな雰囲気が出てきましたので、少し途中経過を技術記事にしたいと思います。
オープンかつ安価で高速なイメージセンサー
当サイトの追い求めるような応答性の高い高速度撮影ができるイメージセンサーとしては、同社のイメージセンサーとしては他に LUPA3000 などのシリーズが存在するようですが、研究開発目的で数個だけ DigiKey などで購入することを考えると、価格的には PYTHON300 はかなり魅力的な価格帯となっているようです。
記憶違いがあるかもしれませんが、確かオンセミ社さんが Truesense Imaging や Aptina Imaging を吸収合併した流れの中で、似たようなシリーズが同一メーカー内に混在していたような記憶があります。
さて、この PYTHON300 ですが、データシートを見ると、VGAで815fps という大変魅力的なスペックとともに、内部のレジスタなど大変詳しく書かれています。
また通常のCMOSイメージセンサーはフレームレートを上げるには読み出すライン数を減らすしかなく、速くするほど横長の画像になるのですが、このセンサーはライン単位ではなく 1×16 のブロックの単位で何かやっているようで、ラインを減らすだけではなく、横方向のピクセル数を減らしてもフレームレートが上がる特殊なセンサーで、「256×256 で 1000fps撮影したい」などと言っている当サイトにはぴったりのセンサーです。
また、イメージセンサーのメーカーの中には NDA を結ばないとデータシートを頂けないところも多数あります。一方でひとたびNDAを結んでしまうと、その情報を使って作った基板設計やソフトウェアなどをオープンソースとして公開することが難しくなります。
ところが、このセンサーは Digikey や Mouser で購入可能な上に、基板設計や、FPGA回路、ソフトウェアを書くのに必要そうな情報がある程度データシートで公開されていそうです。
つまり、オープンハードウェアとして、カメラを開発し、その上で行った研究開発成果などを、公の場で発表したり情報交換できることを意味します。
もちろんちゃんとした製品カメラを作るにはNDAを結ぶことが必要と思われますが、当方はオープンであることを重視する為、あえてそのような手段はとらず、公に公開されている情報だけを用いて、より広い活動を行っていきたいと考えています。
ブートシーケンスとダウンシーケンス
データシートによると、 vdd_18、vdd_33、vdd_pix_クロック供給、reset_n の順で 10us ごとの間隔をあけて立ち上げ、パワーダウンはその逆を行う事を要求しています。
そこで今回はこれらの制御をすべて Spartan-7 から行う回路構成にしています。基本はFPGAから電源ON/OFFやクロック供給などを行うようにしています。
パワーダウンだけは不測の事態を加味して、PGOOD信号を監視して、FPGAが動作不能に陥る前にパワーダウンシーケンスが走るようにしています。
レジスタ表はデータシートに記載があるので、こちらも順にリセットを解除するなど立ち上げていきます。
下記は試行錯誤中ですので正しい手順ではない可能性は高いですが、今のコードです。
// センサー起動
spi_write(i2c, 16, 0x0003); // power_down 0:pwd_n, 1:PLL enable, 2: PLL Bypass
spi_write(i2c, 32, 0x0007); // config0 (10bit mode) 0: enable_analog, 1: enabale_log, 2: select PLL
spi_write(i2c, 8, 0x0000); // pll_soft_reset, pll_lock_soft_reset
spi_write(i2c, 9, 0x0000); // cgen_soft_reset
spi_write(i2c, 34, 0x1); // config0 Logic General Enable Configuration
spi_write(i2c, 40, 0x7); // image_core_config0
spi_write(i2c, 48, 0x1); // AFE Power down for AFE’s
spi_write(i2c, 64, 0x1); // Bias Bias Power Down Configuration
spi_write(i2c, 72, 0x2227); // Charge Pump
spi_write(i2c, 112, 0x7); // Serializers/LVDS/IO
spi_write(i2c, 10, 0x0000); // soft_reset_analog
続けてサイズ設定して、動作開始したところ映像データがLVDSから出始めました。
正し画像データを出す前のトレーニングパターンが出ている段階で、FPGAのLVDS受信の調整を行っておく必要があります(SERDESのbitslipなどbit境界の調整)。
// サイズ設定
int roi_x = ((672 - width) / 2) & ~0x0f; // 16の倍数
int roi_y = ((512 - height) / 2) & ~0x01; // 2の倍数
int x_start = roi_x / 8;
int x_end = x_start + width/8 - 1 ;
int y_start = roi_y;
int y_end = y_start + height - 1;
spi_write(i2c, 256, (x_end << 8) | x_start); // y_end
spi_write(i2c, 257, y_start); // y_start
spi_write(i2c, 258, y_end); // y_end
spi_write(i2c, 192, 0x0); // 動作停止(トレーニングパターン出力状態へ)
// ここでFPGA側の受信をトレーニングパターンで調整
// 動作開始
spi_write(i2c, 192, 0x1);
ZROTモードとは?
データシートを見ていてまず気になったのが ZROT モードというものです。
どうやらこのセンサーには ZROT(Zero Row Overhead Time)モードと NROT (Normal Row Overhead Time)モードの2つのモードがあるようです。
そして ZROTモードだと815fps で、NROTモードで 545 fps と記載されているようなので、ZROTモードが使いたくなってきます。
どいうやら 192 番地の 2bit 目にある zero_rot_enable を設定し 193 番地 xsm_delay を設定すると、Row Overhead Time が調整できるようです。
が、調子に乗って、xsm_delay をどんどん小さくしていくと、下記のように左側がどんどん暗くなっていきました。CMOSイメージセンサーでは通常はライン単位などで、CDS(相関二重サンプリング)してADCしてデジタルデータにするのに時間がかかるはずなので、ここをゼロにできるモード自体が不思議な感じがします。
データシートによると AND9362/D というアプリケーションノートに詳しく書かれているそうなのですが、閲覧には NDA が必要そうなので、ここは潔く諦めることにします。

一方で、左端の黒くなる領域が出ないぎりぎりまで xsm_delay を調整した場合でも、NROTモードよりかは少し早くなるようです。もともとKV260への転送がMIPIコネクタでそちらの帯域制限もあるので、ここは無理をせず、公知の情報で使える範囲で限界を目指します。
具体的には xsm_delay=39 で運用するとわりといい感じの撮影結果になっており、下記のような撮影性能が確認できました。

ResNet や YOLO などの古典的なCNNなどでも例えば 258×256 であったり、416×416 であったりといったサイズは使われてますので、高速度撮影であっても、そのレベルの画像認識センシングには使える撮像が行えそうに思えます。
近日公開を目指したい
ソフトウェアであればまず GitHub で公開してからデバッグするのですが、さすがに基板となると、製造しても動かないものを公開するのは悲劇しか生まない気がしているので、もう少しデバッグが進んでから設計も公開したいと思っています。非商用には自由に使えるようにできればと思います。
現在わかっている課題は
- Spartan-7 用の Config-ROM の品番を間違えて、認識できないものを張ってしまった(これは同じフットプリントの適合品があるので品番変えるだけ)
- KV260 から直接取っている3.3VがイメージセンサONで3.14Vぐらいまで低下している。
(もう少し解析してから、昇圧回路を追加することも検討中)
と言ったところです。他にもいろいろ課題は出てくるかもしれませんが、とにもかくにも動画を撮影することろまでは来ております。
おわりに
イメージセンシングの世界は、撮像を工夫するだけでまだまだいろんなことが出来ると思います。
市販カメラで撮った RGB 画像だけで深層学習を頑張るよりも、撮影を工夫することで新しいアイデアを試して差別化する余地も沢山あると思います。
一方で、データシートのあるイメージセンサがFPGAに直結出来ていて、回路図があって、自由にプログラムできるカメラというのもなかなかないのが現状です。
もっと、多くの方で、オープンに情報交換しながら研究開発ができるカメラが作れればと思います。
なかなか時間がとれず、ゆっくりとした開発にはなっておりますが、引き続きご支援よろしくお願いいたします。
コメント