20101202

Archiduino Project - vol.13

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

時が経つのは早いもので、終わってからもう2週間が経過しようとしているところだが、今回念願の初参加となった「Make: Tokyo Meeting 06」についてレポートしたいと思う。

1. Archiduino-BBについて

まさか本当に売れるとは思ってもいなかったが、ありがたいことに4名もの方にお買い上げいただいた(用意したのは強気の10パック)。本当にありがとうございました。おそらく部品的な不備はないかと思うが、もし不備などあったらTwitterにてご連絡いただきたい。ご連絡いただくよりも各自手配された方が早いとは思うがw

当日現地で配布していた、構成情報などを掲載したA5のペーパーはこちら(そもそも準備枚数が少なかったため1日目には配布終了)。印刷版は少々文字がかすれ気味でしたので、こちらの方が可読性が良いかも知れない。

ご利用の際の注意点としては、ペーパーの注意書きにも書いてあるが、ブートローダの書き込みやスケッチのアップロードを各個で対応していただく必要がある、というこの2点に尽きる。特にブートローダの書き込みには、専用のAVRライターを用意したり、Arduino duemilanoveの基板自体を改造するなどといったことが必要になるが、この点にはご諒解いただいているということ前提での頒布なので、是非ともノークレームでお願いしたい。必要な情報についてはこちら。私も実際この方法でブートローダを書き込んだりしているが、Arduino Unoから構成が変わってしまったため、そろそろライターを買おうかなとさえ思っているところだ。

スケッチのアップロードは、既存のArduinoに載っているATmega328pと換装して書き込んだりしているが、XBee経由でアップロードする方法もあるとかないとか。どこかであるという情報を見たけれど、実際に自分で試せていない。もしかしたら普通に出来ることなのかもしれない。

ちなみにArchiduino-BBは、市販の価格で部品のみ1から集めると850円で準備できる。もちろんXBeeピッチ変換基板やXBeeチップ、ACアダプタは別料金である。売値1000円のうちのあとの150円は、パッケージ代と寄付金ということでありがたく頂戴いたしました。

今回の頒布で思ったのは、コの字型をしたジャンプワイヤが単品でばら売りされていない(あるいは知らないだけかも?)ことがすごく不便だなと思ったこと。ケーブルのものは売っているのだけれど、コの字型のほうは見たことがない(何度も言うが、知らないだけかも)。

(追記)どうやらなくもないけれど1つ10円するというのはちょっとお高いので、1つ1円くらいでなんとかならないものだろうか?

2. 私たち自身の展示物について

当日配布していたパンフレットはこちら。今回、初参加におつきあいいただいた諸氏の協力により、なかなか良いものができたのではないかと思っている。各展示物ごとにページが区切られているので、もし何度かつづけて参加することができた暁には、これらをまとめて一冊の本にしてみたいなとさえ思っている(妄想が過ぎるかな?)。

今回は早稲田大学渡辺研究室の厚意により、パンフレットの印刷代を持ってもらうことができた。印刷屋を使うことは、事前にはある程度考えてはいたが、実際に使うとなると入稿に関するいくつかのルールがあったりしてちょっと手こずった。トンボだとか色指定だとかよくわからんが、こちらとしては送ったPDFをそのまま両面で印刷して欲しいだけなので、プロっぽい仕上がりはとりあえず二の次で、そういう超簡単サービスってのがあってもいいのではないかと思う。

以下に各展示の要点について記す。私が直接関わっていないものについては、当日の掲示パネルから引用した。

2.1 Archiduino

地震動や建物の揺れ、エネルギー消費量や温湿度といった環境データ、居住者の行動や状態・心理などを観測する技術である「建築性能モニタリング技術」が建築分野で注目されて久しい。特に、日本のゼネコンらは独自に、あるいは関連するITベンダーらと連携し、オフィス空間レベルではかなりのものを実装できる段階にある。

