Docker道場で修行してきたまとめ

• Docker=chroot+OverlayFS+カーネルのプロセス分離技術
• 仮想OSとは概念が違う。仮想OSはBIOSより上をすべて差し替えるけど、Dockerは特定用途に必要なファイルだけ差し替える。下から全てなのか、上から必要最小限なのかの違い
• 仮想OSぽいこともできるけど、それは狙ったものではないので、失敗することが多い。ネット上の批判はそのあたりに原因がある。
• ソースコード以外の、たとえばデーモンやライブラリや設定ファイルにバージョン管理の概念を導入したもの
• 開発環境と本番環境の同一性を保証するような用途に向く。または、使い捨てのアプリでも、親環境を汚さないで済む
• 基本的にLinux系OSの上に、やりたいことに関連する依存部分すべてををDocker imageとして用意し、基本となるOSの上にDockerで用意した差分を当てることで、特定の用途として使えるようにしたもの
• 基本Linuxで動く。macOSはUnix系なのでDocket for Macを使うことで動かすことが出来る。Windowsは、仕組みが違いすぎるので、Dicker for Windowsを使うことで、内部的に仮想Linuxを立ち上げることで動かしている
• 最近はクラスタリングを便利にする方向に進化している
• 元となるOSからの差分は、OverlayFSを使って、たくさんのレイヤーを重ねることで実現しており、変更はレイヤーごとで管理するので、仮想OS（すべてを一括管理）より入れ替えが楽。これにより開発中のテストや修正などが迅速に行える
• Docker imageは、レイヤーに相当しており、実際にはファイルやサブディレクトリを含んだ1つの読み取り専用ディレクトリとして実装されている。（OverlayFSの下層レイヤーとして機能する）
• Docker containerは、実行する度に作られる管理単位で、一つのDocker imageから複数のDocker containerを作ることが出来る
• Docker containerは、OverlayFSを使っていることもあって、変更された分は最上位レイヤーに差分としてとして管理される。
• コンテナの実行を終えたとき、最上位レイヤーは破棄されるので、残しておく必要があるときはdocker commitを使って保存しておく必要がある
• レイヤーは複数重ねることが出来る。これにより基本部分や特定用途など、用途ごとに管理できる
• レイヤーの層の分、OverlayFSでの重ね合わせが発生する。ファイルを1バイトでも変更すると、ファイル単位のcopy on writeが発生し、これが最大のオーバヘッドとなる。それ以外の部分のオーバヘッドは小さい。
• Docker containerからは、親となるOSのディレクトリを直接マウントできるので、変化するデータは親のファイルシステムに保存するのが定石（じゃないと、遅くなる）
• 仮想OSではないので、親のOSのディストリビューションや、バージョンに影響を受ける。基本的には動くように作っているはずだが、現実的には、同じディストリビューションの同じバージョンで動かす方がよい（ディストリビュービューターの努力依存）
• 元になるOS部分と、一層目のレイヤーの境界線がわかりにくい。要はOS層の中で、マシンが違っても同じ実行を保証するための、共通因子がはっきり定義されてない印象。ただしこれは、元となるOS部分を限りなく薄くして、一層目のレイヤーを厚くすることで吸収するような方向に進化中とのこと
• どこに使えば使えばいいのか、いまいち解りにくい
• 市販の本は、既に古くなっている部分が多いのでオススメしない。 Dockerドキュメント日本語化プロジェクトをオススメする。

また、docker利用例としてros2とsagemathを思い出したので紹介しておきます。

• ros2はRobot Operating System ver2です。ロボット開発にパッケージシステムや共通コンパイル環境を用意することで、車輪の再発明を抑制してみんなハッピー、みたいなものです。ただ、進化スピードが早いのと、周辺システムまで含めると巨大なので、コンパイルを通すのがしんどいです。おそらくそれをdockerを使って解決しているのだと思います。

• sagemathは数学系の教育補助ソフトに分類されるのかな。jupyter notebookやsageなどを使って数式を書くと、それを解析的に解いてくれたり、グラフに書いてくれたりします。AIやってる人は結構使ってるはず。同様のものが無料のクラウドサービスとして運用されていますが、混むと遅くなるのでこちらでdocker imageも配布されているようです。(なので自分のマシンで立ち上げてもユーザ登録から始まった気がします)

動体追跡システムを作ってみた

