« 2013年8月 | トップページ | 2013年10月 »

2013年9月の2件の記事

2013年9月30日 (月)

RaspberryPiのライブカメラをストリーム画面で操作する

 RaspberryPiを使った猫監視用の自宅ライブカメラプロジェクトは、もうあと一息のところまで来た。残る次の課題は、ストリーミング映像(ポート8080)と、カメラの操作(SSHでポート22)でわかれている経路の一本化である。

 前回の記事にあるようにカメラの遠隔操作には成功した。しかしカメラ操作は、SSHのコマンド経由で、外部に向けてのポートが2つも開いている。不用心だ。それよりなによりコンソールのコマンドでカメラを動かすのでは実用性はほぼゼロである。

 ストリーム画像が出ているブラウザー画面にカメラの操作(パンとチルト)ボタンを追加し、CGIでGPIOを動かす機能の開発が残っている。これにより始めて一般ユーザー(家族だけだが)が使えるレベルになる。

Chrome_title  ストリーミングサーバーにしているmjpg-streamerには、本格的なホームページが用意され、HTMLサーバーも内蔵しているようなので、ここにカメラの操作指示ボタンを埋め込むのは、簡単にできると思っていた。ところが、これが難航したのである(まあ、へそ曲がりの癖がまた出たこともあるが)。

以下は、2週間の悪戦苦闘の記録である。

本格的なウェブページの改修に四苦八苦(9/15/2013)
 mjpg-streamerは、テスト用にウェブページが用意されており、出力プラグインには、自前のHTTPサーバーまで装備されている。普通にポート80でアクセスすると、しゃれたホームページが出現する。

Mjpghome  このホームページは、静止画から、単純なモーションJPEGのストリーミング、JavaScriptを使ったクライアント側でのストリーミング(これでIE6でもストリーミング可能)まで、複数の環境をサポートしており、ここに4つのカメラの方向指示ボタンを埋め込むのは簡単だと当初考えていた。

 しかし、このページは調べ始めると、相当高度なテクニックで作られていて、構造も複雑である。新たに機能を追加するのは容易に出来そうもない。カメラの操作ボタンまでついたJavaScriptの派生ページを見つけたが、こちらはこのあたりは素人同然なので全く手も足も出ない。

 しかも、このホームページのプロトコルは、HTMLでなくてXHTMLという新しい規格だ。スタイルシートはもちろん派手に使われ多数の外部ファイルがある。xformというHTMLの進化したタグまで使われているようだ。良くわからないが、時代の先端を行くページ構成のようだ。

 こちらは特に凝ったボタンを考えているわけではない。もともと、このホームページには画像を反転させたり、回転させたりするボタンが付いている。このボタン機能を真似れば、今、#22ポートでやっているGPIOの操作が動くはずだ。しかし、ソースは凝ったJavaScriptで書かれているので簡単には解読できない。

 所長は、HTML時代にはとっくに現場を離れているので、この世界は通り一遍の知識しかない。このあいだ仕事でホームページを制作する機会があったが、素人の作るホームページとプロの仕上がりレベルは、もう桁違いに違うので早々に自作を諦めて外注に出した(市販のホームページ制作ソフトまで用意したのだが)。

 mjpg-streamerのホームページを参考にせず、別の簡単なindex.htmlをいちから作り直したほうが早そうだったが、このJavaScript満載のソースを前に、すごすご退散するのは悔しい。逃げていてはいつまで経っても技術向上は望めない。生来の負けず嫌いの精神がまたむくむくと起き上がった。ちょうど良い機会である。少しはウェブページ制作に慣れておこうと腰をすえて本格的に挑戦してみることにした。

