« 2013年8月18日 - 2013年8月24日 | トップページ | 2013年9月29日 - 2013年10月5日 »

2013年9月8日 - 2013年9月14日の1件の記事

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月18日 - 2013年8月24日 | トップページ | 2013年9月29日 - 2013年10月5日 »