Edison君に遊ばれている。UVCカメラの電池駆動の企みは難航

せっかくのUVCカメラが消える(2/22/2015)
　久しぶりのLinuxである。Edisonカーネルのビルドは出来たが、元のカーネルが既にUVCカメラをサポートしていることを知って、ビルドを中止し、あちこち（こことか、ここ）のサイトを拾い読みして映像配信（ビデオストリーミング）の実現を先に進めることにした。

　まず、このサイトのffmpegを使ったストリーミングサーバーに挑戦する。ところがリソースをとってくるgitが動かない。gitなどないというメッセージだ。このEdisonのパッケージシステムはopkgと言って、Ubuntuのapt-getと同じようなスタイルなのだが、とりに行くサイトのURLは自分で登録しなければならない。しかも、公式のものより、非公式のこれが良いと勧めるサイトもある。

　この登録しておかないと読みにいかないということがわかるまで暫く四苦八苦していた。映像配信については参考にするサイトが複数あるのだが、手順が微妙に違うので大変である。それにPCのOSがLinuxのときは（カーネルのコンパイルはここでしかできない）、今入力している端末がUbuntuへのものか、Edisonのものかが途中でわからなくなって混乱する。

　やっとのことで、ストリーミングサーバーのインストールに成功した。ただちに実行コマンドを投入する。うむ、動いたぞ。メッセージが出てきた。何い、カメラがない？　本当だ、USBカメラがなくなっている(dev/video0がNot Found)。

　どうしてだろう。アプリをインストールしただけでUSBのUVCカメラを認識しなくなった。何回か試してUVCカメラが入っていないことを確認する。そのうち、カーネルブートの途中で怪しいエラーメッセージがでているのを発見した。

　おやおや、kernel moduleの組み込みに失敗したというメッセージだ。途中から入るディバイスドライバーがインストールされないのでUSB関係は全滅だ。うーむ、わからない。これまでに入れた、ストリーミングサーバーと、カメラの画像を配信するソフトが悪さをしたのか。詳しく調べると、bcm_bt_lpmというモジュールが見つからないというメッセージである。これだけでは全くわからない。

　わけもわからず、ソフトをインストールしまくってきたので、原因の追究はほとんど不可能である。これらの映像配信ソフトは、新しいカーネルが前提なので、今のものと不整合になっていることは十分あり得る。インストールの途中で、こうした設定ファイルを壊したのかもしれない。

　というので、中止していたカーネルのビルドを最後までやってみることにした。これがまた長い。 PCのUbuntuでの作業である。カーネルイメージを作るステップで、ただファイルを焼くだけだと思っていたが、3325もの作業ステップがある。延々と何やら作り替えている。結局2時間6 分もかかった。やっとのことでPCにカーネルイメージが出来たようだ。

　いよいよ、Edison本体に焼込である。祈る気持ちでスクリプトコマンドを入力する。これはそれほど時間がかからなかった。さあ、カーネルが新しくなった。勇んでリブートをかける。ありゃあ、同じところでエラーが出たようだ。

　まちがいない。dmesgで確認すると、全く同じ状況でUSBディバイスがインストールされない。こうなると元のカーネルに戻すしかないが、その方法は急にはわからない。当然、無線LANも初期状態に戻っている。初期状態に戻せなければ、Edison君がゴミに近い状態になってしまう。顔が青ざめてくる。

　気分を鎮めて、周辺を確認する。救いは、エラーは出ているがシステムは立ち上がっていることである。カーネルでのUSBは認めないが、コンソールのCOM7はブレークアウト基板にある独立したUSB-TTLモジュールを使っているので、シリアルコンソールは動く。

ダメもとのreboot otaで復活。映像配信まであと少しなのだが(2/23/2015)
　USBソケットからではなく電源ピンからの給電でEdisonは動くことはわかった。まずは一安心である。現在の状況をまとめてみると、J16からのファーム焼込は不能。カーネルモジュールの読み込みがエラーでできないのでUSB関係は動かない。PCからは何も見えない。

