Archiduino Project - vol.24

建築系におけるArduino利用計画としての「Archiduino Project」。

今回のテーマは、「Wi-Fi化」である。ワイヤレスでマルチホップな無線センサーネットワークをXBeeで実装するという話はすでにしてきたが、最終的にデータをサーバに飛ばすには、インターネットに接続してリモートサーバにデータを送らなければならない。これまではイーサネットシールドを使って有線でデータを送信するという方法をとっていた。

しかしながら、たとえイーサネットとはいえやはり無線化は必定と考え、Arduinoのインターネット接続をWi-Fiで実現するためのシールドを手配した。Seeed StudioでPCBを発注するときに、Seeed謹製の「WIFI Shield」なるもの（$60くらい。国内では千石電商でも購入可能）を一緒に発注してみた。このシールドで使われているWi-Fiモジュール（Microchip RN-131）は技適を通っていない製品なので、日本国内では本来的には使用できないが、あくまで性能評価のための試験利用ということで使ってみることとした。

このシールド（写真ではグレーのアクリルの下にある）を動かすには、Arduinoからシリアル通信でチップにコマンドを送るのだが、どうやらもともとSparkfunのWiFly Shieldで使われているライブラリをそのまま流用できるらしい。そりゃモジュールが一緒だから可能だろうて。

そういうわけで、ライブラリをインストールしてアクセスポイントにWPSで接続し、DHCPでアドレスを振ってもらってサーバにHTTPでアクセス（XBeeから受け取ったデータをGETメソッドでサーバに送信）というコードを書いた。

問題は送信速度ということになる。センサーネットワークでハブになるノードは常にサーバにデータを送信し続けなければならない。何十ものセンサーノードがぶら下がるハブノードは、毎秒数十ものデータを送信し続けることになるのだが、ここで送信に遅延が生じると、データの取りこぼしが発生してしまう。したがって、ハブノードの速さ（通信速さと処理速さ）を検証しておかなければならない。というわけで、今回は試験的に4ノードをぶら下げた場合で検証してみた。

結論としては、実用に耐えない遅さ、といわざるを得ない。秒間1～2回の処理しか捌けなかったという惨憺たる結果である。尤も、各センサーノードが3秒に1回という頻度でデータを送るという現状の設定もなかなかあり得ない話なので、仮に各ノードが1分間に1回程度データを送ればよいということにしてしまえば、このキャパからすれば、2～30のノードをぶら下げるのも可能かもしれない。

それにしても、今回の結果はちょっと残念な結果だったといわざるを得ない。もしかすると、私の書いたスケッチがヘボかったからトロいことになっているのかもしれない。これについては引き続き検証してゆく。ArduinoでWi-Fi化する方法は、大本営からWi-Fiシールドも出ていることなので、こっちも試してみたい。Wi-Fi化については今後も引き続き検討してゆく。

Archiduino Project - vol.22

建築系におけるArduino利用計画としての「Archiduino Project」。

日本建築学会の情報システム利用技術シンポジウムで「オープンソースハードウェアを用いたローコストワイヤレスセンサネットワークの開発と実装」と題して講演を行いました。これまでの「Archiduino Project」を7つのフェーズに分けて、それらについて簡単にまとめたものです。今回は特に小型化と低価格化に加え、行動と環境のセンシングデータを応用した行動推定について新規に紹介しました。この委員会の研究集会はいつも楽しいのでテンションあがりまくりでしゃべくりました（笑

先日のMTM07で販売したArchiduino基板についても、基板だけですが、希望の方に配布ししました。基板そのままでは使えませんので、せっかくですから自前で部品をそろえていただき実装してみて下さい。取扱説明書はこちら。

せっかくなので有言実行と言うことで、ArchiduinoのEagleデータやFusion PCBにそのまま発注できる状態でのデータを公開したいと思います。ライセンスはGPL準拠でお願いしたいと思いますので、基本的に改変した場合は公開していただければと。さらには「もっとこうした方がいいよ」というアドバイスもいただければと思いますので、それはTwitterでお願いします。

- Archiduino Eagleデータ
- Archiduino Fusion PCB 発注用データ

