日本性神巡り - vol.1

日本各地に点在する「性神」を巡る旅。

その第1回目の記事は、性神伝承のなかでも特に有名な、道鏡に由来のある金精神社巡りについて取り上げることとする。場所は群馬県片品村に位置するが、この小さな祠へアプローチするには、国道120号、通称ロマンチック街道にある金精トンネル栃木側出口から若干の登山を経なければならない。そしてその山道はちょっとだけ険しいので、軽装での登山には注意を要する。トンネル付近の駐車場に車を止め、そこから延びる登山道から30分程度の山道を登る。今回はその山道を実況的に解説したいと思う。20歩ごとに一枚ずつ写真を撮影しているので、距離感の参考にして欲しい。

金精神社（wikipedia）

駐車場にある登山道の説明看板。金精神社についてはあまり情報がない。

登山道入り口付近。

看板が心許ない。

最初は土留めのコンクリート壁の縁を歩く。

ごつごつした岩肌の道を上っていく。既に心が折れはじめる。

ロープは積極的に利用した方が良い。写真ではわかりにくいが、道中はそれなりに傾斜がきつい。

ゴツい道は序盤だけ。

数日前の土砂降りで土砂崩れ的なものがあったようだ。登山道の途中が一部崩壊していた。崖側に滑り落ちると大怪我だろう。

この辺から森に囲まれる。

なんどでもいうが、ロープは使おう。先人の心遣いに感謝。

木々の根っこが階段になっている。

倒木もある。

階段の一段一段の蹴上げが膝下くらいまでの高さがあるので、体力的にかなりきつい。休み休み行くべき。

はしごを使って上っても良いし、これをよけて斜面を歩いても良いだろう。

ロープは（略。

徐々にではあるが、木立の生え方に変化が現れつつある。木が細く、散在するようになってきた。

途中に一カ所、案内が出ている。

ゴールに向かって一部下り坂のシーンがある。足場が悪いので注意。

前方になぜか中華風の祠が見える。残念ながらこれが目当ての金精神社である。

笹とアザミが足下に茂っている。

峠を登り切ったところ。いくつかの登山ルートの合流点なのだろう。

金精神社に到着。所要時間は片道30分くらいではないか。外観は神社というよりも寺院、それも道教の寺院とでもいうような外観である。（これってもしかして道教と道鏡を掛けているのか？）

金精神社内観。中央に50センチほどの陽石が据えられている。天然石を砕いて整形したようなつくりである。カリの部分が生々しい。

内部は思っていた以上に荒れておらず、度々参拝者がきていることが推察できる。この手の神社には珍しく南京錠で扉が封鎖されておらず、扉が風雨で開くことがないように置かれた石をよければ内部を見ることが可能である。祠自体はコンクリートブロックによる組積造で、外側を漆喰で塗り込めている。外側の漆喰は一部崩落している。

場所的にもよほど性神信仰に興味のある人か、あるいはたまたま通りかかった登山客ぐらいしか参拝者は訪れないだろう。たまたま通りかかったぐらいでは、この味気ない建物の中に何が入っているかなんて、わざわざ扉を開けて確かめることもないだろう。そんな寂しさの中に、道鏡が残していったとされるご神体が安置されているのだ。何とも切ない。

この神社らしからぬ神社は、そもそもコンクリートブロックの組積造である点も珍しいが、他の性神を祀る神社に比べて異なる点はといえば、水のわき出る泉や井戸、手水舎などが無いこと、山の稜線上に位置すること、祭りを行うための舞台（神楽殿や土俵など）がないこと、などがあげられる。

性神巡りをするにあたり避けては通れぬ場所――一度は行っておかねばならない場所――であるから行ってきたわけだが、なぜこんな場所にご神体が追いやられることとなったのか興味深い。

Archiduino Project - vol.20

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

