EdisonにてWebカメラを有効にし、mjpg-streamerで映像を配信してみました。Edisonを使ったデモとして、そのWebカメラにサーボモーターを2つ取り付け、Web経由でパン・チルト(水平方向と垂直方向)を制御してみました。全体像は下図のようになります。Pro6本)が見えます。コントローラーはPC、タブレット、スマートフォンなどのブラウザです。動作状況の動画はこちらになります。pcDuinoを用いました。この組み立て方は公式の解説にあります。必要なネジが全然足りない(と思う)2つのサーボSG-90の品質が悪く、最初から正常動作しないことがあるのように、なかなか骨のあるキットです。ちなみにサーボSG-90は秋月やamazonなどでも追加注文できますが、店によってはバージョン違いなのかサーボのケースサイズやサーボホーンの径が異なり、さらに加工が必要になったりします。私の場合、SG-90を計12個入手して、正常動作したものは10個でした。」で紹介した方法では映像配信できません。C210を加工して取り付けました。Logicoolのものなら大抵大丈夫だと思います(今にして思えば、もっと画質の良いものにすれば良かったかも)。Edisonと接続します。いくつかコメントします。USBカメラを使うため、電源は7V~15VをJ21に入力します。バッテリーを用いたかったので、Enelooop6本を用いることにしました。Proにしましたが、これはお好みで。サーボモーターは5Vで駆動するため、レギュレータTA4805Sで5Vを作ります。これは手元にあったものをそのまま用いました。Edisonからは下記の5つの信号を引っ張りだしました。Boardにケーブルを直接半田づけしました。J17-1:サーボ用PWMJ18-1:サーボ用PWMJ18-2:GPIO。プルアップされた入力として用いて、シャットダウンスイッチに利用します。GuideのPDFファイルを参考にしてください。サーボモータ用に出力するPWM信号は1.8Vなので、サーボモータに与えるために5Vにレベル変換します。これも手元にあった「8ビット双方向ロジックレベル変換モジュール」を用いました。PCとの接続は、J3のシリアルコンソールにより行います。Edison上での作業になります。EdisonでWebカメラを有効にしmjpg-streamerで映像を配信してみた」に基づいてWebカメラの映像配信を有効にしておいてください。エントリ作成当時はポート8080を用いていましたが、ポート9000を用いるように変更しましたので、ご注意ください。opkgのフィードを設定する」および「libmraaを使ってC++で開発する」を参考に、GPIOにアクセスするためのlibmraaライブラリをインストールします。/etc/opkg/myfeeds.confこのファイルに下記の内容を記述して保存します。http://iotdk.intel.com/repos/1.1/iotdk/x86書けたら、下記のコマンドを実行します。libmraa0これでlibmraaのインストールが完了しました。node.jsで用いるモジュールの準備node.jsによるWeb連携で用いるconnectモジュールとsocket.ioモジュールをインストールします。socket.io@0.9.17使っているスクリプトの関係上、バージョンを指定して最新のものではないファイルをインストールしました。これらのモジュールは/home/root/node_modules以下にインストールされます。libmraaライブラリに対応するmraaモジュールは/usr/lib/node_modules/mraaとしてインストールされていますが、これを/home/root/node_modulesにリンクしておかないと、自作のnodeスクリプトを/etc/rc.localから起動するときに失敗します。そのため、下記を実行しておきます。/home/root/node_modules/mraaソースのダウンロードソースのダウンロードのために、gitをインストールします。git次に、ソースをダウンロードし、pantiltという名前のディレクトリに保存します。pantilt以下、いくつか解説を加えていきます。シャットダウンスイッチシャットダウンスイッチを有効にするためには、下記のコマンドを実行します。&この状態で、回路上のタクトスイッチを2~3秒程度長押しすると、poweroffコマンドが実行され、シャットダウンが始まります。中身は下記のようなPythonプログラムになっています。GPIO15はJ18-2のことであり、プルアップ抵抗つきの入力として設定しています。GPIO番号とピン番号の対応はこちらを参照。time.sleep(0.5)このshutdown.pyスクリプトを起動時に有効にするには、mjpg-streamerの自動起動の際に作成した/etc/rc.localに上記のコマンドを追記してください。サーバーの起動サーバーを起動するには、下記のコマンドを実行してください。EdisonのIPアドレス):8080/にアクセスすると、操作用のアプリが開きます。使用されているポートは下記の通りです。8080:ページの閲覧8888:socket.ioによるソケット通信9000:mjpg-streamerによる映像配信JavaScriptで記述したpantiltserver.jsの中では、下記のようにJ17-1およびJ18-1ピンに対してPWM信号を出力しています。duty1max)/2;p0.write(duty0);p1.write(duty1);サーボモータに50Hzの信号を与えるのですが、細かな周期やパルス幅はオシロスコープの波形を見たりサーボモーターの振る舞いを見ながら微調整しました。Duty比は0~1の実数で指定します。Edison起動時に自動実行する場合は、やはり/etc/rc.localに上記コマンドを追記してください。UIによるスライダを配置してサーボモーターへの指令をJavaScriptで送るようにしています。iOSのSafari/ChromeやAndroidのChrome/Firefoxなどで動作を確認しています。画面の回転にも対応しています。このアプリは、主に下記のファイルで構成されています。UI用ファイルcss/pantilt.cssjs/pantilt.js内で、映像の取得と命令の送信を行っています。Winterで展示しました(週アスPLUSさんにも写真があります)。Wear」から操作できるデモとしました。カメラからの映像を見ながら三輪ロボットを操作してみた」が関連します。沢山の方にお越しいただき、ありがとうございました。Edisonを用いた簡単なデモということで、カメラのパンチルトを制御してみました。mraaモジュールを用いるとJavaScriptで直接GPIOにアクセスできるので、Web連携が容易であるという印象を持ちました。ドキュメントがあまり充実していないように思われるのが残念なところです(Pythonの入力ピンのプルアップ抵抗を有効にする方法を調べるために、mraaのソースをgrepしたりしました)。そのあたりは今後に期待でしょうか。あとは、7V以上の電源の確保と1.8VのGPIO入出力のレベルシフトがやや面倒、というところです。Pi用のカメラモジュールを用いる必要があります。PiではハードウェアPWMが一つしか使えないので、全く同じことをするのは少し面倒です。BlackでのGPIOプログラミングは未経験なのでノーコメントです。(MFTバージョン)」を購入したことをきっかけに、試してみることにしました。目指すのは、いつもやっている「Webカメラを接続してmjpg-streamerで映像を配信する」こととします。結果を先にお見せすると下図のような感じでです。Edisonで配信した映像がAndroidタブレットに表示されていることがわかります。Kit」を指していますのでご了承ください。EdisonでWebカメラを使うために、OSのイメージを自分でビルドする必要がありました。2015年1月に公開されたバージョンでは、デフォルトでWebカメラを利用可能になっています。そこで、ここではまずその方法を解説します。EdisonでのOSのイメージをビルドする方法が知りたい方は、このページの末尾に記録を残しておきますのでご覧ください。EdisonのアップデートをUbuntuで行うことにします。dfu-utilを実行してdfu-utilをインストールしておきます。imageをダウンロードします。2015年2月27日の時点ではedison-image-ww05-15.zipがダウンロードされました。その後、edison-image-ww05-15.zipと同じディレクトリにいるとして、下記のコマンドで書き込みます。Edisonに電源を投入すると、アップデートが始まります。J3コネクタにてシリアルコンソールに接続しておくと、進行状況がわかって安心です。Edisonをリブートすると、起動時に更新が始まります。EdisonのJ16コネクタにUSBカメラ(要変換コネクタ)、J21ピンに7V~15Vの電源を接続します。J3コネクタのシリアルコンソールでログインすると、/dev/video0ができていることがわかります。Edisonを再起動すると、カメラが認識されなくなります。一度電源を切ってから再投入することで認識されるようです。EdisonをWifi接続しておきます。詳細はスイッチサイエンスさんのページが詳しいです。Ubuntuマシンでmjpg-streamerのソースをダウンロードしておきます。Edison用のSubversionのパッケージが見当たらず、ソースからインストールするのは面倒だったため、Ubuntuであらかじめダウンロードしておく、というわけです。Edisonへ移動しておきます。Edisonでの作業です。opkgのフィードを設定する」を参考に、myfeeds.confというファイルを作成して編集を開始します。/etc/opkg/myfeeds.confこのファイルに下記の内容を記述して保存します。http://iotdk.intel.com/repos/1.1/iotdk/x86書けたら、下記のコマンドを実行します。Makefileここで、Makefileの39行目でinput_testpicture.soをビルド対象に含めている部分を下記のようにコメントアウトします。Edison用のパッケージがなく、またその名前の通り、input_testpicture.soはテスト時以外なくても困らないためです。以上のもと、ビルドします。makeビルドが完了したら、下記のコマンドにより、mjpg-streamerを起動します。EdisonのIPアドレス:9000/にアクセスすると、映像が配信されていることがわかります(2014.12.11追記。後に追加するエントリとの整合性をとるため、ポート番号を8080から9000に変更しました)。Androidの場合は簡単MJPEGビューアを使ってもよいです。ポート番号はソフトウェアキーボードで9000と変更してください。Edisonに電源を入れた際にmjpg-streamerが自動で起動するようにしておきます。mjpg-streamerディレクトリにstart_mine.shファイルを作成します。mjpg-streamer/start_mine.sh中には例えば以下の内容を記します。./www"次に、このスクリプトを/etc/rc.localに記述して、起動時に自動的に呼び出されるようにします。/etc/rc.local内容は下記の通りです。&最後に、/etc/rc.localのパーミッションを755にしておきます。Edisonの電源を切り、電源再投入してください(リブートでは駄目)。mjpg-streamerが自動で起動していることがわかるはずです。Blackと比べた場合のメリットは、5GHz帯のネットワークにデフォルトで接続できることでしょうか。Blackで5GHz帯のネットワークにつなぐにはGW-450Dを使う方法がありますが、kernelの再構築が必要であるなど、やや面倒です。Edisonの方でも、7V~15Vの電源が必要な点など使いにくいところはあります。こちらもどうぞこのページの話の続きです。(UVC)が有効になっていなかったので、それを有効にしたkernelと、それを含むOSイメージを作成する方法を解説しました。現在はUVCがデフォルトで有効になっていますのでこの作業は必要ないのですが、記録としてその方法を以下に残しておきます。この作業はUbuntuで行いました。Guideにまとめられています。Ubuntuに必要なパッケージをインストールします。filesをダウンロードします。2015年2月27日の時点ではedison-src-ww05-15.tgzでした。edison-src-ww05-15.tgzにより解凍します。edison-srcというディレクトリができますので、以下の順でまずはデフォルトのイメージを作成してみます。この際環境変数PATHにカレントディレクトリ「.」が含まれているとエラーが出ますので、あらかじめPATHから「.」を削除しておきます。edison-imageなお、最後のコマンドを実行すると、途中で様々なファイルのダウンロードが行われますが、環境やタイミングによりダウンロードエラーが起こることがありますので、エラー出ずにビルドが終了するまで繰り返します。私の場合、成功時に下記のようなメッセージが現れてビルドが完了しました。shown.ビルドが完了した後、以下のコマンドにより、書き込み用のファイル群をまとめます。./edison-src/device-software/utils/flash/postBuild.sh以上により、書き込み用のファイルがディレクトリedison-src/build/toFlashにまとめられます。このイメージを上で行ったようにflashall.shを用いて書き込めます。kernelの設定を変更したい場合は下記のようにして再ビルドしてください。kernelの設定ファイルはedison-src/device-software/meta-edison/recipes-kernel/linux/files/defconfigですので、手作業で変更する場合はこちらを編集します。menuconfigにより設定を行う場合は以下のようにします。Webカメラを有効にする場合は下記の操作を行ったのですが、既にこれはデフォルトで有効になっています。(複数回)と辿ることで設定ファイルがedison-src/build/tmp/work/edison-poky-linux/linux-yocto/3.10.17+gitAUTOINC+6ad20f049a_c03195ed6e-r0/linux-edison-standard-build/.configとして書き込まれます。これをkernelの設定ファイルの格納場所にコピーします。ディレクトリにて下記コマンドによりイメージの作成を行います。./edison-src/device-software/utils/flash/postBuild.sh以上で、edison-src/build/toFlashに書き込み用のファイルができました。16x32ドット」を購入し、長いこと放置していたのですが、少し時間ができたので試してみることにしました。Piで試すことにします。LEDパネルという構成にしました。することで、Adafruitで公開されているArduino用のライブラリを流用することができます。Pi用のチュートリアルが出てることを知りました。LEDパネルに表示するところまでを試してみます(下図)。準備まず、AdafruitのArduino用のチュートリアルを元に、Arduinoで動作することを確かめてください。ArduinoのIDEでFile→Examples→RGBmatrixPanelとたどった時に「16x32」が含まれているサンプルは動作します。5V」の組み合わせを用いました。Megaでもいけるようですが、こちらでは試していません。Piでの準備に入っていきます。LEDパネルに表示することを目指しますが、そのためにC++とOpenCVの組み合わせを用いることにします。最初はPythonと画像処理ライブラリのPillowの組み合わせで試していたのですが、思った速度が出なかったので、C++とOpenCVの組み合わせに切り替えました。Python+Pillow版についてはページ末尾にメモを残しますので、興味のある方はどうぞ。LEDパネルを下記のように接続しておきます。PiのUSBから供給されます。Piではカメラモジュールを使えるようにしておきましょう。Camera」→「Enable」とたどれば良いのでした。PiでOpenCV、および後に必要なcmakeをインストールします。OpenCv」をインストールします。kB)をダウンロードし、下記のコマンドでインストールします。Piのカメラモジュールで取得した画像に対してOpenCVを利用できるので良さそうです。私は普段OpenCVを使っているわけではなく、RaspiCamも今回初めて触ったので、「良さそう」という程度しか言えないのですが。LEDパネル用に私が用意したファイルを準備します。raspi_16x32RGBLEDmakemakeを実行した後、しばらく待つとビルドが完了します。画像ファイル表示用のimage2LEDmatrix、カメラモジュール表示用のcamera2LEDmatrixの2つの実行ファイルができています。Arduino用のserial2LEDmatrix.inoというC言語ファイルが存在します。このserial2LEDmatrix.inoをWindowsなどであらかじめArduinoに書き込んでおきましょう。このスケッチは、下図のように16x32x3バイトの階調(各階調は0~Fで表示)をシリアル通信で受け取り、「.」(ピリオド)を受け取ったタイミングでLEDパネルの内容を更新するように記述されています。以下、image2LEDmatrixとcamera2LEDmatrixの使用法を解説してきます。任意サイズの画像を与えることができます。画像の形式は、JPEGやPNGなど、OpenCVが読み込みに対応しているものです。動作モードは下記の2モードあります。0末尾の0は省略することができます。こちらは下図のように画像の全体をスケーリングして表示します。LEDパネルに紙をかぶせて撮影しています。下記の用に末尾に1をつけて起動すると、下図のように画像の左右または上下を捨て、なるべく画像を大きく表示します。Piのカメラモジュールの映像の表示カメラモジュールの映像を表示するには、下記のコマンドを実行します。LEDパネルに表示されます。真面目に計測していませんが、体感で5fps以上は出ているのではないかと思います。フレームレートが低いのは、動作の安定化のためにwhileループ内でusleep関数によるウェイトを入れているためです。RaspiCam自体は約30fpsで映像を取得する能力がありますのでご注意ください。やってみるとわかりますが(いや、やる前にわかるか)、解像度があまりにも小さいことと、LEDが明るすぎることとがあいまって、何が映っているかわからないことが多く、ちょっと厳しいです。普通に周囲の映像を映すと、ほとんどのLEDがかなりの輝度で輝くので、1.0A以上の電流がパネルに流れてしまいます。そのため、使いこなすには何らかの画像処理が必要そうです。OpenCVを使っているので、エッジ抽出、ビット反転、時間差分などを試したのですが、解像度の小ささから、何が起こっているのかわからず、イマイチでした。何か面白い応用があれば、お知らせ頂ければ幸いです。Pillowで試していました。この方法にはいくつか欠点があったため途中でやめてしまったのですが、メモとして記録を残しておきます。準備まず回路ですが、Python用いてArduinoとシリアル通信する場合は、こちらのstackoverflowにかかれているように、ArduinoのRESETとGNDの間に220μF程度のコンデンサを挟む必要があります。このコンデンサはスケッチ書き込み時は外してください。(追記:すいません、コンデンサなしでも問題なく動くかもしれません。Piでpipとpython-devとlibjpeg8-devをインストールします。LEDパネル用に私が用意したファイルを準備します。https://github.com/neuralassembly/raspi_16x32RGBLED_Pythonraspi_16x32RGBLED_Pythonの中に、画像ファイル表示用のimage2LEDmatrix.pyとカメラモジュールの映像表示用のcamera2LEDmatrix.pyとが入っています。これらを用いるのは、C++版でも用いたserial2LEDmatrix.inoをArduinoに書き込んでおいてください。1に対応しています(末尾の0は省略できます)。画像ファイルのサイズも任意ですが、画像リサイズのアルゴリズム(PIL.Image.NEAREST、PIL.Image.BILINEAR、PIL.Image.BICUBIC、PIL.Image.ANTIALIAS)がイマイチなため、縮小後の画像があまり綺麗に表示されないことがあるのが欠点です(OpenCV版ではINTER_AREAを用いました)。そのため、Python版ではWindowsのgimpなどで事前に画像を横32x縦16にリサイズしておいた方が良い場合があります。Piのカメラモジュールの映像の表示カメラモジュールの映像を表示するには、下記のコマンドを用います。この辺りを参考にしました。camera2LEDmatrix.py残念ながら、こちらはでは、2秒に1回程度しか映像が更新されません。そのため、Pythonをあきらめ、C++とOpenCVによる方法に移行したのでした。Piではじめる機械学習」を執筆しました。カメラからの映像を見ながら三輪オムニホイールロボットをラジコンのように操作してみました。Watchで三輪ロボットを制御しました。Watchでもその映像を表示してみよう、というのが今回のお話。WatchだけではなくペアリングされたAndroid端末とその上で動くアプリが必要です。システム全体の模式図は下図のようになります。スマートフォン側のアプリが三輪ロボット上のカメラからの映像を受け取り、それをWear側のアプリに送ります。カメラからの映像は640x480、15fpsで送られてきますが、Wear側へはそれを280x280、5fps程度に変換してから送っています。スマートフォンとWearはBLEで接続されていますので、データ量を極力減らさないとまともに動作しません。アプリのスクリーンショットはこちら。三輪ロボットを操作してみた」にあります。インポートして、スマホとWearの両方にインストールしてください。Piで動画配信するという方法もありますが、より簡単に試すには、Androidスマートフォン(以下「別スマホ」と表記)を用意してその上でIPWebcamというアプリを動かすのが簡単です。以下、この方法を簡単に示します。別スマホで、IPWebcamをインストールして起動します。起動すると画面にIPアドレスとポート番号が表示されるのでメモします。Limitが小さいほうがWear側のアプリは安定しますWearとペアリングしたスマホでMjpegViewWearを起動。メニューの設定で、IPアドレスと番号をセットします。コマンドは「videofeed」。n」は「n回に一回、Wearに画像を送る」の意味です。大きくすると安定しますが遅いです。小さくすると不安定になるので、nは3より小さくできなくしています。4か5程度にするとWear側のアプリが安定しますペアリングしたスマホで画像が表示されたら、メニューから「Wearアプリ起動」を実行します。Wearがスリープ状態のときは画面を一回タップしないと映像が表示されません。スマホとWear間の通信ですが、データを大量に送りすぎると、通信が切れてしまうことがあります。これは、Wear側の時計画面でクラウドアイコンに斜線が入ることでわかります。Wearがアップデートされるにともない、その問題は起こりにくくなっているように思います。現在は「通信が一度切れたら、スマホ側とWear側のアプリを終了して通信が回復するのを待つ」で済むことが多いです。Winterで展示しました(週アスPLUSさん、TAPPLIさん、星影さんのブログにも写真があります)。この時は下記の構成でデモしました。R映像送信の頻度はかなり安全側に振って設定しましたが、その甲斐あってか10:00~17:00の展示時間中、かなり安定して動作しました。たくさんの方にお越しいただき、ありがとうございました。Watch」というAndroidベースのスマートウォッチで実現したことの焼き直しです。下にリンクがあります。Wearを搭載した、Googleにより正式に認証を受けた端末で実現した、というのが今回の違いです。Wear搭載の時計ならばどれでも動作する(はず)、というメリットがあります。三輪オムニホイールロボットをラジコンのように操作してみました。仕組みなどシステム全体の模式図は下記のようになります。Piではnode.jsが動作しており、操作命令をWeb経由で受け付けています。Wearとペアリングされたスマートフォンから指令を送りますが、その際には「Androidアプリからnode.js+Socket.IOと双方向通信する」の解説を参考に、Gottox/socket.io-java-clientを使いました。Wearからのタッチ情報を用いています。20)に含まれているサンプルwearable/DataLayerをベースに作成します。時計と電話の間のデータのやり取りには下記のページのようにいくつかありますが、今回は送信データ量が大きくないので、シンプルなMessageApiを用います。Data解説用に簡単なサンプルを作成してみました。Wear間の通信だけを実装しています。Studioでインポートして利用できます。neuralassembly/TouchSampleWear側のアプリタッチ位置を電話のアプリにMessageApiにより送ります。タッチイベントから得た座標を毎回送るとデータ送信回数が多すぎ、通信が止まってしまうことがありました。その場合、Wearの時計画面に戻ると、クラウドアイコンに斜線が入り、通信が切れていることがわかります。そこで、下記の対策を施し、通信を安定化させました。タッチの座標の解像度を20ピクセル刻みとし、座標が変化したときのみ座標データを送信する連続的に送信するのではなく、「時計から座標データ送信」→「電話側でデータを受け取ったことを時計へ通知」→「時計側は電話からの通知を待ってから次の座標データ送信」...を繰り返すようにする2番目の変更が安定化には重要のようでした。エントリ追加時は、「データを送りすぎて通信が切れると、Wearかスマホの本体を再起動しないと通信が再開されない」ということが起こっていました。現在は「通信が切れたらWearとスマホのアプリをそれぞれ終了してしばらく待つことで通信が復活する」という動作になっているように思えます。いずれにせよ、通信量を減らすことは重要のようです)電話側のアプリWearから送られたWearのタッチ位置を表示します。述べたように、Wearからデータを受信したらその受信通知をWear側に送り返しています。2013などで展示してきました。OS/enchantMOON/android/iOSなど、OSに依存しない操作がWeb技術により可能になっています。Piはモバイルバッテリーで稼働させているのですが、展示を行う上ではこのバッテリーの消費が早いのが問題でした。PiではLinuxのディストリビューションであるRaspbianが動作しており、シャットダウンと再起動にそれなりに時間がかかります。そのため、展示を見に来て下さっている方がたくさんいる状況でモバイルバッテリーの残量を示すLEDが赤くなると、どのタイミングでバッテリーを交換すべきか悩んでしまうわけです。そこで、せめてモバイルバッテリー一つで展示1日(典型的には10:00~17:00)をもたせられないか、検討してみることにしました。Pi上のレギュレータ(RG2)をDC-DCコンバータに変更するの2点です。電力消費の小さいWifiドングルを探す最も電力を消費しそうなのはWifiドングルなので、消費電力の小さいものを探すのが効果がありそうに思いました。GW-US54Miniというかなり古いものなので、これも電力消費が大きい原因の一つと思われました。rayとの間でWifi通信を行っています(見ての通りとても近い)。デフォルト状態で利用可能だった下記の4つです。WLI-UC-GNM2IO-DATAのものが2つありますが、これらにはハイパワータイプと超小型タイプという違いがあります。GW-US54Miniです。古いだけあって大きいですね。Piに安定化電源で5Vを供給し、その電流を読むことで行います。Piを起動し、命令を受け付ける待機状態になった頃に読みます(実際の展示でも、待機している時間が長いと思われるため)。結果を示す前に注意ですが、以下のデータは、上の写真で示したように、非常に近い距離でWifi通信を行う際のものです。通信の距離が遠くなると電流は大きくなりますし、そうなった際に電流の大小関係は逆転する可能性があります。そのため、以下のデータは私のケースのみに当てはまる、あくまで目安と考えて下さい。WN-G150UMKが最も電流の小さいWifiドングルでした。実際には電流の揺らぎが大きいので、平均的な値を記しています。どのWifiドングルもRalinkのチップを使っているようなので、あまり違いが出ないのではないかと予想していたのですが、IO-DATAの2つは電流が小さくなりました(上で記したように、あくまで私のケースでは、ですが)。WN-G150UMKを用いることにします。Piを破壊する可能性がある(文字通り壊さないと実現できないのですが...)ため、自己責任でお願いします。B+を用いることで同様の効果が得られるはずです。実は上でのWifiドングルの交換でほとんど満足してしまっているのですが、後で思い返して気になるのも嫌なので、もう一つのレギュレータの交換についても試してみます。Piを低消費電力化するには、RG2というレギュレータを交換する、というのが定番のようで、既にいくつかの報告があります。Piをハード的にいじる。3.3VのLDOレギュレーターは効率が悪い。Piこれらの成果を参考にさせて頂き、RG2をDC-DCコンバータに変更してみます。昇降圧DC-DCコンバータモジュール(3.3V/5V)です。作業は表面実装されたRG2を取り外すDC-DCコンバータを取り付けるの順で進めます。Regulator」にて細かく解説されています。RG2のヒートシンクも兼ねているTABですが、ヒートシンクにはんだをモリモリと盛れば熱が効率的に伝わり簡単に取り外せます。2.のDC-DCコンバータ取り付けですが、下図のように3点(PSピンをGNDに接続するので正確には4点)を接続しました。DC-DCコンバータはユニバーサル基板の裏に隠れています。接続がちょっと安直すぎるかなと思いましたが、SDカードへのOSのインストール、Xを起動してのクライアントとしての利用、など一通りの機能は問題なく動作しました。0.34Aおよそ50mAだけ電流が減っていることがわかります。他のWifiドングルでも試してみましたが同様の結果が得られました。Regulator」でもやはり50mA程度の減少が報告されていますので、こんなものでしょう。効果は?既に示したように、Wifiドングルの変更とDC-DCコンバータの利用により、待機状態の電流は0.58A→0.34Aと大幅に減少しました。それに伴って待機時のモバイルバッテリーの持ちが良くなっていることは確認済です。実際の展示では三輪ロボットの操作時(=通信時)に電力消費が増える展示会場ではWifiの干渉によりさらに電力消費が増えると考えられるなどの理由により、「モバイルバッテリーで展示1日もたせる」という当初の目的が満たされているかはわかりません。Springの展示にて検証してみたいと思います。2014.3.22)展示にて検証したところ、10:00~17:00まで、一つのモバイルバッテリー(5400mAhのQE-QL201)で動作可能でした。展示終了の17:00間際にLEDがオレンジ→赤と変わったので、あと1、2時間はいけたのではないかと思います。低消費電力化した効果があって良かったです。A)を用いるとEthernetインターフェイスが省略されているUSBが1ポートのみにより、さらなる低消費電力化が見込めます。そこで、シリアル通信をUSB-シリアルコンバータからGPIOのUARTピンに変更し、USBポートを1ポートで済むようにしてみました。下記のサイトを参考にしました。AもDC-DCコンバータを用いて改造しています。A+を用いることで同様の効果が得られるはずです。0.20A劇的に電流が減ったので驚きです。Pi+カメラモジュールで行っても良いかな?という気がしてきます。今まではコマンドのみの受信だったものに、映像の送信を加えると通信量が増えて新たなトラブルが起こるかも知れない、とは思います。androidによる操作も可能になっています(動画はこちら)。BSHSBD02BK)で実現していますが、こちらの電流もせっかくなので調べてみたところ、0.04Aでした。Piではじめる機械学習」を執筆しました。オムニホイールロボットスタービルドストライクガンダムっぽいドロイド君を作った話はじめにガンダムビルドファイターズの後半の主人公機、スタービルドストライクガンダムをベースにしたドロイド君をつくったのでそのまとめ。背負い物が重いのでスタンド必須SEEDポーズ鎧武ドロイド、バロンドロイドと一緒に本家のスタービルドストライクガンダムと一緒に作り方ほとんどプラモのパーツをくっつけているだけなので、作るのは割と簡単です。今回は腕だけでなく、背負い物のために背中にもポリキャップを仕込んでいます。あと、スタンドを利用するために底に3mm径の穴を開けました。FXバーストドロイド君もそうですが、クリアパーツをいっぱいつけるとカッコいいですね(小並感ではでは。仮面ライダー鎧武っぽいドロイド君を作った話はじめにこれまでガンダムAGE1タイタス風に改造したドロイド君をSNSのアイコンにして来ましたが、テレビ放映も終わってしばらくたつし、そろそろ変更したいと考えていました。見た目のインパクトから、今回の素材は仮面ライダー鎧武をチョイスしてみました。するように、もともとのオレンジアームズをいったんばらしているので、この程度までしか変形できません。バナナアームズ肩パーツ:BB戦士ガンダムAGE2腕パーツ:BB戦士ガンダムAGE1こいつをSNSのアイコンにしたくて作り始めました。ドロイドバロン、変身途中。パインアームズを装着した鎧武と。マンゴーアームズを装着したバロンと。作り方アームズチェンジシリーズのアームズをニッパーで一旦バラバラにした後、下図のように真鍮線で結合します。ドロイド君本体の方にこの真鍮線がはまる溝をつくってはめ込みます。腕はガンダムAGE風ドロイド君と同じく本体にポリキャップを仕込んで取り付けます。上記のような作り方をしているので、アームズチェンジできます。これが...こうじゃ。おわりに新しいSNSのアイコンを作りたいという目的は達せられたので満足です。お高いアームズチェンジシリーズをニッパーでバラバラにしなければならないので、作る際ちょっと心理的に抵抗がありました。本当は斬月も欲しいのだけど次は作らないかも。Springで展示する際のブースのマスコットとして登場予定です。Piの性能では解像度320x240、フレームレート10fps程度が安定に動作する限界でした。USBカメラを用いてもこれは大差ないと思います。(ABC2014S)でもこのような動画のストリーミングを用いた展示を行おうと考えているのですが、320x240の10fpsでは動画のクオリティとしては少し物足りないです。Piよりも高性能なボードが必要になります。気になるのはBeagleBoneBlackだったのですが、ABC2014Sではコンセントが使えるので、より高性能なボードを使って確実な動作を目指すことにしました。ESにUbuntuを導入し、mjpg-streamerを動かすまでの解説です。Serverをこちらの解説に従いインストールします。SDカードへの書き込みは私の場合PC上のUbuntuで下記のように行いました。/dev/sdeの部分は環境に応じて書き換えます。ESを接続し、115200bpsでPCからPandaBoardにシリアル接続しておきます。以上の準備の元、電源を投入すると、インストールが始まります。後でWifiドングルの設定を行うので、ここではネットワークの設定をスキップしました。serverを選択しました。Wifiの設定まず、ネットワークの接続にWifiを用いたかったのでその設定をします。技適の問題があることと、パフォーマンスがあまり良くないらしい(ただし試してない)ことの2点より、市販のWifiドングルを用いることにしました。用いたのはIO-DATAのWN-G150Uです。末尾に下記の内容を追記します。wl12xx_sdio記述したら再起動し、Wifiドングルをさします。-aを実行し、wlan0が存在することを確認します。編集してwlan0として認識されるようにします。末尾にに下記の内容を追記します。環境に応じて書き換えます。192.168.1.1次に、/etc/wpa_supplicant/wpa_supplicant.confを作成し例えば下記のように記述します。接続先のSSID、暗号化プロトコル、パスフレーズなどは環境に応じて変更します。psk="YOUR_PASSPHRASE"}最後に、/etc/resolv.confを作成してDNSサーバーを記述します。本当はresolvconfに自動生成させるらしいのですがServer版のためかうまくいかなかったので手作業で記述しました。192.168.1.1以上の設定がうまくいくと、再起動によりWifiでネットワークに接続されているはずです。mjpg-streamerのインストールまず、OSを最新にします。upgradeそして、mjpg-streamerのビルドに必要な下記をインストールします。subversionそれが済んだら、下記のようにmjpg-streamerのダウンロードからビルドまで行います。snd_usb_audioを記述して再起動しておきます。一部のUSBカメラとUSBオーディオのドライバとの相性が悪いためです。このあたりに書いてあります。起動は下記のような流れで行います。解像度640x480のフレームレート15fpsとしています。30fpsでもPandaBoard側は問題なく動作しますが、受信側にそこまでの性能はないと考え控えめに15fpsとしました。映像が配信されていることがわかります。この映像をandroidで受け取るには、いつも通り簡単MJPEGビューアを使います。このアプリのソースはこちらにあります。アプリを起動したら、メニューから「設定」を選択し、解像度を640x480に、ポート番号を8080に設定します。ABC2014Sでは望遠カメラをストリーミングし、観光地にある望遠鏡のように上下左右に動かすデモを行う予定です。Wifiを使うので、うまくいくかは当日にならないとわからないのがつらいところ。mjpg-streamerの自動起動mjpg-streamerを自動で起動するためには、例えば下記のようにします。mjpg-streamerをビルドしたディレクトリが/home/username/mjpg-streamerであると仮定します。下記の内容を記述します。./www"次に、このスクリプトを/etc/rc.localに記述することで、自動起動します。←この行はもともとある行おしまい。んー、やっぱり後でBeagleBoneBlackでも試そう。