2016年7月6日水曜日


OpenROVのキットを去年の秋口に購入して、そのまま仕事が忙しくなってしまったため完成したのは正月頃で、今年のGWにやっと海で沈めてみれました。(北海道の冬の海中でひっかかるかも?と考えると、冬に試してみることはできなかった。。。)

OpenROVは海中用ドローンという珍しいジャンルなんですが、オープンハードウェアとオープンソフトウェアと組み合わせたもので、ハード的にはアクリル板をレーザーカッターで切り出したものを躯体とし、BeagleBone Black(Raspberry Piみたいなやつ)とArduinoを組み合わせたもので動いています。キットが届いた時はバラバラのパーツです。

海中では無線が使えないので、地上との通信は有線です。とはいえ、イーサネットケーブルを使うのではなく、PLC(電力線通信)用のアダプタを改造した2芯ケーブルを使って通信します。地上に出れば無線が使えるので、そこからは無線LANアダプタに接続して、タブレットやPCのブラウザを見ながら、キーボードやPS3のコントローラーなどを使ってコントロールします。(上記サムネイルの画面)

ソフト的には、BeagleBone Black内でLinuxが稼働しており、USBカメラの画像をnode.jsを使って表示・コントロールしています。Web技術者とも親和性が高い構成なので、思いつきで改造できそうです。実際に、ハードウェアや回路的にも、改造していくことを前提に作られています。

動画ではOpenROV本体を撮り忘れた(撮ったけど消えてしまった)ので、興味ある方は公式サイトをチェックしてみてください。

OpenROVは操作するのも楽しいですが、組み立てるのも楽しいですね。
こういう機能は、こういった要素で機能してるんだ、という発見がたくさんありました。

今は暇を見つけて集魚用撒き餌マシン(OpenROVアドオン?)を作ってます。

2015年4月1日水曜日

CakePHP 3.0でgitを使ったデプロイの覚書

ちょっと前にCakePHP 3.0がリリースされたようなので、落とし穴が多いことは覚悟で実践で使ってみた。

で、最初から躓いたのでメモを残す。

問題


普通、手元のPCに開発環境としてCakePHPを動かせる環境を作っておいて、こちらで開発&ある程度デバッグしたところで、本番サーバにgit経由などでデプロイするケースが多いと思う。

CakePHPも今はGitHubでホスティングされていることもあって、最初から運用を意識した.gitignoreが用意されているんだけども、
  1. 手元の開発環境で
    php composer.phar create-project --prefer-dist cakephp/app [app_name]
    して、CakePHP3のプロジェクトを新規作成
  2. このプロジェクト用gitリポジトリにgit commit&git push (このときgitignoreによりbin/logs/tmp/venderなどはコミットから外れる)
  3. 本番サーバでgit pull
としたとき、gitignoreで外されたvenderディレクトリ内のフレームワーク本体や、bin/logs/tmpなどディレクトリは、どうやって本番環境に持っていけばいいのかわからなかった。
公式ドキュメント調べても、特に書いてなかった。
リリースされたばっかりなので、ブログやstackoverflowなどにも載ってなかった。

解決方法


おそらく、上記3の後に、
  1. 本番環境側にもcomposerをインストール
    上記app_nameディレクトリに移動してから
    curl -s https://getcomposer.org/installer | php
  2. githubのcakephp/appからbin/logs/tmpを取ってくる。方法は色いろあると思うけど、以下のようにすると楽だった
    svn export https://github.com/cakephp/app/trunk/bin
    svn export https://github.com/cakephp/app/trunk/logs
    svn export https://github.com/cakephp/app/trunk/tmp 
    
  3. composerを使って依存関係にあるライブラリをvenderディレクトリに入れ、自動実行されるCakePHPのインストールスクリプトを使ってパーミッションも付与する
    php composer.phar -n install
のようにするのが正解ではないかと思う。みんな困るはずなので、そのうちもっとスマートな方法が提案される気もするけどね。

おまけ


CakePHP 3.0はPHPのintl extensionに依存してるんだけど、MacOSXの場合、homebrewを使ってintlモジュールを入れようとすると
brew install php53-intl
など、PHP本体とは別にintlモジュールを入れる必要があると書いてあることが多かった。