うーむ、JavaScriptではサーバーのコマンドを動かせない(9/17/2013)
 まず、このmjpg-serverの内蔵サーバーのドキュメントを探すが、どうも要約しかない。開発サイトのフォーラムなどを読んでいると、開発は止まっているようだが、「ソースを提供するから自分で好きにやってくれ」という姿勢のようだ。細かい仕様も見当たらない。仕方がない。少しづつ、HTMLソースから調べ始める。

 HTMLソースを読み込んでみると、スケルトンとしてのHTMLの構造は意外に簡単で、かなりの部分はスタイルシートで飾られていることがわかった。スタイルシート(CSS)も生半可な知識しかない。ちょうど良いチャンスだ。この際、CSSも本格的に勉強することにする。

 要するにスタイルシートの理念は、HTMLの文書の構造と、文書自体の修飾方法を分離させ、フォントや、位置、画像などのオブジェクトの取り扱いを独立して定義し、多種類の出力媒体(大小のPC画面、携帯やスマホ、タブレット)にも対応しようと言うことなのだ。

 これまで、やたらと複雑なスタイルシートに悩まされていたのだが、少し飲み込めてきた。ここが丁寧に教えてくれる。 こういう風に、「何故こんなことをするのか」という理由を先に教えられると、こういう規格は飲み込みが早い。

 スタイルシートの部分は殆ど理解できた。そろそろCGIの手順を考えなければいけない。改めて、ソースを調べる。おやあ、このソースの大部分の関数は、JavaScriptで書かれている。しかも、組み込みではなく外部ファイルになっている。

 JavaScriptの勉強をさらに続ける。JavaScriptの多彩な機能に感心するが、何かおかしい。CGIの部分が見つからないのだ。ウェブで手当たり次第に検索しながら機能をしらべるが、今ひとつ判然としない。

 どうも、JavaScriptはクライアント側のサービスで、今やろうとしているサーバー側のシェルスクリプトや、perlなどのCGIプログラムを駆動することは出来ないような気がする。調べていてもはっきりしないので、実際に適当なテスト用のHTMLファイルを用意して、CGIのテストを始めることにした。

mjpg-streamerのサーバーはCGIをサポートしていないことが判明(9/21/201)
 ところが、このmjpg-streamerのHTTPサーバーは、CGIそのものが通らないのだ。CGIは簡単にサーバー側の環境を変えることができるので、セキュリティが厳しいのはわかるが、HTMLソースをどんどん簡単にしていっても、CGIのシェルスクリプトや、perlプログラムが動かないのである。

 エラーメッセージは、Not Found 404だったり、MIME Error(400)とかNo file extention(500)だったり、ファイルタイプや、場所によって微妙に違う。ウェブのあちらこちらをさまよって、HTTPサーバーの勉強を続けるが、このパッケージが装備しているHTTPサーバーの仕様がわからない。

 Cソースまでついているのだが、1500ステップ以上あるソースコードを調べる気にはならない。HTTP:1.0準拠ということなので(これは開発サイトに明記してあった)cgiスクリプトはサポートしているはずなのだが、はっきりしない。

 いくらやってもらちがあかないので、原点に戻って、カメラ操作シェルではない、普通のテキストがCGIで出るのかやってみた。結果はやっぱりだめだった。このサーバーはCGIをサポートしていない。

このHTTPサーバーをさっさと諦めて、Apacheなどの正規サーバーをインストールすれば良いのだろうが、既に、RasPiのCPU使用率が80%以上になっており、これ以上負荷はかけたくない。何かオプションでもあるかと、再度、しつこく、開発元のサイトを調べたり、お得意のGoogleにエラーメッセージ全文を投げる検索をやってみるが、思わしい情報は得られなかった。

 やれやれ、Apacheか。いずれにしても、このまま引き下がるわけには行かない。CGI以外にカメラを動かすコマンドを画面で操作する方法はないだろう。今のRaspberryPiは、SDカードサイズが4GBなので、そろそろファイル容量が心配なのだが、そんなことにかまっておられない。先に進むしかない。

Apache2の設定に一苦労。やっとCGIを認めてもらった(9/23/2013)
 Apacheのインストールは数多くのウェブサイトで紹介されているし、apt-getなのでインストールそのものは至極簡単である。紹介しているサイトがむしろ多すぎて迷うくらいだ。ただし、
apt-get install apache ではなく、apt-get install apache2 である。

 何と言っても、gccとならんでデファクトスタンダードになっているHTTPサーバーである。恐らく多くの企業のサーバーもこのApacheを使っているはずだ。盛りだくさんな機能がある。逆にこういう小さなマシンのサーバーをこじんまり設定する方がかえって難しい。

 CGIは元々セキュリティに気を遣わなければならないところなので、そう気楽に設定しても動かない。やたらと制限が多い。それでも、この前のmjpg-streamerのHTTPサーバーに比べれば格段に情報が多いので設定は楽にできそうだ。インストールが順調に済んだので早速設定に入る。

 ところが、Apacheの設定ファイルの中味が、バージョンや、ディストリビューションによって、微妙に違い、何が正しいのか良くわからないのである。だいたい設定ファイルそのものの名前が違う。一方の情報では、httpd.confだが、別の情報ではapache2.confである。

 中味のパラメーターも、必ずしもこの設定ファイルの中にすべてあるのではなく、分散して別のファイルに入っているものもある。沢山あるウェブの導入ガイドをあちこち見比べつつ、必要なパラメーターを定義していく。

 最後までうまくいかなかったのが、肝腎のサーバーアドレスの設定である。明示的にサーバーアドレスを指定すると、エラーで立ち上がらなくなり、指定しないと警告は出るが、ちゃんと立ち上がって、テスト用のindex.htmlが見える。気持ちが悪いけれど、動いていることを良いことに、とりあえずこのままにして先へ進むことにする。