Fusion PCBへの発注については、このデータをそのままメール送信していただければ大丈夫ですが、ファイル名を所定の形式に変更する事を忘れないようにして下さい。

Archiduino Project - vol.19

建築系におけるArduino利用計画としての「Archiduino Project」。

今回はサーバ側のプログラムについて。

これまでのプロジェクトではあまり触れてこなかったが、ハブノードはセンサノードから受け取ったデータを受信用のサーバに随時送信を行っているわけであり、当然サーバ側にはそのデータを受信するためのプログラムが動いている。私はサーバサイドで動くプログラムについてあまりというか全然知識がないので、とりあえず動けばいいや的に、例によってPerlでCGIを書き、HTTPのGETメソッドで送られてきたデータを受け取る、といういつもの方法を使うことにした。

Pachubeにデータを送るために、受信側のプログラム（サーバサイドで稼働）はeeml形式のXMLデータを書き出すこともやらせている。私の勘違いでなければ、Pachubeのアップデートのタイミングといっしょにeemlの書式（必要なデータ項目）も変わったりするので注意が必要だ。というわけで、サンプルプログラムを以下に掲載する。

Archiduino MBT - vol.1

なお、MBTとはこのArchiduinoプロジェクトが始まるきっかけとなった「Make Buildings Talk」プロジェクトの頭文字をとったものであり、これはその名残である。HTTPdとCGIの動くサーバを用意し、任意の階層に上記CGIを設置する。データファイルなどの保存のために、同じディレクトリにeemlとdataディレクトリを用意しておく（パーミッションは666など）。dataにはその日ごとに記録ファイルが作られ保存される。eemlにはPachubeへのアップロードに対応した（＝Pachubeに随時参照させる）eemlファイルが保存されるが、フィードに関する設定情報をeeml直下にあるfeeddata.csvに記録しておく。これは例を参考にして、エクセルなどで適宜項目を作成して欲しい。

ちなみにハードの話であるが、私がサーバとして使用しているのはMac mini（Mac mini Serverではない）である。Mac miniはコンパクト／安い／デザインも良いというわけで、今後もなにかと重宝するのではないかと考えている。今はWindowsをブートキャンプしているけれども、今後はLinuxとかでやれないモノかと夢想中。

Archiduino Project - vol.18

建築系におけるArduino利用計画としての「Archiduino Project」。

今回は新型のハブノードについて。

Arduino DuemilanoveがUNOになるタイミングに合わせてイーサネットシールドもバージョンが上がりました。新しいイーサネットシールド、というよりもUNOではこれまでのハブノードのスケッチが動かない（使用していたライブラリに問題がある？）ので、これを機会にUNO＋新イーサネットシールドの構成で再構成してみた。

というわけで構成は至って単純。UNOにイーサをのっけておまけに「もろもろシールド」を乗せただけである。

UNOとXBeeシールドとの相性は相変わらず悪いので、最近はXBeeシールドを使わないことにしている。従って、例によってXBeeはピッチ変換基板を「もろもろシールド」（※センサーやLEDなどをユニバーサル基板にのせたもの）にのせることで実装した。前作でもサーバへのアップロードに失敗すると圧電ブザーを鳴らすことにしているが、これはLEDの点灯だけにしても良いと思っている。ま、そこは趣味の問題。

次にスケッチ。結論から言えば完全移植には一歩至っていない。DNSサーバにドメイン名からIPを逆引きする部分については未実装だが、とりあえず静的IPという前提であれば問題はないと言うことにした（鋭意実装中）。ただし、DHCPによるローカルアドレス取得には対応済み。ちなみにDHCPのライブラリはこちらを使用。また、そのほかのライブラリとしてはPStringとXBeeを使用している。

というわけで、バージョンゼロのスケッチを以下に掲載する。

Archiduino HUB - ver. 0

Archiduino Project - vol.16

建築系におけるArduino利用計画としての「Archiduino Project」。

いよいよ念願のメッシュネットワークによるローコストモニタリング基盤が実現できそうな運びとなったので、興奮冷めやらぬうちに報告したいと思う。

