20101227

Archiduino Project - vol.14

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

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

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

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

20101210

花園におけるメリーゴーランド的考察 - vol.2

私は情報空間としての「茶室」と同列にこの「神社空間」――社殿の他、周辺設備や装束、儀礼のようなソフトウェアや鎮守の森などといった地形も含む――を扱いたい。つまり、先に述べたような茶の湯における三原則、「仕度の原則」「しつらえの原則」「仕掛けの原則」は神社空間においてもぴたりと合致すると考えている。

空間の中にさまざまな含意や隠喩をもたせ、そこで行われる行為に対して客を迷わせることなく、静謐の裡に誘導することを目指している。茶庭でいえば、入り口の門扉から茶室までの誘導空間であり、これは亭主の趣味に依るところが大きいが、一見すると手入れのされていないような鬱蒼とした茂みを、身をかがめて足下を見ながらゆっくり歩くことで自然と茶室へと辿り着いたり、あるいは本来誘導されるべきではない方向へはそれとない表示方法――例えば関守石など――によって行く手を塞がれる。茶室やその周辺空間に配された装飾には一輪の花でさえ意味があり、例えば利休が秀吉を茶室に招くにあたって活けた一輪の朝顔と、そのために刈り取った他のすべての朝顔の話、「朝顔の茶会」の逸話が有名であるが、これは茶の湯におけるもてなしの心、つまり「一期一会」のための仕掛けの在り方について物語っている。もてなすべき客のために高度に整備された空間は、客に対して「感動」や「情動」という心理作用をもたらす。もてなされる客はもてなす亭主の気配りに対して敬意を払い、相互にこの言外のやりとりを愉しむ。そこに「主客一体」の空気がうまれ、そこでこの空間の意義が完成される。

今となってはまことしやかに包み隠され、無毒化、無菌化されてしまってはいるが、この茶室におけるロジックと同様の意味を持つ、男女和合のための空間装置としての機能が「神社空間」にもあると主張したい。そう考えるための手がかりとなるいくつかの論拠を以降に挙げてゆく。

「鎮守の森」という言葉があるが、神社という空間に接するとまず目に映るのは、参道から社殿一体の領域を覆うように鬱蒼と茂る木々の木立である。町中にある神社では、多くの場合は年季の入った数本の巨樹だけが残されている場合が多いが、郊外や田舎の平地にポツネンと残された鎮守の森は、遠くからでもそこに社殿が安置されていることが一目でわかる。神社空間は自然の奇景に重ねて設置されている――というよりも奇岩や奇景を神として祭祀している――ことが多いため、そういった理由からでも場所の特定は決して難しくはない。

中沢新一「アースダイバー」にあるように、水利の良いところや傾斜地の上がったところ、沖積層の先端部などにある場合も多い。農村部の神社空間は山の麓にひっそりと階段状の参道が設けられており、名もない小山を背景としながら、道なき道に転がる石を頼りにおそるおそる歩を進めなければ来た道も行く道も見失いかねないようなところにある神社も未だに多い。そのような地形ではわかりにくいが、一方で、海岸沿いの小高く隆起した地形に配された神社などでは非常にわかりやすいのが、「鎮守の森」は女性の「恥丘」さながらの様相を呈していると言うことである。小高いふくらみと、その上に茂る木々。その木々の裡に隠された参道への入り口。つまり、神社空間それ自体はその外郭からして母体の隠喩であると言えよう。

女性のみがもつ子供を産み・育てる器質は、それ自体が子孫繁栄の象徴として信仰的な祭祀対象であるだけでなく、それと同時に、その「ご神体」と「交信」することがそのまま現世的な「子孫繁栄」へと繋がる道に他ならなかった。その現世的な御利益の「根源」としての母体を崇拝し、敬い、その深奥との連結こそがこの「神」と繋がる唯一無二の根拠であった。その「神」は定期的に「乱れ(月経)」るため、時にはなだめたり、時にはご機嫌を伺うなどし、その具合を極めて慎重に見守り、見極めなければ、決して子孫繁栄へとは至ることができない。従って、「神」と「交信」して結果を残すためには、そのタイミングや具合に対して神経を払い、また、敬意を払わなければならないものだった。これは旧時代におけるフェミニズムの在り方であるといっても差し支えあるまい。