Apache2でストリーム画像を出力する(9/25/2013)
 mjpg-streamerは、ポート8080に、ストリーミング画像を出力する。Apacheで、この画像を出力するのは、このポート8080をリンクするHTMLタグを書けば良いはずである。ただ、理屈でそうなると考えているだけで実際に試してみたわけではない。

 これが出来なければ、Apacheを動かす意味がない。Apacheが動き出したので早速、index.htmlに、必要と思われるタグを書いてテストしてみる。
<img src="ストリーミング映像のURL?入力パラメーター" > というようなタグである。

 最初は、うまく画像が出なかった。それにしても、このHTMLの仕様、何とかならないものか。ちょっとしたことで、簡単にサーバーは、"Internal Error..."を吐き出し、表示を拒絶する。あちこち調べまわるが、原因を究明できない。

 手当たり次第に行をコメントで外していって、やっと原因がわかった。画像が出ないのは、<img src=..というタグのエラーではなく、なんと、Content Type: text/html の行のあとに、改行がないというエラーだったのである。

 HTMLの頭の<meta ..などで始まるヘッダー行は、色々なファイルから適当にコピペしたもので代用している。コピーを繰り返すうち、改行をとってしまったらしい。どこかにHTMLチェッカーのようなものがあるとは思うけれど、人騒がせな仕様である。

 Content Type行のあとに空白行を入れて、めでたくApacheのテストHTMLにストリーミング画像がでた。いやあ、嬉しい。ここまで来ればもうあと一息だ。ApacheのCGIが動くことは、テキスト表示で確かめてある。

動作ボタンをつけたライブカメラ画面遂に完成(9/26/2013)
 ストリーム画像の出力に成功したので、勇躍、CGIの開発に移る。テキスト出力でCGIが動くことは確かめてあるので、その部分に、WiringPIのコマンドを
 system("./gpio -g write 27 1"); などとperlでgpioコマンドを実行するだけである。

 ボタンのコーディングが結構難しい。ハイパーテキストでリンクする方式より、formタグでボタンにする方が見栄えが良いのでこちらにしようと思ったが、formタグにはひとつのsubmitボタンしか定義できない。仕方がないので、パンの左右、チルトの上下、合わせて4つのformタグを定義した。

 わくわくしながらテストに入る。おやあ、上下左右にボタンを配置したつもりだが、真ん中にかたまって表示されている。表示はともかく、動かしてみよう。ダメだ。全く反応なし。まあ、こういうのには慣れている。

 あちこち調べたあげく、CGIのリンク先は、相対リンクでなくフルパスが必要ということがわかった。 Action="http://192.168.0.5/cgi-bin/gpio.cgi?22"などとして入れてみる。さあ、どうだ。おおお、動いた!

 テスト用のCGIプログラムのメッセージが画面に出て、カメラがグイッと回った。やった。できた。しかし、画面が完全にテキスト画面になり、画像を見るには「戻る」を押さないと映像が戻らない。

 考えてみれば、リンクするから当然なのだが、これはまずい。試しにテスト用のメッセージをとってみたが、今度は例の"Internal Error"が出るだけで当然モーターは動かず画面もエラー画面のままだ。そりゃそうだ。リンクしても出す材料がなければ、エラーにするしかない。

 困った時のウェブ頼みである。「元の画面に戻る HTML」などのキーワードで対策を調べてみる。すぐにその対策は見つかった。

 <meta httm-equiv="refresh" content="秒数; url=戻り先UR">

とすると、一旦このページに飛んでも、「秒数」後、元のページに戻るというタグのようだ。秒数を0にして試してみる。よーし、一呼吸おいてだが、動かした後の画面にもどった。良いぞ。いやあ、ライブカメラの完成である。嬉しくなって、カメラ一式を居間に移し、早速フィールドテストに入る。

S_p9286083  ボタンを押しながら、周囲を見回せるというのは、とても気分が良い。何度かやっているうち、やっぱり猫がどこからともなく集まってきた。しかし、今のところカメラを置いたビューローの蓋を上げてあるので、猫はここに飛び上れない(まあ、いずれはやられるだろうが)。

制御を再帰方式にするが、画面更新時間は改善されない(9/27/2013)
 ストリーム画像と同じ画面でカメラを動かすことには成功した。しかし、ボタンは、見映えよく上下左右に配置できていないし、やっぱり、ボタンを押した後、一呼吸(1秒以下だが)、画面が消えるのはまずい。何とか改善したい。