しかしながら、モニタリングに必要なハードウェアインフラはおよそ高価であるため、一般の住宅レベルなどより広範に利用されるためにはそのコストを圧縮する必要がある。その方法論としては、複数の目的にまたがって複合的に利用できるようにすることでメリットを多重化したり、必要十分な性能に絞ってそもそも安価にしてしまおうという考え方がある。また、ハードウェアを後付け的に利用できるよう、設置と管理方法に柔軟性を持たせることで、個人でも対応できるような容易さを持たせることも必要だろう。

ここではArduinoをベースとした、簡易にして必要十分なセンサーネットワークインフラの構築を実証的に行うだけでなく、建築分野にとって必要十分な性能を持つ専用Arduinoクローンである「Archiduino」の試作に取り組んだ結果を展示した。

今後はハードウェア的に不十分な箇所(ハードウェアの違いによる取得データの整合性、既存のArduino用シールドとの互換性など)について取り組むことを検討している。また、住空間に設置しても何らおかしくない外装(Outer Case)のデザインにも取り組んでゆく。

2.2 Slipper 2.0

住宅やオフィスなどの居住空間で居住者の位置や行動をセンシングする技術は、携帯電話やPHS、アクティブ型RFIDタグを使ったものを含め、すでにいくつか存在するが、いずれも機能やコストにおいて一長一短である。

ここでは「スリッパ」のかかと部分に設置されたRFIDリーダと、床下に埋設されたRFIDタグとを用いることで、居住者の歩行軌跡を検出するデバイスの開発に取り組んだその成果を展示した。床下敷設型RFIDタグについては、2010年現在ですでに3軒の実験住宅において実装されており、実際の生活をモニタリングしたデータを取得している最中である。

居住者の行動モニタリング技術としてこの方法が妥当なものであるとは決して思っておらず、さまざまな方法を試してみたいと考えている。また、デバイスによる身体拘束性の低減と小型化、低電力化についても重要な課題である。現段階ではWindowsCEとPDAによる構成だが、Arduinoによる構成へと移行してゆきたい。

研究的には、行動パターンの検出(生活習慣の検出)や生活場面の文脈理解(コンテクストアウェア)、他の住空間システムとの連携などを是非とも実現したい。

2.3 OpenCVとProcessingで居住者の可視化

(展示パネルより引用)Arduino は安価にセンシング可能なデータデバイスです。そのデータをPachubeに送信し続け、それらをためていきます。それらのデータをSketchUpという図面を描くソフト上のオブジェクトに反映させ、リアルな世界とバーチャルな世界を結ぶ試みをしております。ここでは、実際の家をセンシングしたデータから室温を取り出して、室温の推移を可視化しております。

定点観測した画像を並べた動画は見ていて面白いものです。しかしながら、通常用いるにはプライバシーという問題とどうやって表示するのかという問題があります。ここでは取得した写真をOpenCVで減色処理し、Processing.jsを用いてホームページ上でもそれらの動きを表現することができました。

2.4 Arduinoで音の可視化+Human Probe & Share

(展示パネルより引用)都市や、テーマパークのような自由に散策できる状況にいる時、多くの場合はパンフレットや地図を見て、自分の行動を決めていると思いますが、知らずのうちに自分の周りの環境から影響を受けているのです。周辺で大きな音・変わった音がした時や、人の話声がガヤガヤと聞こえて来た時など、音のする方が気になって「ちょっと行ってみよう」という様に周辺の環境が人間の行動や心理に影響を与えていることがあります。そこで、本提案ではこの「音」に着目し、それを直感的に分かるように「見える化」し、散策者に情報を提供します。


人にセンサを取り付けデータを取得するという「Human Probe」という概念に基づき、音センサとGPSを散策者に取り付け、その人が「どこにいて、どんな音環境にあるのか」をリアルタイムで取得し「見える化」して提供します。また、一人のデータだけではなく、同様の機材を持つ複数名のデータを同期することにより、自分のいない場所、離れた場所の音環境を知る事ができ、行動のキッカケや興味の喚起を促します。この提案によって散策行動の範囲拡大や滞在時間の増加を促し、都市やテーマパークにおける散策行動をより活性化させることが出来ます。