今回の記事でついに20回目となり、個人的にはひとつの区切りを迎えたように思う。今回の内容は「Eagleをつかった自作Arduinoの回路設計」と「Fusion PCBをつかった自作基板の発注」である。各種センサーのコントロール基板（いわゆるマイコン部分）としての「自作Arduino」の製作は、この内容を持ってほぼ完成であると思われる。これ以降はおそらくそのバリエーションでしかないだろう。

これまではユニバーサル基板やブレッドボードの上に様々な部品配置をおこない、その上でArduinoを走らせると言うことを行ってきたわけだが、その方法に限界を感じるようになってきた。第一に、ダウンサイジングが困難であるということ。第二に、手作業の数が半端ないので時間的なコストが大きいと言うことである。確かにはんだ付けは楽しい、しかしながら、その労力はその楽しさをいつか損ないかねない。プロトタイプの作成段階をとっくに終え、いまや量産の段階に入らんとするとき、やはり方法の変革は必要だろう。

ということで、基板のプリントに手をつけるときが来たというわけである。ちなみに、千石電商などでも感光基板を売っているのを目にしていたが、結局これも道具やら材料やらの手配に時間とコストがかかるので、どうせならPCB（Printed Circuit Board）サービスを利用してやろうともくろんでみた。特に最近話題の「Fusion PCB」なる、中国は深玔にあるというローコストなPCBサービスを使ってみようというわけだ。ちなみにFusion PCBはすでに何度か利用したことのあるSeeed StudioのPCBサービスである。

PCBを利用するに当たり、最初にすべきは発注用のガーバーデータ（部品配置やシルクプリントなどのデータとドリル穴あけ用のNCデータとをひっくるめた意味とする）の作成である。ガーバーデータの作成は、よくわからんけど、とりあえずソフト上で回路図と基板上の部品配置図とを作成してからデータを書き出す、みたいな手順を踏むらしい。というわけで、ガーバーデータの作成の前に回路図を組まなければならない。回路図については、これまでさんざんArchiduinoを作ってきたワケなので、これと同じ回路で良い。というわけで、回路図を組むのにEagleを使ってみることとする。

ちなみにEagleはドイツ製の回路図作成フリーソフト。フリーの状態だと設計できる基板のサイズに制限（50x100mmくらい）があるが、シロウトのDIY程度であればこれで十分だろう。ちなみにEagleのすばらしいところは、回路図を組めば同時に部品の配置図まで作成してくれ（もちろん基板上の最終的な配置は自分でする）、配置を終えれば自動配線機能により最適化された配線をしてくれてしまうというすぐれものである。

世界中のユーザーに支えられているおかげで、Fusion PCBをはじめとして、世のPCBサービスに納品すべきガーバーデータの書き出し設定ファイルが手に入り、これをつかってぽんぽん進めていけば、なにも考えることなく基板発注が終わってしまうと言うわけだ。すばらしいというしかない。

たしかにEagleの操作性はちょっと今ひとつなところはあるが、それはあくまでIllustratorなどと比較した場合であるわけで、不便だなとは思いつつも慣れればたいした問題ではなく、フリーソフトとしては十分な完成度であろう。ちなみに日本語版はなく、有志が日本語化パッチを出している程度なので、その辺の覚悟は必要だろう。

Eagleの使い方についてはまた別な機会に譲るとして、回路図の作成→配置図の作成まで終わったら、Fusion PCBに納品すべきガーバーデータの作成である。これもFusion PCBから公開されている設定ファイルを読み込み、それにマッチするかどうかチェックすれば良いだけだ。不適合な箇所についてはアラートが出るので、主に配線とドリル穴とのクリアランスの問題だと思うが、その部分の修正を行えば良い。アラートが出なくなったら納品できるデータと相成ったわけである。

Fusion PCBへの納品方法は、Seeed Depotで販売されている「Fusion PCBクーポン」みたいなモノを購入し、その購入番号とデータとを先方にメールで送ればあとは中の人が宜しくやってくれるという寸法である。50x50mmの基板（×10枚）で9.9ドル、最も安い郵送方法だと送料が3ドルちょっとなので、トータルでも13.42ドルだ。1ドル87円換算だとすると、1,170円くらい。これで10枚のプリント基板が手に入るのだから、安いと言わざるを得ないだろう。ちなみに50x100mmの場合、15ドル上乗せである。