Photo  画像の復帰が遅くなるのは、一旦リンクして別の画面に遷移した後、そこから再び元の画面に戻って来るからである。実は、metaタグを使わないで、画面を元へもどす方法を思いついている。現在は、index.htmlのリンクからCGIへ飛ばし、そこでgpioコマンドをだしたあとmetaタグのrefreshで元の画像ページに戻っている。

 これを、CGIプログラムにindex.htmlに相当するページを出力させ、ブラウザのURLをこのCGIから始まるような再帰的な構造にするのである。こうするとジャンプした先は最初の画面なので、1回分画面送出が減らせて画面遷移が早くなる理屈である。

 こういう工夫が一番楽しい。善は急げ、である。早速、perlに、index.htmlのHTML行を出力するコードを書き加える。ところがこれが言うことを聞かないのである。すべてperlのエラーとなる。

 最初、"(コーテーション)が入っているメッセージを print "  "で出そうとしていることがわかり、これを print << "EOF" という複数行をまとめて出力する方法に変えるがそれでもダメ。コンソールにプリントアウトしてみても正しいメッセージは出されているのに、CGIにすると"Internal Error"で動かない。

 暫くはまっていたが、これも意外なところが原因だった。終端文字のEOF(これは何でもかまわないが)の文字の後、こいつも空行が必要なのである! EOFが見つからずファイルの最後まで表示しているらしい。テキスト表示では無効キャラクターは表示されないが、HTMLでは不良文字としてはねられる。やれやれ。

 やっと、HTMLはカメラ操作のあとストリーム画像を表示する画面に戻った。しかし、期待したほどの速さではない。まあ、心持ち早くなったような気がするが、これだけ苦労して動いた割には報われなくてがっかりである。まあ、ソースコードは小さくなって満足だが。

 formタグのsubmitボタンが不揃いになるのは、ウェブ情報であっさり解決策が見つかった。HTMLの仕様上は、同一行に複数のボタンはおけないが、スタイルシートをつけると簡単に解決することが分かった。早速これを真似て実装する。うまくいった。

Livecam_title  まだまだ不満は多いが、この5月から始めたRaspberryPiのライブカメラプロジェクトは、めでたくこのあたりで大団円となったようである。本当の遠隔制御は、まだテストしていないが、これまでのポート8080と22を閉じて、80にポートマッピングすればうまくいくはずだ。ただ、80番はもっとも攻撃を受けやすいポートなので、何らかの防御策を考えておかねばなるまい。あ、猫対策も残っていたか。

| | コメント (0) | トラックバック (0)

2013年9月13日 (金)

RaspberryPiのライブカメラ遠隔制御成功!

 この5月から延々と続けていたRaspberryPi(以下RasPi)を使ったライブカメラプロジェクトは、遂に遠隔地から、映像を見ながらカメラをパン(左右)やチルト(上下)できる段階に到達した。宿願のライブカメラの実現である。

S_p9126072  ライブカメラを見ていて、もどかしさを感じるのは、いま、この映っている映像の外側がどうなのかさらに見たいと思っても、全く手も足も出せないということである。それが少しでもカメラを振れるとなると、不思議なことに、その焦燥感というか欲求不満はずいぶん解消されるような気がする。

 まだ、ストリーム部とカメラ可動部は別の経路だし(操作指示は、SSHのコマンド経由)、猫の監視用なのに猫のいたづらに対抗できない裸のケースのままで、実用までにはまだやることが沢山ある。しかし、自宅から遠く離れた事務所のPCで自宅内の映像を見ながら、カメラを動かしてみると、何か急に世界が広がった気がしてとても気分が良い。

 おりしも、7年後の2020年東京オリンピック招致が決定した。このところ暗い話題ばかりの日本に久しぶりの朗報だ。日本人と言うのは、こういう課題を与えられると恐ろしく力を発揮する民族である。何か潮目が変わって先の期待が持てそうな気分である。

 がた老AVR研究所の電子工作も、このところ停滞気味だったが、オリンピックに負けず、このささやかな成功をバネに、はずみをつけて行きたいものだ(9/12/2013 記)。
 