2.5 ARモデリングツール

(展示パネルより引用)これからは、3Dデータのデジタル入稿やカスタムメイドでのモノづくりが盛んになると思われます。そんな世の中のために、形を決める際に机や椅子の正確な寸法を知らなくても、自分自身の身長や部屋の大きさに対応した「なんとなくの大きさ」でモデリングする事ができるツールを作りました。現実の空間に重ねて、原寸でモデルを作る事を目的としています。2台のカメラによるステレオビジョンで奥行きの座標を取っています。

3. 出展者としての感想

前回まではあくまで自分たちが「お客」として参加していたわけだが、今回は初めて「店側」としての参加であった。いろいろ気合いが入っていた点と、入れそびれた点とがあり、それらについてレポートしてみたい。

まず、私たちは前日の夜にいくつかの展示品を運び込むということを行った。いわゆる「前乗り」である。他の出展者さんたちも多数いるに違いない、ちょっとは内覧会くらいな感じかなと思っていたが、ところが現地に着いてみると、意外と誰もいない。大規模な出展を行う企業ブースくらいだ。というわけでこちらとしては展示物の設置リハをし、駅前のマックで買ってきたハンバーガーを食べながら、無駄に時間を費やしたというわけだ。

もっとも、配布用のペーパーなどはかなり重量があったので、車による前日搬入は正解だったかもしれない。ブース内の整理整頓、作品や備品の管理のために、2~3個はダンボール箱があった方が良いかもしれないと思った。

用意したペーパーは500部。最初ということもあってどれくらい用意すればいいか全く数が予測できなかったので、残ってもイイヤという感覚でやや多めに準備した。実際に配布してみると、2日間まるまる「配りまくる」ことでちょうど配り終わる感じであった。今回の来場者数が8000人程度ということを考えると、500部は6%くらいということで、もし次回があれば来場者予測数の5%程度で良いかもしれない。

開催日当日、始まって1時間と経たずに思ったのは、お客さんほとんどみなさんちゃんと話を聞いてくれるということであり、その説明が想像以上に大変だということである。お客さんは1回聞けば良いところ、我々はお客さんの数だけ話をしなければならない。一緒に参加してくれた学生のみなさんも言っていたが、のどが痛くなるくらいは必至であろう。今回は生協食堂での展示なのでさほど大声でなくても説明できたが、混雑を極める体育館ではもっと酷いことになっていたかもしれない。

もちろん、この点についての反省点はいくつかある。ひとつは、展示物の解説用パネルを初日までに準備できなかったこと。とりあえずこれだけ読めば何やっているかが分かる的なものをどうして準備しなかったか悔やまれたが、2日目はこれを用意できたことで多少は楽になったような気がする。もうひとつは、説明しなければ理解できない展示であったということ。せっかく「Make:」という場なのだから、何か動くような物体としての展示やデモを中心にして、もっと直感的に理解できる展示内容に厳選すれば良かった。あるいは、全体をまとめた5分程度のムービーを流し続けるとか、そういう方法でも良かったかもしれない。まぁでもお客さんと対面でコミュニケーションを取るというのが良さでもあるので、あまり省略しすぎるのも良くはない。せめて自分たちの休憩や他の展示物を見る時間をとるための時間稼ぎであるとか、用途は限定した方が良いかもしれないな。むしろ、説明の最中にいくつか見せたい写真や図表があったので、パネルとは別で、これらを用意しておいた方が良いかもしれない。

せっかくの参加と言うこともあり、プレゼンテーション(30分)もやってみた。これについては事前の告知などほとんどしていなかったこともあって、観客は最初5人くらいしかつかなかった。始めてみれば通りがかりのお客さんがちらほら寄っていくという感じだった。ほかの出展者らのプレゼンテーションでは、事前にペーパーを配布するなどしてかなり告知をしていたところなどは人だかりもできていたようである。もっとも、それだけ人を呼ぶほどのコンテンツを用意することの方が先ではあるな。なお、当日のプレゼンテーション資料はこちらにアップロードしてある。


