RaspberryPiのライブカメラを外からアクセスする

とんすけさんのMotion Playerシールド
　RaspberryPiの話の前に、報告しておかねばならないことをひとつ。すんさんの掲示板にも書いたが、とんすけさんのMotionPlayerシールドのことである。少しトラブルがあったのだが、とんすけさんの手助けで簡単に解決したので、ここでお礼を兼ねてご紹介する。

　とんすけさんには大変お世話になった。この場を借りてあらためて御礼を申し上げておきたい。このMotionPlayerシールドとは、STM32F4-DiscoveryをベースにSDカードに入った音楽ファイルや動画ファイルの再生を液晶のタッチパネルで操作するプレーヤー基板のことで、ファームウエアが提供されており、ピンヘッダーをハンダ付けするだけで動作する。

　これを知った、そもそものきっかけは、例によってshuji009さんが、すんさんの掲示板で絶賛紹介されたことからであるが、とんすけさんそのものは2年ほど前、やはりshuji009さんの紹介で、STM32F103の外部メモリインターフェースFSMCを使ってLCDをドライブし、60fpsの動画を成功させた人として記憶に残っている。凄い人だなあと感心していたが、驚いたことに、この道のプロではなくアマチュアの方だそうである。いや凄すぎる。

　それはともかく、所長は、何度も言うように、「格安」とか「破格の値段」というのに弱い。秋月で多種類に亘って売り出されているCPU基板、STM32(8もあるが）Discoveryシリーズは販売促進という狙いで何しろみんな思い切った価格設定である。用もないのについ手が出てしまう。

　MotionPlayerのCPU基板STM32F4-Discoveryは秋月で発売後すぐ売り切れになり、直前に手に入れて、ひとりほくそえんでいたのだが（悪い性格だ）、間もなく潤沢に出回り始めて、そのうち興味も薄れ、現物はパッケージから出すこともなく部品庫に眠っていた。

　もうひとつの必要なパーツ、Aitendoの3.2インチTFT液晶は以前、直営店の店頭で見つけて、あてもないのに買い込み、これも部品庫のこやしになっていた。部品番号を確かめる。間違いない。同じ液晶基板だ。これで2つも長期在庫がさばける。これはもうこのシールドを買うしかないだろう。週末にネットで銀行振り込みをしたら月曜の夜にもう届いた。恐るべき早さである。

　ところが、これが動かない。画面は白いラスターのままで、何の映像も映らない。シリアル端末をつないでメッセージを出してみるとソフトそのものは動いているようだ。タッチパネルも何か感じているが肝腎の画像はでない。

　ピンソケットの接触不良などは念入りにテスターで測って問題なし。TFTの初期不良が一番疑われるが確信はない。買ったのはもう2年近く前で今さら交換を要求するのも気が重い。それに、わざわざ出かけて行って交換して同じだったら目も当てられらない。思い余って、とんすけさんに、何か情報はないかとメールを出してみた。

　すると本人から、すぐ返事があり、送ってくれれば調べてあげると言われた。販売元でもないのにそれは申し訳ないと断わろうと思ったが、彼は複数台持っているとのことなので、正常に動く1台を貸してもらえば嬉しいのだがと少しあつかましいお願いをしてみた。

やっぱり初期不良だった。AitendoでTFT液晶は買いなおし(5/19/2013）
　まもなく返事があって、こちらの申し出を快く承諾されて完動品を送るとの報せが届いた。いやあ、これは有難い。待つこと数日。分厚いエアシートに包まれて、TFT液晶が届いた。感激、感激である。

　早速、接続してみる（ピンソケットは接続済み）。全く問題なく稼動した。音楽再生でpauseをかけると時々大きなノイズが入るのが少し気になるが（これはSDカードのバッファーサイズを大きくすると殆ど解消した）、動画も出る。タッチパネルの操作も楽だ。いや素晴らしい出来映えである。やっぱり2年前に買ったTFT液晶の方は初期不良だった。

　とんすけさんに借りたTFTを返却しようとした時、ふと思いついた。不良品のTFT液晶をAitendoに持ち込んで交換してくれる保証はない。お店で不愉快な気持ちになるくらいなら、これを、お礼がわりにとんすけさんに差し上げてはどうだろうか。

　とんすけさんが言うように、ちょっとしたことで直るのかも知れないが、こちらにはテスト環境もないし、不具合を特定できる技術も持っていない。とんすけさんのところで生き返ってくれれば、生きとし生けるものに少しでも幸せが訪れるというものだ。

　何か、修理を催促しているようで、最後まで迷ったのだが、こちらで持っていてもしようがないし、その旨、説明すれば理解してもらえると期待してメールを送る。予想はあたって快く受け取ってもらえた。2台を送る。ささやかなことだが、気持ちが通じると言うのは嬉しいものだ。

　次の日、秋葉原に出て、Aitendoを訪ね、件のTFTを買いなおした。幸い在庫はまだ沢山あった。ここに来るとついいらないものを買ってしまうのだが、今日は、USB-TTL（CP2102の方)ブレークアウト基板だけで我慢する（RasPi用）。買って帰ってTFTを早速テスト。もちろん何の問題もなく稼動した。

画像のフレームレートを上げる(5/31/2013)
　RaspberryPi（以下RasPi)の話に戻ろう。LogicoolのウェブカメラC270を使ったRasPiのストリーミングビデオは、自宅内のLANでは、問題なく画像を見られるようになった（ただし、motionの画像を見るのは、IEでは不能、FireFoxはメモリーリークでハングする。Chromeは全く問題ない）。

