Firefox OS WoTハッカソンに参加してきた

2/14-15に行われたFirefox OS WoTハッカソンに参加してきました。

申し込んだ時点で70名の募集のところ既にいっぱいで、補欠でしたが数日でキャンセルが何人か出て、繰り上がりで参加出来ることになりました。
終わった今、改めて見てみたら50位ぐらいまで繰り上がっていたので、こういうのは諦めたら駄目ですね。

アイディア出し

初日は企画コンセプトやWoTの概要説明から始まり、アイディア出し＆チーム決め。
最終的には、以下にまとめられているものを作ったわけですが、
http://fabble.cc/dobogo/pitagoraxsugoroku
いきなり「要件定義」に書いているような立派な案が出たわけではなく、お菓子を食べつつ、光らせたいとか、NFCを使いたいという、使いたいものベースで、だらだらとホワイトボードに書き付けていました。
途中でゲーム的なものや動きのあるものが作りたいという流れになり、すごろくというアイディアと、ピラゴラ装置というアイディアが発生。それらを組み合わせた「いろんな仕掛けのあるすごろく」になっていきました。
当初、そのすごろくはFx0を持った人間が歩き回るという話になっていましたが、どこかのタイミングでロボット(この時点ではふぉくすけの存在は無く、車に乗せたFx0)に移動させるというアイディアが出てきて「すごろく」と「ロボット」の二本立てとなりました。
最終的に、今回はインパクト重視で「ロボット」に注力し、すごろくは余力があったらという方針になりました。
ふぉくすけが採用された経緯が記憶からすっぽり抜けていますが、他のチームの方から、ふぉくすけのヌイグルミをお借りして、ふぉくすけロボという具体的なゴールが昼食前には完成しました。

設計と実装

ロボットの方針が出たあたりで、ざっくりとどういうモジュールが必要かと、それぞれの間のやり取りの図を書き、それを元に役割分担をしました。私はhttpd.jsを使って、Fx0内で動くサーバーの実装を担当しました。
ふぉくすけロボは、足と尻尾はmbedで制御されているのですが、その指示はFx0からHTTPで、mbed側のサーバに飛ばしています。私が作ったのは、リモコン側からのリクエストをそのままmbedに飛ばす、一種のリバースプロキシというわけです。
とりあえずリモコン担当の方、mbed担当の方と、ざっくり必要そうなAPIを相談し実装。
mbedが制御しない、表情制御については、並行で作られている表情プログラムを呼び出す事になるので、一旦呼び出し口だけを用意しておきました。

実装そのものは大したことが無いのですが、テストが大変でした。ひとまずFx0にインストールしてみて動かしてみたのですが、デバッガにソースが出てこない。console.logも出てこない(確か)。
仕方がないので、FirefoxのWebIDEからシミュレータを起動して、そこでテストしようとするも、バージョン2.1以降(unstable)でないとやはりソースが出てこない。
やっとデバッガにソースが出たと喜んだものの、コールバック内のブレイクポイントは機能しないという状況でした。Flame(fxos ver3.0?)をお借りして試してみたところ、シミュレータと同様の状態だったため、console.logでプリントデバッグで進めました。

また、初日はネットワーク環境が不安定で、テスト用の無線LANになかなか繋げられず、mbed側サーバーとの疎通が安定して出来るようになったのは2日目になってからでした。
今回のハッカソンはWoTがテーマになっていますが、実際のWoTの現場でも、安定したネットワークの確保は課題になると思います。

もう一つ大変だったのは、現状のhttpd.jsのパスHandler機能、要するに静的ファイル配信の機能がFx0でしか動作しないことでした。リモコンは静的なHTML+JSで書かれているので、これをロボット側のFx0から配信しようとしたのですが、シミュレータやFlameでは動作せず、しばらくたってFx0で試して、初めて機能する事を確認しました。

そんな新しい端末やOSらしいトラブルに見舞われながらも、何とかかんとか、ふぉくすけロボを完成させることができました。