　J3のシリアルコンソールは動いているので、ここのシェルを経由してOSにコマンドを送ることは出来る。とにかく、わからないが、スイッチサイエンスの「買ったときに最初にやる方法」をやってみることにした。動いているシェルから、roboot ota を入れてみた。マスストレージのイメージは消えていないだろうという読みである。

　余り期待をしていなかったのだが、これが見事に動き始めた。順調にファームを書き換えて行く。そもそもこのreboot otaというのが何をするステップなのかわかっていないのだが、とりあえず何かやっているようなので期待は持てる。

　再構築が終わったというメッセージが出た。もう一度電源を入り切りして立ち上げ直す。なんと、あのエラーメッセージが消えた。NO ERRORでシステムが立ちあがった。いやあ、助かった。今まで入れたパッケージは消えたが、初期出荷時に戻ったことは間違いない。

　もういちどopkgをインストールしなおし、gitも入れる。段々様子がわかってきた。インストールしたffmpegは動いている。UVCカメラに作動中のLEDが点くので、このあたりは問題なさそうだ。nodejsのサーバーも動いている。不思議なことに今度はブート時のエラーメッセージは出ない。

　両方のパイプ（カメラとffmpeg、ffmpegからサーバー）も、どちらかを切ると反応があるので映像は送られているようだ。しかし、ストリーミングの映像を確認することが出来ない。うーむ、あと少しなんだけどな。

mjpg-streamerで念願の画像表示成功(2/25/2015)
　ffmpegが難航しているので、このあいだのRaspiで最初に動かしたmjpg-streamerを試してみた。こいつはソースからコンパイルしなければならない。道が遠いので敬遠していたのだが、そうも言っていられない。

　以前のRasPiのときは難航したcvnからのソースダウンロードは幸いあっさりOKとなった。opkgとgitを最新のものにしたからかもしれない。コンパイルも順調に終わった。動かしてみた。

　やったー、こちらは案外あっさり絵が出た。一度RasPiで動かしているからか。 　2回目の成功とはいえ、やっぱり嬉しい。フレームレート15で640x480の映像が、快調に配信される。記念すべき、Edisonからの画像配信である。

　それにしてもたいしたものだ。カメラのUSBケーブルの方が重くて小さな本体が振り回されている。こんなちっぽけなものがWiFiを通して画像を送り出しているのだ。 　これを電池駆動で動かせたら、移動体からの画像発信という夢の実現である。暫くカメラを動かして遊ぶ。ただ、このmjpg-streamerのHTTPサーバーの部分の改良は前に失敗している。このままでは、自分の好みの画面にすることは難しい。

　ということで、この前、途中のままだったffmpegの方を再挑戦することにした。この組み合せのサーバーには、耳新しいwebsocketという、これまでお馴染みのHTTPサーバーを使わないプロトコルを使った方式だという。

　この前、動かしたときEdison側は正常に動いたように見えた（エラーメッセージがないだけだが）。しかし、クライアントのPC側では画面枠はでるものの画像そのものを見ることが出来ない。mjpg-streamerの方が動いたので、少し余裕を持ってこのwebsocketと言う手法を少し丁寧に勉強してみることにした。

驚異のnode.js。websocketという新しいプロトコルで画像が出た(2/28/2015)
　この方式はHTTPサーバーを経由するのではなく、nodeというスクリプト処理プログラムでHTTPドキュメントを送るらしい。ひとつひとつがシングルスレッドで動く。つまりクライアント側とは常に一対一なので、多数で動かすときはかえって効率が良いのだという。

　確かに、マルチCPUがクライアント側でも当たり前になったり、回線の容量が桁違いに増えた状況では、Apacheなどの少数のサーバーにデータを集中してリクエストを一元化しているより早くなるのかもしれない。

　理屈はわかったが、実装がどうもまだ理解できない。node.jsというスクリプトマネージャーのようなところで、HTTPドキュメントを送っているようだが、具体的なデータの授受の手法は全く理解できない。

