List of Projects:
1Click飲みRomoCartTempescope色色[:iroiro]Other Projects

2015年1月4日日曜日

Hardware Protoyping Speed Test: Phidgets vs Arduino

I recently had a chance to play around with Phidgets, which is yet another hardware prototyping kit.
I've always considered Arduino as sufficient, so why would I ever want to take on a new prototyping kit?


The standard Phidgets I/O board
The website claims a "quick" and "easy to use" set of sensors and controllers to "get projects finished on time".
If Phigets can provide a faster development iteration loop, which I believe is the single most important thing in hardware development, that may be enough of a reason to switch over.

In this article, I will implement 3 standard hardware prototypes, and compare their implementation speeds using Phidgets and Arduino.


What is Phidgets?

The biggest different between Phidgets and other prototyping kits is that the Phidgets controller itself isn't programmable.
Instead, you connect Phidgets (proprietary) sensors to the I/O board (pictured above), which connects to a PC.  You can use high-level programming languages (Java/C++/etc) to directly control the sensors/actuators.

Some characteristics of Phidgets include:
Simplicity+Speed →No need to mess around with resistors and current calculations, just plug-in the components and you're ready to go.
Connectivity →You're working on your PC from the start, so I've found that connecting your newly made hardware to other programs/network is very simple.
(Really) expensive →You have to use the components provided by Phidgets to take advantage of the two points stated above.  The components are modularized (to enable the plug-in capability), making them very expensive.


Speed Tests!

I compared Arduino and Phidgets by implementing 3 very simple prototypes:
#1 Blink →Just blinking an LED
#2 Servos →Using a potentiometer to control a servo
#3 Pedometer →Using an accelerometer to count steps, and display it on an LED array

Here's a video showing the implementation, side-by-side:



#1 Blink

The LEDs are made to blink with 500ms period.

■Implementation details

Arduino source
Phidgets source

■Time to implement

Arduino: 1m 44s
Phidgets: 1m 11s

Not a complete landslide, but implementation with Phidgets was 30 seconds faster.
Arduino had the handicap of needing resistors on the LED, which Phidgets doesn't need.
However, the output pin on Phidgets needed a screw driver to fix, which was more work than I'd expect from a rapid prototyping kit...

■Cost