デモ

完成したふぉくすけロボですが、mbed側は、mbed + 無線LANモジュール + モーター*3という構成のため、非常に電気を使うようです。さらに、それを乾電池だけで動かしているため、下手に動かすとデモが出来ない恐れがありました。
それでも、デモの数分間、ふぉくすけロボは頑張ってくれて、おかげさまでARM賞もいただけました。

Firefox OSに対する感想

Firefox OSは使う分には、特に問題無いレベルにあると思います。少なくともFx0やFlameは、スマートフォンとして普段使うのに必要十分な動作をしていました。
開発環境も、若干使いづらいところはあるものの、今後改善していくだろうし、何よりWeb技術でアプリが作れるという特性は、潜在的な開発者数が、AndroidやiOS以上に存在しているという事を示しています。httpd.jsは普通のアプリにはまず使われないと思われるので、今回ほどの苦労はしないはずです。

また今回はFirefoxOSの端末としてFx0を使うことが、ある種の縛りとしてあったのですが、他のチームの発表を見ると、Fx0ではなくOpen Web Boardを主にしたものもいくつかあり、スマートフォン以外の応用可能性が、Firefoxには十分あるように思います。

ふぉくすけロボの発展

ふぉくすけロボはその動きをリモコンに頼っていたわけですが、リモコンからは単にHTTPでリクエストを飛ばしているだけです。つまりロボのFx0にHTTPに投げられる存在であれば、何であれふぉくすけロボを操作出来るわけです。
今回作れなかったすごろく側ですが、センサーとHTTPクライアントを埋めた壁、床を作ることで、すごろくがふぉくすけを動かす仕組みなんかが作れると、わけがわからなくて良いと思います。

それと懇親会の最後で、ふぉくすけが出た状態のFx0をお面のようにしたのですが、カメラAPIと組み合わせて、任意の顔をお面にするアプリが作れるなあと考えていました。
問題はFx0もFlameも持っていないことなわけですが。
今後機会があれば作りたいです。

wii-tagとりあえずのまとめ

夏ぐらいからCREAMとかGRLとかlaser-tagとかに関わって、考えた事のまとめ。

wii-tagを作り始めた動機はlaser-tagを見て、以下のようなことを考え始めたのがきっかけでした。

• レーザー光線は危険
• 原理上複数人で遊べないのはつまらない
• laser-tagの面白さはどこにあるか気になる

もっとも、最初からwii-tagを作ろうとしたわけではなく、これらの事、特に一番下の事柄を考えることから始めました。

laser-tagの仕組みは大掛かりだけど単純で、レーザーポインタの軌跡をカメラでとらえてポイントされた位置をプロットして、その位置にブラシを描いた画像を、ポインタを当てた壁にプロジェクターで投影する、というものです。
laser-tagについて、レーザーポインタで絵を描くという宣伝文句が使われますが、実際にはレーザ光線で直接描いているわけではなく、カメラ、コンピュータ、プロジェクターがレーザー光線と描かれた絵の間に存在するわけです。
仕組み上、レーザーポインタは派手ではあるけど、座標を指定する役割しか持っていません。またカメラも結局のところ座標指定に必要なセンサーでしかなく、レーザーとカメラはセットとなります。座標の指定をしたいなら、レーザーポインタである必然性は実はなく、x,yの組さえ作り出せれば、他の道具でも構わないわけです。
この事からlaser-tagの核は、コンピュータ、プロジェクター、壁の3つではないかと考えました。
ではレーザーポインタの代わりに使えるものは何かという事で考えたのがWiiリモコンです。割と安直ですが、Wiiリモコンは以下のようなものです。

• レーザーポインタとほぼ同じ操作感
• レーザーポインタほど危険ではなく
• 複数人による操作も可能

ここまでくるとWiiリモコンによるlaser-tagみたいなものがどのようなものか気になるわけです。誰かやっていないかと調べたのですが、誰もやっていないようで、自力でどうにかしないと手に入らない事が分かりました(実際にはGRLオーストラリアの人たちがWiiリモコンを使っていたのですが、その時は調べ切れませんでした)。