　画像の解像度は、358X288（motionのデフォルト解像度）ながら、前の30万画素のカメラに比べれば、格段に綺麗な映像である。次は、これを外から見られるようにすることと、このカメラの可動部を制作することだが、その前に解決しておきたい問題がある。

　それは、画面のフレームレートである。現在は、motionのパラメーターファイルをいじっても、1秒に2～3回程度(2～3fps)にしかなっていないので、動きの早い猫などの姿は満足に捉えられない。もう少し多くないと実用的とはいえない。

　motionの設定ファイル(motion.conf)は、非常に多くのパラメーターがあって、ともかくわかりにくい。少々いじっただけでは改善されなかった。PCのUbuntuで動かしてみたら全く同じようなフレームレートなので、低いのはRasPiのハードウエアの限界ではなく、この設定のせいに違いなのだが、どこを直せば良いのかわからない。

　何度目かのmotionの設定ファイルの見直しで、やっと見つけることが出来た。ファイルの最後の方にある、Live Webcam Serverという設定項目群の中にフレームレートを規定するところがまだあったのを見落としていた。

　motionのフレームレートを設定するパラメーターは、いくつものところにあり、2ヶ所まで変更してあったのだが、最後の設定が、defaultの1の（1fps)のままだったのである。

　いくら、その前の設定でframe_rateを上げていてもストリーミングのときには、ここで下げられてしまうのである。このwebcam_maxrate というパラメーターを1から、30にすると、映画並みの滑らかさになった。

　おーし、猫がケージから飛び降りても、しっかり画像がとれている。良いぞ。ただし、ネット上のデータ転送量は、これまでの毎秒12KBから50KB以上に跳ね上がった。まあ、これはとりあえずそんなに大きな問題ではない。次は、このストリームを外からアクセスするしかけの開発である。

ポートマッピングのテストは成功(6/4/2013)
　本来の目的は、留守宅にいる猫たちの監視である。外からライブカメラ的に見えなければ意味がない。一般家庭のルーターは、一応セキュリティ機能がついていて、外部からのアクセスリクエストは殆ど中に入れないようなしかけになっている。このままでは外から見ることは出来ない。

　というより、殆どの家庭用のルーターは、1つのグローバルアドレスをいくつかのローカルアドレスを持った機器で共用しているので（IPマスカレードともいう）、届け先を指定しない限り、外部からのパケットは届かない。

　外からのアクセスを可能にする方法が、ポートフォワードとか、ポートマッピングというしかけである。外部からのリクエストパケットのポート番号をキーに特定のローカルアドレスの機器に振り分ける。こうすることによって外部とのネットワークゲームや、ストリーミングが可能になる。

　ただ、不用意にポートを開けると、前にも書いたように、ネット上を飛び回っているロボットのポートスキャンを受けてあらぬ攻撃を受ける恐れもあるので、細心の注意が必要だ。画像転送以外に、カメラの位置制御もやりたいのでポートは複数あける必要がある（Apacheを立ち上げて、HTTPプロトコル(80)一本でやる方法もあるが）。

　偉そうなことは言っているが、実は、これまでは講釈だけでこういう実際の作業は始めてである。恐る恐るルーターのポートマッピングのテストを始める。motionのストリーム用のTCPのポート番号は808１なので、まず、こいつだけ開けて、Raspiのローカルアドレス(192.168.0.5)に通すことにする。

