Intel Edisonのセットアップ
買おうかどうしようか考えていましたが、なぜか手元にあるので、セットアップを備忘録的にまとめておきます。
Intel Edsionとは
IntelがIoT向けに発表した超小型でLinuxが動作するチップセット。購入して動かすには単体購入だけでは面倒なため、どちらかの拡張ボードと一緒に購入することになります。
本体はArduino Unoと比較しても小さいですね。
今回はBreakout Board Kitを入手したので、そのセットアップを書いておきます。Breakout Boad Kitはこんな感じです
起動
2つのマイクロUSBケーブルを用意します。１本は電源取得用。もう１本はいわゆるデバッグシリアル用です。
デバッグシリアルはFTDIドライバが入っていれば認識します。Macのscreenコマンドでボーレートを115200に設定しておき、電源をつなぐとしばらくすると起動ログが流れます。
そしてログイン画面（デバイス名をすでに変えているのでedison0となっています） LinuxのディストリビューションはYocto Projectです
初期ログインは"root" パスワードはありません。
ファームウェアのアップデート
購入直後（2014/10/28）時点のファームでは、文字入力時に最初の１文字を取りこぼすなど、不安定なのでまずはファームウェアを書き換えて最新にします。
バーションは以下のコマンドで確認できます
# cat /etc/version edison-rel1-maint-weekly_build_16_2014-10-14_14-56-19 <-- 書き換え後なので現時点の最新
Macでの書き換えはこのページに記述がありますが、以下に手順を
Edisonの電源をUSBケーブルでMacから取っていれば、Mac上にEdisonというUSBメモリがあるはずです。まずはその中味を全て削除しておきます。Mac上で
※削除コマンドは気をつけて下さい
$ cd /Volumes/Edison $ rm -rf * $ rm –rf \.*
ファームウェアはIntelの公式ページの最新版「Edison Yocto complete image」をダウンロードしてきます。てっきりイメージファイルかと思ったら、そうではありません。zipファイルを展開して、マウントされているEdisonのUSBメモリに展開されたファイルを全てコピーします。
今度はEdison上から、以下のコマンドでリブートさせつつ書き換えを行います
# reboot ota
自分の場合、2回リブートしたような気がしましたが、ファームウェアの更新が成功すれば、ログイン状態になります。書き換えが成功したかどうかは
# cat /etc/version
で確認しましょう。
セットアップ
最新の状態にしたら、Edisonの初期セットアップを行っておきます。設定項目は以下になります。
- Edisonのデバイス名を設定
- rootログインのパスワード設定
- WiFiの設定
セットアップ用のスクリプトが用意されているので、それを使います
# configure_edison --setup
以下設定画面(CUI)はこんな感じ
Configure Edison: Device Name Give this Edison a unique name. This will be used for the access point SSID and mDNS address. Make it at least five characters long (leave empty to skip): ----- Configure Edison: Device Password Enter a new password (leave empty to abort) This will be used to connect to the access point and login to the device. Password: *********** Please enter the password again: *********** ----- Configure Edison: WiFi Connection Scanning: 1 seconds leftt 0 : Rescan for networks 1 : Manually input a hidden SSID 2 : hogehoge 3 : fugafuga Enter 0 to rescan for networks. Enter 1 to input a hidden network SSID. Enter a number between 2 to 15 to choose one of the listed network SSIDs:
全ての設定が終了すると以下のメッセージが出ますので、まずはifonfigを叩いてIPアドレスが付与されているのを確認しておきましょう。
Initiating connection to honypod. Please wait... Attempting to enable network access, please check 'wpa_cli status' after a minute to confirm. Done. Please connect your laptop or PC to the same network as this device and go to http://192.168.**.** or http://edison0.local in your browser. root@edison0:~#
メッセージにもありますが、どうやら自動的にhttpサーバーが起動するようなのでアクセスしてみます。
設定したデバイス名とIPアドレスが表示されます
※どこかでSSHを有効にするかどうか聞かれたような気がするけど、覚えてない....
参考ページ
たった１日で出来たWeb + Android + Arduinoのリアルタイム連携プロトタイピング
はじめに
今回のネタは、早稲田大学で行われているAndroidアプリ開発養成講座TechInstituteで、センサー回りの講座を受け持つことになり、Androidのセンサーを使った応用例として作成しました。
動作概要
Android
動作としては某L◯NEの「ふるふる」っぽい動作をAndroidでは行います。「加速度センサー」で、ある一定の加速度を超えたら、「GPSセンサー」で位置情報をサーバに送信します。Webサーバでは送信された位置情報をGoogleMapにマッピングします。
Arduino
Arduinoには何かセンサーを接続します。なんでもいいのですが、「照度センサー」とします。照度センサーにより、周囲が暗くなったらサーバに「暗くなった」ことを通知します。
Web
Webサーバは送られてきた位置情報のマッピングを行います。またブローカサーバがArduinoからのセンサー情報を、接続している全Android端末にPush配信を行います。
構成
ざっくりこんな感じです。
もうちょっと詳しく書くと
Androidアプリから、位置情報をMQTTプロトコルでブローカにpublishすることで、subscribeしているWebサーバがそれを受信して、GoogleMap上にマッピングします。Arduinoから「暗くなった」とブローカにpublishすると、Androidアプリでは事前にそのTopicをsubscribeしているようにしてあるので、Pushが飛んできます。※MQTTについてはこちらを参照
使っている技術は難しくありません。
- Androidアプリ：加速度センサー、GPSセンサー、MQTTクライアント
- Arduino：照度センサー、MQTTクライアント
- MQTTブローカサーバ：mosquitto
- Webサーバ：Node.js + WebSocket(Socket.IO) + MQTTライブラリ
それぞれの画面
Androidアプリ
スクリーンネームを入れて、スタートボタンを押して「振る」単純なアプリです。加速度センサーをチェックして、振れ幅が大きくなったら位置情報を送信します。
Arduino
UIは無いです。Cdsセルで周囲の照度を測定して、一定値以下になったら「暗くなった」と通知します。
AndroidにはPushで通知が飛んできます。
Web
Node.jsでWebSocketを使用して、送信された位置情報とスクリーンネームをマッピングします。
作成の流れ
- Androidのセンサー応用例のデモを作ろう
- ふるふるっぽいのなら、加速度センサーとGPSセンサーでできそうだな（ここまで前日案）
- 位置情報を表示するMapが欲しいな。んじゃMQTTを使ってNode.jsで受けるか
- MQTTブローカサーバ立てる
- PyhtonでMQTTのPubSubのサンプルを作成して動作を確認
- Node.js + Socket.IOでGoogleMap表示部作成
- MQTTライブラリをNode.jsに組み込んで、ブローカをSubscribeするようにする
- PythonでMQTTのサンプルのPublishを作成して、ダミーの位置情報をブローカに送信するとNode.js上のGoogleMap上にマッピングできることを確認
- Androidアプリで加速度センサーとGPSを組み合わせてアプリを作る
- MQTTライブラリを送信用に組み込んで、8で作成したtopicフォーマットに沿って送信するようにする
- Andoridアプリをふるふるすると、無事GoogleMapに表示できた＼(^o^)／
- Arduinoも講義で扱うし、ArduinoにもMQTTクライアントがあるからこれも繋げてみよう
- 題材で使用する照度センサーとArduino Ethernetを組み合わせてMQTTでブローカに投げるようにする
- Androidアプリの方にArduinoの通知を受け取れるように、MQTTブローカへのSubscribeを追加
- ほぼ完成＼(^o^)／
ここまででほぼ１日８時間くらいの作業という感じでした（途中買い物行ったりしてので、出来たのは夜中近く）
参考情報（Topicの扱い）
-
- subscribe "PUBLIC/location/port/all/#"
- publish "PUBLIC/location/state/hogefuga" ← hogefugaはスクリーンネームが入る
Node.js
- subscribe "PUBLIC/location/state/#"
-
- publish "PUBLIC/location/port/all/push"
※ArduinoのあたりのTopicの扱いが変だけど、最後取ってつけた関係上...
まとめ
ここに出てくる技術はひと通り経験したことがあるので、アイデアが出れば実装はさほど難しくありません。 だいたい１日の作業でこのくらいまでプロトタイピング実装できるんだなーと、あらためて今の技術の恩恵を感じました。逆に言えば、技術よりもアイデアの方が重要なのかも（こっちのが難しい）
さて、実装してみると色々展開できることが見えてきます。
MQTTなので上手くTopicのPublish/Subscribeのルールを決めてやることで
他にも
- ボタンでの通知を時間間隔での通知にして、ジオフェンスを使った遊びや監視？
- Arduino側をウェアラブルデバイスとしてアイデアを膨らますこともできそうです
- Arduino側を様々な家電に置き換えて考えると、コントローラ＆通知システム作れますね
ソースコードは公開してもいいのですが、なんせ１日で作ったレベルなのでちょっと...
要望があれば整理して公開できるようにするかもしれません。
台湾に行ってきました（Computex Taipeiとかもろもろ）
休暇を利用して、台湾へComputex Taipeiの見学およびリサーチをしてきました
Computex Taipei
- ESECやETよりも人は少ないように見える。日程の前半は海外在住者のみ入場可（入場口で揉める某台湾人）
- 規模は東京ビッグサイトの東館全体の3倍くらい（南港の方が人は多い気がする）
- 見て回るだけなら、１日半あればとりあえず回れる。期間中はパスがMRT乗り放題のカードになる
- 出展内容は玉石混交、かつアイテムによって整理されていないので、重要なのがどこにあるか把握困難
- PCメーカのメインは南港展覧館にあり、Intel, acer, ASUSなどがPCを中心に展示している（IntelのReal Senseを使って触れないで操作するデモだけど、そんな大きなモニタキッチンにｒｙ）
- 部品としては、ケーブル・電源・キーボード・マウス・スピーカ・スマホアクセサリがほとんどで、どれも同じような物が多い
- スマートフォンは、深センのメーカを中心にいくつかがODMの生産を受け付けている感じ。CPUはMediaTekが多い
- 台湾ではLTEは始まっていないが、4GLTEを謳ったスマートフォンがちらほら
- スマートウォッチ系もたくさん出ていた。しかし中身は「万歩計」付き「時計」というのがほとんど...（これはE-inkのタッチパネル）
- 「Android Wear」と大々的に書いてあるブースに行ったら、完全なコールドモックだったよ／(^o^)＼
- ハードウェアばかりで、ソフトウェア系はほぼ皆無（当たり前だけど）
- 展示側からすると、MOQいくつでいくらで買う？くらいの商売しか考えていないような感じ
- ドラレコがかなり出ていた。HUDもチラホラ。GoProのパクリのような物も。自動車関連製品の安いのはここから輸入されるような感じがする。実際、台北のタクシーはほぼ100%ドラレコが付いている。光華商場でもドラレコはかなり売られていた（バックミラーの下に付いてるのがドラレコ）
- ITRIのGoogle Glassのようなもの。3Dプリンタとボンドで作られたワンオフものらしいw（本人談）
まとめ
方向性や情報収集が目的なら数年に１度行けば十分かと。自分たちの戦略があって、何が足りないか探しに行くにはいいかもしれない。 がっつり商談するか、現地にコネがあって、いくつか会社をハシゴするのが現地周り的にはヨサゲ
マスプロダクトなハードウェアは台湾や中国から日本に入ってくるけど、今のkickstarterのような新しいニッチなハードウェアは中華圏からではなく、むしろ先進国から産まれてくるということを認識できた。マスなハードウェアは箱でしか無く、これからのハードウェアはネットワークとの連携でむしろソフトウェアが重要視されるため、今までの流れが変わりつつあるように思える
台北市内
収入格差が大きくなっている感じ。昔よりも高級車が増えた。台北市内の土地が高騰していて、軒並み億の値段が付いているとのこと。実際、天母の建築中のマンションは10億らしい。あまりに高いのでむしろ東京の土地を買いに行く台湾人もいるとか。この土地の高騰はバブルっぽい感じがする。一般の人が普通に投資してる。中国の資金が流れ込んでるのか、中国の経済崩壊が起きたら巻き込まれる可能性がありそう（証券会社に集まる人々。取り付け騒ぎかとオモタ）
- 台北駅の少し南の風景、だいたいこんな感じ
- 老若男女みんなスマートフォン、老齢になると大画面のを使っている。みんなそれで写真撮ってますが使いこなしているのか？
- iPhoneは見たところ10% 〜 15%程度、ほとんどがAndroid端末
- バスこんなに走ってたかな...高速道路でも一般道でもトラックはあまり多くない
- 暑いからか、ショートパンツの女性が多い
- 鼎泰豊あいかわらず美味しいです
- ハローキティがあるゆる場所で仕事してる
- ユニクロは日本のほうが安いw
- LINEユーザ多い、そこら中でピコピコ音がしてた
- 光華商場はそれほど安くない
- ヤマト運輸が制服とかも日本とほとんど同じっぽい感じだった
- 足裏マッサージは痛くなかった。足裏＋脹脛で50分2000円くらい
- 教室は円形に並べられてた。これは最前列ツライw
新竹 ITRI
今回、某台湾人の計らいで新竹にあるITRIに行ってきました。日本で言うところの産総研と言った感じ。台北のFabLabとかとリンクしないのかなーとか思ったりしたけど、台北からバスで１時間と離れているので難しそう。
- 中でやってるのを少し見せてもらいましたが、ソフト・ハードともにやってる模様
- 災害時にスマホから写真を撮って、投稿するとマップに表示されるシステムとか作ってました。たぶんこれ。これってセカイカメｒｙ
- その他独自アーキテクチャCPUとか、UI/UX研究とか
- 中の人たちは箔付けのために転職してくることが多く、早ければ数ヶ月で大手メーカへ転職してしまうらしい
観光地
前回台湾に行った時に、故宮などの有名どころはひと通りいったので、今回はちょっと違うところへ行ってきました。車で回ったのでだいぶ楽でしたが普通だとかなり面倒な場所かもしれません。観光地は中国人と韓国人がバスツアーで回っているらしくかなり多いです。日本人は最近は個人ツアーなのかもしれません。そういえば彼らはみんな高いデジタル一眼を持っているのですが、日本で流行りのミラーレス一眼ではなかったですね。なんででしょう
- 野柳地質公園は奇岩の公園。かなり観光地として人の手が入ってしまっていて微妙...
- 平溪線はノスタルジックな感じで良い。鉄道好きならなお楽しめる。今回は車で行ったけど、電車の方が楽しそう
- 十分瀑布は台湾のナイアガラらしいです。日本のナイアガラの吹割の滝よりはマシです(^^;
歩いて行く隣には平溪線が走っている
まとめのようなもの
たまーに海外行くと、色々現地の事情とか見られてやっぱりいいですね。今回は現地で某ニセ台湾人に案内してもらったり、たまたま現地にいた某スマートグラス関係者と情報交換したりできました。何年か前に台湾に行ったこともあって、時間の流れとかトレンドの移り変わりも見えてました。Computex Taipeiとかのキッカケが無いとなかなか行けないので、ちょうど良い機会でした。次は何年後に行こうかなー
ArduinoのWiFiシールド(CC3000)でWiFiのセットアップ
ArduinoでWiFiが使える、かつTELEC取得済みのCC3000 WiFiシールドを入手したので、セットアップしてみました。
まずはハンダ付け
スイッチサイエンスから購入したのですが、ブツがビニールに入ってるだけで特に説明書らしきものはありません。Arduinoシールドとはいえ、ピンソケットも付属していないので、一緒にピンソケットも購入しておいたほうがいいでしょう。
このようなWiFiシールドだとさらに重ねる可能性があるので、ピンソケットをこのようにハンダ付けしておきます。なおこのシールドはSPIを使用していますので、重ねる場合は注意して下さい。
WiFiのセットアップ
WiFiのセットアップはsparkfunのページのCC3000 Hookup Guideを見ながら行えば問題ありません。
CC3000のライブラリのダウンロード
ライブラリのコードはGithubにありますが、リポジトリのmasterをココからzipファイルで落としてきて展開した方が楽です。落として展開したフォルダを「SFE_CC3000_Library-master」→「SFE_CC3000_Library」のようにちょっと修正して、ライブラリフォルダの中に放り込みます。Macだと~/Documents/Arduino/librariesになると思います。
WebClientで動作確認
ライブラリにファイルを置いたら、ArduinoIDEを起動します。動作確認はArduino Uno R3で行いました。
ファイル→スケッチの例→SFE_CC3000_Library→WebClientでサンプルスケッチをオープンします（※Macの場合）
// Constants char ap_ssid[] = "SSID"; // SSID of network char ap_password[] = "PASSWORD"; // Password of network unsigned int ap_security = WLAN_SEC_WPA2; // Security of network unsigned int timeout = 30000; // Milliseconds char server[] = "www.example.com"; // Remote host site
SSIDとPASSWORDの部分を、接続したいSSID名とパスワードに変更するだけです。serverは接続確認を行う先のURLです。このスケッチは起動時にクライアントのIPアドレスを設定して、"http://www.example.com/index.html"をGETで取ってくるようになっています。書き換えたらArduinoに書き込みます。書き込みが終ったらシリアルモニタを起動します。この時通信速度は115200に設定します。
正常にIPアドレスを取得し、www.example.comからデータを取得できると下記のようにGETで取得したログが流れます。
このスケッチをベースにスケッチを書けば通常のEthernetと同じように使えるようになります。
SmartConfigを使ったセットアップ
このCC3000のウリは、スマートフォンでSSIDとパスワードを設定できることのようなので、そちらも試してみます。
ファイル→スケッチの例→SFE_CC3000_Library→SmartConfigでサンプルスケッチをオープンします（※Macの場合）
ここでスマートフォンアプリを用意しておきます。iOS版とAndroid版があるのですが、iOS版はiTunesからダウンロードできるのに対し、Android版はなぜかTIにアカウントを登録してapkを自分でインストールする必要があります。今回はapkインストールするのが面倒だったので、iOS版でセットアップしましたが基本的には同じようです。
- SSID : 接続するアクセスポイント
- Password : パスワード
- Key : オプションなので特に設定する必要はありません
ここまで設定を入力したら、Aeduinoにスケッチを書き込んでシリアルモニタを起動します。Arduinoが起動すると"Starting SmartConfig"とメッセージが出たら、スマートフォンの"start"ボタンをタップします。成功すると、下記のようにsparkfunのサイトにpingを打って動作確認してくれます。
うまく設定ができない（Arduinoがタイムアウトする）と下記のようになります。スマートフォンのアプリの"start"のタイミングに気をつけてください
FastConnect
SmartConfigでの設定は、毎回起動時にSSIDの設定しなければならず面倒ですが、実は一度SmartConfigでSSIDとパスワードを設定しておけば、CC3000内部に記憶されるので、このFastConnetが利用できるようになります。（電源を外しても記憶しているようなので、内部Flashに記憶しているのかな）
ファイル→スケッチの例→SFE_CC3000_Library→FastConnetでサンプルスケッチをオープンします（※Macの場合）
SmartConfigで設定済みなら、何の問題もなく下記のように動作するはずです。
このSmartConfigは結構便利ですね。
netatmo ウェザーステーションを買ってAPIを叩いてみる
netatmo ウェザーステーションとは
その名の通り気象情報をセンサーで取得するデバイスです。基本構成は2つのセンサーデバイスで、大きいほうが室内用、小さいほうが屋外用となっています。電源は室内用はUSBから、屋外用は単４電池2本で駆動します。それぞれのセンサーから取得できるデータは以下になります。屋外用のセンサーというのは実はありそうで無いので、ベランダなどに設置しておくと今の屋外気温が取得できるので面白いです。
室内用
- 気温
- 湿度
- 気圧
- CO2
- 騒音
屋外用
- 気温
- 湿度
これを設置してユーザ登録してログインすると、PCではこんな画面でデータを見ることができます。
※地図の部分はボカしています
ちなみに、全世界の今の気温もGoogleMap上でみることができます。クリック
また、iPhoneアプリ、Androidアプリもあります。Androidではウィジェットに設定できるのでこれは便利！です。
IFTTTと連携
このデータを元にIFTTTを使って連携しようと考えました。例えばこんな感じのレシピを作れます。
これは「湿度が10%を切ったら、Tweetする」ということになります。とはいえ、本当にやりたかったのは「毎朝8時に、今の屋外の気温をTweetする」のようなことがしたかったのでこれはイマイチです。IFTTTではnetatmoウェザーステーションはトリガーにしか使えない、かつこの場合、３つの事象が含まれるのでIFTTTでは実現できません。
netatmoのAPIを利用
というわけで、netatmo APIを利用して作ることにしました。ここにアクセスして、「MY APPLICATIONS」を登録することでAPIを叩くことができるようになります。
APIの取得の仕方等はNetatmo ウェザーステーションを買ってみたので Node.js でいじってみたを参照して下さい。
今回はVPSを使わず、手元にあったRaspberry Piを使用して、下記のような構成を作ってみました。
- Raspberry Pi + Ubuntuを使用
- netatmo-api-pythonを使ってPythonスクリプトを作成
- TwitterのOAuthはrequests_oauthlibを使用
- cronを設定して毎朝8時にPythonスクリプトを実行し、最新データを取得してTwitterに投稿する
- 屋外は「温度」「湿度」のみが取得しかできないので、ここにある不快指数の計算式を使って、不快指数を同時にTweetしています
結果
気温: 19℃ 湿度: 68% 不快指数: 65 @さいたま 2014-05-02/07:59 #netatmo
— 繋がれたひよこ (@tomo_watanabe) 2014, 5月 1これはこれで簡単にできるので、もう少し色々連携させたくなってきました＼(^o^)／ Raspberry Pi上でMQTTのブローカーを導入して、周辺デバイスと連携とか
【日本正規代理店品・保証付】Netatmo ウェザーステーション NET-OT-000001
- 出版社/メーカー: Netatmo
- 発売日: 2013/10/10
- メディア: エレクトロニクス
- この商品を含むブログ (1件) を見る
Mosquitto(MQTT)を動かしてみた
MQTTとは
MQTT(MQ Telemetry Transport : MQはMessage Queuing?)というプロトコルで、TCP/IP層で動作するWebSocketっぽいもの（ザックリ）。詳しくはそこはかとなく書くよん。を見てもらった方が分かりやすいです。簡単に言えば、M2Mでの使用を考えた軽量なメッセージプロトコルという感じです。Mosquittoはブローカの実装で使用します。
2013年のカンファレンスでは、2011年当時の「Beluga」（現Facebook Messenger）に使われているという発表があったようです
MQTTのブローカとクライアントの動作確認の構成
今回下記のような構成でMQTTの動作確認を行いました。
Mosquittoにsub.pyで接続し、pub.pyによってpublishされるとsub.py側に出力されることを確認します。
Mosquitto（ブローカ）のインストール
パッケージからインストール
Ubuntuでは基本的にはパッケージインストールができるので
$ sudo apt-get install mosquitto
以上でインストールと起動まで完了します。停止・再起動はserviceコマンドで行えます。
ソースからコンパイルする場合
開発環境のインストール
$ sudo apt-get install gcc make g++ libssl-dev libc-ares-dev
Mosquittoのダウンロードページからソースを落として展開し、makeしてインストールします。
$ wget http://mosquitto.org/files/source/mosquitto-1.3.1.tar.gz $ tar -xvzf http://mosquitto.org/files/source/mosquitto-1.3.1.tar.gz $ cd mosquitto-1.3.1 $ make $ sudo make install
環境設定ファイルを設定します。
$ sudo cp /etc/mosquitto/mosquitto.conf.example /etc/mosquitto/mosquitto.conf
デフォルトでMQTTは1883ポートを使用します。必要に応じてサーバのポートを開放します。
起動します。
※引数なしの起動方法では前述のconfファイルは使われず、デフォルトで起動します。-cオプションでファイルを指定する必要がありますが、何も修正していなければ動作はデフォルトとなります。
$ mosquitto 1397719018: mosquitto version 1.3.1 (build date 2014-04-17 15:13:13+0900) starting 1397719018: Using default config. 1397719018: Opening ipv4 listen socket on port 1883. 1397719018: Opening ipv6 listen socket on port 1883.
この場合、サーバがIPv4/6両対応なので、ポートそれぞれでリッスンしている状態になります。
PahoクライアントでPub/Subを実行する
Pahoの下の方に各言語用のダウンロードリンクがありますので、そこからcloneしてきて利用するのがいいのと思います。今回はPythonクライアントのexampleを少し修正してsub.pyとpub.pyを作成しました。
paho MQTT pythonライブラリのインストール
$ sudo pip install paho-mqtt
sub.pyの実行
詳しい解説は後回しにしてまずは実行してみましょう。まずは待ち受けのsub.pyを実行しておきます。
コードはsub.pyにあります。
起動して、ブローカサーバに接続するとこのようなメッセージになります。
$ python sub.py rc: 0 Subscribed: 1 (0,)
ブローカサーバへの接続が失敗した場合こんなメッセージが出ます。
Traceback (most recent call last):
File "sub.py", line 60, in <module>
mqttc.connect("HOST", 1883, 60)
File "/Library/Python/2.7/site-packages/paho/mqtt/client.py", line 588, in connect
return self.reconnect()
File "/Library/Python/2.7/site-packages/paho/mqtt/client.py", line 710, in reconnect
self._sock = socket.create_connection((self._host, self._port), source_address=(self._bind_address, 0))
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 571, in create_connection
raise err
socket.error: [Errno 61] Connection refused
接続に成功していればブローカサーバ(Mosquitto)の方では以下のようなメッセージが表示されているはずです
1397719236: New connection from 2001:3e0:0:*:*:*:*on port 1883. 1397719236: New client connected from 2001:3e0:0:*:*:*:* as paho/E917914937EA634F0F (c1, k60).
一部"*"でマスクしています。
pub.pyの実行
次にpub.pyを実行して、メッセージを送信します。
コードはpub.pyにあります。
コンソールをもう一つ開いてpub.pyを実行すると直ぐに終了します。
$ python pub.py 1
sub.pyの出力の方を見てみると、１行メッセージが追加されていると思います。
rc: 0 Subscribed: 1 (0,) message 0 Hello MQTT!
pub.pyを実行することにより、subscribeしていたsub.pyの方にメッセージ送信が行われたことがわかります。
解説
sub.pyの方から見ていきます。（以下抜粋）
# メッセージを受信した時に呼ばれる。
def on_message(mqttc, obj, msg):
print(msg.topic+" "+str(msg.qos)+" "+str(msg.payload))
# 接続先のブローカを設定する
mqttc.connect("HOST NAME", 1883, 60)
# "message"というtopicをsubscribeする
mqttc.subscribe("message", 0)
sub.pyは起動すると"message"というtopicが来るまで待機状態になります。pub.pyを実行して。メッセージを受信すると、topicとqosとpayloadを表示します。今の場合は
- topic : message
- qos: 0
- payload : Hello MQTT!
pub.pyの方はこれだけですね。
publish.single("message", "Hello MQTT!", hostname="HOST NAME")
"message"というtopicに"Hello MQTT!"を送信しています。qosは省略されていますが、デフォルトが0になっています。今回は簡単にするためにtopcを"message"としましたが、これを"$SYS/#"のようにワイルドカードで指定したり、"paho/test/single"のようにすることもできます。この指定の仕方はMQTTの仕様のようで、これを利用して各々のM2M機器がsubscribeする対象を設定できるようになっています。
まとめ
MQTTを実動作させるテストを行いました。MQTTの実装はLinuxやMacだけでなく、mbedやArduino、Androidなどにもありますし、様々な言語での実装もあります。またNode.jsでWebSocketと組み合わせてブラウザへの出力もできます（この辺は後日）僕はこのM2M用途としてのMQTTはよく知らなかったのですが、実際使用してみると結構いろいろなことが出来そうな気がします。プロトコルはシンプルだし、QoSの概念が導入されているのも面白い点です。
スキーとGoProとウェアラブルの関係を考える
初めての趣味でのエントリになります。
今シーズンは週末に冬山に行くことが多いです。スタッドレス買ったので勿体無いというのもありますが。一昨年にGoPro Hero2(今はHero3)を買ってからスキーの時に持参して撮影をしてみたりしてるので公開してみようと思います。
GoProのアタッチメントはヘッドストラップでこんな感じ
まずは動画を公開。場所はオグナほたかスキー場のゲレンデトップから第６ペアリフト沿いのコースを滑ってます。１本目は割りとゆっくりめでウェーデルンで速度を調整しています。２本目は同じ小回りですが、こちらはずらさずカービングターンでスピードを殺さずに滑っています。違いがわかるでしょうか？
ウェーデルンで滑走
カービングで滑走
撮影した斜面を下から見るとこんな感じ。最大斜度は約20度ちょっとくらい
GoProとは
GoProは今は「アクションカメラ」というジャンルを確立した「デジタルカメラの派生」で、JVC・ケンウッドやソニーが対抗機種を投入して盛り上がっています。GoProの成功に関してはこちらの記事アクション・カメラの代名詞「GoPro」誕生秘話が創業者へのインタビュー映像で明らかに
個人的にGoProの登場時に凄いなと思ったのは
- LCDレスなどの従来のデジカメにあった機能レスの割り切り
- 広角でかつ、映像自体がかなり綺麗に取れる
- 天候に左右されないレンズ性能とハレーションの少なさ（逆光でも白飛びしない）
- 各シーンに合わせたアタッチメント
購入してから性能的には満足していますが、一方でいくつか不満点もあります（ただしHero2に限る）
- 電池持ちが悪い。8GBのSD差しても意味ない...(´・ω:;.:...
- ボタンの反応がわかりづらい。音がするものの、もうちょっとなんとかならんの・・・
- 手ぶれ補正が欲しい（スキー動画揺れすぎ）
ウェアラブルデバイス
自分が思うにGoProは「ウェアラブルデバイス」です。スポーツという制限化の中で、身に付けることによって従来撮れなかった映像を撮れるのです。スキーの場合は両手が塞がっているので、こういう場合に非常に便利です。
ウェアラブルに必要な要素として
- 必然性
- ファッション性
だと思いますが、GoProは「スポーツという制限化での必然性」があります。この例はGoogle Glassが遠隔手術に使われたり（Google Glassで手術をライブ中継、教育効果に期待：米大学病院）、Kinectが手術の病巣カルテをジェスチャーで操作する（Opect）どちらも必然性があって、制限化での活用が非常に有効です。またどちらも一般の人にとっての日常ではなく、非日常な利用です（Google Glassの発表の時は飛行機からパラシュートで飛び降りてくるというアクションカメラ的デモであって、実はなんの日常的な必然性は無い...）
一方で我々がウェアラブルとして身につけているものは
- 眼鏡
- 腕時計
- 指輪・ネックレス
- 帽子・手袋
どれも今は必然性よりもファッション性が重要視されている製品です。眼鏡は目が悪い人にとっては必然ですが、ファッション性が重視されてますし、腕時計は昔は正確な時間を知ると言う意味で必然性がありましたが、今はファッション性の方が高いですね。指輪は元来、魔除けや魔力を身につけるといった必然性から生まれたもののようです。帽子・手袋は防寒の必然性もありますがファッション性もあります。
ウェアラブルデバイス百花繚乱の昨今ですが、ウェアラブルは「必然性」ありき、後「ファッション化」するのものではないのでしょうか？今のところ「日常の必然性」を具現化したウェアラブルデバイスは難しいのでは？と考えています。自分としては「非日常シーンでの必然性」を具現化した「面白いウェアラブルデバイス」が出てくることを期待しています。
