Archiduino Project - vol.8

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

今まではデータを取ることばかりに主眼を置いていたが、もう少し「制御（コントロール）」の方面に取り組んでいこうと考えた。これは先日の日本建築学会の研究協議会「スマートな情報通信技術で実現する建築性能モニタリングの未来像」で、クリーングリーンリサーチ社の福井エドワード氏が「これからは可視化から制御へ」と述べていたことに、今更ながら、気づかされたからである。

というわけで早速ではあるが、Pachubeにアップされたデータに基づいたエアコン制御という課題に取り組んでみることにした。エアコンであればリモコンの赤外線発信をArduinoで実装すれば、容易にONとOFFを制御することができると考えたからである。場合によっては、赤外線発信を組み合わせることで複数の家電、たとえばエアコンと扇風機を同時に制御することもできるだろう。

最初に取り組んだのは、リモコンの赤外線の発光周期を取得するところである。秋月で売っている赤外線受信モジュールを購入し、単純にArduinoに接続する。ごくシンプルなスケッチを使い、赤外線の発光周期を取得する。

実はここがなかなかうまくいかず、一瞬挫折しそうになった。ネットで検索するといろいろと複雑なスケッチも見つかるのだけれど、実際に私の環境で有効だったのはきわめてシンプルなものだった。

つぎはこの信号を発する側の回路とスケッチの作成である。回路の方は何も考えることなく、デジタルピンの然るべき箇所に赤外線LEDを挿しただけのものである。今回はPachubeにアップしてあるデータを取得して、そのデータに基づく制御を実装することが目的であるから、ArduinoにEthernet shieldを載せてインターネットに接続できるようにし、Pachubeからデータを取ってくる部分のスケッチを実装することとした。

単純にローカルだけでセンサネットを完結しようとするなら、センサノードのXBeeから送られてくるデータを常に見張っていれば済むのであるが、ネット上のサーバを参照する方がシステムとしては汎用性があると思われた。

Pachubeへのデータ送信は、これまでにHTTPのGETメソッドを使ったものを過去に実装したことがあったが、いわれてみれば受信については今まで取り組んでいなかった。ネットで検索しても参考になるスケッチはなかなか見当たらなかったので（どこかでみた気もするが）、ここは素直にHTTP経由でhttp://www.pachube.com/api/feeds/XXXX.csvを取得する方法を試してみた。この方が今後発展性があるような気がする。参考にしたサイトとしてはこちら。

参考サイトのスケッチでは、一回アクセスしてデータを拾ってくると終了してしまうプログラムだったので、これを定期的にデータを取ってくるように書き換えるなどした。また、例によってDHCPなどの機能を追加してプラグアンドプレイを実現できるようにもした。基本的には、他人様のコードを参照しながら、過去に作ったスケッチのコードを組み込んで、練り上げるようなプロセスである。そこに私自身のオリジナリティは存在しないかもしれない。

以上のプロセスを経て、今回は33℃を超えたときにエアコン（冷房）のスイッチを入れ、30℃を下回ったときにスイッチを切るという、実に単調な制御を実装することができた。もう夏も終わりに近づいてきたので、室温が33度を超えるような場面がこなくなりそうではあるが、完成した日の翌日がなんとか暑い日であったので、このエアコンの自動制御システムが無事稼働する運びとなった。冒頭のグラフは室温の推移である。

確かに33度を超えたところでエアコンのスイッチが入り、30まで下がったところでスイッチが切れ、再度上昇に転じていることがわかる。特に日中の暑い時間はそれを短期間に何度も繰り返している。パッと見た感じでわかるように、非常に効率の悪い運転をしている。せっかくなので、温度の変化に対応して、自動的に設定温度を変更する方式に変更することにした。これについては、消費電力のモニタリングも同時並行で進めつつあるので、続報したいと思う。

Archiduino Project - vol.7

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