とかく旧時代は男尊女卑の世界と考えられがちであるが、決してそんなことはなかったのではないかと思う。もちろん科学的な根拠には乏しかったのだろうが、古代の男どもも女性なくして子供は産めぬと当然わかっていたわけで、如何にして効率的かつ安全に子供を増やし、集団を拡大していくかということを考えれば、男性が女性への態度や関係を工夫しようと考えるのは何ら不自然なことではない。むしろ問題の大きさが故に、現代よりももっと真摯な対応が為されていた可能性も否定できない。卑弥呼の例もそうだが、天照大命も女性の神であるとされ、前期神々の時代から後期神々の時代に至るまでは女性が集団の象徴として尊崇されていた。生産の象徴としての「神」、あるいはその「神との交信者」として、「神」と同じ身体を持つ女性が神格化され、祭祀や呪術、時には政治を司る役割を担っていたのである。現代においても、神の託宣をうける巫女はあくまで女性の役割であり、儀式を司る進行役として男性の神主が置かれているに過ぎない。

生産の象徴としての女性的身体が神格化され、信仰の基盤としておかれたために、その信仰の拠り所としての偶像が求められることとなった。そもそも本来的には物理的な身体性が神格化された「神」であったため、それに対して改めて身体性を与えるという方向には向かなかった。そこで「神」を隠喩するような象徴的な造型へと拠り所が求められたのではないか。生産と繁栄の象徴である母体を神域全体とみなしたうえで、その外郭空間としてこれを保護する「鎮守の森」という地形を設定したのは、この「隠喩」の地形的な応用に他なるまい。従って、母体の物理的な形態を隠喩した「鎮守の森」が「鎮め」「守って」いるのは、生命誕生と子孫繁栄を司る女性的身体性が神格化された「神」であり、また、「神」と同じ身体を持つ女性そのものなのである。

「鎮守の森」の入り口には、「神」へ至る道の入り口の目印として「鳥居」が立っている。鳥居の由来には諸説あるが、これまでの議論を踏まえ、鳥居を女性性の隠喩として捉えれば、これはすなわち参道の入り口であることから「陰唇」の象徴として見ることができよう。二本の柱と二本の梁、そして地面とで構成される四角い外形線は、参道すなわち産道への入り口にふさわしい形状ではないか。あるいは女性の股座であると見ても良いかもしれない。その鳥居の前に立ち、柱の間を抜けるとそこは参道である。その入り口をくぐり、参道を抜け、「神」へと触れようとする意志は、すなわち男女和合と出産、子孫繁栄への意志の表れであるとみなすことができる。

現代においてもまだ根強く残っている考え方のひとつに、身内に死者が出たあとの忌中の期間に鳥居をくぐるなと言うものがある。鳥居をくぐると言うことはすなわち子孫を増やそうという意志の表れであるが、前述した考え方はこれを禁忌するものである。なぜ禁忌する必要があったのかと考えてみよう。身内に死者が出たと言うことは、病気の蔓延や気候の変化などといった死へと向かわせる原因があるか、あるいは、死者が出たことで労働力や組織形態に変化がおこり、今で言えば多大なストレス要因になりやすい環境に身をさらす可能性が出たと言うことを示唆するものである。このような環境が妊娠した母体に対して良くないことはあきらかであり、現代でもこのような環境での妊娠は避けるべきであると考えても何ら不自然ではない。当時の人々はこのことを経験的に知っていたのだろうか、環境が安定するまでの期間を服喪の期間とし、その期間は事を荒立てたりすることせずに平穏に暮らすべきだというある種の「知恵」を、性交渉に向かう意志への抑止力として設定するためにこのような「禁忌」を用意したのではないか。

鳥居を抜けるとそこは「参道」である。「参道」はすなわち「産道」と音を同じくし、隠喩と言うより、もはや明喩である。音の同一性から、神社空間の女性性との相似を勘づく人も少なくない。参道の端々には「神」へ通じる道を照らす灯籠が置かれることが多いが、私はこれはかなり現代に近い時代、言うなれば「神社空間」に含意された意味がかなり廃れ、忘れられた頃の産物ではないかと考えている。後述することになるが、聖域において実施される「祭り」にはおそらく必ずといって良いほど「火」が用いられたはずであり、現代のように人工的な灯火のなかった時代にはその「火」だけで十分暗闇は照らし出されたはずである。少なくとも道しるべ程度にはなったであろう。ただ、その「祭り」の場に至るまでの空間を盛り上げるための演出としてかがり火が用いられ、その利用の利便性のために灯籠が開発されたとも考えられなくもない。ともあれ、神社空間における「灯籠」には未だ意味を見いだせていない。