4. 来場者としての感想

今回はあまり細かく見る時間が取れなかったので、2点だけ。

4.1 mbed

ポストArduinoと噂される「mbed」についてだけ書いておく。「mbed」はArduinoと同様にマイクロコントローラの一種だが、ArduinoがATMEL社のATmega328などを使っているのに対し、mbedはNXPセミコンダクターズ社のLPC1768を使っている。6000円ほどするmbedボード上には、USB、Ethernet、シリアル通信が実装されている。特筆する点としては、IDEはウェブベースのものとして用意されており、ブラウザ上でコーディングを行ったり、ライブラリをインポートした、コードのコンパイルをしたりする。mbed上での実行にはダウンロードしたコンパイル済みファイルを外付けUSBドライブとして認識されているmbedに保存するだけだ。

Arduinoに比べてやや値段は張るが、Ethernetシールドも一緒に買ったと思えば安いのかもしれない。単体としての性能はArduinoに比べて高性能である。ただし、A/D変換能については変わらず8bitである(もしここが10か12、あるいは16bitであったら間違いなくmbedを使っていたかもしれない)。mbedを部品から組み立てることが可能かと言えば、できないこともないのだろうが、今のところやっている人を見たことがいない。部品点数はArduinoと大差なさそうではある(未検証)。

Arduinoがもつハード的な広がり(クローンやシールドの豊富さ)とユーザー層にはまだ至ってはいないが、その性能の高さと魅力的な使い勝手の良さがゆえ、黙っていても今後はユーザーを増やしてゆくだろう。特にArduinoで出遅れた人にとっては、mbedは渡りに船かもしれない。私も一つ買ってみようかと思う。

mbedとArduinoの棲み分けについていえば、Arduinoの魅力はあの「限られた性能のなかで以下にうまくやるか」的なところにもあったわけであり、また、私自身がやっているように、必要な機能だけをチョイスして、コントローラに必要な核となる部分を自分で安く作れてしまうところにもあったわけだ。つまり、とにかくいろいろつまって高機能な心臓部が欲しければmbedをベースとすれば良く、Arduinoは量産や小型化、ストイックなまでの限界プログラミング(?)への挑戦、などという棲み分けが出来るかもしれない。ともかく、mbedをいじってみたいという欲求が私の中にも芽生えたようだ。

4.2 パーソナル・アンド・デジタル・ファブリケーション(略してPDF?)

現時点では3Dプリンタやレーザーカッターなど、業務用に使われていたツールが低価格で販売されるようになり、一般のユーザーでもこれらを使った製作が可能になってきた。これらのツールを使ったデスクトップ・ファブリケーションと、前述したArduinoやmbedなどといったラピッドプロトタイピングツールと組み合わさることで、動いて・楽しく・本当に欲しい・自分だけのモノが、それなりの品質で作れるようになってきた。これらのツールを連携させるのは、もちろんPCをはじめとしたデジタル端末であり、これによって実現されるのは、パーソナル・アンド・デジタル・ファブリケーション(PDF)である。これは着実に地歩を固めているように見える。

さて、我らが建築分野はこの流れとどのように関わろうか?

建築におけるパーソナルファブリケーション、すなわち「セルフビルド」の系譜は、建築史的には1966年の「ドラム缶の家(川合健二)」をひとつのターニングポイントとして考えることができる。早稲田出身の身としてはもちろん石山先生のことを忘れるわけにはゆかないが、それらの歴史を前にすると今の私は無知に等しい。これについては鋭意書物を読みあさるつもりである。それにしても理科大の図書館は蔵書が貧弱すぎるなコレハ。