でも、実際に
brew search php5
で検索すると、-intlがついてるモジュールは見当たらない。

困ったので色々調べてみたら、ちょっと前からphp本体にintlモジュールを組み込んだ状態で配布する形式に変わったようだった。

なので、
brew install homebrew/php/php56
だけで最低動作環境はクリアできる。

2015年2月16日月曜日

「Bluetooth HCIスヌープログを有効にする」とは何なのか

全部読むのが嫌なせっかちな人へ

  • Android 4.4(API 19)以降の開発者向けオプションには、「Bluetooth HCIスヌープログを有効にする」というチェック項目がある。
  • 「Bluetooth HCIスヌープログを有効にする」をOnにした場合、BlueZのhcidump相当のログが出力される。
  • ログファイルの保存先はメーカーによる。/etc/bluetooth/bt_stack.confを確認すると保存先がわかる。
  • hcidumpのログはWiresharkで解析できる

いきさつ

2013年の11月頃に、Nexus5(当時4.4.0あたり)を入手できたまいむぞうは、開発者オプションに「Bluetooth HCIスヌープログを有効にする」というチェック項目を見つけ、当時からiBeaconやBLEに興味を持っていた私はこのオプションをいじくりまわしていた

なんとなく、正体を知れた私は、特にブログなどにまとめることもなく、そのうち誰かがブログにまとめてくれるだろう、と思いつつ、興味の対象を他に移した。

時は流れ、2015年2月に、仕事上BLEのパケットを解析する必要に迫られ、当初は手持ちのSenserTag付属の開発キット(CC2541 ミニ開発キット)に付属のPacket Snifferを使おうと思ってたんだけど、買ったまま使わずに置いといたら、ソフトウェア側がバージョンアップしてうまく動かなくなっていたので、どうしようか途方に暮れていた。

そんなときに「Bluetooth HCIスヌープログを有効にする」オプションの存在を思い出した。改めてググってみても、自分のTwitterがひっかかるだけであまり使っている人がいなさそうだったので、自分のメモ的にもこのオプションの使い方をまとめることにした。

「Bluetooth HCIスヌープログを有効にする」とは何なのか

まず、「Bluetooth HCIスヌープログを有効にする」オプションは、Android 4.4(API 19)あたりで増えた開発者オプションである。

「Bluetooth HCIスヌープログを有効にする」をOnにした時の挙動なのだが、公式ドキュメントをちゃんと読んでいないものの、これはhcidump相当のログを出力するオプションらしい。

元々AndroidのBluetooth周りは、Linux上のOSSであるBlueZを使っているのだが、Ubuntuや他のディストリビューションにBlueZをインストールした場合、HCI(Bluetoothのハードウェアとソフトウェアの境界線ぐらいに相当するレイヤ)上のコマンドラインデバッグツールとして、hcidumpというログ出力用プログラムが利用できるようになっている。

hcidumpを稼働させつつ、BlueZが入っているPCとBluetooth機器を通信させると、その間を飛び交っているパケットを記録しておく(パケットスニファ)のが、その役割となっている。

Androidの実装を確認はしていないものの、「Bluetooth HCIスヌープログを有効にする」をOnにした時に出力されるログのフォーマットは、hcidumpのものと同じっぽいので、Android内部でhcidumpそのもの、もしくはBlueZのライブラリを使ってhcidump相当のコードが動いているように見える。

Bluetooth HCIスヌープログを有効にするをOnにして、ログを取り込む

実際にログを取得してみよう。

「Bluetooth HCIスヌープログを有効にする」オプションは、Onにしている間のBluetooth通信を監視するものなので、最初にBluetooth機器をすべて切断し、Bluetoothを使うアプリも全て停止しておく必要がある。

Androidの設定アプリから、開発者オプションに入り、「Bluetooth HCIスヌープログを有効にする」にチェックを付けた後、デバッグしたいBluetooth機器と接続したり、iBeaconなどを扱うアプリを起動すると、その通信内容がログに記録される。

このログは、メーカーごとに保存先が異なっているようなので、以下のコマンドを使って確認することができる。

