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

秋月のネットで赤外線投光機キットを見つけて、勢いで車載用赤外線暗視装置(ドライブレコーダーを兼ねたもの)として作ってみたんだけど、同居しようと思っていたラズパイ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

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