1-2相励磁のマイクロステッピングはうまくいった(8/26/2013)

 前回までの記事でライブカメラの可動部がとりあえず完成し、2方向とも動作したことはご報告した。しかし、チルト部のモーターの力が弱く、すぐ脱調してしまう。このままでは使えない。まずこの改善から手をつけることにした。

 モーターの制御は2つともマイクロステッピング制御で、この制御はパルス制御で言えば1相励磁であり、力が一番弱い。チルトは1:2のギアで減速しているが、下を向いたUSBカメラをあおるのは意外に力を必要とする。

 しかもUSBケーブルの取り回しをうまくやらないとケーブルの抵抗でうまく動かない。モーターは一旦止まると無電力状態となり、チルトはギヤがあるので止まるが、パンは、直結なのでモーターで保持状態を作らないとケーブルの抵抗であともどりしてしまう。

 この解決は厄介なのであとにするにしても、チルト部の力不足を補う手段は急務である。パルスの2相励磁にすれば間違いないと思うが、せっかくマイクロステッピング制御を組み込んだのに、今さら音のうるさい2相励磁に戻りたくない。このままで力を増やせないか色々検討した。

 ウェブで調べると、台形制御というのが1-2相マイクロステッピング制御にあたるらしい。これまでのマイクロステッピングに比べれば、4ステップでなく、倍の8ステップを要するが、それほど複雑ではない。力は、2相励磁の1.4倍まで行かないが、1.2倍くらいになるはずだ(1相と2相が半分づつ。動作図参照)

12  早速、やってみた。ステートマシンのステップ数は倍になるが、やっていることは変わらない。一つのフェーズの台形部分が長すぎるようにも思うが、Xと*X 、Yと、*Yを同時にONにすることは、全く意味がないので(両極で引き合うので電力の無駄)、これは仕方がない。

 メモ用紙の上で何度も動作を確かめる。ソースの修正は簡単に済んだ。Tiny2313のフラッシュ2Kバイト以内にも納まった。動かしてみる。おおー、力は十分だ。カメラを楽々持ち上げる。ただ、ステップ数は1相のマイクロステップの倍になるので、回転速度は半分になる。カメラのチルトくらいなら気にならないが、もう少し速く回したいときもあるのでいずれ改善したいところである。

 ついでに正・逆転のロジックを工夫してコードを少なくする。正転は、X, Y, *X(負), *Y(負)の順で、逆転は、X,*Y(負), *X(負), Yだが、良く見るとXのところの位置は変わっておらず、Yのところだけ逆になっていることがわかる。

 その部分だけロジックを追加すれば、まるまるシーケンスを別に作らなくても、正逆転が出来ることがわかった。 これでコード量はかなり抑えられた。

1-2相マイクロステッピング制御をもうすこし調べる(8/29/2013)

 パワーがあることは確認できたが、何か、回転がぎこちないような気がする。カメラのチルトの一回の動作量はごくわずかなので、どんな回り方をするのか、1-2相励磁のマイクロステッピングをもう少し詳しく調べてみることにした。

 AVRStudioのプロジェクトを別に起こして、この制御方法で連続回転するプログラムを作り直す。ちょうど良い機会なので、ついでにこのモーターがどれくらいの速さまで回るのか、タイマーのプリスケールを替えて高回転(1/64から、1/8、PWM周波数8khz)にしてみる。

 変えるところは1ステートメントだけである。テストしてみる。全く動かない。ええー、何故だ。耳をモーターに近づけると、わずかに音がした。ははー、6V程度では、この速さでは脱調で全く動かないのだ。しかし、クロックが4MHzしかないので選択の範囲が狭い。中間の速さにすることが出来ない。

 あきらめて、元へ戻す。連続回転が始まった。うーむ、やっぱりなんかカクカク回っているような感じがする。こういうことが気になると、先に進めなくなる性格である。ロジアナを久しぶりに引っ張り出して、CPUのピンからプローブし、4チャンネルのPWMポートを計測してみた。

 意外なことに、4チャンネルのPWMの間隔は全く同じで、不規則なところはどこも見当たらなかった。とすると、要するに1相の間隔が32ms(32ステップ)程度の速さでは、こんな感じのスムーズさでしか回らないようだ。

12microstep  そこで思いついたのが、32ステップを半分の16ステップにして速度を早くする方法である。ウェブなどで見ているとマイクロステップと称していても、8ステップや16ステップ程度が多い。半分にしても問題ないだろう。

 これの変更も簡単だ。32ステップあるサインカーブの定数を端折って半分にするだけである。早速試してみる。うむ、スピードが速くなっただけ回転のぎこちなさが少なくなった。ただ、暫く連続して動かすと、モーター(SPG27-1601SK)がかなり熱を持つことがわかった。

 このモーターの定格が良くわからないのだが6Vくらいでこんなに熱くなるのだろうか。まあ、手で触れる熱さなので余り気にすることでもない。そもそも今回は連続して回さない。

ここに、上記1-2相励磁のマイクロステッピング制御でモーターの正・逆転、停止のテストができるプログラムをAVRStudioのプロジェクトフォルダーの形で固めたものを置きます。回路図はつけませんが、ソースのコメントを参考にしてください。

「M12STP2313.zip」をダウンロード