$ adb shell cat /etc/bluetooth/bt_stack.conf | grep BtSnoopFileName

例えば、Nexus5やNexus7は/sdcard/btsnoop_hci.logへ、Galaxy S4は/sdcard/Android/data/btsnoop_hci.logに出力されるようになっていた。
(/sdcardが指している先は本当にSDカードなのかどうかは、端末による。たとえばSDカードが無いNexus7も同じパスに保存される)

あとはADBなどで

$ adb pull /sdcard/btsnoop_hci.log . 

とすればPCに取り込むことができる。(USBケーブル経由でAndroid File Transferや、エクスプローラ経由でも取り込めそうだけど)

ちなみに、一度ログを保存した後、「Bluetooth HCIスヌープログを有効にする」オプションをOff→Onとすると上書きされてしまうので注意。
また、Onのまま放置するとストレージを食いつぶすので、使わない時はOffに戻しておこう。

hcidumpのログを解析する

OSSエコシステムとしては、hcidumpのログは、Wiresharkに取り込んで解析するのが一般的らしい。

まいむぞうはMac使いなので、MacOSX対応のWiresharkをインストールする必要があった。

Wiresharkのインストール自体は、各OSの手順に従って欲しいのだが、一昨年に試した時点ではWireshark本家提供のMacOSX用パッケージはうまく動かなかったので、Homebrewで入れた気がする。(うろ覚え)

Wiresharkが立ち上がってしまえば、File→Openで取り込んだbtsnoop_hci.logを読み込むだけで、通信内容が解析されて表示されるようになっている。

例として、BLE113を使ったiBeacon互換のアドバタイズパケットを解析したスクリーンショットは以下のようになる。


解析結果をクリックして行を反転させると、その行に相当するバイナリ列も反転されるので、なんとなく雰囲気は読み取れると思う。

ただ、Bluetooth規格に記載がある部分は解析されるのだが、当然ユーザ定義部分は解析されない。たとえば、iBeaconとして使うときのUUID/Major/Minor/TxPowerなどは解析できないので、Appleのドキュメントを読み解く必要がある。

また、当然解析された部分についても、その意味や選択肢は公式ドキュメントを参照する必要があるだろう。

2014年8月31日日曜日

Parrot Rolling Spider(ドローン)を飛ばしてみた

先日amazonで1万ちょいで買ってしまったので、近くの公園で飛ばしてみた。
(部屋でも飛ばしたけど、テレビ裏のだすてぃーなところに突っ込んじゃってわやわやになるので諦めた)


面白い。初代ドローンは見たこともないけど、基本的に同じ仕組みなのかな?

機体の下部に超音波センサーが付いていて、地面からの距離を元に高度を自動調整できる。
かつ、機体に入ってる加速度センサーにより、傾きも自動調整できる。

なので、環境条件がよければ(無風かつ舗装路)、自動ホバリングできるので、高度の上げ下げぐらいなら3Dオブジェクト感覚。
スマホを傾けるとドローンも傾いて移動始めるので、定点往復するだけでも楽しい。

だがしかし!
まだファームやアプリの詰めが甘くて、よく暴走するw

アプリ側で高度上限を設定できて、それ以上は上昇しないようにできるんだけど、一度暴走して上空10mぐらいまで飛んでったときは焦った。emergency cut offがあるので、プロペラ止めて落下させ、地面近くでまたプロペラ回すとか、高度な技術が要求されるw

これ、ファームもなんか変だけど、たぶんアプリ側がショボいのだと思う。よく強制終了するし、ハングするし、(おそらくアプリがショボくて)Take offと同時に全力で前傾姿勢になって向かってくるし(しかも水平に修正できない)、コントローラーはジョイスティック型なんだけど、何を意味するのかいまいちわかんないし。

emergency cut offはいつでも効くみたいなので、ドローンと通信回路はまぁ良いとして、アプリがアワアワしつつ変なデータ流してるのだと思う。