今度の話もアプリケーションの話である。これも前回同様に可視化の文脈であるが、今度はPachubeに貯めたデータを3DCGモデラーであるGoogle Sketchup（GSU）上で表現するといったもの。Sketchupはフリーで手に入るCGモデラーとしてはきわめて優秀で、建築業界ではBIM（Building Information Modeling）と連携する際にも利用されることがある。

建築設備や環境の分野では、建築以後の場面でなんらかの数値を可視化したいという場面があると思われるが、設計図書の情報を手っ取り早く活用して3DCGで可視化するのに、GSUは適任であろう。GSUはRubyによって拡張する事が可能であり、その拡張性からも今後さまざまなアプリケーションのインフラになるのではないかと予想できる。

さて、今回は前述したとおり、Pachubeにアップされたデータを随時取得し、GSU上の3DCGモデルに対して付加情報を載せていくという事に取り組んだもののレポートである。結果として、想定していたとおりのシステムはことほどかように実装されたのである。いくつか問題点があるとすれば、それはGSUに由来するものであり、モデルの部品点数が多くなると表示に時間がかかるとか、半透明の表現がちょっとめんどくさいとか、そういったことがあるようだ。

なお、本システムの実装は@kousukekikuchiが担当した。

Archiduino Project - vol.6

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

今回はハードの話ではなくてアプリケーションの話。

Arduinoを使って住空間内のさまざまな環境データをセンシングしているが、単にセンシングするだけではなくて、最近はやりのARToolkitをつかってARによる可視化表現にトライしてみた。センシングしたデータはPachubeに保存されているが、マーカーを読むタイミングでPachubeからデータをダウンロードし、OpenGLによる3DCGグラフとして推移を表現する。類似のプロジェクトは、Pachubeによる公式のものも含め、すでに海外でいくつか報告されているが、実際の利用に際する問題点の検討などをする上で、自分で実装する事はやはり大事な事であろう。

さて、ARにまつわる問題として、そもそも「マーカーを読んでAR表示する」といったことを汎用的に利用できるハード・ソフト基盤が整っていないので、そういうものが出てこない以上、コンテンツの提供側はハード・ソフトも一緒に提供していかなければならない。そのことがAR普及における巨大なハードルになっていることは明らかだ。その辺を突破するのが「セカイカメラ」かと思っていたけれど、いまや寂しいくらいその火は消えてしまったようだ。

この件についてはひとまず保留することとして、ARで表現すると確かにさまざまな付帯情報を載せる事が出来る。データの推移を見せたり、色を変えて見せたり、拡大縮小したり、動かしたり。単に「30℃」と表示されるだけでなく、それが「上昇し続けた上での30℃」なのか「下がって30℃」なのか、そう言った事もわかることで、それを見た人間の理解は深みが増し、判断の幅が広がる。結果として、さまざまな行動を起こす契機となる。

情報技術によって支援されるべきこと、今回の文脈でいえば「拡張されるべき現実」とは、このような「人間に本来的に備わっている知能をより幅広く活用できるようにすること」であるに違いない。

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まで。

Archiduino Project - vol.5

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

順番が前後するが、写真の基盤はArchiduino Projectのために試作した汎用Archiduino基盤である。Arduinoの回路図とにらめっこしながら、シロウトなりに必要最小限にして最大限の構成で回路を組んだつもりである。

開発コンセプトとしては以下の通りである。まず、すべて秋葉原で手に入る部品で構成できる事。基盤は名刺サイズのユニバーサル基板（100円）を使うこと。センシングに必要な機能だけに絞ること。

これらを勘案し、まずUSBでスケッチを描き込むための回路については、これを思い切って削除した。これは実際の利用場面では、おそらく、一度描き込んだスケッチを変更するといった事はあり得ないと判断したからである。ではどうやってATMega328Pにスケッチを描き込むのかと言えば、ブートローダを書き込む際に一緒に書き込んでしまうという方法をとった。この方がおそらく大量にセンサノードを準備する時に作業効率が良いのではないかと思ったからだ。そのため、ATMega328Pは基盤に直接半田付けせず、28pinソケットを介して回路に接続される。