中々先に進まないなあ(9/3/2013)
 AVRのプログラムをいじり始めると止まらなくなった。RasPiの制御部の開発に対する潜在的な逃避なのかもしれない。この部分は所長が普段余りやらないLinuxのウェブや、スクリプト周りの開発だ。苦手なものをなるべく先送りしたい気分があるのだろう。

 連続回転のプログラムは、UARTとタクトスイッチで操作指示が出来るようになっているが、スタンドアロンでも動かしたくなり、タクトスイッチで回転を止める機能を開発し始めた。以前、リニアPCMプレーヤーの同時押しのロジックである。タクトスイッチを2つ同時に押した時に、モーターの回転を止める。

 十分な待ち時間(100ms)をとったのだが、スイッチの同時押しがどうしても実現できない。こいつもロジアナに助けを求めるしかないかと考え始めた頃、はっと気がついた。このプログラムはイベントドリブンで、いくらスイッチの同時押しで停止のフラッグが上がっても、動作キューには2つの動作指示(スイッチを2度押したことになる)が残っており、回転が止まらないのだ。

 わかってみれば、またもお粗末なミスである。まさしくプログラムは思ったようには動かない。書いたように動くという至言どおりの結果であった。

 同時押しで、やっとモーターを止めることができて、さあ、いよいよRasPiの制御の開発だと気分を高めていたころ、こんどは、突然、チルト部がおかしくなった。脱調のように音はするけれどモーターが回らない。

 やれやれ、今度は何がおかしいのだ。ソフトは換えていないのでハードのトラブルだ。まさかモーターが壊れたわけではないだろう。コネクターの接触不良か。テスターで接触を確かめるが問題ない(ステッピングモーターは1相でもはずれると回らない)。

 その日は諦めて、次の日、トラブルシューティングを開始した。基板を何気なく見ているうち、CPUチップの形が少しおかしいのに気がついた。何と何と良く見るとCPUチップがソケットから浮いてはずれかかっている。何でチップがこんなに浮き上がったのだ? 

 そうか、ロジアナでPWM波形を調べた時、プローブを挟むために、少しチップを浮かせたことを思い出した。それが、テストで何度かケースを裏返したりしているうち、はずれかかったのに違いない。CPUチップをしっかり差し込んで、全く問題なくモーターが動いたことは言うまでもない。やれやれ、こんなことで、なかなか先に進まない。

RasPiのGPIO制御はあっけなく成功(9/4/2013)
  今まで延ばし延ばしにしていたRasPiのGPIO制御の開発を意を決して始めることにした。最近のウェブにはRasPiの情報が溢れている。GPIOの制御の方法を調べているが、沢山のウェブサイトが見つかって、調べれば調べるほど何が良いのかわからなくなってきた。

 大きく分けると、Debianが用意したというディバイスファイルにパラメーターを書いて動かす方法、さらにGPIOを制御する専用のライブラリー群(wiringPIなど)をインストールして、このコマンドを利用する方法、あるいはLinuxのディバイスドライバーをいちから自作する方法(これが一番難しい)である。

 最後の方法は、いわばOSのドライバーを書くわけで、プロレベルの技術が要求される。UnixやLinuxはリアルタイムOSではないので、入出力処理の途中でタイムスライスが入って処理が中断される可能性はゼロではないが、カーネルのディバイスドライバーを作れば、このあたりの心配はなくなる。挑戦意欲がふつふつと湧いてくるが、やや蛮勇に近い。

 現実的な解は、最初の2つのうちどちらにするかである。こういうときは手法そのものを検討するよりもっと簡単な選択法がある。それは最終の目的を明確にしてから必要な仕様に戻る手法である。これが一番無駄がない。

 今度の目的は、モーター駆動のトリガーとなるワンショットパルスをGPIOで出してカメラをどちらかに動かすだけである。正確さや、同時性などは求められていない。とすると、GPIOを直に叩くライブラリも不要で、ディバイスファイルにASCII文字を書いて制御する方法が一番簡便だ。まずこれで動かすことにする。

 ただ、カメラ側のVccは5Vなのに、RasPiは、3.3Vで5Vトラレントでもない。レベルシフターICも考えたが、今回は、大量のストックのあるフォトカプラー(PC817)を使うことにした。モーター部とRasPiをハード的に完全に分離することができて一石二鳥である。

 実装の前に、まずはブレッドボードでGPIOから直接LEDをつけるテストをやる。問題なく点灯した。次にフォトカプラーをブレッドボードに挿し、フォトカプラー経由でLEDを点けてみる。これも問題なし。

 いよいよ、Tiny2313の入力ピンにフォトカプラーの出力をつなぐ。フォトカプラーの出力はオープンコレクターなので、Vccが必要だ。でも、良く考えてみたらTiny2313の入力ピンは5Vでプルアップしている。フォトカプラーのVccはこれで代用できるのではないか。

 フォトカプラーの出力(コレクター)を入力ピンにつなぐだけで動かしてみた。ビンゴ!だった。コンソールのシェルコマンドのechoの連打で、見事にフォトカプラー経由でモーターが動いた。