　ダイナミックDNSのサービスを受けなくても、自分の今のグローバルアドレスで、外から直接ここへアクセスすれば、所定（RasPi)のサーバーが外から見えるかの確認は出来るはずだ。自宅のルーターの設定サイトにログインしてポートマッピングのエントリーを追加する。

　作業そのものは、1分もかからない。あっという間に終わった。本来なら、ネットカフェとか会社とか別のサイトからアクセスしなければわからないのだが、世の中には、色々なサービス（一種のプロキシーサーバー）をしてくれるサイトが結構沢山あってこういうことを、簡単に調べられることがわかった。

　こうしたネットサービスそのものの信頼性を疑う向きもあるが、疑ってばかりいても始まらない。ここのサイトで実際に試してみる。ルーターのポートマッピング（フォワード）を有効にして、テスト。おお、これまで拒否していた、ポート8081の認証に成功した。我家のルーターで閉じると、ちゃんと拒否した。良いぞ。動いている。

　次は、ニューヨークとベルリン、メルボルンの3ヶ所からアクセスしてくれるというこのサイトでテストする。すごい。3ヶ所とも1秒内外でアクセスに成功した（このサイトの説明が真実なら）。ネットワーク的には無事つながっているようだ。

DiCEと同じ機能を持つ別のスクリプト開発(6/6/2013)
　外から8081ポート（motionのストリーム）にアクセスできることが確認されたので、次は、これを名前でアクセスするしかけの準備に入る。グローバルアドレスは固定ではないので、プロバイダーが変更したときは、これに自動的に追従する機能が必要だ。

　ネットを調べると、DiCEというパッケージが一番使われているようだが、驚いたことに、このパッケージは、日本の個人の制作である。もともとはWindows用のパッケージだが、Linux用もある。ただ、サポートはLinux用は余りされていないようだ。

　しかし、前にも書いたように、必ずしもこれを使わなくても、ダイナミックDNSのメンテナンスは自作スクリプトでも出来るような話がWebに出ている。へそ曲がりでは誰にも負けない所長である。自分で作りたくなった。久しぶりのLinuxのプログラミングだ。心がはやる。

　検索を続けているうちに、ちょうどこちらが使おうとしているNiftyのDDNSサービスを自動化するスクリプトのソースを公開しているサイトを見つけた。これは助かった。細かい、プロバイダーとのやりとりはそっくり真似をすることが出来る。ありがたくソースを頂く。