以前からOpenCVを使って色々作ってみていたんだけど、画像加工や特徴点ベースのマッチングに使う、つまりアプリ全体を俯瞰してみるとコア部分ではあるけどあまり全面に出てこない部分で使っていたぐらいで、本格的にOpenCVと向き合ったのはこれが初めてかもしれない。

画像加工や解析の場合、ゴールは同じでも色々なアプローチがあって、各カテゴリごとにOpenCVのAPIとしてたくさんのアルゴリズムが実装されているんだけど、ちゃんと使いこなすためには論文を読んで理解しておく必要がある。(OpenCV自体では、APIの説明しかしてないので、パラメタの意味や使い分けは別途調べる必要がある)

また、理論的にいくつかのアプローチは除外できても、結局は複数のアプローチを実際に試してみることになるので、自分としても3歩進んで2歩下がる感があったり、このあたりを受託でやるとなると、発注者の理解を得るのはなかなか難しいなぁ、と思ったり。

閑話休題

さて、この動体追跡システムですが、製品として発売されているものもあるようで、そちらではスーパーの出入り口カメラを向けておき、出入り口前にボーダーラインを引いておくことで、来店数をカウントできるような機能もあるみたい。

また、コインパーキングの空き情報や、違法駐車の自動取締りなどにも使えそうなので、時間がある時にRaspberry pi3あたりで実装してみようかなと思っています。

こちらも事業化したいので、興味ある方は連絡ください。

赤外線暗視装置を作ってみた

秋月のネットで赤外線投光機キットを見つけて、勢いで車載用赤外線暗視装置(ドライブレコーダーを兼ねたもの)として作ってみたんだけど、同居しようと思っていたラズパイ3ではCANの処理が思ったより重かったのと、この投光器の光量ではあまり遠くまで見えなかったので、車載向けを諦めて持ち歩き可能にしたのがこちら。

5インチディスプレイも付けたので、OpenCVを使ってリアルタイム動画解析するのであれば、かえってこっちの方が良かったかもしれない。WiFiの無い現場でもUSBキーボードだけでパラメータ調整して再コンパイルできるからね。

途中で3Dプリンタが壊れてしまったのでケースは中途半端だけど、3Dプリンタさえ修理が終わればもうちょっと実用的になるはず。。。

gstreamerを使って遠隔地監視したり、motionを使って動体監視したりまでは試してみたんだけど、害獣駆除用の檻の扉の制御とかもやってみたいな。

色々応用できそうなので、うまく事業化できればいいなと思っています。興味持たれた方はご連絡ください。

CANから情報を取得して車載ナビに情報表示してみた

最近の車は自動運転に向けて各種センサーデータがCANというネットワークを介してやり取りされているんだけど、規格がオープンでネット上に情報がたくさんあり、必要な基板も中国から安く買えるようなので試しに作ってみたものがこれ。

昔はサーキットや峠に頻繁に行ってたけど、最近はそんな熱もすっかり冷めてしまったので、たまにミニサーキットに行きたくなった時に水温管理できればいいな、ぐらいのモチベーションで作ってみました。

自動運転に向けての各メーカーの取組みも各社それぞれで、車種ごとにも違うので、汎用性が薄いのが難点かな。自分用としてはいいけども。

上記のように、ちょっと汎用的な応用は難しいのかもしれませんが、特定用途であればいけそうです。興味ある方はご連絡ください。

室内測位システムで複数同時測位してみた

そういえば、YoutubeやFacebook/Twitterでは公開してたけど、ブログに書いてなかったなと思い出したので、整理したいと思う。

まずは、以前に作ったiBeaconを使った室内向け測位システム作ったよ を発展させて、複数同時に測位できるようにしたシステム。

このシステム用に、結局iBeaconも自作した(ファーム担当した)ので、追加機能など色々応用できそうなんだけど、iBeacon自体あまり聞かなくなったので惜しいなぁ。

とはいえ、IoTとしてだとビーコンとしてのアプローチは有効な選択肢の一つだと思うし、iBeaconは聞かなくなってきてもGoogleのEddystoneなどを使って多機能に進化したものは消えずに細々と使われ続ける気がする。

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

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

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

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

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

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

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

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の後に、

4. 本番環境側にもcomposerをインストール
   上記app_nameディレクトリに移動してから
   

   curl -s https://getcomposer.org/installer | php