　実際に動かしてみると、エラーもなく動いているようで、クライアント側も反応があるのだが、画面の枠だけが表示されて、画像は出ない状況である。とにかく何を調べれば良いのか全く見当はつかない。

　ところが、PCでLinuxを立ち上げて、ウェブブラウザー（FireFox）を動かしていた時のことである。試しにURLを入れてみたら、突然、画像が表示されたのである。何だ、何だ、動いているではないか。画素数が320X240で荒いけれど間違いなくUVCカメラの画像である。

　パラメーターを640X480に換えて再始動してみる。ちゃんと高解像度で立ち上がった。何ということだ。Linuxでは動いていたのだ。慌てて、OSをWindow7側に切り替えてみる。やっぱりWindowsでは動かない。FireFox、IE、Crome、どのブラウザーもことごとく画面枠だけで表示されない。

　しかもLinux側では、IPアドレスではなく、node.jsに定義したEdisonサーバーのドメイン名を、クライアント側で入れるだけでリンクしてしまう。ええー、PCホストの/hostsやネームサーバーに登録もしていないのにどうして？

　いや、今までの概念を超えた方式のようで、まだ何が何だか良くわからない。Windowsでは動かないが、まあ、ここまでくれば上等だ。カメラを車に積んで景色を外に配信することは夢ではなくなった。

　残る問題は、カメラを含む大電力の供給である。Edisonは7.5Vから15Vの外部電源を要求する。これはUSBを含めた大きな消費電力を安定的に供給するためのマージンをとっているからと思われるが、この供給には、結構大きな電池が必要である。

　車載カメラの課題は、Edison本体から、電源の問題に移ったようである。

モバイルで動かそうと高出力DC-DCコンバーターにはまる(3/4/2015)
　Edisonによる車載カメラのプロジェクト(自然発生的だが)は、バッテリー電源の実装の段階に来た。その前に、実際のEdisonの消費電力を調べてみた。以下の数字はすべて7.5VのACアダプター経由で、1オームのシャント抵抗で測った電流値である。

　OSを立ち上げてアプリが動いていないとき　　　　　50mA
　ブート時やTopなどの常駐アプリ稼働時　　　　　～120mA
　USB UVCカメラを接続し、OSが認識  　　　　　　～150mA  
　Mjpg-streamer 静止画　  　　　　　　　　 　　　　  ～250mA    
　　　　　同上　　　　動画　　  　　　　　　     　　　平均350mA

始めマルチメーターで測ったときは、ピークが1Aを超す時があったので心配したが、オシロで確認してみると、1Aを越えるときは一瞬のピークの時だけで、ほとんどは上記の範囲に収まっていた。

　さて、7.5V以上のDC電源である。一番早い解決は、リチウム充電池(3.7～4.2V)を2つ直列にして、7.4～8.2Vを得ることである。余りにも芸がないが、これで動けば何の問題もない。実際に動かしてみた。

　ところが、UVCカメラを動かすあたりから動作がおかしくなり、現実に画像を送り出すには、この850mAhのバッテリーでは容量が足りないようだ。恐らく大電流時に電源電圧が規定より下がってしまうからだろう。もっと大きな容量のバッテリーか、電圧を上げる必要がある。

　さあ、困った。ちょっと前から、可搬で動かそうと、リチウムバッテリーひとつで7V以上をだすDCDCコンバーターの試作が難航している上に、究極の解決法も見事失敗した。別の方法を考えなければいけない。

　現在、試作しているコンバーターは、NJM2360がターゲットである。手持ちにはLM2735という新世代のチップがあるが、こいつは、既に何個か壊して少し挑戦する意欲が失われている。NJM2360の方は、沢山の方が色々試されており情報が豊富だ。とりあえずはこちらで進めている。

　外付けのパワーTRをつけると2A以上の出力が出せるらしい。トランジスターは発熱するので、どうせ作るなら、ここをFETにしようと回路図を探すのだが、なかなか適当なものが見つからない。