S_p9076064  これを4つ作れば、とりあえずカメラ制御はSSH経由、画面はストリーム経由で、カメラの遠隔制御が実現する。早速、フォトカプラー4つの実装を始めた。最初、元のパン部のメイン基板に入れようと思ったが、手狭なので無理することもないと、別の小さな基板を用意する。

 この基板の固定は、これまでのスペーサーではなく、FDDケースの切れ端を応用したフォルダーで固定する(写真参照)。ちょっとごつくなって考えていたほどスマートには出来なかったが、こういう実装の工夫も楽しみの一つである。

S_p9126065  ライブカメラプロジェクトも大詰めに近づいた。あとは、Apacheを立ち上げ、ライブカメラページをつくってやればプロジェクトは完成である。

ディバイスファイルで操作するよりWiringPiの方が簡単だ(9/6/2013)
 RasPiのCGIプログラムの開発に着手した。このあいだ少しやったperlの勉強を再開する。ディバイスファイルにASCIIを書き込むのは、perlでどうやるんだっけ、などという初歩的なところからおさらいする。

 最近は、perlは流行らないみたいだけれど、このあいだのDDNS(ダイナミックDNS)のサポートの続きである。PHPとかpythonとか、Rubyなどにも目移りするが、ただでさえ遅れているプロジェクトだ。別のものにさらに手を出してリソースを分散させるのは止めておこう。

 偉そうなことを言ってはいるが、まともなウェブページの制作は今度が始めてである。まあ、勉強といっても、ウェブでいくらでも情報が入る時代で、参考書を買ってくる必要もない。良い時代になったものだ。

 そのうち、echoとリダイレクトでディバイスファイルにパラメーターを書き込む手法が何となくかったるくなってきた。perlで書くにしても、ステートメント数が多くなる。ウェブを見ていると、WiringPiというライブラリーを使うほうがコード量を減らせそうだ。

ウェブの情報を参考にWiringPiをインストールする。しょっちゅう当ブログにコメントを寄せてくださる、ばんとさんのサイト「メモたんく」でも詳しく紹介されている。

 このインストールは、apt-getではなく、最近senshuさんの掲示板でも話題になっている、gitリポジトリからソースコードを貰ってきてビルドするようだ。

 恐る恐る、言われるままにコマンドを叩く。おーし、全くエラーなしにインストールできた。まずは試してみる。おお、これは便利だ。普通のコマンド入力のような感じでGPIOが操作できる。これくらいなら、perlで書かなくてもシェルスクリプトだけで十分だ。早速、カメラ操作用のワンショットパルスを出すスクリプトを、sleepコマンドを使ってでっちあげる。

スクリプト gpio_run (GPIOポート番号) は、以下の通り。
 #!bin/bash
  ./gpio write $1 1   # 引数のGPIOポートを1にし
  sleep 1s            # 1秒待って
 ./gpio write $1 0  #  0に戻す

motionよりmjpg-streamerの方が軽くて良い(9/8/2013)
 Raspiで動くビデオストリームプログラムは、今使っているmotion以外にもいくつかあることがわかった。そのうちのひとつmjpg-streamerの評判が良さそうなので、試してみることにした。

 メインサイトの説明によれば、貧弱なスペックでも滑らかな映像が得られるとある。motionは動き検知などの機能があって単純なストリーミングはどうも少し重そうなのである。

 今、ウェブページの制作準備でそれどころではないのだが、つい道草を食う。現実逃避の悪い癖である。言われるままにapt-getを繰り返してパッケージをインストールする。このパッケージは、svnというソースコード管理システムを使って、makeでソースからビルドする本格的なパッケージである。

 おやあ、エラーが出る。最初のapt-getのインストールは何事もなく終わったのだが、svnで最新のソースをとろうとすると、エラーが出る。場所が移転したので別のところからリポジトリを作れと言われる。言われたところにURLを変えると、今度は別のエラーになる。おかしい。その日は深夜だったので開発を中断し床についた。

 次の日、腰をすえてトラブルシューティング。まず、apt-getで忘れていたシステムのupgradeをする。小一時間かかったが無事終了。しかし、svn coコマンドのエラーはとれない。どうも、エラーメッセージが示すURLの中に!があるのがおかしい。

 ウェブを漁っていると、ソースコードからのビルドではなく、tarボールのバイナリが見つかったが、今度はRaspiのブラウザーmidoriでダウンロードができない。どんどん迷路に入る。

 svnを少し勉強する。どうも受け側(RasPi)の設定もパラメーターに入れるみたいだ。手探りでパラメーターをいじるうち、何とかSourceforgeのサイトから、ソースコード一式がgetできた。それからは早かった。makeも無事終わり、長いコマンドを入れてmjpg-streamerの動作を開始する。