Fusion PCBに発注し、先方から「under processing」の返信が来たら、後は安心して10日ほど待てば良い。おそらくUPSなどの速達便を使えばもう少し納品が早いのだろうが、発注したモノよりも値段が張るので気が引ける。はやめはやめの発注が肝要だろう。発注して待っている間に秋月などに部品の手配をする（これもネット経由）のがいいだろう。

というわけで待つこと10日。香港ポスト経由で日本郵便が持ってきてくれる。書留である。小さな段ボール箱にエアキャップで梱包されている。このエアキャップ、日本のモノに比べて実に貧相で、ぎゅっと握るだけで相当数が破裂する。ともあれ、開梱、チェック、部品の実装を行い、動作の確認、というわけだ。

Twitterなどを見ると多くの先人たちがFusion PCBをすでに利用しているようだ。なるほどこの手軽さと安さは非常に魅力的である。送料にお金を掛けないと時間がかかるが、のんびり次回作のアイディアでも練りつつ待っているのが良いのではないだろうか。

ちなみに、今回発注したのは2品。ひとつは、これまでのArchiduino基板と互換性のある名刺サイズの基板。もうひとつは、ATmega328を使いつつも最小までダウンサイジングをしたモノとの2種類である。前者は50x100サイズになってしまうのでちょっと値が張る（1枚250円くらい）。後者は右の写真の通りで、2.54mmピッチのグリッドで14x14サイズ（38mm四方）に収め、AC駆動かつXBeeチップを搭載可能な基板とした。これで1枚120円なのだからすばらしいよね。

初めてPCBを利用して強く思ったのは、一度Eagleの使い方を覚え、PCBサービスの利用方法を覚えれば、おなじ「Arduino」という道具でも活用の幅が段違いに広がるということである。例えば、ちょっとした隙間に基板全体を収めなければならない場合でも、そのサイズに合うように回路を設計すればよく、配線が出来ないだとか、基板の大きさが合わないだとかが理由で、もろもろを断念することがなくなるのだ。これはすごい。それから、とりあえず現段階では、はんだ付けという作業は部品の実装だけに限られるわけであり、大幅な労力削減と正確性が確保された。確かにちょっとはんだ付けするに精密さが要求される場面があるが、職人でなければ出来ないというレベルではない。そろそろ各方面にばらまくことも考えてみようか。

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.17

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

Archiduino Project - vol.5でもすでに紹介しているが、自作のローコストArduinoを更新したのでレポートしたいと思う。

基本的な構成は変更がなかったという意味で、すでに私の中では完成されたものなのかもしれない。設計思想について以下にまとめてみる。

・名刺サイズのユニバーサル基板上で完結する（横23×縦15グリッドの範囲の中に収める）。
・XBeeの通信機能を持つ（ピッチ変換アダプタを介することは許容する）。
・デジタル／アナログ入力端子については、最大限利用可能な数を確保する（13＋6でなくても良いこととする）。
・ATmega328P-PUを使う（小さいのとかはとりあえず考えない）
・スケッチは直接書き込めなくても良い（別途ArduinoなどでアップロードしたICを換装することでもよしとする）
・基本的にはACアダプタ（9V）挿したら延々と回り続ける仕様にしたい。
・なるべく必要最小限の構成を心がける。

写真のものはバージョン3.5である。

既存のバージョン3でも上記の条件をすでに実現していたが、Power LEDはピッチ変換基板のLEDと統合できたり、バイパスコンデンサの位置のせいではんだ付けの労力が大きくなってしまっていたことなどもあり、それらの点を変更したいと考えていた。また、スケッチのアップロードについても、既存の基板上の余剰スペースを活用して対応できるようにしてみたいとも考えていた。これらについて対応したのがバージョン3.5である。導線部分などのアクロバティックな構成を考えるのに苦心した。これはほんとパズルだな。だが楽しい。