現時点で語れること、私の甘い希望的観測で言えば、この新しいクラフトマンシップ、つまり「パーソナル・アンド・デジタル・ファブリケーション(PDF)」を建築の世界に対しても接続してゆきたいということだ。多少こじつけになるのかもしれないが、これまでに研究してきたこと、これまでに関わってきたプロジェクトなどすべて、この話に繋げられるような気がする。例えばモニタリングの話で言えば、得た観測データが建築を作る上でのコンテクストになり得るということや、E邸で見たパネル工法とその製造過程、RFIDなどICTを使った生産と流通の管理・効率化、データベース利用による材料・部品の管理と発注、メディアアート的なツールを用いたスタディツール、空間の管理や可視化のためのCADソフト利用、生産力のクラウド化、などなどである。こういった新しいツール、新しい方法論があれば、50年前とは違った方法でセルフビルドを考えることが出来るかもしれない。そう期待したいところである。

しかしながら今直感的に思いつく問題が大きく2点ある。

1つは、建築にさほど興味のない人、普通であればハウスメーカーや地元の工務店に相談に行くような人たちが、どのようにPDF建築に取り組むというモチベーションに接続していくことができるかという問題である。

ひとつのモチベーションとして、PDF建築の方がコストダウンが見込める、ということがあるかもしれない。しかしそれは果たして本当であろうか?あるいは仮にコストダウンができたとして、そのコストダウンに対して「作り手の時間・労力的コスト」が釣り合うだろうか?がんばった割に対して安くならなかった、ということにはならないだろうか?

そもそも近年は庭付きの一戸建てを持つ「一国一城の主」的なビジョンが持てない時代である。そういう時代において、もし本当に安く・楽しく・便利で・快適で・美しい住空間が実現できればこれは成功するかもしれない。そのためにこちらが準備・整備すべきことは非常に多い。一昔前にはやった「LOHAS」だって、雑誌を読んでいるあいだはなんとなくロハスな気分になれたかもしれないが、実際にロハスな生活をしている人がどれだけ増えたというのだろうか?ファッションではなく、本当に建築の「用強美」が手に入る手段として存在しなければ、ただのブームに終わってしまう。また、用強美を得るために建築家並みの特殊技能が必要になるというのであれば、要するに「ハードルが高い」というのであれば、それもまた不可と言うことになるであろう。

つまり、もうひとつの問題点として、一般の人でも可能な「建築設計」という方法論を根本的に考え直す必要があって、それを考える側も受け取る社会も、その変化にどれくらい耐えられるのかと言うことが問題になるのではないかと思う。

PDF建築を可能にするのは、単に既存のCADやモデラー、見積・積算ツールの使い勝手を向上させたり、ハードルを下げたりすればいいという問題ではない。また、お金がないから仕方なくPDF建築を選択するしかないというネガティブな姿勢の受け皿になるようなものであってもならない。

いわゆるマイホーム幻想は、高度成長期に国家の政策としてぶち上げられたものであって、30年とか35年といった長期間をローンの弁済に充てさせることで多くの人々を勤労の「奴隷」にし、そこから抜けさせなくさせた上で、勤労すべきもの以上に生産させられた「価値」を「ウワマエ」としてピンハネされていたわけである。酷い言い方をすれば国家ぐるみの搾取システムであって、搾取される側もその幻想を共有しあうことでむしろ積極的に連帯を保っていたと見ることもできる。政治的な観点から見れば、このようなヒトとカネとモノとを動かす「エコシステム(生態系、転じて収益構造)」は非常に良くできていると言えなくもないが、もう当代においてこの仕組みはうまくは回らなくなっているように思う。

つまるところ、私たちは与えられた「人生」という時間をどこでどのように、何をして暮らすのかという問題に行き当たることになるのであって、日本という国家の中で生きていくために最低限必要なお金をどうやって手に入れ、また、自分が満足できる生き方のために必要なカネをどうやって稼ぎながら、私たち自身のエコシステムを構築することができるのかという問いにぶち当たらざるを得ないのである。前時代のエコシステムは、これから住居を求めようとする若年者層に仕事もカネも回ってこない現代においては、もはや機能不全であることはすでに述べた。だからこそ、これからPDF建築を考えていくというのであるならば、そういったヒトの生き方、カネの回し方といったこともひっくるめて、また、その中でどうやって家を造るのかということについて考えて、考え直していかなければならないと思うのである。建築を社会的に考えるということの根本は、つまるところそういうことに違いないだろう。