大同小異、参道を抜けると社殿が姿を現す。神社の社殿は、もっとも基本的な構成としては前室としての拝殿と、後室としての本殿という平面になっている。尤も、社殿と言うよりも祠というようなよりコンパクトなものであれば、素朴な小屋が建っているか、あるいは奇岩や奇景といったものに注連縄がかかっているか、場合によっては小高く盛った土の上にそれらしく鎮座されているだけといったこともある。

ここで注目するのは、きちんと社殿がある場合についてである。拝殿と本殿とは、きれいに中央寄せで前後に並んでおり、拝殿の方がいくつかの儀式を執り行う都合上、本殿よりも一回り大きく作られている。拝殿の中央後方から本殿に繋がる廊下、多くの場合は数段の階段によって本殿と連結されている。この空間は人間が利用することを前提としない、つまり、「神」が行き来するためだけのものであるため、人間的な寸法を持ってはいない。まるで出窓のような大きさの本殿である場合もあるし、より簡素なものでは神棚のように拝殿の内部にせり出してしまっているものもある。これは前述した「祠」のようなものに含まれるとみなして良いだろう。ともあれ、「神」は前室を経由した先の空間に安置されている。この構成は、前述したような女性の膣から子宮にかけての身体的な構成を隠喩したものであり、また、参道から社殿へと至る神域全体の相似形でもある。つまり、神社空間は女性的身体への自己相似的な構成をもっており、高度に数学的な意匠であると言うこともできよう。

現代においては、きちんと整備された社殿を持つ、いわゆる「神社」で祀られている「ご神体」は、ほとんどの場合、くぐもった光を反射する丸い鏡である。一方で、粗末な掘っ立て小屋のような祠――今となってはごくたまにしか見られないが、それでもまだそれなりの数が残っていると思われる――で祀られているのは、不思議な形をした円柱状の石棒や、丸い岩であったりする。それらはひとつだけがぽつねんと安置されている事よりもむしろ複数個がごろりと、半ば無造作に置かれている。大きなものになると祠の中にはなく、祠の外の参道脇にあったり、そもそも屋根さえかかっておらず野晒しにされていたりする場合もある。多くの場合は自然木や自然石であるが、新しいものは人工的に造形されたものであることもある。よくよく見ると注連縄がかけられているものさえある。それらはすべて「男根」もしくは「女陰」を想像させる形をもっている。

(続)

20101203

花園におけるメリーゴーランド的考察 - vol.1

人類が残してきた建築物をたどってゆくと、我々はそこに装飾の歴史を見ることになる。多くの場合それら装飾には意味があり、物語がある。現代のような情報技術が発達していないような時代においてはほとんど唯一といってよいほど、装飾はその社会において生きる人々の情報や知識を継承するための手段となっていた。装飾は建築物の立面においてのみ施されるのではなく、平面であったり開口部をふさぐ窓であったり、あるいは構造体から独立したアイコンとしての物体であったり、安定的に設置されるものとも限らず一時的に設置されすぐ撤去されるものでもあった。多くはその動的な変化にこそ伝達されるべき意味が含まれている。

我々が現在において使っているような数字や文字という抽象的な媒体が存在しなかった時代には、象形文字やヒエログリフのような図像を空間に刻み、あるいはもっと直接的に絵そのものを大きく描くことで物語全体を伝えることも行った。フランスのラスコー洞窟にある壁画には、狩猟の場面や動物を描いた壁画が残されている。ネイティブアメリカンのトーテムポールには、その一族代々の長の歴史が刻み込まれ、文字ではなく口述伝承により語り継がれている。イタリアのルネサンス期宗教絵画においては聖書に記された文字そのものではなく、物語の中のある場面を障壁画によって切り取って見せ、そのインパクトと共に我々に物語を伝える役割を担ってみせた。中国は敦煌の莫高窟においては、仏教の経典に関する内容が極彩色で描かれている。建築空間に意味を包含させた装飾を施すこととなったのは、おそらくは当時、空間が最も長持ちのする媒体(メディア)であったからに他ならないからであり、文字自体もまだあまり定かではなかったような時代においては、場面のイメージである絵としたほうが意味の伝達がしやすかったに違いあるまい。