3.5を作ってみて、スケッチのアップロードには対応しなくても良いのではないかと思ってしまった。やはり、ICへの書き込みは作業を切り分けて別途実施し、施工した基板にこれをがんがん嵌めて電源通して設置完了！という流れで良いのだとあらためて思い直してしまった。いちいちスケッチを描き直すような使い方を想定しないことが、やはりこのプロジェクトの前提条件であろう。

以下に構成部品を記す。

・秋月電子 低損失三端子レギュレーター5V500mA TA48M05F：AC電源からの入力電圧の調整に必要。5Vを出力。100円。
・秋月電子 低損失三端子レギュレーター3.3V500mA TA48M033F：上記で得られた5Vを更に3.3Vに変換。XBeeチップの作動に使用する。100円。
・秋月電子 水晶発振子 16MHz：16MHzの発振に必要。10個入り500円。
・秋月電子 絶縁型ラジアルリードタイプ積層セラミックコンデンサー 0.1μF 50V：主にバイパスコンデンサとして使用。10個入り100円。
・ATMEL AVRマイコン ATmega328P-PU：Arduinoの心臓部。250円。
・Digiインターナショナル XBeeチップ：出力の弱いもの（短距離型）と強いもの（長距離型）とがあるため、設置状況に応じて選ぶこと。2,730円～
・スイッチサイエンス XBeeピッチ変換基板とソケットのセット：2mmピッチのXBeeチップを2.54mmピッチに変換するためのゲタ。1セット500円というのはちょっと足元を見られている気がするが･･･
・秋月電子 カーボン抵抗（1/4W 4.7Ω）：抵抗。100本100円。
・秋月電子 スイッチングACアダプター9V1.3A 内径2.1mm NP-12-US0913：Arduinoの電源として。750円はちょっと高いなぁ。
・秋月電子 ピンソケット（1×14pin）：アナログ／デジタルの入出力端子用。50円×2点。
・秋月電子 2.1mm 標準DCジャック 内径2.1mm 外径5.5mm：ACアダプタから電源を受けるためのDCジャック。4個入り250円。
・秋月電子 両面ガラスユニバーサル基板：2.54ミリピッチのユニバーサル基板。60円。

東京電力エリア内電力使用状況

東京電力が今日から電力使用量の公開を始めたので、早速これをPachubeにアップするスクリプトを書いてみた。公開されているのはグラフのGifイメージなので、画像解析っぽいことをやる必要があった。以下はPachubeによるZoom Graphである。


フィードはこちら。

例によって取得したデータからeeml形式のファイルを作成してこれをPachubeに読み込ませる方法をとった。私のアカウントでは、Pachubeは3ヶ月しかログを保存してくれないので、ローカルにもログを残すことにしている。東電は1時間おきのデータしか公開してくれないので解像度は粗いが、前年・前日データも一緒に公開してくれているので、それはそれでありがたい。

フィードにアップされるデータはCSVやJSON、あるいはXML形式で共有されるので、他のサービスやGadgetなどと連携したい場合はこれを使っていただけるとよいのではないか。

東電がこのサービスを今後どれくらいつづけるかは不明だが、これから夏に向けて電力の使用方法についてをみんなで考えていかなければならない我々にとってはまさに必要なデータである。必要と思っていたそのときにこのようなデータが公開されたのは、渡りに船、であろうか。

LEDランタン - vol.1

計画停電によって夕暮れ時に停電になる事があったけれど、今更ながら灯りのない生活はなかなかに厳しいものです。そこで私もまわりのMakerに倣って、LEDランタンを作ってみました。



手元にあったIKEAの調味料瓶（４コセットで200円くらい？）―買ったものの使い勝手が今ひとつのため廃棄処分寸前―がハウジングの大きさとしてちょうど良さそうだったので、これを流用することにした。開け閉めできるフタの部分を灯火スイッチにすれば、電池も無駄にならないし、本来から備わっている「開け閉め」という動作をそのまま引き継いでモードの変更ができる。