20101030

Archiduino Project - vol.12

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

いままでは独自のプリント基板を用意するような方向性で検討を重ねてきたが、ある時ふと「ちょっとした用途」みたいな場面でさっくり組めてさっくり使える自作Arduinoがあるとべんりだな、などと思ったので、これまで自作してきたArchiduinoの構成をブレッドボード上で実現する回路を考えてみた。右掲のものがそれである。

各種センサから受け取ったデータをXBee経由でハブノードに送信するためのセンサノードという位置づけになっている。したがって、これはハブノードありきの構成となっているので、万が一、これを利用しようという人がいた場合はその点ご注意願いたい。データが取れているかどうかを検証するには、ハブノードがあるだけでなく、ハブノードからのデータを受け取るデータサーバもなければならない。つまり、Archiduino Networkの存在が前提である。

向かって右側がArduino本体の構成、左側がXBeeシールドの構成である。例によって必要最小限であり、本体基盤はLEDさえ省いてある。というよりも、構成上の都合で省かざるを得なかった。XBee変換基板の方で実装できるので、そちらでの実装に代えた。

正直なところ、この回路構成がベターなのかどうかについての保証はない。ただ、これで動作しているという事実だけが回路の有効性を示しているに過ぎない。レギュレータが2つも配された構成が良いのかどうかということも、正直なところ私には判断しかねるのだ。従って、もしこれを利用される場合には、その点について容赦していただきたい。

なお、27-30のa-d番地がデジタルピン、17-22のf-j番地がアナログピンに対応している。VCC、GNDについては上下端の+-列から取ればいい。スケッチについては、これは私のやり方だが、別のArduino完成基板上でスケッチをアップロードしたATmega328Pを使っていただきたい。

20101018

Archiduino Project - vol.11

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

今回も自分の備忘録的な内容ですが、私が普段よく利用しているセンサ類の一覧と、参考にさせてもらっているウェブサイトのご紹介です。まずはセンサ機器について。

★温度/温湿度センサ
・Sensirion 1チップ温度・湿度センサ(SHT-11):3,000円とちょっと高いが、実装は比較的簡単。デジタルI/O pinに接続。
・National Semiconductor 高精度IC温度センサ LM60BIZ:マイナス側の温度まで測れる。100円で安く、実装も簡単。
・National Semiconductor 高精度IC温度センサ LM35DZ:上記とほぼ同様。こちらも非常にお安い。

★照度センサ
・浜松ホトニクス フォトICダイオードS9648-100:1,000lx程度、つまり照明下の屋内程度まで計測可能。

★距離センサ
・Sharp 測距モジュール GP2Y0A21YK:80センチまでの短距離型。秋月だと400円だけど、千石で売っている浅草ギ研のものはやけに高かった気がする。
・Sharp 測距モジュール GP2Y0A02YK:150センチまでの中距離型。
・Sharp 測距モジュール GP2Y0A710K:100-550センチまでの長距離型。ちょっと値段が張る。

★電流センサ
・galileo7 Wattmeter Shield:現在販売中止中(?)。クランプ型の電流センサで電力の簡易計測。
・秋月電子 ブリッジダイオードDIP型 DF06M:ブリッジダイオード。7個入り100円。
・U-RD 超小型クランプ式交流電流センサ(φ10/80Arms):電流センサ。1つ1,500円くらいと言うのはちょっとお高いな。
・秋月電子 電解コンデンサ 220uF 25V:20円。

★風向・風速・雨量センサ
・Sparkfun Weather Meters:ちょっと大きいですが、風向・風速・雨量センサとして安価に入手できます。70ドルくらいですが、関税や送料などいろいろかかって1万円弱くらいになります。ストロベリーリナックスで7,350円で販売しています。