装飾による情報の伝達といった方法だけではなく、建築自体が持つモニュメンタルな性質によって、ある人物――多くの場合は時の権力者――の権力誇示のための道具としても建築はその役割を担うこととなった。「天下布武」を掲げて安土城を建設した織田信長も、絶対王政を民衆に誇示するためにヴェルサイユ宮殿を建てた太陽王ルイ14世も、あるいは古代エジプトの王たちも、はたまたブルジュ・カリファを建てたアラブの金持ちも、みな考えることは同じというわけである。


建築自体による恣意的な情報操作、例えばファシストらによる建築や、ブルータリズム的な表現による印象操作なども、それによって我々の意志や判断力に対して影響を及ぼし印象を強化しよう意志がそこに介在するという意味において、これもまた先の主張と同じ議論の範疇であると言えよう。つまるところ、建築物を含めたすべての空間構成物が人間に対して刺激を与える装置であると見なす限り、たとえ作り手の恣意性の有無に因らずとも、我々は空間に囚われているのである。

刺激装置としての空間としてよく語られるのは「茶室」であろう。茶の湯の極意は三つあるといわれている。準備を整えて客を待つ「仕度の原則」、くつろげる空間を演出する「しつらえの原則」、ゲームのルールを共有する「仕掛けの原則」である。「仕度の原則」は空間を司る側が提供するプログラムであり、「しつらえの原則」は空間そのものが発揮しうる性能であり、「仕掛けの原則」は空間に参加するもの同士が暗黙的に共有する知識と言い換えても良いだろう。これらの原則は茶室に限らずとも、すべてのよりよき空間の創造において必要なことであると考えられるが、ともあれ、茶室に招く側も招かれる側も、いずれ劣らず高度な知性と教養を要求され、その「ゲーム」を共に達成した暁における相互の充足感、満足感、一体感こそが茶の湯の真骨頂であろう。


翻って、私は「神社」について語りたいと思う。「神社」の原型空間とは、日本列島に土着していた古代の民衆が形成した、「男女和合」に関するコミュニティとシステムを醸成し、促進するための、非常に緻密に計画された空間であると言うこと告発したい。

まず予備知識として頭に入れておかねばならないのは、日本における「神」の系譜は大きく二つに断絶されている。ひとつは天照大神や大国主命らをはじめとする古事記に登場する神々であり、人知を超越した力を発揮する神話の神々である。もうひとつは神武天皇(紀元前6世紀頃)以降の現代に続く天皇の系譜である。現代において天皇はその神格が否定されていることになっているが、それら天皇たちはその存在や年代、役割などがある程度歴史的な資料と共に裏付けられており、神話・伝説的な性格がきわめて薄く、また西洋的な宗教における超人としての「神格」は存在せず、生物学的に見ればごく普通の人間であるに違いない。ともあれ、系譜としてはこのように大別されるし、後者においては大陸から侵略者として渡ってきた朝鮮半島系の血筋であるという指摘もある。

ここで重要なことは、前者の神々はどこへ行ったのかということである。結論から言うと、これらの神々は出雲にまつられている。更にいえば、これらの神々は後の天皇家一族らを頂点とする集団によって放逐されたものと見られている。どういうことかというと、もともと日本列島で形成されていた豪族集団(前期神々)とその集落が、外部(後期神々)からの侵略によって住むところを失い、人を失い、血筋を失った。当時はまだ十分な科学的知識がなかったことから、戦のあとに発生した飢饉や疫病――これらは戦争そのものによって行われた略奪や簒奪、人的な大移動に原因がある――などといった災害の原因をその「怨念」と恐れたため、侵略者の集団は自らの手で殺戮した人々を「神」として祀ったものだといわれている。

自分の手で殺した人々を神として祀る――この不自然さを疑うかもしれない。確かに、優れた業績を残した人を神格化することで、後世に残された人々がその御利益にあやかろうという構図は歴史的にもよく見られる。例えば徳川家康の日光東照宮や、乃木希典の乃木神社、太平洋戦争をはじめとした戦争での戦死者らを祀る靖国神社がよく知られている。一方で「殺した人々を神と祀る」ことについて言えば、藤原猛の論を借りると、法隆寺が大化の改新で中臣鎌足らによって誅殺された蘇我氏一族を弔うために建てられた寺であるという説があり、また俗説的には、板東地方において独自の政権を樹立したことで朝廷に誅殺された平将門の首塚の話もある。話を敷衍すれば、針塚や鋏塚といったように、我々が「破壊」した道具に対してもその考え方は通底しているといえるだろう。