実際に作り始めると、Wiiリモコンをパソコンで使う方法がなかなか分からず、またセンサーバーも自作したりと、結構大変な作業でした。
その間にCREAMでの活動の中で、本家laser-tagについても触ったり、設定をいじったり、外でやったりする中で、レーザーポインタは必須では無いにしろ、派手さや遠距離到達性については無視できない特性であることに気付かされ、また危険性については回避しえない事の確認もしました。

今現在、wii-tagはプロトタイプとしては、ほぼ完成状態にあり、一度どこかの壁にプロジェクションして、動作を確かめたいと考えています。
ほぼ完成した今、気になっているのは、この5ヶ月ほどwii-tagを作りつづけた行為は何なのかという事です。
現時点での答えは、wii-tagは鑑賞行為であり、批評行為であるというものです。
ベルナール・スティグレールが紹介しているのですが、19世紀において美術館は作品を鑑賞するだけの場ではなく、模写をする場だったそうです。眼だけではなく、模写という手の運動によって、作品を自分の中に取り込む事が、作品を鑑賞するという行為であり、批評行為だったわけです。
wii-tagはまさにlaser-tagの模写と言えます。5ヶ月がかりでwii-tagを作ると言うことは、5ヶ月がかりでlaser-tagを鑑賞してきた事と同じであり、ここまでやらないとlaser-tagについて最初に考えた事を解決する事は不可能でした。
またこのことは、デジタル・テクノロジーが安価になる事で、デジタル・テクノロジーを利用した作品も模写出来るようになったという事を表しています。
wii-tagについては、鑑賞、批評行為であったと一応結論づけるとして、模写による鑑賞が、デジタル・テクノロジーによる作品についても可能になったという事がどういう事なのかについては、もう少し考える必要があるようです。

wii-tagのソフトウェア部分とか

今度はソフトウェアについて。

結局はペイントソフト

wii-tagのソフトウェア部分は結局の所ペイントソフトです。
元ネタであるLaser Tagのソフトウェアにはセッティング用のツールも含まれてはいるけど、こちらも本質的にはペイントソフトってのは議論を待たないかと。
元々Laser Tagは仮想的にスプレーをレーザーに置き換えたものだし、GRLのGはgraffitiのGなわけで、当然といえば当然ですが。

wii-tagにしても、実際にはマウスでも描く事が出来るように作られているし、他のポインティングデバイス用に拡張しやすいよう、ある程度、気を使って作っていたりもします。
なので、作っているのはwii-tagというより、wii-tagをするためのプラットフォームというのが正しいわけです。丁度いい名前が無いので、もうしばらくはwii-tagと呼ぶ予定。

Laser Tagの面白さ

wii-tagを作ろうと思った頃に、少し考えたのだけど、レーザータグの面白さは、レーザーで描く事ではなくて、都市の壁面に別の文脈を持ち込む点にあるのですよ。
実際には壁面どころか路面にビデオカメラとプロジェクターとパソコンという装置を持ち込んでいるので、言葉による説明によって想像される以上の文脈の衝突があったりするわけです。

今思い出したけど、去年Python with Hardwareのみなさんたちと秋葉原で飲み会をしたとき、居酒屋の壁面にプロジェクションをしたけど、起きている事態としては同じですね。

とはいえ、都市の文脈に別の文脈をぶつけるというのは、スプレーを使ったtaggingやgraffitiやらと変わらないわけで、レーザータグにしろwii-tagにしろ、それら旧来の手法とどうちがうのかってのは、しっかり考えるべき問題かと思います。
現象レベルでは、物理的痕跡が残るかどうかというのが大きな違いではあるけど、そこはあまり重要じゃない予感がします(許可を取る際には大きなポイントですけど)。

wii-tagと自作センサーバー

Laser Tagを自分の中で消化する為に、wii-tagと称してWiiリモコンを使ったLaser Tag的なものを作っています。