★無線通信(XBeeチップ)
・Digi XBee無線モジュール・チップアンテナ型:もっとも標準的なXBeeチップ。2,730円。
・Digi XBee無線モジュール・ワイヤアンテナ型:ワイヤアンテナ付きのXBeeチップ。2,840円。ワイヤアンテナの意味があまりよくわからない。
・Digi XBee Pro無線モジュール・チップアンテナ型:長距離を飛ばすならこちら。4,200円とちょっとお高い。

★圧電スピーカ
・秋月電子 圧電スピーカー(圧電サウンダ)SPT08:エラー報知用のブザーとして。もっと小型のものもありますが。

続いて、Arduinoの自作基盤製作に必要な部品などについて。

★Archiduino自作基板用部品
・秋月電子 低損失三端子レギュレーター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円はちょっと高いなぁ。
・秋月電子 2.1mm 標準DCジャック 内径2.1mm 外径5.5mm:ACアダプタから電源を受けるためのDCジャック。4個入り250円。
・秋月電子 ピンソケット(1×14pin):アナログ/デジタルの入出力端子用。50円×2点。
・秋月電子 ブレッドボード EIC-801:一番小さいというわけではないけれど、これで「Archiduino」のほぼ最小構成が可能。250円。
・秋月電子 両面ガラスユニバーサル基板:2.54ミリピッチのユニバーサル基板。60円。

上記の部品を使いながらひとそろいのArchiduino自作基盤を作成しようとすると、ブレッドボード(250円)+3端子レギュレータ2種類(200円)+発振子(100円)+ATmega328p(250円)+抵抗(100円)+セラミックコンデンサ(100円)+ACアダプタ(750円)+DCジャック(250円)+XBeeチップ(2,730円)+XBee変換基板(500円)≒5,000円といったところか。XBee関係を積むと飛躍的に高くなる。ACアダプタ、XBee関係を抜くとちょうど1,000円。10個単位で作ろうとすると、1個あたり約800円。まだちょっと値が張るな。

お次は部品・センサ類の販売店ウェブサイト。

★国内
秋月電子
千石電商
スイッチサイエンス
galileo7
ストロベリーリナックス

★海外
Adafruit Industries
Seeed Studio Depot
Liquid Ware
SparkFun

最後に、参考にさせてもらっているブログなど。敬称略。

建築農業工作ゼミ
建築発明工作ゼミ
なんでも作っちゃう、かも。

随時加筆していきます。

20101007

Archiduino Project - vol.10

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

この記事は過去の記事の再編集である。

ガリレオ7で売っている「Wattmeter」をようやく実装した。写真には搭載していないが、XBeeチップを直接シールドに実装でき、全体的にコンパクトに収まる仕様になっている。

配電盤の赤と黒のケーブルにU_RD社のクランプ型電流センサーを咬ませて計測を行う。扇風機とエアコン、冷蔵庫を稼働している状態で約10A程度の電流が流れていることがArduinoIDEに流れるシリアル出力の値からわかる。100Vの交流電源であるから、この状態でおよそ1000Wの電力を消費している事が推測できる。

この設置にあわせ、室温の変化を捉えながらある一定の温度に達した場合にエアコンのスイッチを入れるアクチュエータノード(Archiduino Project - vol.8参照)も一緒に稼働させた。ある暖かな日の室温と電力の推移を右記のグラフに示す。

ぎざぎざに推移するのがおそらく冷蔵庫であろう。グラフの右端で突発的に跳ね上がっているのはおそらくドライヤーによるものだ。また、後半の数値を底上げしているのは室内の照明や音響機器によるものではないかと考えられる。

さて、ここでは室温が33度を超えたとき(実際にはArduino自体の発熱を拾ってしまっているのでもう少し低い値であると考えられる)にエアコンのスイッチを入れ、30度を下回ったときにスイッチを切るという設定にしている。そのあたりのこともvol.8で書いた。

いうまでもないが、スイッチが入ると同時に電力も増加し、スイッチが切れると同時に電力が減少する様子が伺える。グラフに掲載している期間(約17時間)の消費電力は約3(kWh)であった。