いわゆる町中でよく見かける一般的な「神社」で祀られている神々というのは、後期神々によって放逐された「前期神々」のことである。もう一度整理すると、大陸的な思考や文化をもって侵入してきた実像のはっきりする「後期神々」が簒奪した、日本に土着的に暮らして独自の文化的思考を持っていた実像のはっきりしない「前期神々」が、いわゆる神道における「神々」である。各神社の境内にはその神社の由来が掲げられていることが多いが、そこには国産みの物語に出てくる伊弉諾尊や伊弉冉尊という名前や、八岐大蛇退治で有名な素戔嗚尊や奇稲田姫だとか、およそ現在の日本語の体系とは毛色の違う発音の神々の名前が挙げられている。先に述べたように、民族としての断絶だけでなく、ここには言葉としての断絶、すなわち文化としての断絶があることを改めて認識することができる。民俗学者の柳田国男はこのような人々のことを「非常民」と呼んだ。これは先の「後期神々」によって追いやられた人々に対応し、都市ではなく山野に住んだり流浪の民として生きることで細々と命脈をつないだようである。

もともと人々の往来が激しい大陸とは異なり、日本列島はその孤立した地理、コミュニティ、民族という背景をもっており、そのなかでいかにして効率的で、なおかつ安全に人口を増やさねばならないかということがコミュニティ維持のための重要課題であったということは想像に難くない。近親による交配は遺伝的欠陥を持ちやすいということは経験的に分かっていたことだろう。民俗学者の赤松啓介が指摘するように、「お講」であるとか「おこもり」「夜這い」であるといった民俗的風習は、この課題に対して古代の人々が編み出したひとつの答えに違いないだろう。そして驚くべきことに、つい数十年前、つまりは第二次大戦の戦後あたりまで、このような風習は日本全国に残っていたと言うことである。年長者が年少者の性の手配――場合によっては直接相手――をするということは、実はそこはかとなく現代でも行われているといっても過言ではあるまい。しかしながら近代的な価値観の浸透や児童福祉法や風営法といった法整備によりこれらの風習は廃れてしまったが、もしかすると今もどこかの山奥の村々で密かに行われているのではないかと、つい想像の翼を広げてしまう。

このような風習は、運用をあやまるとムラの秩序を乱す原因になりかねないので、ルールによって厳格に規律が守られていた。実施する時期や年齢、実施に際しての手順など、それらは事細かに決められており、成熟して儀式となった。集団の若者はその手順をきちんと経た通過儀礼を果たすことで、ようやくムラの大人衆として認められた。オトナの役割は大きく三つとであると考えられ、農作業など食い扶持生産の分担、人的資源生産の分担(要するに性交渉と出産育児)、そしてそれらをつなぐシステムとしての民俗的儀式・習慣の維持運営である。重要なのは三点目であり、どのようなムラでも維持運営のための会議を行うために使われるオトナが集まる空間があり、そこは「聖域」として扱われ、若年者のみならず女性さえも厳しく立ち入りを禁じられた。沖縄に「御嶽」と呼ばれる場所があるが、これもその名残であろう。

「儀式」を厳格に実施するためには、それが絶対的なものであるという幻想を集団が共有しなければならない。そのために、「儀式」は何か絶対的な存在――およそ神様的なもの――からの授かり物であるという仮定が置かれた。儀式の聖性を担保するために、それを執行する場は「聖域」であるとされ、その意味的なつながりと管理上の都合により、オトナたちの「聖域」と地理的に関係の強い場所が選ばれた。

これらのシステム全体を統合した空間を設定するために、「絶対的な存在」としては土着の神々(前期神々)が選ばれ、儀式を実施するための場としてそれらの神々を祀る場としての「神社」が選ばれ、儀式を運用するための手続きとして「祭」が定められたのである。