動画でないと、さっぱり分からないと思いますが、こんな感じです。

緑色の線は、マウスで描いたもので、紫色の線はWiiリモコンで描いた線です。
ここまで作って考えた事もあるけど、それはとりあえず置いておきます。

さてWiiリモコンを使うには、センサーバーが必要になります。
Wiiの正式センサーバーでも良いのですが、Wii本体の電源が入っているとリモコンをWiiに取られてしまうことがあるので、自作する事にしました。

最初に作ってみたのがこれです。

びっくりするほど、やっつけです。
材料は、赤外線LEDが4個と抵抗2つ。USBで携帯を充電出来るケーブル、導線数センチ。

前にデコチャリの手伝いをしたときに作りました。
ハンダ付けしたところは、その時その場にあった養生テープで一応保護しています。

みかけはひどいですが、ちゃんと動きます。

紫色に光っていますが、これが赤外線です。デジカメを通すと紫色ですが、肉眼では当然見えません。
赤外線が出ているだけでなく、Wiiリモコンも反応してくれました。


一応、これでも使えるのですが、導線が絡まりやすくて非常に使い辛いので、もうちょっとマシな姿に変えることに決定。先週末、材料を集めて工作しました。

その結果がこれです。

かなりセンサーバーらしい形になりました。
材料はほぼ初代から流用しましたが、USB充電ケーブルは捨てて、USBのBコネクタ(メス)をつけてあります。
バーの部分は、千石で「ご自由にお取り下さい」と書いてあったレールです。ICとかが入っているやつですね。

もちろん、ちゃんと光ります。

レールの溝が、typeZの頭にすっぽり入るので、非常に安定しています。

完成と言ってよいとは思いますが、部分的にハンダがむき出しで少し怖い部分があるので、そこの手当ては必要かな。

ソフトウェア側については、また今度書くことにします。

gainer.pyで遊ぶ

Ouch! Ouch! Ouch!さんのgainer.pyをいろいろいじってみた。

が、なかなかうまくいかない。
備え付けLEDを光らせることと、ボタンの入力を取る事は出来たけど、加速度センサーの値がうまく取れない。
なぜかTrue or Falseで返って来る。Gainerの資料を読んでみるけど、よくわからん。

というか、True or Falseって明らかにPython側の話だよなと気付いたので、ソースとにらめっこ。
加速度センサーの値はget_specified_analog_input_continuous_modeで取っていたけど、こいつがset_to_gainerを呼んでいる。
で、set_to_gainerは確かにbool値を返している。多分これが原因だろうなとget_from_gainer_valueに変更。
しかし、変えていいもんなのか？I/Oモジュールが壊れたりしないよな？
と、恐る恐る実行すると、うまいことXYZの値がとれました。
結果はこんな感じです。

130 128 123
129 121 123
129 124 123
131 129 124
133 140 136
134 139 142
133 138 111
153 137 127
129 136 125
132 159 124

#左からXYZ

ついでに今回のコード。

from gainer import Gainer
import time

GAINER_PORT = "ポート番号"
gainer = Gainer()

gainer.open(GAINER_PORT)
gainer.configuration(1)

for i in range(10):
    #but = gainer.get_button_state()
    #print but
    xin = gainer.get_specified_analog_input_continuous_mode(1)
    yin = gainer.get_specified_analog_input_continuous_mode(2)
    zin = gainer.get_specified_analog_input_continuous_mode(3)
    print xin,yin,zin
    time.sleep(0.5)
#gainer.set_onboard_led(1)
#time.sleep(3)
#gainer.set_onboard_led(0)

gainer.close()

gainer.pyは調査の過程で、私好みに勝手に改造してあるので、素のgainer.pyでは動かないかも。
他にも、setとgetが入れ替わっているところがあるけど、バグ報告はどうしたらいいのかな。
Ouch! Ouch! Ouch!にいちいちコメントするのも迷惑な気がするし。