アナログとデジタルの入出力ピンについてだが、これも数を減らしている。本来はおのおの6pin、14pinほど実装されているが、それらを全部使うような事は、我々の利用の範囲ではまずあり得ない。従って、経験的に最小限の数の実装とする事とした。アナログについては6pin、デジタルが4pinである。センシングの範囲であればまずこれで足りる。別な理由としては、基盤背面の回路設計が私にはこの規模で限界であった。

Arduinoとしての部分は材料費で500円もあれば出来てしまう。しかしながら、センシングしたデータを無線、特にXBeeによるメッシュでマルチホップな無線センサネットワークでサーバに飛ばしたかったので、XBeeシールドに相当する回路も実装した。XBeeと基盤との接続は、市販のピッチ変換基盤を使っている。これらを組み合わせて、XBeeチップを除くとおよそ1000円で実装できてしまう。XBeeチップはまだちょっと高くて3-4000円ほどしてしまう。

センシングは常時安定的に行いたいので、ACアダプタからの電源供給とした。この辺は今後重要な課題になると思ってはいるが、充電池では長時間計測には耐えられないことから、現状では致し方ない。今後は建築設備の一部分としてセンサノードを位置づけ、どこにどのように設置するのが現実的か考えなければならないだろう。

Archiduino Project - vol.4

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

これは最もオーソドックスな利用方法のひとつである、環境計測のためのセンサノードの設置例である。温湿度センサ（Sensirion社SHT7x）と照度センサ（浜松ホトニクスS9648）とを用いている。ちなみにこれを載せているのは独自に再設計したArchiduino汎用基盤である。

照度センサの計測レンジは最大でも1000lx程度で、1つ100円という価格を考えるとこれはごく一般的な室内の水平面照度を測ろうとするぶんには十分な範囲である。温湿度センサはワンチップで非常に容易にデータを取得する事が出来るのだが、ひとつ3000円という価格がちょっとハードルになっているように思う。

センサノードが卓上にごろりと置かれていたり、家中をケーブルが這いずり回っているという状況は普通ではないので、写真のように、”計測が可能な場所での計測値”を利用するしかないという前提でセンシングをしなければならない。要するに、センシングに理想な場所でのデータはまず得られないと言う前提で考えていかないと、その先にある実際の利用場面で困るに違いない。

写真のような設置だと、どうしてもACアダプタの発熱の影響が無視できなかったりとか、あるいはArduino自体の発熱さえも無視できないわけだが、私自身はそんなに厳密なデータにこだわってもどうしようもないのではないかと思っている。人間の五感の解像度はそこまで敏感に出来ているわけではないので。

写真にあるセンサノードは、いわゆるPlug and Playでセンシングできる事を前提にしているので、壁面のコンセントにガチャっと差し込むだけでデータをばんばん飛ばし始める。絵的にはまだちょっと無骨だけど、これくらいのお手軽さでやれないとね。

Archiduino Project - vol.3

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

環境計測ばかりではなく、人間の行動計測にArduinoを活用できないかという事にも取り組んでいる。これはその一例。「窓の開閉」という単純なON／OFFを取得する。

赤外線の距離センサは、秋月では3種類販売されている。写真のものは最もレンジが短いもの（SHARP製GP2Y0A21YK：0.1-0.8ｍ）であるが、この窓は全開にするとこのレンジを越えてしまうので、現在実装しているのは中距離レンジのもの（同社製GP2Y0A02YK：0.2-1.5ｍ）である。ちなみに長距離レンジのもの（同社製GP2Y0A710K：1.0-5.5ｍ）もある。

得られたアナログ入力値を距離に変換する必要があるが、これは実測値に基づいて、distance = 688780 * analogRead ^ -1.32の式に代入する事で得ている。ちなみにR二乗値、つまり重決定係数（寄与率）は0.9を越えて近似されている。

これにより得ている開閉のデータは、Pachubeにアップロードされている。
Pachube: 5385