まず、なぜ「メッシュネットワーク」にする必要があったのかという点について。これについてはひとえに、伝送距離の長距離化のためには必要不可欠であったからである。XBeeの仕様書によれば、日本国内では電波法の関係上（？）、出力が低く抑えられてしまっており、XBeeチップのレギュラー版であれば公称120m（屋外見通し距離）ということだが、実際にはこれよりももっと短い距離しか飛ばない。屋内になると更に短く、ドアや階段を途中に挟むとほとんど届かないと思ってよい。

このような問題をクリアするためには、まず手っ取り早くはより高出力型であるPro版を使うという手もあるが、実際には思った以上に距離が伸びるというほどでもない。2階建ての家の一階の隅から二階の隅まで届くのかといえば、答えは明確にNoである。具体的にいうと、「箱の家ではない」の一階寝室に置かれたセンサノードからは、それがPro版を載せていても2階リビングにあるハブノードまでは届かない。

こうした問題を解決するためには、やはりバケツリレー型のメッシュネットワークを構築し、そのネットワーク上にデータを流してやる、という方法をとらざるを得ない。尤も、こちらとしては既存の技術を使わせてもらうにすぎないわけで、やれることには限界があるし、多分にチップベンダー依存ではある。だがこれまでに1ノード数千円で構築できる安価なセンシングインフラが建築分野で使われた事があったかといえば、おそらく答えはNoのはずである。

メッシュネットワークにすれば万事解決というわけでもない。もちろん、ボトルネックがあると、そのノードの故障が他のノードからのデータの不達を引き起こす可能性をはらんでしまうので、ロバストなノード配置を気にしなければならない。

今回実装してみてわかったことでもあるが、1サイクルの処理に4秒「も」かかっている――ログの間隔が最短でも4秒おき――のは、やはりArduinoの非力さが露呈したといっても過言ではあるまい。技術的にはもう少し早くできるのかも知れないが、今の手持ちの実験環境ではそんな感じである。

通信速度の問題について改めて検証したところ、どうやら温湿度センサ（Sensirion SHT7X）の処理部分に時間がかかっている事が判明した。別なセンサを使用したところ、この問題が発生しない事がわかっている。

さて、前振りはそんなところにして、今回の実装についてメモを残しておきたい。まず最初にやらなければならなかったのは、XBeeをAPIモードで動かすためのさまざまな設定である。いくつかの段階で手が止まることがあったので、自分自身への備忘録ということも含め、やや詳細に書き残しておく。

なお、今回使用するメッシュネットワークは、いわゆるZigBeeではなく、Digi International社の独自実装プロトコルであるDigiMeshを利用することとした。その理由は二つ。第1に、手持ちのXBeeがすべて「シリーズ1」と呼ばれる製品であったこと。ちなみにシリーズ2はZigBeeに準拠した製品である。第2に、ZigBeeはクラスタツリー型のネットワークを構築するが、DigiMeshは完全グラフ型のネットワークを構築するという違いがあるとかそういう話をどこかで目にしたからだ（公式の仕様書に記載あり）。ともあれ、ここは第1の理由によるところが大きい。

最初に行う手続きは、手持ちのXBeeをAPIモードに変更する作業である。ネットで検索するとその手続き方法が見つかる。例えばこことかここが詳しいが、ここに書かれている方法はZigBeeのものであってDigiMeshのものではないことに注意されたい。DigiMeshのファームウェア（XB24-DMあるいはXBP24-DM）は、事前にDigiのウェブサイトからダウンロードしておく（各種あるが、レギュラー版だとxb24-dm_804B.zipでよい）。APIモードの送信データ形式の説明などは、マニュアルに目を通すなりして「そういうモノなんだ」という程度の理解で良いので知っておいた方がいいだろう。また、私が引っかかった点としては、「APIモードは2のエスケープモードで使用する」というところだ。「1（without escape mode）」にしてしまうとダメなのであった。つまるところ、設定の変更箇所はID（Modem VID）、NI（Node Itentifier）とAP（API Enable）だけだろう。

XBeeをAPIモードに移行するところまではできた。Arduinoにセンサなどを載せるところの話は省略し、いよいよ実際に走らせるスケッチの話になる。