Arduino: $24(Arduino Uno
Phidgets: $80(Phidgets Interface Kit 8/8/8)

Even the standard Phidgets board is very expensive.



#2 Servos

Here, we let users change the position of the servo by rotating the potentiometer.

■Implementation details

Arduino source
Phidgets source
On both of the implementations, we are receiving the potentiometer readings as analog input, converting it to angles, and sending it to the servo.

■Time to implement

Arduino: 6m 07s
Phidgets: 3m 20s

Phidgets took about half the time of Arduino.
Most of this is because Arduino couldn't power the servo, so I needed to add an external power supply.

In terms of software, the Phidgets Java SDK lets you write in an event-driven fashion which I personally like.

■Cost

Arduino: $37(Arduino Uno, Servo S03T, Potentiometer)
Phidgets: $139(Phidgets Interface Kit 8/8/8, Servo Controller, Servo, Rotary Encoder)

Adding sensors and switches really ups the cost of Phidgets prototyping.



#3 Pedometer

Here, we use an accelerometer to detect walking, and count the footsteps which we display on an LED array.

■Implementation details

Arduino source
Phidgets source
I implemented a very simple high-pass filter.  I calculate the power: sqrt(x^2+y^2+z^2), determine its moving average, subtract it from the power, and detect zero-crossings of the high-passed power.

■Time to implement

Arduino: 13m 45s
Phidgets: 10m 15s

Implementing the walking detection was considerably faster on Phidgets, but adding the LED array took very long, resulting in a very dull result.
(Without the LED array, it only took 4 minutes to implement a pedometer on Phidgets.)
While I only needed to plug the accelerometer into the USB port in Phidgets, I had to Google the pin layouts of the accelerometer module for Arduino.

On the software side, the strength of being able to program using a high-level programming language on Phidgets really showed.
I was able to use various (self-made) utility libraries to speed up the implementation:
a moving average calculator class which makes calculating moving averages a one-liner,
a graph drawing toolkit that let me visualize and debug the accelerometer output
The time spent programming was a clear win for Phidgets: (Phidgets: 3 mins Arduino: 6 mins)

■Cost

Arduino: $31(Arduino Uno, Accelerometer
Phidgets: $150(Phidgets Interface Kit 8/8/8PhidgetSpatial 3/3/3 Sensor)

Just to press home the point, Phidgets is expensive.



Results

Just looking at the implementation speed, Phidgets was faster on all 3 tests.
There were some (good and bad) characteristics of Phidgets that were made apparent in the tests:


■Good things about Phidgets


1. Very fast hardware construction
As long as we stay in the realm of what Phidgets provide as modular components, prototyping hardware in Phidgets is very fast.

2. Lets you use various software resources

In the third test, I was struck by how enabling it is to be able to use the various Java utility libraries that I'd accumulated over time, in a hardware prototyping setting.
Phidgets makes hardware prototyping as easy as writing quick and dirty scripts on your PC.

3. No knowledge of electronics needed

As far as I've played around with (which isn't much), Phidgets seems to let you prototype hardware with very limited knowledge of electronics.  This may be very beneficial for programmers who have no experience in hardware.


■Bad things about Phidgets


1. Difficult to build stand-alone gadgets
Phidgets needs to be controlled by a PC, which means that its difficult to build portable/wearable devices.

2. Not simple enough

Why do I need a screw driver on a prototyping board?
I don't think the designers really thought what it means to do rapid prototyping.
The fact that I need to use a breadboard for a simple task as making an LED array (in task #3) is disappointing.
People should be able to prototype with their bare hands. (no screw drivers, no breadboards, no jumpers)

3. Doesn't scale

The good thing about Arduino is that the more you improve your prototype, the closer you get to a product.
With Phidgets, at some point you will need to redesign your hardware, and convert everything you made into "proper" electronics (which won't be a problem if you're happy with only having one copy of your hardware.)

4. Expensive

In the tests above, the prototypes using Phidgets was 3~5 times as expensive as Arduino.
This means that people can't really buy a new Phidgets board for each project, so you need to take everything apart before you start a new project.
The use cases for which this is OK is fairly limited (discussed below).


Summary

There are several situations where I thought using Phidgets would be perfect.

Have a set in your meeting room/brainstorming room

Why not have a Phidgets set lying around in your meeting room?
The speed at which Phidgets lets you create prototypes means that you can probably make prototypes in the middle of a brainstorming session.
This would be a fantastic alternative to drawing pictures or building mocks with LEGOs,
and the downsides of Phidgets portrayed above aren't so critical if the prototypes only need to last for 20 minutes.
(I would like point (2) above to be fixed before I buy a set for my meeting room though...)

When every second counts
There are times when you need to build a working prototype as fast as is conceivably possible, like in a hackathon, or if you need to show your boss that the idea he's about to present to the board in an hour just doesn't work. (it's happenned.)
It may be good to have these things lying around as part of your arsenal.

If you're a programmer who's intent on not learning electronics

I think it's great as a communication tool for programmers who have no skill (or intent on learning) electronics to show their ideas to hardware developers in the team, who may happily implement it on a more robust platform.


I would say that for someone who just wants to start learning electronics now (including children), I'd suggest something else (e.g Arduino).  However, the various characteristics of Phidgets do make them fabulous for certain situations.

If you want to play around with Phidgets, try buying the two kits below:
Phidgets Interface Kit 8/8/8 →standard I/O board for connecting the sensors to your PC
Phidgets Starter Kit #1 →kit containing various Phidgets compliant sensors.

ハード開発スピードテスト:ArduinoとPhidgetsを比較してみた三本勝負

こんにちは。河本です。
ハードウェアのプロトタイピングというとArduinoが有名ですが、最近Phidgetsという開発環境を入手しました。
Phidgetsの標準I/Oボード
「プロト開発なんてArduinoで充分じゃん!」と思っていたのですが、公式ページでは「とにかく早く簡単に」開発が行えることに自信を持っている様子です。
試行錯誤を高速に行うためにも、開発スピードは最重要。もしArduinoより早く開発できるのなら確かに魅力的です。

そこで今回は、ArduinoとPhidgetsの両方で電子工作の定番課題3種を実装して、実装の早さ、簡単さ、その他特性を比較してみました。



そもそもPhidgetsってなに?

電子回路の知識がほぼ0でセンサ/アクチュエーターを使った開発ができるプラットフォームです。
↑みたいなI/Oボードにセンサ他を刺すと、PCからJava/C++等の高級言語で制御できます。
特徴としては:
簡単 →抵抗だの電圧/電流だの気にせずとも、モジュールを刺せば動きます。
早い →最初からPC上で高級言語で制御するので、ハードとPC/ネットを連携させるシステムがすぐ書けます。
高い →各パーツがモジュール化されているため、スイッチ一つとっても目が飛びでるブルジョア設定です。


比べてみた

以下の3つの定番課題をArduinoとPhidgetsの両方で実装してみました:
#1 Blink →ただのLチカ
#2 Servos →ロータリーエンコーダーでサーボの角度を制御できる回路
#3 Pedometer →加速度センサを使って簡単な歩数計を作る

やってみた:




#1 Blink

LEDを500ms周期でチカチカさせます。

■実装の説明

Arduinoのソース
Phidgetsのソース
説明は特に要らないですよね。

■実装時間

Arduino: 1分44秒
Phidgets: 1分11秒

圧勝というわけではありませんが、Phidgetsのほうが早く実装できました。

ArduinoではLEDのために抵抗が必要なぶん少し時間がかかりました。
ただPhidgetsは出力ピンがネジ止めが必要なため、予想以上に手間取りました。

ソフト面では特に大きな違いはないと思います。


■値段

Arduino: $24(Arduino Uno
Phidgets: $80(Phidgets Interface Kit 8/8/8)

Phidgets高ぇ。。。



#2 Servos

ユーザがロータリーエンコーダーを回すと、入力に応じてサーボの角度を変えます。

■実装の説明

Arduinoのソース
Phidgetsのソース
ロータリーエンコーダーの値をアナログ入力で受け取り、この値を角度に変換してサーボに送るだけです。

■実装時間

Arduino: 6分07秒
Phidgets: 3分20秒

Phidgetsは半分ぐらいの時間で実装できました。

Phidgetsでのハード製作は3箇所ケーブルを刺すだけ。
それに対してArduinoは一度サーボを動かそうとして失敗し(電流不足のため)、別電源を持ってきたりしてます。

ソフト面では、Phidgetsはイベントドリブンで書けるため、個人的には好みです。


■値段

Arduino: $37(Arduino Uno, Servo S03T, ロータリーエンコーダー)
Phidgets: $139(Phidgets Interface Kit 8/8/8, Servo Controller, Servo, Rotary Encoder)

スイッチやセンサが入ってくると、Phidgetsの値段が跳ね上がります。



#3 Pedometer

加速度センサで歩行を検知し、歩数に応じてLED配列を点灯させます。

■実装の説明

Arduinoのソース
Phidgetsのソース
歩行の検知のためには、非常に簡単なハイパスフィルタを作ります。加速度のパワー値(sqrt(x^2+y^2+z^2))の移動平均を計算し、パワー値から移動平均を引いたものをハイパス加速度として使い、これのゼロクロスを検知して歩数を数えます。

■実装時間

Arduino: 13分45秒
Phidgets: 10分15秒

歩数の検知まではPhidgetsが圧倒的に早かったのですが、LEDの配列を用意するところで手間取り、あまり差がない結果となりました。

LED配置を除くと、Phidgetsでは4分程度で歩数計が作れてしまいました。
Phidgetsでは加速度センサはUSBポートに刺すだけなのに対し、Arduinoはネットでピン配列を調べたり配線したりする作業に時間が取られたのが印象的です。

ソフト面では、歩行検知でPhidgetsの強みがフルに出ました

移動平均の計算のために(自作の)移動平均計算用クラスを使いまわしたり、
加速度データをグラフ描画ライブラリで画面上に表示することでテスト+デバッグが迅速に行えたため、プログラム開発が素早く行えました。
プログラミングの時間だけを見るとPhidgetsは圧勝です。(Phidgets:3分半 Arduino:6分半)

■値段

Arduino: $31(Arduino Uno, 3軸加速度センサ
Phidgets: $150(Phidgets Interface Kit 8/8/8PhidgetSpatial 3/3/3 Sensor)

やはりPhidgetsのコストは桁が違いますね。



結果

実装スピードだけで見ると、Phidgetsは3つのテスト全てで勝ちました。
とはいいつつ、色々な得手不得手が見えてきました。

■Phidgetsの長所


1. ハード製作が早い
最初に書いたように、Phidgetsではモジュールをプチプチ繋げるだけなので、その範囲で工作できるうちは非常に気軽に早く製作が行えます。

2. PCのリソースがフルに使える
#3のテストでは、僕が自作した便利クラス(移動平均、グラフ描画等)を使うことで、ハードの開発・テスト・デバッグがただのソフト開発と同じ簡便さで行えました。
また制御プログラムをPCの他のプログラムや、ネットワークと連携させることも非常に容易くなります。

3. 電子工作の知識が要らない
軽く遊んだ限りでは、電子工作を何も知らないソフトウェア開発者がハードのプロト開発を行うことが簡単にできそうです。これまで画面の世界に留まっていたプログラマーがリアルワールドをプログラミングできるようになるのは非常に価値の高いことだと思います。

■Phidgetsの弱点


1. スタンドアローンのガジェットが作れない
あくまでPCに接続して動かすものなので、持ち回りのよさが必要なガジェット(ウェアラブルとか)は少し厳しいです。

2. 「簡単さ」の詰めが甘い
個人的に致命的だと思いました。
Digital Outピン(↑の作例でLEDを刺してたところ)に配線するために何故ドライバーが必要なのでしょうか。本当に早いプロト開発を行うには、工具要らずで手でパチパチ接続できるようにしたいものです。

3. スケールしない
Arduinoの良さは、プロトの完成度を高める過程で製品に近づくという点だと思います。
Phidgetsはあくまでプロト開発しか出来ないため、いくらプロトを改良したところで製品には近づきません。
いつかちゃんと電子回路化しないといけないのだとすると、二度手間に感じる場合もあるかもしれません。

4. 高い
やはりArduinoと比べて試作が3~5倍ほど高くなります。
Phidgetsボードを何枚も持つわけにはいかないので、作っては壊しを繰り返すことになります。
この物作りが成り立つのは、結構ユースケースが限られそうです。


まとめ

以上を踏まえてPhidgetsを使ったらいい場面を考えてみたいと思います。

会議室とかに置いておく
 会議室にPhidgetsを1セットを置いておき、絵コンテを書いたりレゴでモックを作る感覚で、ワイワイ喋りながらガジェットを作る、といったユースケースには最適だと感じました。
 アイディアをすぐに遊べる状態にすることで、アイディア出しの活性化効果は抜群だと思います。
 「挿すだけで動く」というメリットが活かせて、「高い」というデメリットが気にならないユースケースです。
 (ただしその場合は、工具が必要な部分を直してもらいたいですが・・・)

開発スピードが命の場面
 ハッカソンで「とりあえず動くものをすぐに作らないといけない」、上司が無茶言うんで「それじゃうまく行かないよ」ってすぐに見せたい場合など、一分一秒の実装スピードが効く場面では非常に強いと思います。

俺は電子工作なんて絶対覚えないぜ、っていうプログラマー
 プログラマーがアイディアを形にして、チームのハードウェア開発者に伝えるための手段として使えると思います。

全部少し特殊な状況です。
「これから電子工作を始めたい」という人は、素直にArduinoを選んだほうが良いです。

色々難ありですが、場面によっては非常に力を発揮するプラットフォームだと思いました。
遊んでみたい、という人は以下の2つを買っておけばとりあえず大丈夫です:
Phidgets Interface Kit 8/8/8 →I/Oボード。ここにセンサを繋げる。
Phidgets Starter Kit #1 →Phidgets対応センサのセット。RFIDリーダー/ライタとか付いてて面白い。

こういったものを使って、少しでも沢山のプログラマーがハードの世界に飛び出てくれることを願います。

2014年12月27日土曜日

河本の実験室の2014年まとめ

今年も、無くても死なない物を沢山作りました。
2014年も残り僅かとなったので、まとめてみたいと思います。去年のまとめ


言葉をカラーパレットに変換する色色[:iroiro]

ソチオリンピック」の検索結果

言葉から連想される色を生成するサービスです。(リンク
ネットの検索結果に基づき、どんなに抽象的な言葉でも「それっぽい」色を提案してくれます。

2月の公開後、約50万語が検索されました。

ちなみに一番検索された言葉は「青峰大輝」です。
日本のデザイナーだけでなく、中国のアニメ好きに使われたり、服のコーディネートをする人が現れたり、予想外に流行りました。
Mashup Awards 10でも8作品にAPIとして利用して頂けたのも嬉しい出来事です。

少し残念なのは、欧米ではあまりウケなかったことです。
色に対する感覚が合わなかったんでしょうかね。


部屋をマリオカートの世界に変えてしまうRomoCart


iPhoneで操作できるロボット「Romo」とプロジェクションマッピングを組み合わせて、部屋をマリオカートの世界に変えてしまうゲームを作りました。(リンク
「生活空間をゲームにしてしまおう!」という夢いっぱいのコンセプトに共感してもらえたのか、ニコニコ技術部で一位になり、engadgetCNET等の海外メディアでも取り上げられました。

単に静的な環境に絵を投影するのではなく、「物」を拡張してパワーアップさせる手段としてプロジェクションマッピングを使うという考え方は、レーシングゲームに留まる話ではなく、色々な発展の方向性があると思います。

来年も多分色々作ります。


住民の行動に合わせて部屋の照明環境を最適化するロボット照明「Myra



住民の場所や行動(読書中、歩行中、テレビ鑑賞中など)を認識し、複数のロボットアーム照明を協調動作させて最適な照明環境を作り上げるシステムです。(リンク

ぶっちゃけ照明って見たい場所だけ照らされてりゃいいよね」という考えから作ってみました。
日本語版の動画は作らなかったのですが、海外では意外とウケてHackadayなどのメディアに掲載されました。


サイゼリヤの間違い探しを自動で解くプログラム




サイゼリヤに行って間違いさがしがどうしても解けなかったんで、画像認識で解くプログラムを作った、というお話。(リンク
異様にRTされました。みんなサイゼリヤ好きなんですね。


iPhoneをサーマルカメラとして使えるFLIR ONEの熱画像をプロジェクションマッピングしてみたら意外と面白かった、という動画です。(リンク

熱湯と氷水が混ざり合う様子が見れたり、教育やらなんやらで使えそうな雰囲気ですが、あまりこれといった目的で作ってません。

Hackadayイタリアのメディアで紹介されました。

僕が「なんのために」作ったかというストーリーをちゃんと伝えなかったためか、記事で勝手な意味を持たせられてコメント欄が混乱するという目に遭いました。動画をアップするなら、ちゃんと「なにが課題で」「なんのために」作ったのか分かりやすく伝えなきゃ駄目だという良い例です。


部屋に天気を再現させるtempescope


今年でtempescopeプロジェクト(http://tempescope.com)も3年目になりました。
これまでは細々一人で作ってきたtempescopeですが、去年のMA9でハードウェア賞受賞をきっかけに、チームができ写真家に写真も撮ってもらい
CEATECやMFT2014で展示したり、engadgetGizmodoMAKE:本誌に掲載され、ようやく2015年のクラウドファンディング開始に向けて動き出しました。

個人的にはホリエモンが「欲しい」と言ってくれたあたりがピークです。2回も。




たったの1Clickで飲み屋が予約できる「1Click飲み


去年のMashup Awards 9で優勝した1Click飲みは事業譲渡して、別の運営主体様にお任せすることになりました。(リンク

まだプロモーションをかけていないので使っている人は少ないのですが、実はちゃんと使えます→ App Storeリンク


実験:建物のWifiをホッピングして東京から大阪まで通信できるか


日本の全ての家がWifiを備えていたら、Wifi同士を繋いだネットワークで東京からどこまで通信できるか実験してみました。(リンク
今年はこれ以外にも
住んでいる場所の時間帯とTopcoderのスコアの関係を調べたり、
Wikipediaの人に関する情報から色んな分析をしたり、
気象庁のデータをクローリングして、世界で一番過ごしやすい場所を探索したり、
色んなデータで遊びました。
初歩的なクローリングや認識技術を組み合わせるだけでも、軽い学会発表ぐらいならできそうなネタが検証できてしまえる、面白い時代になりましたね。


その他、私事。

・7年勤めた日立の中央研究所を辞めて、Googleのソフトウェアエンジニアになりました。
退職エントリとか書いてないんですが、日立中研に興味ある人は聞いてくださいな。

・子供が生まれました。

これが:


こうなりました:



来年の抱負とか。

今年は「作って、アップして、メディアに紹介されて満足して、終わり」の物が多すぎた気がします。
来年はもう少し、最後まで行く物を増やしていきたいと思います。
例えばtempescopeは来年の今頃は販売している予定です。
その他のプロジェクトもオープンソース化したり、売ったり、コミュニティを作ってちゃんと形に残すことを目指していきたいです。
そんなわけで2015年も河本の実験室を宜しくお願いします。

2014年12月22日月曜日

iPhoneをサーモカメラにできるFLIR ONEを遊び倒してみた


こんにちは。河本です。
ちょっとクリスマスには早いですが、長らく欲しかったFLIR ONEが手に入ったので遊び倒してみました。


FLIR ONEで見れば排気ガスが熱いのが見える!

FLIR ONEってなに?

こいつです:

*日本だと並行輸入品でしか買えないので高いです。国内で販売が始まるのを待ったほうがいいです。

iPhoneに装着するだけで、↑みたいな熱画像が撮影できるようになるiPhoneカバーです。
今のところ0℃から100℃の間で120x160ピクセルの画像が撮れるっぽいです。


なにができるの?

FLIR ONEをもって色々撮ってみました。
街を見ると、人がくっきり見える
車はエンジンとタイヤが熱い!


スーパーにて。レンコンだけ冷たい。陳列したばかり?

鍋が熱い!
Arduino UNO
駐車場を見下ろすと、さっきまで走ってた車がわかる
冷え性の僕(左)と妻(右)
赤ちゃん超かわいい。


FLIR ONE×プロジェクタで「熱さ」が見える机を作ってみた

こんなハックもできます。
FLIR ONEの出力をプロジェクタで投影することで、物の熱さが見える机を作って見ました。
見た目が同じでも違う温度の水が入ったグラスが違う色になったり、
熱湯と氷水をトレーに入れると、少しずつ混ざり合う様子が可視化されて面白いです。
食べ物を冷まして子供に食べさせるのにも使えそうですね。
これを実装したアプリやプロジェクションマッピングのサーバのソースを欲しい人がいたら連絡ください。


不満たらたら

以下、改善して欲しい点:
カメラを認識するまでの時間が遅すぎる。公式アプリでも自作アプリでも、カメラへの接続を開始してからちゃんと認識するまでボタンを押しまくったりして平均20~30秒ぐらいかかります。即応性がないと、「いざ」という時に接続ができなくて困りそうです。
iPhoneを充電してくれるわけではない。iPhoneカバーとしては特大サイズですが、追加バッテリーと思えばそこまで酷くはありません。しかしFLIR ONE自身は自分用のバッテリを積んでいるにもかかわらず、iPhoneは充電されません。何故そうした。
着けたままだとiPhoneを充電できないし、デバッグが面倒。FLIR ONEを着けていると、iPhoneの充電口がふさがれてしまいます。その結果、FLIR ONEを着けたままではiPhoneの充電もできないですし、PCに接続してデバッグすることもできません。↑のプロジェクションマッピングを作るためには、わざわざログをネットワークに吐き出すモジュールを作りました。面倒。

色々直して欲しい点はありますが、街や世界を今までと全く違った視点で見れるのは本当に楽しい体験です。
まだ国内で買うと高いですが、是非みなさんも機会を見つけて遊んでみてください。

2014年12月1日月曜日

世界で一番住みやすい場所を計算してみた

こんにちは。河本です。

東京は寒すぎず、カラっとした過ごしやすい日が続いてます。

こんな日が続くと日本は世界で一番快適な国なんじゃないか、なんて思ってしまいますね。

ところで本当に世界で一番過ごしやすい地点ってどこなんでしょう?

気象庁が出している数値予報データから計算してみました。
全球の気温 (2013.11.30 06:00+UTC)
(Background image taken from TerraMetrics for educational purposes)

方法

まず元データとして、気象庁が計算している6時間毎の全球域数値予報モデルを取得しました。
これは、6時間毎に地球を0.5度毎に区切った領域全ての気温、湿度、風速、気圧などを計算したデータです。
(ちなみにSynthetic Skyはこれの1時間毎のデータを使ってます)

これを使えば世界中の好きな場所の温度(上図)や湿度(下図)がわかるわけです。

全球の湿度 (2013.11.30ぐらい)
(Background image taken from TerraMetrics for educational purposes)

また、「過ごしやすさ」を定量化するために「不快指数」を使います。

不快指数とは、知っての通り温度と湿度から「不快さ」を定量化する指標です。
ただし、65~70を快適さの中心として、これより高い場合は「暑くて不快」、低い場合は「寒くて不快」という評価を行う指標なため、少し扱いにくいのが欠点です。

そこで、もっとわかりやすい「快適指数」という指標を定義しました。

単純にふるまいが「高いほど快適」「低いほど不快」となるように「不快指数」を変換しているだけです:
快適指数=   (不快指数が67.5以上の場合) 1-(不快指数-67.5)/(85-67.5)
      (不快指数が67.5未満の場合) 1-(67.5-不快指数)/(67.5-55)
(0~1内に収まるよう適宜切り捨て/切り上げ)
パラメータの選択の意図:
67.5=快適指数の快適域の中心
85=「暑くてたまらない」の閾値
55=「寒い」の閾値

この定義から、地球上の全ての場所の「過ごしやすさ」を定義できるようになりました。

以下の図は一昨日(11月29日)の快適指数を計算したものです。
北半球の多くは寒すぎるため青(不快)になってますね。
日本付近は、陸は青(不快)ですが、海にいけば赤(快適)が広がっています。
逆に、南半球は季節は春で、快適さが広がっています。
地球上の「快適指数」(2014/11/29 09:00JST)
以上のデータを過去1年分(2013年11月29日から2014年11月29日まで)を取得し、以下を計算してみました:
1. 平均「快適指数」が一番高い場所はどこ?
2. 「快適日」(不快指数が65~70の間の日)が年間を通して一番多いのはどこ?

結果

1. 平均「快適指数」が一番高い場所はどこ?
各地点における6時間毎の快適指数を単純に平均化し、最大地点を計算しました。
最大地点はここです:
2013/11/29~2014/11/29の間の快適指数平均値。白いマークは最大地点。どこだこれ。
え、うそ日本じゃないの?
最大値の場所(白いマーク)はウガンダ、年間を通して平均快適指数実に87.4の超優良エリアです。
世界で一番過ごしやすいのはヴィクトリア湖のほとり。

ちなみに東京は平均33.6。
以下の年間の快適指数推移を見ると、この差は明らかです。
東京は冬は快適指数がサチってます(寒すぎるんですね)。
ウガンダは年間を通じて高い快適さを叩き出しています。
春と秋以外は東京の快適指数は低い


年間を通じて高い快適指数のウガンダ




2. 「快適日」(不快指数が65~70の間の日)が年間を通して一番多いのはどこ?
各地点において、快適な日(不快指数65~70の間)であった日数の割合を計算しました。
最大地点はここです:

2013/11/29~2014/11/29の間の快適日数割合。白いマークは最大地点。またここか。
やっぱりウガンダです。
ウガンダの快適日数割合は77%。
東京はたったの14.3%なので、だいぶ勝ってます。
どうやら地球で一番快適な場所はウガンダで間違いないようです。

少し調べてみるとウガンダは「アフリカの真珠」「緑の国ウガンダ」だそうです。(ソース
日本が世界一快適だなんて、世間知らずの思い上がりでした。反省します。

まとめ

・老後はウガンダに住みましょう。アフリカって灼熱のサバンナに象が歩いてるイメージしか無かったんですが、全然違うんですね。「どこだこれ」とか言ってすみませんでした。

・今回は温度と湿度から算出した「快適指数」という観点のみで「一番過ごしやすい」地点を算出してみました。他にも「道を歩いてて殺される率」「ハブに噛まれる率」など色んな「過ごしやすさ」の観点を含めて再度過ごしやすさを評価してみたいですね。

・データがあれば、日常のふとした疑問に簡単に答えられるようになります。データを入手する方法や解析テクニックを小学校とかで教えたら、日本はもっと面白い国になるんじゃないですかね?


2014年11月16日日曜日

サイゼリヤの間違い探しが難しすぎたので大人の力で解決した

こんにちは。河本です。
僕はサイゼリヤに行くとまずキッズメニューの間違い探しを解くんですが、
今回は難しすぎたので、大人の力(=画像処理)で解決することにしました。
2014年9月版。みんなもやってみよう!
(以下、間違い探しの答えが出てきます。見たくない人は↑の画像で頑張ってから読もう。)


やり方

いろいろ書いてますが、左面と右面の違う部分を色の差分から見つけてるだけです。
紙の歪みを吸収するために、少しややこしいことをしてます。

(1) 間違い探しページの写真を撮る
↑の写真です。普通にiPhoneで撮りました。

(2) ページ領域を抽出する
画像からページの部分を見つける必要があります。

今回は面倒なので、左側は手作業で指定しました。
角を手作業でタグ付けして・・・
こっちは手作業。
射影変換で台形補正します。OpenCVならWarpPerspectiveです。
台形補正しても、紙が曲がってたので少し歪んでる。
次に、左側の画像をテンプレとして使って、右側の画像から紙部分をSURF+マッチングでオブジェクト認識して見つけます。(参考:whoopsidaisies's diary: OpenCVで画像の特徴抽出・マッチングを行う
右面は自動で見つける
そんなわけで、両面の画像ができました。
両方歪んでますが、そもそも紙が曲がってるので射影変換ではこれが限界です。
左面と右面


(3) 局所差分を算出
ざっくり両面の画像が取れましたが、歪みのため単純比較はできません。
例えば、左と右のピクセルの色距離を単純に比較(AbsDiff)するだけでは、こんなことになってしまいます:
左面と右面の同じ位置のピクセルの色の距離。これでは間違い部分は見つけられない。
そこでどうするかというと、
左面の小さい領域を取り出し、
100x100の小さい領域。
再度オブジェクト認識で右面から同じ領域を見つけ、


見つけた領域の左面と右面を比較、差分抽出(absDiff→threshold→erode→dilate)します。
文字の輪郭はどうしても差分ノイズが乗りますが、erodeで大体消えます。

この局所領域を少しずつずらして、ページ全体の差分画像を作り上げます:
(左)差分画像 (右)元のページ
ちゃんと答えのところに大きい差分が出てる。

(4) 間違い部分の抽出
最後に差分画像から輪郭抽出(findContours)して、「間違い」を探します。
見つけた領域を元の画像に描画したのが以下です:

誤認識は3つあります。
また、一個だけ見つけられていないのがありますね。(どこでしょう?)
実際には二値化のステップの閾値を下げれば見つけられますが、そのぶん誤認識も増えます。
今回の問題では、精度を下げてでも再現率を上げた方がいいですね。

というわけで、一番最初にページ領域を手作業でタグ付けする部分以外は、全自動で間違い探しを解くことができました。


さいごに

・最初にテンプレを手作業で作らないといけないのは、いろいろ自動化する方法があります。例えば「同じような画像が2つ並んでる一番大きい領域を探す」みたいなことをしたり、机を見つけて除外するとかすればいいんですが、ちょっと汎用性が落ちそうなので今回は止めました。

サイゼリヤのサイトに過去の間違い探しの画像データが上がってます。元画像なので、精度よく間違い認識できます。答えも載ってるけどな!
歪みが無いので簡単に間違いを認識できる。
・iPhoneアプリにしたり、メニューに直接答えを投影したりとか色々見せ方が考えられますね。暇な時作ります。

・OpenCVが使えれば世の中の大抵の問題は解決できる。

2014年11月3日月曜日

建物のWifiをホッピングして東京から大阪まで通信できるか

日本ほど建物密度が高い国なら、Wifiだけでどこまでも行けるはず・・!
(Satellite Image taken from TerraMetrics for educational purposes)

こんにちは。河本です。
最近ネットの自由を脅かす様々なニュースが話題になってますね。
NSA職員が傍受したヌード写真で遊んでたり
英国がネット検閲に力入れ始めたり
ハンガリー政府が「インターネット税」の導入を決めたり
現行のインターネットは、施政者の息がかかった電気通信事業者のインフラ無しでは繋ぐことすら出来ません。
これはしょうがないことなのでしょうか?

ところでネットワークの種類にWANETというものがあります。

簡単に言うと、短距離の無線ノード同士を接続することで、バケツリレー的にデータを遠くまで運ぶ技術です。
中央の統制者が居ないため、検閲しにくく、インターネット従量課税なんてアホなこともできません。

そこで今回は、もし住宅に置かれたWifi基地局同士を繋いで純度100%の「草の根インターネット」を作ったら、東京からどれぐらい遠くまで通信できるのか、を検証してみたいと思います。

各戸に短距離無線しか無くても、複数の家を中継すれば遠いところまで通信できる


前提条件

・国内の全ての建物に1台の無線基地局が置かれている
・基地局は通信圏内にある他の基地局と相互接続されている
・通信距離は色々実験する(Wifi:~100m ブーストしたWifi:3200m)

今回は「そもそも接続可能なのか」という観点だけを考えるので、伝送速度やロバスト性などは考えないとする。

建物データの取得
この検証のためには、国内の全ての建物の位置を取得する必要がありますが、そんなデータはどこにも公開されていません。

そこで今回は、Google Mapsから画像認識してクローリングしてきました。
怒られそうなので詳細は省きますが、このように建物の中心点と大きさを認識します:
建物認識の結果
(Satellite Image taken from TerraMetrics for educational purposes)
こんな感じで全国4000万戸の建物を抽出しました。

下の図は国内の全建物の密度を示してます。東京と大阪が濃いですね。
国内の建物分布
(Satellite Image taken from TerraMetrics for educational purposes)

Wifiを使う場合の通信範囲
各家に通常のWifi基地局(通信半径100m)しか無い場合に、東京駅からホッピングで通信できる理論的な範囲(=100m以内にある建物同士を繋いで行った時に、東京駅からカバーできる領域)を計算してみました。


ノード間通信距離100mのWANETで東京駅からWifiのホッピングで通信可能な範囲
意外と狭いですね。
通信領域内の建物は246万戸、全体の5%程度の建物しか含まれません。
東京の半分と埼玉県の一部分しか入っていません。
大阪と通信するなんて、夢のまた夢でした。

よく見ると、荒川と多摩川に塞き止められていることがわかります。
Wifiの通信距離では、川を越えられないんですね。
荒川を越えられなかった。(赤点:東京駅から通信できる建物。対岸には赤点が存在しない。)
次に、必要なホップ数を見てみましょう。
下の図では、東京駅から通信する際に中継する建物の数を表しています。
最大(東吾野あたりまで)で700ホップも必要なことがわかります。
今回は通信の性能の話はしませんが、スループットを出すのも大変そうですね。


ノード間通信に必要なホップ数。都内はだいたい100ホップぐらいで行ける。
というわけで、一般的なWifi基地局では、都内ですら通信できない場所があるという、残念な結果になりました。

Wifiをブーストした場合の通信範囲
普通のWifi(IEEE 802.11 a/b/g/n)で通信できる距離は、国内では100mだけですが、
せっかくなのでブースターを使って通信距離を伸ばした場合に、どれぐらい範囲が広がるか実験してみましょう。(日本では違法です)
このブースターは3.2kmまで行けるなどと言っているので、
200m, 500m, 1000m, 2000m, 3200mで実験してみました。

各建物の通信距離が200mの場合
ノード間通信距離200mのWANETで東京駅から建物をホッピングして通信できる範囲
通信可能な建物は798万戸、全体の17%です。
急に広がりましたね。一番北は群馬まで届いています。
興味深いのが、荒川と多摩川の越え方です。
通信距離が200mあっても川の本流では越えられていないため、川が細くなる場所まで大回りしてのルートが取られています。
一方、江戸川と相模川はそれでも越えられていない様子です。


各建物の通信距離が500mの場合
ノード間通信距離500mのWANETで東京駅から建物をホッピングして通信できる範囲
通信できる建物は1320万戸、全体の28%です。
川は難なく越えられるようになりました。
北はいわきまで届いています。
しかし伊豆半島の田舎っぷりには負けてしまった様子です。 

各建物の通信距離が1000mの場合
ノード間通信距離1000mのWANETで東京駅から建物をホッピングして通信できる範囲
通信可能な建物は3202万戸、全体の68%です。
一気に通信範囲が全国レベルに広がりました。
大阪ばかりか、九州まで到達できたのは驚きですね。
九州まで行くのに1200ホップ程度で済んでいることも予想外でした。

一方、北のいわきはどうしても越えられていないようです。

また、伊豆付近の接続エリアが疎なのが気になりますね。
このへんを空爆されたら西と東の通信が遮断されそうです。


各建物の通信距離が2000mの場合

ノード間通信距離2000mのWANETで東京駅から建物をホッピングして通信できる範囲
通信可能な建物は3258万戸、全体の70%です。
さっきから50万戸ぐらいしか増えてません。
鳥取まで開通したぐらいの変化でしょうか。


各建物の通信距離が3200mの場合
ノード間通信距離3200mのWANETで東京駅から建物をホッピングして通信できる範囲
通信可能な建物は3380万戸、全体の72%です。
2000mとほとんど違いがわかりません。長野県の山間部にもネットが開通したぐらいです。
九州まで350ホップで通信できるようになったのは嬉しいですが、相変わらずいわきが越えられていません。。。

まとめ
・一般的なWifiをホッピングするだけで23区内は通信できる(かも)。その外には行けない。

・1000mぐらい通信距離があれば全国レベルのネットワークが貼れる
 →全部の家に1000mの基地局を置く必要はないかもしれない。例えば川の手前とかに置くだけで、残りは通常のWifiで十分かもしれない。(未検証)

・完全に自由が守られた国では、こんなネットワークは無駄かもしれません。でも広域災害が起きたり、日本のインターネットへの締め付けが強くなってきたときに「市民がいかにして自らを守るか」を市民レベルで常に考えていくことに価値があると思います。
・例えば独裁国家にこっそり無線基地局をばらまいて、検閲不可能なネットワークを無理やり張っちゃったりしたら面白いよね。

・地図とか衛星写真を画像認識すると色々解析できて面白い。

・いわきの闇は深い。

おしまい。


(Satellite Image taken from TerraMetrics for educational purposes)