現代において「祭」は太鼓をたたいたりお囃子を奏でたり飲み食いしたりといった具合だが、儀式へと通じる手続きの一つであるという仮定から見ると、そこにある道具や衣装、空間構成といったものがすべてその「儀式」を暗喩した「装飾」であるという解釈に繋がってゆく。つまり、法被などの装束は、およそ薄衣によりできて脱ぎ着がしやすく、身体のラインやペニスの存在が目立ちやすくできている。酒や食い物で腹を満たされたあとは、交合の相手探しのために男女入り乱れて踊り狂う。音曲や火炎により興奮は極度に高められ、意気投合した男女は鎮守の森の夜陰に紛れて交わるのである。


(続)

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

20100915

Archiduino Project - vol.4

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

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

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

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

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

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

20100914

Archiduino Project - vol.3

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

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

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

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

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

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

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

20100903

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で送られたデータを受信し、ファイルに記録するためのプログラムが設置されている。特にこれといった工夫はない。

20100902

サーバの移転について

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

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

\t-works

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

Arduino・Pachube・Sketchupを連携したローコストモニタリングの実践

日本建築学会の全国大会(富山)において、9月10日(金)14時から開催される研究協議会「スマートな情報通信技術で実現する建築性能モニタリングの未来像」で講演します。講演タイトルは「Arduino・Pachube・Sketchupを連携したローコストモニタリングの実践」です。

この1年間で取り組んできたArduino関係の研究や開発事例、実装事例などを通して、安価なモニタリング環境の提案を通じた情報システム基盤の普及と課題についておはなしさせていただこうと思っています。

みなさまのご参加をお待ちしております。詳細は以下の通りです。

研究協議会一覧

追記:
当日使用したスライドをSlideshareにアップロードしました。

プロフィール

★氏名
遠田 敦 (ENTA Atsushi)

★略歴
1980年1月 埼玉県越谷市生まれ
1999年4月 早稲田大学 理工学部 建築学科 入学
2003年3月 早稲田大学 理工学部 建築学科 卒業
2003年4月 早稲田大学 理工学研究科 建築学専攻 修士課程 入学
2005年3月 早稲田大学 理工学研究科 建築学専攻 修士課程 修了
2005年4月 早稲田大学 理工学研究科 建築学専攻 博士後期課程 入学
2007年10月-2009年3月 早稲田大学 理工学術院総合研究所 助手
2008年3月 早稲田大学 理工学研究科 建築学専攻 博士後期課程 単位取得退学
2009年2月 早稲田大学 博士(建築学)取得
2009年4月-2010年3月 早稲田大学 理工学術院 理工学総合研究センター 客員研究員
2009年4月-2010年3月 早稲田大学 人間科学学術院 人間科学総合研究センター 客員研究員
2009年4月-2012年3月 早稲田大学 人間科学学術院 e-school教育コーチ

2010年4月-2015年3月 東京理科大学 理工学部 建築学科 助教
2012年4月-2013年3月 東京電機大学 未来科学部 建築学科 非常勤講師
2015年4月- 日本大学 生産工学部 創生デザイン学科 助教
現在に至る

★専門分野
建築情報システム, 建築人間工学, 人間-環境-ロボット系研究

★社会活動
2006年-2009年 建築計画委員会 建築人間工学小委員会 資料整備WG 委員
2006年-2008年 ユビキタス都市建築委員会 公共建築小委員会 委員
2006年-2009年 情報システム技術委員会 性能モニタリング小委員会 委員
2009年-2010年 建築・都市分野における情報インフラ構築特別研究委員会 委員
2009年-2011年 情報システム技術委員会 建築性能モニタリング小委員会 委員

2010年-2011年 情報システム技術委員会 情報社会デザイン小委員会 行動センサリングWG 委員
2010年- 建築計画委員会 建築人間工学小委員会 委員
2011年-2013年 情報システム技術委員会 スマート建築モニタリング小委員会 委員
2012年-2014年 建築計画委員会 建築人間工学小委員会 幹事/同小委員会 研究情報交流WG 幹事
2013年- 情報システム技術委員会 スマート建築応用モニタリング小委員会 幹事

★受賞歴
2002年11月 早稲田大学 優秀卒業論文賞
2006年3月 日本建築学会 関東支部研究報告会 若手優秀研究報告賞
2006年11月 ゼネラルエンジニアリング株式会社 ロボットアイデアコンテスト 努力賞
2007年3月 日本建築学会 関東支部研究報告会 若手優秀研究報告賞