自分の興味範囲にiBeaconがあるのですが、セミナーで仕組みを色々教えてもらったので、PICマイコンを使ってiBeaconを作れないかなぁと思って調査中。
iBeaconに興味津々
えっと、iBeaconの定義を実はよくわかってないのですが(汗)、下回りはBLEを使っていて、どんな情報をどのぐらいの頻度でどのぐらいの電波強度で送るか、というあたりはBLEの話しらしい。んでiPhoneなどでその情報を受け取ったあと何をするかは、アプリの話しらしい。iBeaconつーのはBLEの一部機能をこう使って、アプリでこういう機能を作るとこんな事ができますよー、という規格の話なのかな?と思ってる。(今のところあまりここには興味が無いのですまん)実際、BLE周りがわかると、iPhoneの代わりにLinuxでもiPhoneがやろうとしていることと同等の機能を実現できそう。つーかiBeaconがすごいのって、iOSに標準で乗っててOSレベルでiBeacon端末とおしゃべりができる環境が用意された(搭載率100%かつアプリアクティブ率100%)ことなんだと思う。垂直統合の強さだよね。
ちなみにAndroid 4.3以降だとBLE関係(ただしセントラルのみ。BLE端末を読み取る側)のAPIが整備されたので、iBeaconとiPhoneでしたいことと同レベルのアプリは(技術的には)実現可能。ただしAndroidの場合OS標準のアプリや機能は今のところ無いのと、Androidの場合はBLEのスタック(いわゆるドライバレベル)の実装が一本化されてなくて、Android 4.3 + BLE搭載端末が増えても混乱が増すだけなんじゃないか?というのが多方の予想みたい。このへんスッキリすれば世の中変わるのにねぇ。
O2Oとしてのユーザトラッキング
で、O2O的にオイシイのは、物を買わなくても(物を買うとPOSから情報を取れる)、誰が何に興味がある(のでどの棚の近くに来たか)がわかることではないかな?とおもった。実際iBeaconとiPhoneの組み合わせでクーポンを出すところまでは今でも実現できているけど、実際にBLEの恩恵を受けて電池消費が少ないのはiBeacon側であって、iPhoneはこの機能のためにBluetooth受信機をずっと起動しなければならず、1日でバッテリーの50%を消費するらしい(出典忘れた)ので、実際にはOffってる人が多いはず(いや、今iPhone持ってないので詳しいことわかんないんだけど)
でも、iPhoneなどのスマホをBLE端末(ペリフェラル)として扱って、棚やフロア毎に誰が近寄ってきたかを記録するマイコンぽいのを設置(してクラウドで集計)しておけば、iPhone側の電池消費は無視できて、お店としてもユーザトラッキングできちゃうので、これこそが本命なのかな?と今思った。
となると、AndroidのBLEペリフェラル対応ができたら世の中変わるかもね?
(まぁ実際にはそんな危ないこと許してくれない団体ができたり、デフォルトでOffってたりしてうまくいかないんだろうけど)
iBeacon互換端末を作っちゃおう
なんかRaspberry Piを使ってiBeacon互換機は作れるようなので、同じ仕組を使ってちっちゃいLinuxボード(最近だとBeaglebone blackとかね)でiBeaconは作れるみたい。まずはこっちをやってみて、パケットの内容を理解したらそれをPICで実現するためのファームを書くような感じなかぁ。(でもiBeacon対応のマイコン自体はこんなのが出てくると個人では太刀打ち出来なくて、このビーコンに対応したアプリを作るとかSIする感じになるのかなぁ)WiFiによる屋内測位はiBeaconで置き換えられるか?
んで、BLEのセミナーではLinuxマシン(仮想マシン)にBluetooth 4.0対応のUSBドングルをつけて、SensorTagにBlueZのコマンドラインプログラムや、PythonやCやJavaScriptからアクセスしてみようって内容だったんだけど、この中のJavaScriptを使ったnobleというパッケージがモダンな感じで使いやすそうだった。BLEではその仕組み上、近くにあるBLE端末(ペリフェラルというらしい)のIDと信号強度をスキャンできるんだけど、nobleを使うと結構簡単に電波強度を扱えそうだったので、距離や障害物などによってどれくらい電波が減衰するのか調査するプログラムを作ってみた。
iBeaconのハードウェア部分はBLEを使っているので、これがわかるとiBeaconを使った屋内測位(WiFi使った測位はよくやってるよね)が使い物になるのか、どのくらいの間隔で設置するのがベストなのかわかると思うんだよね。
テスト環境と構造
こんな感じで、MacOSXにUbuntu 13.10を入れて(BlueZを使いたかったので)、BLE USB Dongle経由でSensorTagをスキャンして(というかBLE的にはSensorTagのブロードキャストを受け取って?)、その時の受信電波強度(RSSI)を記録しておき、過去50回分の平均値と標準偏差を調べてみた。
テスト内容と結果
ちょっと見えづらいかもしれないけど、やったことは以下の通り。
- 個体差を調べるためにSensorTagを2台使って比較してみた(B列とD列)
- SensorTagに付属のゴムケースを付けてみて、電波の減衰具合を見た(F列)
- SensorTagのBLEチップ(らしきもの)を隠すように設置してみて、電波の減衰具合を見た(H列)
- SensorTagとBLE Dongleの間に人体を置いて(具体的にはDongleのすぐそばでDongleを隠すように座って)、電波の減衰具合を見た(J列)
実験場所は自宅で、居間〜廊下までの長細い部屋。(雰囲気は上の写真で察するべし) 周りに電波を発するものはなし。(WiFiとか3G/LTEとかはある) 生活雑貨はあるけど長細い部屋だし、基本SensorTagとBLE Dongleの間には障害物はないので、電波的には好条件なんじゃなかろうか。
過去50回分の平均値と標準偏差とした理由は、対象者(スマホを持っている人。位置を知りたい人)が長々と同じ場所にいるわけではないと思うので、このぐらいがいいところなのかなぁと思ったので。実際には、もうちょっとサンプル数を増やしたほうが結果が安定するんだけど、過去50回分でも平均値はプラマイ1ぐらいに収まる感じに見えた。ちなみに、同じBLE端末は毎秒1〜10回程度スキャンされ、その時のRSSIを記録して集計している。
自分は電波関係に詳しくないし、電波暗室とかではないので、所詮適当だけど。
結果として言えそうなこと
まとめるとこう言えるかなと。- 複数のSensorTagを同時に取得(現実的にはとても短い間に次の機器に切り替わる)するのは問題ない
- 1秒間の平均スキャン回数(RSSI計測回数)は1〜10回程度と、けっこうばらける。距離によって変化するわけでもないし、原因がわからないけど、Rawデータを見る感じでは、だーっと流れてるなーと思ったら突然詰まって、数秒後にまただ～っと流れ始めるように見える。これはテスト環境(Bluetooth周りのスタックやnobleなどのライブラリ)の問題かもしれないけど。
- SensorTagの個体差はあまりなさそう(よかった)
- 電波なので受信電波強度は常に変動するのだけれど、1m以上の場合は標準偏差はほぼおなじに見える(サンプル数が足りなくてバラけているけど)
- SensorTag付属のゴムケースをつけたり、SensorTagの向きを変えたりした場合、多少電波が弱くなるものの、さほどではない。(ように見える)
- Bluetoothの電波は、水や水分を多く含む人体に弱いと聞いていたけど、今回のように隣に人が居て邪魔している程度であれば、あまり電波は弱くならない。
- 距離は0m〜7mまで計測した(我が家はそんなに広くない)けど、屋内測位するなら実際は1mからになる(1m以内に接近することは少ない)と思われる。SensorTagを使うなら-80dBmぐらい? 一応BLE Dongle的には障害物がなければ25mぐらい届くらしいけど、ここから先は同じような勾配で減衰していくっぽい。(グラフを見る限り)
- 障害物や設置方向より、距離による減衰が強いように見える。
- ただ、1m時と7m時の差は15dBm程度に見えるけど、標準偏差が5dBm弱ある時もあるので、1m単位の測位は難しいんじゃないかと思う。フロアやルーム単位が現実的なのかな。
- BLE機器というかiBeaconは安いようなので、同じフロアに複数のiBeaconを撒いておけば、一番近いiBeaconを探すのは簡単にできそう。
- 逆に緯度経度的な2次元絶対座標を求めるのは、色々工夫しないといけないんじゃないかな。これみたいに建物の見取り図に設置箇所を落として管理すると、いい感じに行けそうな気もする。
ただ、もうちょっとリニアに急勾配で電波が減衰してくれれば1m精度ぐらいで測位できそうだけど、現状だとあまり精度が出ないんじゃないかなぁ。iBeaconが安いなら、2m間隔ぐらいでマトリックス状に置くという絨毯作戦も使えるかも?と思った。
「平面上の任意の既知の点に、円状に電波が減衰される端末が複数あり、それらを同時に計測しながら現在地を求める問題」に詳しい方がいらっしゃいましたら、いろいろ教えて下さい。
0 件のコメント:
コメントを投稿