構成部品は3Vのボタン電池、電池のケーシング、LED（超高輝度LED25000mcd）、LED拡散キャップ、錫メッキ線、IKEA調味料ボトル、ティッシュ、以上である。

LEDの光は直進性が強いので、拡散キャップを付けるが、それでもまだグレアが厳しいので、くしゃくしゃに丸めたティッシュペーパーを瓶に入れてソフトな光になるよう調節する。

テーブルに置けば手元の灯りに、キャップ部分を下にして置けば部屋全体を照らす拡散光、手に持って歩けば懐中電灯として、一台三役なかなかの優れものとなった。今度のMakeで売ってみようかしら？

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

Archiduino Project - vol.15

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

すでにポータルでは使用しているが、記録したデータをGoogle Chart APIを利用してグラフ化することに取り組んだ。現時点では基本的にPachubeが提供するものとほとんど同じだが、自分のフィードのデータを一覧したいというその一点需要のみでやってみた。

entasan.dyndns.org/mbt/chart.cgi

GCAPIの詳細な仕様はこちらに掲載されているが、いろいろとクセのある感じに仕上がっている。慣れるのにはちょっと時間がかかった。上記のURL先で表示しているのは、いわゆる「折れ線グラフ」であるが、もちろん、2本以上の折れ線グラフをひとつの図上に載せることは可能である。しかしながら、GETメソッドでチャートを呼び出すというGCAPIの仕様上、送信されるクエリの長さ（Length）が2000バイト（すなわち2000字）を超えるとエラーになってしまう。従って、あまりにも多くの情報を詰め込んだグラフは、一度には描けない。24時間のデータをそこそこ詳細に載せるとしたら、せいぜい2系列しか載せられないだろう。

そのような仕様上の制限はあるものの、１ページに掲載可能なグラフ総数などに制限があるわけでもないので、使いようによってはそこそこ便利なのではないかと思った。余談だが、私が修士論文を書いたとき、シミュレーション結果をウェブ上でグラフ表示することに取り組んだが、その際はPerlのGD::Graphモジュールを使ったものである。GD::Graphで描かれるグラフは、それはそれは懐古趣味的な絵柄であった。

Archiduino Project - vol.14

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

12月26日に友人の設計事務所で定期的に行っている勉強会に参加させてもらい、そこで最近取り組んでいるArchiduinoに関する内容について話させてもらった。これはそのとき使ったスライドにちょっとだけ手を加えたものである。

趣旨としてはこうだ。
・ArduinoみたいなラピッドプロトタイピングツールをつかっていろいろなものをTinkeringする人（Make:r）が増えてきている。
・我々も「Archiduino」を通じて建築分野において有用と考えられるICT設備を開発してみた。
・OSHW（オープンソースハードウェア）という流れがエレクトロニクスや工芸、手芸、など各分野に浸透してきている。
・建築もOSHWの流れに位置づけていきたい。あるいは、セルフビルドの系譜に接続していく方法を模索したい。
・1000万人が年収200万円そこらという時代を考えれば、建築家は金持ち相手に特化していくか、住宅取得という方法そのものを変えていくしかないのではないか。

質疑の要旨としては以下である（「→」が回答）。細かなものは省いた。
・情報や通信プロトコルの仕様については？
→APIを公開・共有し、みんなが使えるようにして、情報の出入り口で課金するなどすればいい。委員会あるいはコンソーシアム的にやる方式はもう古いのではないか？
・情報を握ったものが権力者、みたいな風潮の中で、これはそういうものになっていってしまうのか？
→情報を握るだけではダメだ。情報から意味やある種の答えを抽出できるような人やシステムが力を持つことにはなると思う。
・これまでのセルフビルドがうまくいかなかったところにICTを持ち込んでうまくいく勝算はあるか？
→自分の身近な問題としてこういう問題がある以上、勝算があるかどうかは抜きにしてやるべき意義はあると思う。「Make:」という行為の延長がどこまで届くか、可能性は未知数。