5. 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 
   

6. 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

だけで最低動作環境はクリアできる。

「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のドキュメントを読み解く必要がある。

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

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

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

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円で数個制作できるぐらい揃います。
とってもオススメです。

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

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

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

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

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

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

こんな感じで。

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

これ、何に使えるのか考えてるんだけど、

• iOSのiBeaconを使った近接検知(店に来た、特定の棚に近づいた)より、もうちょっと踏み込んだ来店イベントやクーポンとして
• 工場などでの工程ごとの作業時間管理
• 来店客の動線を把握することで、商品のディスプレイ方法の最適化、興味のある商品ニーズの発掘、興味から購入に至るプロセス(いわゆる買い方)の研究など

みたいな感じかなぁ。

ただし、現状ではBLE対応スマホ(iPhone 5S/5C/4S/Android 4.3以降など)、またはiBeaconなどのBLEペリフェラルを持ってないと使えないのが問題かなぁ。

博物館など、入り口でiBeacon渡せるような感じなら問題ないんだけど。

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

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ドングルをつけて、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列)

受信電波強度(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間隔ぐらいでマトリックス状に置くという絨毯作戦も使えるかも?と思った。
「平面上の任意の既知の点に、円状に電波が減衰される端末が複数あり、それらを同時に計測しながら現在地を求める問題」に詳しい方がいらっしゃいましたら、いろいろ教えて下さい。

MacでParseのCloud Codeへのデプロイコマンドparse deployでエラー発生

ちょっとハマったのでメモ。

Parseのサーバサイド実行環境であるCloud Codeのチュートリアルを試してみたんだけど、サイトの通り

> parse new MyCloudCode

した後に、Windows版のparseconsole.exeから

> parse deploy

するとちゃんと動くのに、Mac/Linux版(試したのはMac)のparse deployではエラーが発生して、pythonのバックトレースが出て止まった。

ググってみたら、

> curl -s https://www.parse.com/downloads/cloud_code/installer.sh | sudo /bin/bash

して新しいparseコマンドをインストールし直せばいい(古いとエラーが起きる)とあったけど、これでは解決しなかった。

もうちょっと調べてみると、pythonの特定バージョンでは動かないという報告を見つけたので、自分の環境を調べてみると、macportではpython25パッケージを使っていたみたい。

> port select --list python

してから、

> sudo port select --set python python27

としてインストール済みのpython27(具体的にはPython 2.7.3)に切り替えたら正常にparse deployできた。

OSC2013北海道での講演資料

やっと今年の分だ(汗)

今年は、本当はスマートグラスの話をしようと思ってたんだけと、google glassは変えなかったのでvusixのM100を狙ってシルバーライセンスを購入(評価版が早期にもらえる)したんだけど、当初の予定より送れているらしくて、実物がOSCに間に合わないという問題が発生!

急遽、BaaSネタをこしらえました。

Parseは完成度高いしドキュメントしっかりしてるのでオススメです。

でも、さくっとGCM飛ばしたい時以外は、あまり効果的な使い方が見つからないかも。(結局サーバ側のコードを書きたくなるけど、ParseのCloud Codeじゃ足りない気がする)

といいつつ、今年のGoogle I/Oで発表されたはずのMobile Backend Starterは無かったことになってる(サービスとして発表したのではなく、サンプルアプリとして公開するつもりだった?)ようで、これもそのまま使うには微妙。

でも、サーバ側コードいじるつもりなら、Mobile Backend StarterのコードをGithubから落としてきて、これをそのまま使うのではなくてテンプレートとして使うなら、つまりMobile Backend Starterの元になっているGoogle Cloud Endpointsを使って拡張ありきでつかうなら、これが自分の使い方としては一番現実的なのかなぁと思った。AndroidもiOSもWeb(JavaScript)も使えるからね。

Baa sでお気楽アプリ開発 from Yusuke Ohmichi

去年のAndroid勉強会でADKを扱った時の資料を公開する

去年のOSCの流れだと、去年のAndroid勉強会でADK扱った時の資料も会ったほうがいいかなーと思ったので上げておきます。

こっちはSlideShareにはアップしておいたんだけど、ブログに貼るの忘れてた…

Adkを使って音声コマンドで操作する戦車を作ってみた from Yusuke Ohmichi

今更2012年のOSCの講演資料を公開する

ある御方に「もう2年ぐらいブログの更新止まってるよ」と言われたので見なおしてみたのですが、去年のOSCの資料上がってないですね…

単純に忘れてました…

せめて発表した資料ぐらいSlideShare経由でアップしておいたほうがいいかなーと思い直したので、整理します。

講演内容は、Android端末を複数使って、脳波(B3Band使用)と手元のスマホで戦車のラジコンをコントロール(ADK使用)し、的を画像認識(OpenCV使用)してBB弾を発射し、それをシースルー型HMD(BT-100使用)で表示するというものです。

WiFi環境下でXMPPを使って双方向通信することで、拡張可能な形で作っています。

Androidでへっぽこ思考戦車を作ってみた from Yusuke Ohmichi

Androidの熱いトコ

今は無き北海道スマートフォン勉強会向けに作った資料ですが、震災の影響で無期限延期になってしまったので、第8回 Android勉強会 in 札幌で使わせてもらいました。

タイトルとか色々直してないですけどね(汗)

内容は、AndroidってJavaとかC/C++とかJavaScriptの層があって、それぞれ興味を持っている対象が違うよねって話。

Androidの熱いトコ

View more presentations from Yusuke Ohmichi

そろそろAndroid本についてうんちく語っておこうか

勉強会向けに「そろそろAndroid本についてうんちく語っておこうか」という切り口で、自分が所有してるAndroid関係の本をまとめてみました。

勉強会では1時間かけて辛口トークの予定ですが、こちらは一口コメント程度で。

ちなみに、以下の本の購入代金を合計すると、70760円也。これを高いと見るか、安い見るか。まぁ得た価値から鑑みると、本の代金はたいてい安いんですけどね。

濃いAndroid本

古い本だが、未だ超えられない本。特に概念について突っ込んでまとめてある。未だよく見る

"Google Androidプログラミング入門" (江川 崇, 竹端 進, 山田 暁通, 麻野 耕一, 山岡 敏夫, 藤井 大助, 藤田 泰介, 佐野 徹郎)

さすがオライリー・クオリティー(でも自分が持ってるのは初版)

"初めてのAndroid 第3版" (Ed Burnette)

とにかくサポート範囲が広くて、てんこ盛りな本。この本でしか解説してない項目も結構ある。

"入門 Android 2 プログラミング (Programmer’s SELECTION)" (Mark Murphy)

ちょっと古めだけどAndroidの主要な機能や使い方について解説がある本

"コードからわかるAndroidプログラミングのしくみ 開発で困ったときの解決アプローチ" (フランク・アブルソン, チャーリー・コリンズ, ロビ・セン)

一般的な初心者向けのAndroid本

初心者向けに浅く広くを目指した本? 新しめで主要な機能は押さえてる感じ

"初歩からわかるAndroid最新プログラミング" (安生 真, 柴田 文彦, 藤枝 崇史)

内容は悪くない。今でもたまに見る。ただほぼ同じ内容で2.1/3.0対応として出してたり、Androidっぽくない書き方をしてるのは微妙

"Android 1.5プログラミングバイブル" (布留川 英一)

ゲームやUIにこだわる人向けのAndroid本

Android開発の上流工程にフォーカスを当てた本。著者は実績ある方ですし、上を狙うなら考慮しておくべきことがぎっしり

"AndroidアプリUIデザイン＆プログラミング　　アイデア固めからユーザーフィードバック分析まで" (渡嘉敷 守)

SDKについてるサンプルゲームを改造して進化させようというコンセプトの本

"Google Android アプリ開発ガイド" (柳井 政和)

JavaまたはCを使ったOpenGLベースのゲーム実践本

"プロフェッショナルAndroid ゲームプログラミング" (ウラジーミル・シルバ)

持っている者は救われる(ことがある)レシピ系Android本

珍しい和製オライリー本。ひと通り読んでおくと安心。別名ブリリアント本

"Android Hacks　―プロが教えるテクニック & ツール" (株式会社ブリリアントサービス)

レシピの範囲が広くて結構使える。今でもよく見ます

"AndroidSDK開発のレシピ―104個のレシピで学ぶAndroidアプリ開発の極意" (塚田 翔也)

我らが女子部のアイドルが書き上げた結構マニアックなレシピ本。別名やんざむ本。おそらくフレームワークのソースを読んで調べたんだろうな

"Android Layout Cookbook アプリの価値を高める開発テクニック" (あんざい ゆき)

もはや役に立たないと宣言されることに意味があるAndroid本

特に特徴もなく、1.5時代の本なので既に古い

"入門Google Androidプログラミング" (伊原 頌二, 藤枝 崇史, 柴田 文彦)

青本の前身。今こちらを買う理由はない。

"Google Android完全解説 (アスキームック)" (アスキー)

木南さんはいい人なんだけど、もう内容が古い。いわゆる木南本

"Google Androidアプリケーション開発入門 画面作成からデバイス制御まで――基本機能の全容" (木南 英夫)

HT-03Aが発売されたタイミングで出た、初の翻訳本

"初めてのGoogle Androidプログラミング サンプルで学ぶ必須作法と基本手順" (ジェローム・ディマジオ)

SDKに付いてくるサンプルゲームの解説+α

"はじめてのAndroidプログラミング (I・O BOOKS)" (若林 登)

国内で一番最初に出た本?

"Google Android入門 ~携帯電話開発の新技術" (嶋 是一)

ネイティブ狙いではないAndroid本

AndroidでのFlashを扱った唯一の本

"Flashではじめる Androidアプリ開発入門　［Flash Professional CS5.5対応" (古堅 真彦 池田 泰延)

HTMLとJavaでもここまでできる

"Androidアプリケーション開発ガイド ―HTML＋CSS＋JavaScriptによる開発手法" (Jonathan Stark)

タブレットなどでの業務用端末を想定?

"クラウド活用のためのAndroid業務アプリ開発入門" (出村　成和)

組み込み向けAndroid本

唯一にして必見(組み込みやるなら)

"基礎から学ぶ 組み込みAndroid" (坂本 俊之, 出村 成和, 渡邊 昌之)

AndroidするためのJavaのお勉強本

いわゆるJavaっぽい書き方をマスターする

"Effective Java 第2版 (The Java Series)" (Joshua Bloch)

マルチスレッドに自信を持つために

"Java並行処理プログラミング ―その「基盤」と「最新API」を究める―" (Brian Goetz, Joshua Bloch, Doug Lea)

ニュースから読み解くAndroidの過去・現在・未来

第7回Android勉強会での発表資料として、以下のような資料を作ってみました。

といっても、あまり時間をかけれなかったので，リンク集のような感じになっています。

ニュースから読み解くAndroidの過去・現在・未来

View more presentations from Yusuke Ohmichi.

去年のXperiaタッチ＆トライイベント参加者が20人強だったのに比べ、今年のIS01タッチ＆トライイベントでは50人の申し込みがあるなど，やはりAndroidは盛り上がってきてるなぁという印象です。

Android用のバーコードスキャナにBitmapから解析する機能をつけた

Androidにはバーコードスキャナってゆーアプリがあります。

オープンソースなんですがGooglerが作っているようで、Android本体の標準アプリになってもおかしいくないような品質のアプリなんですが，こいつはカメラでバーコードを写して解析するような動作しかサポートしておらず，静止画として既にバーコードなどがファイルとして手元にある場合(ネットからダウンロードしたなど)の時には使えるものではありませんでした。

やりましょう!

で、先日ついったーで「IntentにBitmap込めて送ったら、結果が帰ってくるようなヤツ欲しいなー」とつぶやいてる人がいたので、作ってみました。

と言っても、一晩で作ったものなので，ちゃんと動いているか怪しいですが。いや、実際一部動いてないですが(汗)

欲しい人もたくさん居るっぽいので、とりあえず出来たもののAndroidプロジェクトをそのまま配布します。ライセンスは元のApache licenseを踏襲ということで。

Bitmapから解析する機能を付けたバーコードスキャナのプロジェクト

Bitmapから解析する機能を付けたバーコードスキャナ本体(デバッグキー版)

で、本来はAndroidマーケット上で流れているアプリに取り込まれてくれたほうが楽だと思うので，Google Code上のプロジェクトにパッチを提供しました。テスト用のActivityも付けたので，使い方知りたい方はこちらも御覧ください。

送ったパッチのissueページ

このページの☆を増やしてもらえると、本体に取り込まれるのも早くなるかも!?

たぶんどっかバグってると思うのですが、あまりマジメに直す気はないので、おかしいところを見つけた場合は教えてください。GitHubにでもブランチ作ります。