20110225

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によるマルチホップなセンサネットワークが構築できるはずだ。次回はその実用性に関するレビューについて書いてみようと思う。