しかも、Nexus5(4.4)とGalaxy S4(4.4)とiPhone5C(OS7)で、それぞれ別のファームダウンロードしようとするし、しかもGalaxy S4のファーム流した後にNexus5のファーム流したら、Galaxy S4と接続できなくなったしorz
接続にはBlueTooth LowEnagyを使ってるみたいだけど、おそらくBlueToothスタックの違いに悩んでいるのではないかと推測。iPhone5Cではまだ飛ばしてないけど、こっちのアプリとふ

追記:

iPhoneで飛ばしてみて分かった。しょぼいのはAndroid版アプリだわ。
iPhone版だと完成度がぜんぜん違う。まともに飛ぶし、操作感あるし、体験自体が違う。
まぁこのタイミングのAndroid版だからねorz


あれ?
ってことは、飛行姿勢制御はドローン内部じゃなくて、スマホ側で行ってるんだね。
追記終わり

あと、超音波センサーが舗装路では効くけど、草むらに入ると効かなくなるので、困ったドローンが暴走を始めるw

広くて人の居ない駐車場を探さないとね。

2014年7月6日日曜日

CardBoardを自作してみた

なんとなく忙しくなってきそうなので、遊び納め的にCardBoardを自作してみました。

CardBoardとは、Google IO 2014のお土産として、会場で配られた3Dメガネ自作キットのことで、ダンボールとレンズと磁石で構成されています。このCardBoardにデモ用アプリを起動したスマホを装着すると、左右の画像の視差により三次元的に見える仕組みになっています。

まぁ、巷でFakeRiftと言われているもののひとつです。
KinnekoさんがABCなどのイベントで展示していたやつを、Googleも作ったということですね。

で、CardBoardですが、公式ページからCardBoard用の型紙もダウンロードできるので、Google IOには参加してない方でも試してみることができるようです。


…ってのを今朝知ったので、ちょうど今日は暇してるし、作ってみよ〜ということになりました。

会場で配布していたものは、パッケージを開けるとレンズや磁石などがセットされた状態で配布されているようで、上記サイトでは型紙の画像の他、レンズや磁石なども購入できるようなのですが、近くの100均にあるもので代用可能のようなので、適当に買ってきて試してみました。


最低限必要な物は、上記型紙画像を印刷した紙と、ダンボールと、レンズ(上記ミニルーペからはレンズ2枚取れます)と、磁石1組です。100均で400円で揃いました。

レンズは焦点距離40mmのものが必要らしいのですが、上記ミニルーペのレンズですと、人間側の気合があれば3次元的に見えることが確認できました。もちろん焦点距離なんて確認してません(汗)
このミニルーペのレンズには方向があるようなので、縁のカットの方向を合わせるのがコツです。合わせないと画像がブレたまま重なりません。



また、Googleが配布した時のレンズと、今回ミニルーペから取り出したレンズは、直径が違うので、ダンボールを型紙通りにくり抜いたのではうまくハマりません。
中央下部が型紙どおりにくり抜いてレンズを合わせたものですが、穴が小さすぎるようです。上部のようにレンズがすっぽり入るよう、現物合わせでくり抜く必要があります。

CardBoardの操作は、スマホ本体の加速度センサーと、磁石を使って操作します。
CardBoardにスマホを入れてしまうと、直接タップできないので、CardBoardに付いている磁石をスライドさせることで、スマホ本体の磁場センサーを使ってタップをエミュレーションするようになっているようです。
(オレのスマホに磁場センサーなんて付いてたっけ? と思いましたが、Nexus5とGalaxy S4で動作確認できました。付いてたんだ…)

Googleが配布していた時の磁石は、結構大きかったようですが、要は磁場の変化を読み取れる程度の磁石であればなんでも大丈夫のようです。
自分の場合は、100均にいわゆる強力磁石(ネオジム磁石など)の大きい物がなかったので、小さいネオジム磁石の受け側と、同じく小さいネオジム磁石に取っ手が付いているものを買ってきました。
ちょっと磁力が足りないようで、型紙通りよりはスマホ側にずらして操作する必要がありますが、一応動くには動きました。


肝心の3D具合ですが、オモチャにしては良好です。
さすがにRiftと比べると解像度が低いし、センサー精度はRiftほど良くないし、計算速度はPCに勝てるわけないのでカクカクするし、レンズの焦点が想定と違うものなので、どうしてもなんちゃって感は否めません。
(自分はRiftは持ってませんが、試したことはあります)