　Perlで書かれている。Perlなら、昔、Linuxに夢中になっていた頃、ウェブのCGIを作るために、本を2冊も買って勉強し、実際に通信ログの統計ソフトを開発したことがある。懐かしい(所長の蔵書は第2版で写真はPerl5のもの）。

  久しぶりに、Perlをお勉強する。ネット上のソースを、手元の参考書や、ウェブの情報を頼りに解読していった。perlは最近、Pythonとか、日本発のオブジェクト指向スクリプト言語Rubyなどに押されているようだが、とても強力な言語だ。

　ただ、余りにも色々なことができるため（この大量の特殊変数はとても覚えきれない）、人が書いたソースの可読性は余り高くないかもしれない。ただ、件のソースは、凝ったことはしていないのでまあまあ読み取れる。

それにしても、このwgetを使ったサイトの解析にはしびれた。

# @nifty DDNSのIPアドレス更新ページをwgetでアクセスし、現在のIPアドレスを確認 

$wget = `wget --secure-protocol=auto -O - -q $atniftyddns?$conf_ipaddr`;
$wget =~/[0-9]+(\.[0-9]+){3}/; #この正規表現で、nnn.nnn.nnn.nnnの文字列抽出！
$current_ip = $&;　#抽出したＩＰアドレスを変数に収容

　これだけのスクリプトで良くあの大量のHTML文書から、IPアドレスを抜き出しているものだ。たったの1行である。ソースコードをRasPiにとりこみ、シリアル端末にメッセージを出すコマンドを追加してテストを始める。

　現在使っているAUひかりは、一旦つながってしまうと滅多にグローバルアドレスは変わらないようだ。このところ全く変更がない。どうも、それほどあせって自動化を図る必要もなさそうだ。とりあえず手動でコマンドを出して動かしてみる。cronにするのは後でも良い。

　よし、現在のグローバルアドレスが端末に出て、このPerlスクリプトが書いたテキストファイルに収容された。ここはこれくらいで良いだろう。まだ、NiftyからダイナミックDNSのドメイン登録をやっていないのでこちらを先に進めることにした。

DDNSのドメインを登録したが、勤め先からの接続は失敗(6/10/2013)
　NiftyのDDNS（ダイナミックDNS)サービスは、XXX.atnifty.comというサブドメイン(XXXが自分の名前）なら、一ヶ月￥200で、独自のドメイン（YYY.comや、ZZZ.jpなどが選べる）なら￥400で借りることが出来る。

　迷ったが、まあ最初なので、安い方にしておく（登録したドメインネームは、まだ認証機能がついていないのでここでは公開できない）。前にも書いたが、このNiftyのDDNSのサービスのサイトはとてもわかりにくいところにある。

　しかしページが見つかれば設定は至極簡単である。申請して、その名前がまだ使われていなければ、ほんの数分で登録が終わる（もちろんNiftyユーザーとしてログオンする必要あり）。登録がOKになったので、早速テスト。自分のPCでpingを打ってみる。

　だめだ。not reachableになってしまう。中からは名前を引くとグローバルアドレスになるからだめなのだろうか。いや、グローバルアドレスの直打ちならpingは通る。おかしいところはない。頭を抱えた。

　しかし、心配は無用だった。暫くすると、pingが返ってきた。そりゃそうだ。すべてのネームサーバーに瞬時に登録されるわけではない。沢山のサーバーを経由するわけだから少し時間がかかるのは当たり前なのだ（一旦つながれば、キャッシュされるらしく瞬時に帰ってくる）。

　次の日は出勤日だった。朝、出かける前にRasPiの電源を入れ、ウェブカメラを生かしたまま事務所に出た。ひととおりの仕事を片付けて、どきどきしながら、RasPiのストリーミングサーバーにアクセスする。グローバルアドレスが前日と替っていないことは確かめてある。

　残念。つながらない。それならとグローバルアドレスの直か打ちで8081のポートにアクセスしてみた。しかし、これもつながらなかった。ただ、門前払いでなく、ネットはつながるが、向こうのレスポンスがタイムアウトしているような感じだ。それならと、pingを打つ。何と、この事務所、pingが通らない。まあ、IT関連の事務所なので、ICMPパケットのフィルターが掛けられているようだ。

遂に外部からのアクセスに成功(6/12/2013)
　帰宅して、早速つながらない原因を追究した。内部のローカルアドレスでは問題なく動く。ルーターのポートマッピングのエントリーを調べる。今、2台のRasPiがいるので（1台はSAMBA用）、念のため、8081のポートは、2つのローカルアドレスにエントリーしてある（特にエラーにはならない）。

　ふむ、今、ストリーム用に生きているのは、192.168.0.10の2台目のRasPiで、もう一台の192.168.0.5は電源が入っていない。順番は、あーっ、192.168.0.5の方が先頭だ。このエントリーをルーターがどう解釈するかだが、ルーターが親切に2台を調べて動いている方にデータを送るなんてことは殆どありえない。

　これだ、これだ。これに違いない。事務所で動かなかったのは、電源の切れている192.168.0.5の方に8081リクエストを送っていただけに違いないだろう。あわててポートマッピングのエントリーをストリーミングサーバーにしている192.168.0.10の方だけにする。

　不具合（と思われる）箇所はすぐ直したが、その確認は今ここでは出来ない。意気込んだ気持ちの吐け口がわからなくて、ウェブを手当たり次第に検索したときである。自作したWWWサーバーが動いているかどうかテストしてあげるという親切なウェブサイトを発見した。

　おおー、これなら外に行かなくても、自分のところからウェブサーバーの状況を見ることが出来そうだ。ポート番号が、HTTPの80番でないのが少々心配だが、だめもとである。早速、このサイトの項目に　http://XXX.atnifty.com:8081/ と入れてみた（XXXは仮名）。

　やった、やりました。見事に、1Fに設置したライブカメラの映像が、PCに出現した。ヒャッホー、遂に、外部から自宅内のウェブカメラの映像が見えた瞬間である。2年前のBeagleBoardあたりから狙っていた機能が遂に実現したのである。

　この数日後、事務所のPCで、実際に映像が映ることを確認した。名前引きでもちゃんと見える。これで間違いなく、ストリーミング映像は外部からアクセスできることがわかった。ライブカメラプロジェクトは、いよいよ次の大物、カメラのパンとチルトのモーター制御の開発に移ることが出来る。あ、DDNSの方もテストしておく必要があるか。