Mjpgstreamer  おおお、見事にmjpg-streamerのページが出た。おやあ、静止画だ。うん大丈夫、左下にstreamのボタンがある。これを押す。よーし、動画が出た。良いぞ、motionより遥かに早い。フレームレートは20くらいまで行き(このときRasPiのCPU使用率は70%程度)、カメラの前でかざした手が滑らかに動く。

 このストリームは、FireFoxでもメモリーリークにならない。快調だ。このパッケージにはWWWサーバーもついているので、Apacheも必要ない。簡単に自前の制御を入れたページが作れそうだ(Chromeでも動く。IE6は静止画はOKだがストリームは映らなかった)。

オーディオルーム(工作室)と居間の間のテストで猫が映る(9/10/2013)
 フォトカプラー基板も出来て、スクリプトも出来た。これでパンやチルトが簡単に出来る。いよいよ遠隔制御のテストである。時間はもう深夜なのだが、もう誰も止められない。カメラ一式を居間に持ち込んで、ビューローの上に設置し、地下のオーディオルーム(工作室)から制御する。

S_p9126069  家族はもう就寝して居間には誰も居ない。照明をつけて下へ降り、ブラウザーとSSHを立ち上げてテスト開始である。PCに居間の映像が映る。TeraTermのコマンド入力で、カメラを動かす。よーし、動いた。チルトもパンも問題ない。機嫌よく動かしていたら、カメラの片隅に見慣れない物体が映った。

 何と猫が高さ1.2mのビューローの上に跳び上がってカメラのそばにいるのである。考えてみたら、深夜誰も居ない居間で、マイクロステップで音が小さいとはいえギギッとか、ググッとか異音がしてカメラが動く。猫にとっては一大事の事件だ(猫は音に極度に敏感である)。

 見に来るのは当然なのだ。しかも、Raspi基板のLEDは、ネットのアクセスで点滅している。2匹いるうちオスの1匹は噛み癖がある。留守宅でカメラを動かせば、早晩、猫の襲撃を受けることは自明となった。

 想定外の条件である。カメラ可動部は、それに対する備えは全くない。裸のままである。実用に当たっては、アクリルケースなどの防御策を考えなければならない。

事務所で遠隔制御成功(9/11/2013)
まあ、それはともかく、残るは、自宅外でのアクセスのテストである。まだ制御を組み込んだページが未完成なので、SSHの22番のポートを開けないとテストが出来ない。22番はアタックが心配だが、まだ常時電源を入れたままにするわけでもない。恐れることはないだろう。

 朝、RasPiとカメラの電源を入れて事務所に出かける。事務所のPCはWindows8である。コマンドプロンプトをどうして出すのかわからない。端末プログラムもない。そこで使い慣れたTeraTermをダウンロードする。

 Windows8は出だしのところだけがスマホ風になっているが、実は中味はあまり変化はない。コマンドプロンプトもTeraTermも問題なく動いた。さあ、いよいよ実験開始。まずTeraTermを立ち上げ、生のIPアドレスでSSH接続する。

 つながった。ドメインネームでも動いた。rootからmjpg-streamerを動かす。長ったらしいパラメーターは昨夜、シェルスクリプトにしてある。

 おお、メッセージが出て立ち上がった。あせる手でChromeのブラウザーに生アドレスを入れる。出た!地下のオーディオルームが映った。さて、ここまでは一度motionで動かしている。問題は、次のカメラ操作だ。

 自作シェルスクリプトgpio_initで、WiringPiを初期化し、gpio_runでカメラにパルスを送る。 ひゃっほー、画像がずるっとずれてカメラ位置が変わった。motionに比べると格段に画質が良いし、反応はきびきびしている。あちこち動かしてみる。

 うーむ、パンの逆回転ができない。カメラの初期位置を間違えたようだ。段々階段の暗いところに移動したまま元へ戻れない。しかし上下のチルトは問題ない。とにかく動いた。じわじわと嬉しさがこみあげてくる。

 Raspiでウェブカメラをいじり始めたのが5月だから、ここまで4ヶ月ちょっとかかったことになる。意欲が下がっていたので実働時間は大したことはないが、それでも感慨ひとしおである。やればできるものである。

| | コメント (4) | トラックバック (0)

« 2013年8月 | トップページ | 2013年10月 »