しかし、一応首を振った方に画面が追従して360度見えるし、浮き出て見えます。
ちゃんと3Dしてます!!
この程度のものでもアイデア次第で色々使えそうかなぁと思いました。

…が、Riftほどの衝撃は受けなかったので、初めて試す方は、先にRiftを試してみてVRの可能性を感じたほうが良いと思われます。

Rift用に出ている表示用ソフトをAndroidに移植できそうです。実際にデモアプリで使われている3DムービーはRiftでも見たことがあります。
Unityちゃんと勉強しようかなぁ。


ダンボールとレンズと磁石さえ揃えば、製作時間そのものは2時間程度(90%はダンボールの切り出し時間)です。
難易度は、小学生の夏休みの自由研究程度です。
材料も400円で数個制作できるぐらい揃います。
とってもオススメです。

2014年2月23日日曜日

iBeaconを使った室内向け測位システム作ったよ

個人的に色々ありましたが、なんとか生きております。。。

現在お仕事が無いので色々研究開発を進めてまして、個人的に興味があるiBeacon周りのプロトタイプを作ってみました。

使い方やできること、測位精度などは動画を見てもらうのが早いです。


全部入りで作ったので、簡単に内容だけ見たい方はこちら↓
アプリはほぼ同じでiBeaconを3mスパンぐらいで配置しています。



まだちょっと動画は準備出来ていないのですが、ヒートマップ連動版も準備中です。

こんな感じで。

今は送信側と受信側を入れ替えて、iBeaconを持って室内を歩くと、Raspberry Piなどの名刺サイズPCが読み取るようなシステムを作ってます。

これ、何に使えるのか考えてるんだけど、
  • iOSのiBeaconを使った近接検知(店に来た、特定の棚に近づいた)より、もうちょっと踏み込んだ来店イベントやクーポンとして
  • 工場などでの工程ごとの作業時間管理
  • 来店客の動線を把握することで、商品のディスプレイ方法の最適化、興味のある商品ニーズの発掘、興味から購入に至るプロセス(いわゆる買い方)の研究など
みたいな感じかなぁ。
ただし、現状ではBLE対応スマホ(iPhone 5S/5C/4S/Android 4.3以降など)、またはiBeaconなどのBLEペリフェラルを持ってないと使えないのが問題かなぁ。
博物館など、入り口でiBeacon渡せるような感じなら問題ないんだけど。

事業化したいので、興味ある方は右のプロフィールから連絡ください。

2013年11月14日木曜日

iBeaconを使った屋内測位の可能性を検討してみた

先日札幌の無料セミナーでBluetooth Low Energy(BLE)を扱うものがありまして、いっぱい面白いことを教えてもらったので、ごにょごにょ遊んでます。
自分の興味範囲に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ドングルをつけて、SensorTagBlueZのコマンドラインプログラムや、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列)
受信電波強度(RSSI)の単位はdBmらしいんだけど、1mWなんちゃら(よくわかってない)の時を0dBmとして、それより電波強度が弱いとマイナスの値になるらしい。今回はすべてマイナスだったので、0に近いほうが電波が強く、0から離れるほうが電波が弱いことになる。

実験場所は自宅で、居間〜廊下までの長細い部屋。(雰囲気は上の写真で察するべし) 周りに電波を発するものはなし。(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次元絶対座標を求めるのは、色々工夫しないといけないんじゃないかな。これみたいに建物の見取り図に設置箇所を落として管理すると、いい感じに行けそうな気もする。
つーわけで、技術的にはiBeaconで屋内測位(2次元座標ぽく)は、実現できそう。
ただ、もうちょっとリニアに急勾配で電波が減衰してくれれば1m精度ぐらいで測位できそうだけど、現状だとあまり精度が出ないんじゃないかなぁ。iBeaconが安いなら、2m間隔ぐらいでマトリックス状に置くという絨毯作戦も使えるかも?と思った。
「平面上の任意の既知の点に、円状に電波が減衰される端末が複数あり、それらを同時に計測しながら現在地を求める問題」に詳しい方がいらっしゃいましたら、いろいろ教えて下さい。