今回は居室に人がいないときにもエアコンをつけるという操作を行ったわけであるが、これはあまりスマートな方法ではないだろう。今度は居室に人がいるかどうかを判別した上で操作を行うように変更してみたい。また一方で、現在の実装は16度に設定した冷たい空気で空調するようにしているが、25度くらいの設定温度でやんわり空調するような方法にした方が、居室にいる人の心理的な影響を考えれば、そちらのほうがよりよいのではないかと考えている。

さらに可能ならば、屋外から帰宅したときは一気に冷やし、在室状態が続いていたときは緩やかに冷ますとか、一般の空調にはちょっと真似のできない「コンテクスト・アウェア」なアクチュエーションまで実装できたら、文句はないな。

20101006

Archiduino Project - vol.9

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

今回はちょっとした思い出話とメモ書きです。

Arduinoに触れたときからいわゆる「Archiduino」の検討はすでに始まっていたといっても過言ではない。確かに、Arduinoボード自体は非常に良くできていたし、個人がArduinoをベースにしていろんなものをつくったり切ったり貼ったりというのは非常に簡単にできるすぐれた代物であった。私もその簡単さの魅力に取り憑かれたわけだし、その汎用性にはいまも夢中だ。

しかしながら、これを産業レベルで活用していこうということになると話はちょっと違ってくる。

端的に言えば、Arduinoの基本ボードには不要な機能や部品が多いと思う。例えば、USBでスケッチを読み書きするといったことは、ひとたびモニタリングシステムが運用段階に乗ってしまえばもうほとんど使わないで済むわけだし、もし書き換えが必要ということになればチップごと交換してしまえばいい。「Archiduino」実現の暁には、そもそもそのコントロール用の基盤が非常に安価になるはずだから、それごと交換してしまってもいいだろう。あるいは、デジタルやアナログの入出力ピンの数も、アナログが6つにデジタルが14個という構成だが、これもその半分程度に絞ってしまって構わないと思う。

さて、ここまで読んだ読者諸兄は思われただろうが、なぜここまでして「Archiduino」なるものをつくる必要があるのか。Arduino MiniやNano、Pro、あるいはArduino Fioといった、既存の小型基盤を使えば済む話ではないかと思われたことだろう。確かに「Archiduino」は車輪の再発明に違いないし、優れた先達たちの開拓してくれた道を行くようなものである。しかしながら前述したように、例えば住宅内でのセンシングといったような限定的な用途で実装しようとした場合、既存の小型基盤ではちょっとずつ要求仕様に満たないのである。

例えば、センシングのように24時間365日延々と動かす必要があるときは、リチウムイオン電池ではとても持たないわけであるから、AC電源を取ってくるしかないわけだし、宅内でZigBeeを使ったマルチホップを実現しようと思えば、XBeeチップを載せられなければならないわけだし、それでいて可能な限り小さくしたいわけである。できれば住宅設備として小綺麗なハウジングを用意してどこか壁にでもくっつけたいし、場合によっては壁の後ろに入れてしまってもいい。

とにかくそれらもろもろの要求仕様を整理すると、やはり独自に基盤を用意するしかないと考えるに至ったわけである。とまぁそんなわけで、いまはまだ自力でできるレベルで機能の選別と省スケール化を検討している段階だけれど、最終的には4センチ角の両面基盤に収めたいなと願っているわけである。

そんなことを考えている最中にATmega328pにブートローダを書き込む作業をする必要があったのだが、久しぶりすぎて手順を思い出せなかったのでメモっておく。つまるところ、以下のページ参照のこと。

http://www.geocities.jp/arduino_diecimila/bootloader/index.html

そういえば話は変わるけれども、Arduinoをベースにして商業用のシステムを作っちゃったりしたら、やっぱりGPLとかそういうのに抵触しちゃうのかな?法律の話はよくわかんないんだけれどね。

20100924

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

20100920

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℃」なのか、そう言った事もわかることで、それを見た人間の理解は深みが増し、判断の幅が広がる。結果として、さまざまな行動を起こす契機となる。

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

20100917

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

20100916

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