温熱環境と居住者の心理（温熱環境に対する評価や行動目的など）とを説明変数に取り、窓の開閉のON／OFFを目的変数に取るロジスティック回帰分析を実施すれば、どういうタイミングで環境調整の欲求が行動に表れるかが予測できるのではないかと考えている。

また、居住者の心理については、実際の利用場面でその都度アンケートを採るわけにはいかないので、行動や振る舞いの様子から予測できないかと考え、これについても研究を実施している。

Archiduino Project - vol.2

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

さっそく番外編となってしまうが、植栽の水やり状況を監視する「Garduino」の実装例である。Garduinoについては、書籍「Make:」の8、9号に掲載されている。また、Garuinoにも詳しい。

実装例と言っても、完成基盤を利用したのではなく、自作基盤であるが、要は釘と動線を半田付けしたものを土中に埋設し、その土中の電気抵抗を観測する事で灌水量を計測しようというものである。

問題はと言えば、＋極の電極として使用した釘がすぐにイオン化されてぼろぼろに溶け崩れてしまうという点であろうか。

Archiduino Project - vol.1

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

センサノードからデータを受信する「ハブノード」の外観を添付する。データの送信エラーを警告するための圧電ブザーを搭載し、同時に、送信成功を緑色LED、送信失敗を赤色LEDの点灯で知らせる。

ノードは4階建てで、下から順に、Arduino、Ethernet Shield、XBee Shield、自作基盤、である。1階のArduino基盤と3階のXBee基盤との間には、自作のケーブルによってICSP間が連結されている。各階の階高が非常に狭いので、直角ピンヘッダなどをうまく工夫して作成している。

4階のエラー警告用の自作基盤は、圧電ブザーとLEDいずれもがArduinoのdigitalOutを一定の間隔でON／OFFするだけで鳴動したり点灯したりするので、プログラム自体も大して複雑ではない。各端子の＋極をdigital I/O端子につなぎ、－極をGNDにつなぐだけである。

Arduinoで走らせるSketchにはちょっと工夫を施した。Arduinoに最初から添付されているEthernet用のプログラムは、サーバのIPアドレスが固定である事が前提となったものであるが、必ずしも静的アドレスであるとは限らない。つまり、いわゆるURLからIPアドレスを逆引きする「名前解決」を実装する必要がある。

また、ハブノードのネットワークに対する柔軟性を担保するため、ローカルアドレスを固定するのではなく、ネットワークないのDHCPサーバから動的にアドレスを受け取るような仕様にした。つまり、ハブノードにEthernetケーブルをつなぎ、AC電源をつなぐだけで機能するようにした。

センサノードは随時ハブノードに対してデータを送信するが、ハブノードはこれを受け取り、適当な書式に形を整えて、データ記録用サーバにデータを送信する。送信の方式はHTTPのGETメソッドを用いている。この形式を採用したのは、単に実装が簡単だったからという事のほかには理由がない。

データ記録用サーバにはこのGETで送られたデータを受信し、ファイルに記録するためのプログラムが設置されている。特にこれといった工夫はない。

サーバの移転について

すでに予告していたとおりですが、「\t-works」をホスティングするサーバの移転を実施しました。どこに行っても大学の環境に依存するというのはやはり賢い選択ではないと思うし、サーバでいろいろプログラムを走らせたりもするので、ホスティングサービスをいろいろ見ましたけれど、結局自宅で運用する事にしました。Mac miniでBootcampしたWindowsでApacheなどを動かしています。最大の旨味は、Perlerである自分にとって、CPANからインストールした各種モジュールを自由に扱えるという点です。

ページの構成については、現在まだ作業中ではありますが、基本的には各種SNS（ウェブログ、Twitter、Tumblr、Facebookなど）やサービス（Youtube、Ustreamなど）に対してアップした記事について、RSSなどを駆使し、それらのダイジェスト版としての「ポータル」という形で作成していく事を考えています。つまり、私自身の活動の「再編集」ページという位置づけです。これは「創造の時代」から「編集の時代」へという時代の流れを意識しています。

\t-works

これからもよろしくお願いします。