　それでも、いくつか回路例が見つかったので、手持ちのFETで回路を組んでみるが全然ダメである。始めブレッドボードのためかと思ったが、調べを進めるうち、リチウムバッテリーのような低電圧では、FETのゲートをドライブできないことがわかる。

　モータードライバーに使ったFETアレイ（MP4401)が、低電圧でも(2.5V)で動きそうなのを発見して、急遽さしかえる。動いたぞ。いや、リチウムバッテリーだけでは無負荷の時に電圧がでても、ちょっと負荷をかけると途端に電圧が下がってしまう。試しに、Edisonをつないでみるが、思った通り、立ち上がるものの、すぐ電圧が低下してリセットしてしまい使えない。

　いつものように、はまりだすと止まらないのが所長の悪い癖である。NJM2360にこだわってしまった。ストロベリーリナックスのDCDCコンバーター(LM2735)は、800mA(12V)が出せるというのをみて意地になってしまったこともある。

NJM2360にパワートランジスターを外付けしても動かない(3/8/2015)
　秋葉原に出た時に、秋月で、パワートランジスター(2SC3694)とゲート閾値電圧の低いFET（IRLB8721）、それにトロイダルのインダクターなどの部品を揃えた。本格的なDC-DCコンバーターを作る覚悟である。完全なプロジェクトの脱線だが、これはいつものことだ。

　まずはデータシートにも紹介されている外付けトランジスターによる出力である。これがうんともすんともいわない。ブレッドボードが原因ではないだろう。トランジスターのないときは快調に既定の電圧が出る。

　何度か、配線を確かめるが誤りはない。部品の定数を替えたりブレッドボードの配線を変えたりするが変化はない。どうも基本的なところが間違っているように見えるが、データシートを見ても間違っていない。インダクターをトロイダルに変えると、FETも入れない裸のNJM2360の方が、高出力になったりして気に入らないのだが、もっと気に入らないのがこのTRの不動作である。

　思いあぐねていたころ、ふと、トランジスターなどの極性を調べるテスターを以前面白がって買ってあったことを思い出した。（DCA75）。まさかと思うが、これでパワートランジスターの極性を調べてみよう。部品棚からDCA75を取り出して、早速測ってみた。なんとなんと、これがあたりであったのである。

　驚くことにパワートランジスターのピンの順番は、2SC1815などの小さなTO-92パッケージのものとは逆だったのだ。小さい方は、ラベルを見ながら左からECBなのだが、2SC3694のような　TO-220タイプのピンは、ラベルを前にして左からBCEなのだ。

　データシートにはちゃんとそう書いてある。しかし思い込みとは恐ろしいものである。ふんふん、左からECBねと、ろくに確認もせず配線していた。パワートランジスターだから逆差ししても何にも起こらなかったけれど、いやいやお恥ずかしい。

NiMH電池でも、DC-DCコンバーターでは動かず(3/10/2015)
　トランジスター外付けのNJM2360はピンアサインを正しくして何事もなく動作した。負荷抵抗をつけて出力電流を測定する。インダクターをトロイダルの大型(9A)を入れたりすると、さすがに単独より大きな電流(350mAぐらいまで)を大した電圧降下もなく(7.5V設定で、7.02V)取り出せる。

　ブレッドボードなので少し不安があるが、こんなものだろう。まずリチウムバッテリーの電源でやってみる。いや、これは単独の時と同じで、Edisonの立ち上がりまでが精いっぱいで、USBカメラを付けた時点でハングする。トランジスターの外付けの効果はない。

　さてそれでは、用意したエネループ電池（NiMH）ではどうだろう。4ケ用意したので1.4X4=5.6Vまで上がるし容量も心配ないはずだ。動かしてみる。Edisonの立ち上がりは勿論OK。USBカメラも問題ない。さあ、最後のストリームサーバーの始動だ。

　残念、ストリームサーバーを動かした時点でシステムが不安定になり、ネットが落ちた。うーむ、難しいものだ。当面の方策はすべて失敗である。どうもお店を広げすぎたようだ。このへんで、戦線を整理し、ブログに報告することとしよう。