ここで改めてこのセンサネットワークの構成をおさらいすると、インターネットに接続しているハブノードを親機とし、親機はすべてのセンサノードからのデータを一気に引き受け、インターネット上のサーバにデータを送る役割をする。また、ここでセンサノードは子機であり、それぞれのノードは様々なセンサを搭載しており、そのデータを随時親機に向けて送信するエラーのチェックなどは一際せずに、送ったら送りっぱなしである。また、伝送の遅延についてもチェックするでもなく、RTCを搭載するでもないので、データはサーバに届いた時刻をセンシングした時刻として残す。私が扱うデータはそれほどタイムクリティカルなものではないので、タイムラグは一切無視である。いってしまえば、そういう「良い加減」なシステムであるから安くて良いのだ。

なお、親機からサーバへのデータ転送は、お得意のHTTPのGETメソッドを使う方法としたのは言うまでもない（笑）

今回の実装に際し、実装を最優先させたので、サーバで走らせている受信側のプログラムなどいろいろ変更することとなった。とはいえ、大した変更ではないし、むしろ必要な変更であったとも言える。

親機で走らせるプログラムはこちらである（これはローカルネット上のサーバに送信するバージョン）。いろいろ設定は各自変更していただき、ライブラリも適宜導入していただきたい。DHCPも搭載しているので、ルータにつなぐだけでOKである。

子機で走らせるプログラムはこちらである。送信先のノードのアドレスを、親機のXBeeチップに記載されている64bitアドレスに設定する。そのほか、サンプルコードでは温湿度センサ、照度センサを搭載した場合のコードも記載してあるので、他のセンサを載せたい場合などに書式を参考にしていただきたい。なお、私はどうしてもデータを一度文字列にしたい修正があるので、わざわざPStringというライブラリを使っていたりするが、そのへんはご容赦願いたい。また、PStringした文字列をuint8_tに変換する部分の処理については、早稲田大学情報理工学科の林明宏助手にご協力いただいた。

さて、これらをおのおの実装していただければあとはすんなりDigiMeshによるマルチホップなセンサネットワークが構築できるはずだ。次回はその実用性に関するレビューについて書いてみようと思う。

Tweet Translation Bot

かねてから構想にあったプログラムに（やっと）手をつける事が出来たので公開します。

Tweet Translation Bot - 0.03
Tweet Translation Bot - 0.02
Tweet Translation Bot - 0.01

こんな感じで再投稿されます。

●概要
日本語でつぶやいた記事をそのままGoogle Translate(GT) APIかExcite翻訳を利用して英語に翻訳し、それを英語用の別アカウントに投稿し直すBotです。翻訳の精度は翻訳エンジンに依存します。翻訳エンジンが進化すればきっと翻訳精度も上がるでしょう。現時点では、読めなくもない、と言う程度です。翻訳エンジンが翻訳しやすい日本語でつぶやきましょう。

●設置方法

1. 下記のソースコードに従い、いくつかのPerlモジュールをCPAN経由でインストールする。ちなみに、XML::Simple、Net::Twitterさえ入れれば、ほかのはすでに入っている可能性が高い。
2. 翻訳したTweetを投稿したいTwitterアカウントを取得する（以降、これをenアカウントと呼ぶ）
3. enアカウントにログインし、画面下部の「API」というリンクを辿り、下記の設定事項にある4つのAPIキーを取得する。詳細はhttp://perl-mongers.org/2010/06/_perltwitteroauth.htmlを参考にしてください。
4. 取得した4つのキーを下記に設定する
5. 以下の設定事項にある、翻訳言語の設定を行う。
6. user.csvをテキストエディタで開き、「username」の箇所を日本語で投稿しているアカウント（jaアカウント）に書き換える。usernameの隣の数字は最終投稿時間であり、jaアカウントが更新されるとこれも更新される。つまり、この時間以後に追加された記事に対して翻訳を行うという事。必要ならば動作させる前に修正する事。
7. Perlの動作する環境（例：Windows環境下でActiveperlをインストールした環境）でこのスクリプトを動作させる。簡単のためTransbot.batを同梱しており、これをダブルクリックすれば起動する。
8. 常時監視し続けるため、コマンドプロンプトは終了させずにおくこと。

●ご意見など
Twitterでお寄せください。@entasanまで。