たった１日で出来た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側を様々な家電に置き換えて考えると、コントローラ＆通知システム作れますね
ソースコードは公開してもいいのですが、なんせ１日で作ったレベルなのでちょっと...
要望があれば整理して公開できるようにするかもしれません。
Socket.IO for Android（nginx1.3.13リバースプロキシ対応版）
前回のエントリでnginx(1.3.13)でWebSocketをリバースプロキシしてみたのですが、それでは以前作成したSocket.IO for Androidのサンプルがリバースプロキシを通りませんでした。うーんと(´ε｀；)悩んでいた所、 @gtk2kさんに情報を頂きましたのでコードを修正しました。
@tomo_watanabe お疲れのところ申し訳ないけど、一応nginxプロキシ経由で接続できるようになりました。説明が長いためブログで qiita.com/items/15379fe0… twitter.com/gtk2k/status/3…
— gtk2kさん (@gtk2k) 2013年3月3日修正内容
@gtk2k さんが投稿されたnginx(1.3.13) のリバースプロキシでNode.jsとSocket.IO for Android(weberknecht)をつないでみるのまんまですので、詳細はそちらに譲ります。（細かい違いは"Upgrade"を大文字小文字関係なく比較するようにしています）ただweberknechtの修正が必要になったため、jarライブラリからソースとして取り込むように修正しています。 それと、起動時に入力するIPアドレスはポート番号も含めた形で渡すように修正しました（リバースプロキシを利用すると80になるため）
コード
Android-SocketIO(github)を参照して下さい
MAKERSとかAndroidとか
Android Advent Calendar 2012 17日目(12/17)の表担当@tomo_watanabeです。
17日目裏の担当は@Toro_kunさんです。
MAKERSとかAndroidとか
今回は最近話題になっているMAKERSとかAndroidとかを考えてみようと思います。
Androidってどんな位置付けだっけ？
ってことで独断と偏見で下記のように置いてみました。仲間違いが居ても気にしないように。
Androidが出たときは、モバイルとしてはiPhoneとWindowsCE(当時)くらいしかありませんでしたが、昨年辺りからFireFoxOSやTizenといった新しいモバイル技術がHTML5を後ろ盾に来年あたり注目を浴びそうな気配がします。こういった新しいモバイルはiPhoneとAndroidから始まり、今後も楽しみな分野です。
さてこうなってくると、縦軸を整理してサービスやプロダクトを開発するという動きが出てくることになります。今はままだiPhoneやAndroidのアプリやWebアプリが中心ですが、Webとデバイスを繋げるようなプロダクトが今後多く出てくると予想されます。
Androidを取り巻く環境の変化
最近話題になっている「MAKERS」では、自分で欲しいものは自分で作る的な流れから、グローバルニッチな製造業の出現を予想しています。この流れはおおよそ合ってると思いますが、それが直ぐに来るのか？あるいは5年後になるのか？という感じでしょう。方向としては新しい製造業が生まれる機運があるとしたときに、Androidをやるメリットがあるのか？先日行われたMaker Faire Tokyoを見てきた感じでは、数年前はMacを使ったプロトタイプが多かったのが、ここ最近は電子工作そのもので、よりプロダクトに近いもの。Arduinoを使ったプロトタイプっぽい展示が多くなってきた気がしました。個人的にはMacを使っていた部分がAndroidに置き換わって行くのではないかと考えていたのですが、ここへきてプロトタイプはマイコンで、製品は電子工作で行うという流れになっているように感じました。
MAKERSとAndroidと
では将来的に見てAndroidをやる意義はあるのでしょうか？ちょっと乱暴な図を作ってみました。
Webとモバイルとデバイス。これらをプロトタイピングするには、iPhoneやAndroidの技術は欠かせません。ハードはArduinoを使えばプロトタイプ作成などは十分可能です（プロタイプ軸）ただし今後注目されそうな分野、HTML5や自分で造るデバイスなどをやるとすると、電子工作・回路のレベルでの技術が必要になってきます（MAKERS軸）いずれにしてもモバイル技術はこれからも中核になる技術として必要であり、AndroidやiPhoneのアプリが作れるというのは必須技術になってきています。その上で、HTML5やハードを学ぶという...いや結構大変な気がしますが、これらの分野のうち2つについてはある程度のスペシャリストとして技術を身につけることが重要になってきます。
それでもAndroidをやる理由
ハードを勉強しようとすると電子回路に手を出すことになります。AndroidではADKという拡張機能を使ってArduinoと連携することがかなり容易にできるようになっています。ハード寄りの人はAndroid + Arduinoで何か作って、クラウドと連携を行うという課題を立てればWebとの連携を勉強できます。Androidを学習することはこのように周辺技術を上手く取り込み学習することができるメリットがあります。
まとめ（オチ）
デバイスの連携としては実は現状ではiPhoneの方が面白くなりそうだったりします。Bluetooth4.0(Bluetooth Low Engergy)にiPhone4Sから対応しており、対応ハードもチラホラ出て来ています。Arduino対応のシールドも出てきそうですし、今後はBLE対応が注目です。BLEやりたい人はiPhone4S以降を買いましょう（あれ？
"Google Android"はGoogleの管理下で、彼らの市場はグローバルマスであり、グローバルニッチではありません。そのためGoogle Androidをそのまま使うことは難しく、今後AOSPを使うのか？他の選択肢があるのか？というのが課題になりそうです。
個人的に、来年はGoogle本社に行ってグーメン（元記事なぜか削除されてる( ﾟдﾟ)）してきた村上総裁が「Androidもうええねん」という本を出版して
総裁「諸君らが愛してくれたAndroidは死んだ、何故だ！」 はまっつ「坊やだからさ・・・」
というやりとりが行われるとワクテカして、今年を締めくくりたいと思います。
グーメン
【書評】Android×Arduinoでつくるクラウド連携デバイス
インプレスジャパンさんから献本を頂いたので、内容の紹介と感想を
著者は @itog こと伊藤元氏
対象読者
以下の各要素を基本的な所から説明しています。
一方でサーバ側（クラウド）の方は省略されている感じなので、想定読者としては、サーバサイドの知識をある程度知っていて、デバイスにも手を出してみたい人向けといったところでしょうか。個人的には以下のような方におすすめします
- メーカの研究開発部門でプロトタイピングをしてみたい人
- すでにクラウドとAndroidのアプリを書いてて、デバイスを繋げてみたい人
内容の紹介と感想
この本ではデバイスをクラウドと接続してIoTらしいサービスがプロトタイピングできることを説明しています。その手段としてAndroid×Arduinoを使っています。プロトタイピングから製品化へ、実際の製品ではAndroidもArduinoも使わない可能性は高いです。しかし今この時代、性能ではなく体験が重要になっています。体験はこういったプロトタイピングで確認できるということを、この本を通して学べると思います。
前半はAndroid Open Accessory(AOA)とその周辺の紹介です。このAOAはGoogleIO2011で発表されましたが、個人的には思ったより広まっていないな。という感じです。一部のMakerな人とAndroid界隈の人たちがチラホラ。
さてArduinoというデバイスをAOAでは利用するのですが、この本だけでArduinoを勉強するのはちょっと厳しいかもしれません。Arduinoについてまずは弄ってみようと言う方は「Arduinoをはじめよう 第2版 (Make:PROJECTS)」とArduinoをはじめようキットから始めるといいかもしれません。キットの方はArduino Unoで、この本に出てくるArduinoはArduino ADKというタイプですが当然ピンコンパチです。個人的にはいきなりAOAに挑戦するよりも、Arduino単体でLEDやブレッドボードをひと通り触ってみてから、AOAとの接続する方が遠回りのように見えますが実は理解しやすいでしょう。これはAOAでのデバッグ時に動かない原因がArduinoなのかAndroidなのかの切り分けが、断然楽になります。
内容は先に書いたように、あまりハードを知らない人向けに書かれていて、回路図の説明はプルアップ・プルダウンなどの用語解説もありますので、どうしてそういう回路になるのか？なども理解できるようになっています。
Androidについては最初にHello Worldの作り方があるものの、AOA自体が結構実装レベルとして大きいので、Android初級者にはやや厳しい内容になっています。ここは他の本でカバーする感じになります。個人的にはAOAを使う上でのAndroidのコードの定石の書き方があれば良かったと思います。（ここは自分もちょっと苦労してこんなの作成したので）
後半はクラウドとの連携の部分ですが５章のみなので、やや内容が少ないのが残念です。前提としてRubyやRails, Gitの知識があることとなっていて、個人的に涙目...orz
全体的に技術的に網羅されているのですが、この本１冊で！ってのは難しいので、Arduino、Android、クラウドそれぞれを別の知識で補っておくと、理解が深まると思います。
Let's Make!
書籍目次
組込みにおけるHTML5の意味
7/2にMobile5という勉強会に主催者兼発表者として参加しました。
発表資料を公開しておきます。
View more presentations from Tomo Watanabe
とはいえ、素晴らしいまとめ記事をジャーナリストの星さんに書いていただいたので、そちらを見たほうがわかりｒｙ
まとめ
今回の勉強会では他にもTizenやBlackBerryから見たHTML5や規格としてのHTML5、ユーザから見たHTML5の利点など、様々な角度からHTML5を観るという点で面白かったと思います。HTML5自体は規格と技術なので、それが誰にどう影響するのか？という視点は大事です。
今回、私は組込みとHTML5という、一見関係無さそうな両者をプラットフォームという括りで一つのシステムとしてプロトタイプを作成しました。私の中では「組込み」と「モバイル」と「Web技術」は統一場理論的な話であり「デジタル家電」とはこれらを統合したプラットフォームそのものだと考えています。そして、その路線をきっちり進んでいるのが、AppleとGoogle、そしてAmazonなどの企業だと思います。彼らはユーザ体験を大事にし、クールなコンテンツとデバイスをセットで提供することに長けています。
私は逆に「ユーザ体験」を「ユーザ自身が創れる」プラットフォームというの考えることが多いです。それが「究極のユーザ体験」になるだろうと半ば確信的なところもあるのですが・・・今回のオープンソーシャルな開発の先には、いずれユーザ自身が、パーツを組み立てるだけで、自分だけのユーザ体験を創れる可能性を示したかった。ということです。
ただその世界では開発者が必要なくなるかもしれません。それは残念なことかもしれませんが、それはきっと正しいのだと思います。その時は別の商売があるのでしょう（ディアゴ◯ティーニでプリ組立シリーズ全10巻とか・・・）
HTML5のブラウザ的な問題とかは実は大変なんだろうな。とは思いつつも、開発環境やプラットフォームとしてのブラウザがあると考えれば、ユーザに非常に大きなメリットが生まれてくるのではないでしょうか。
さいごに
このデモンストレーションですが、もし興味のある方がいらっしゃいましたら、ご連絡頂ければと思います。可能であればデモを見て頂き、意見を聞かせて頂きたいですし、ディスカッション等もしたいと思っています。連絡先はTwitterにメンションをいただけると反応しやすいです。よろしくお願いします
組込み技術とモバイル技術（２）
ESECでのブースセッションの資料をSlideShareで公開しました。内容は多少変更していますが、だいたい言いたいことはわかるかと思います。
View more presentations from Tomo Watanabe
メーカの開発現場の現状
私は元々は組込み系のエンジニアなので、リアルタイムOSを扱ったり、デバイスをコントロールするようなのは好きです。ただ、時代が変わりビジネスとして成立させるためには、より高レイヤの仕事をやるようにしないといけなくなっているのも事実です。そのため、多くのメーカではいわゆる上流工程に人をリソースをアサインすることで、ビジネスを継続してきました。これは単純作業になる業務を外部に開発依頼することで、コスト削減にとして一定の効果がありました。
さてこの施策はデバイスドライバや機能の一部を切り出すことで、「機能的に何を作るかが決まっている」場合は効果がありました。つまり継続製品であったり、派生製品である場合に効果があります。
モバイル技術における課題
しかしモバイル技術が主流になると、この効果が期待できなくなってきます。モバイル技術のコアはサービスになります。このサービスというのは機能ではないので、リリース後も日々改善を行う必要があります。ここで言うサービスとは「モバイルアプリも含めたユーザ体験」になります開発自体も改善が前提の開発手法を採用しないとなりません。今までどおりに企画だけ作って、外部に開発委託することになると、
・サービス開発を外部委託
・リリース後の改善も外部委託
さて、これでユーザに満足のいくサービスを提供し続けることが可能でしょうか？サービスがコアだとすれば、致命的になりえます。もっともユーザと対話すべきフロントエンドを外部開発することは、自社のブランド・サービスを丸投げしていることになります。つまりモバイル技術が主流になると
・ユーザとの接点（UI/UX）の改善・サービスの提供を重視 ・ユーザ体験の継続的提供
という面を重視することになり、重要なのは機能実装や追加では無くなります。
技術的には今後モバイル技術だけではなく、Web技術の対応が急務となります。HTML5はブラウザだけに影響する話ではなく、BeagleBoneは組込みボードですがNode.jsがサーバとして動作します。組込みでもハード＋HTML5技術は動き始めています。こういった製品分野の動向をちゃんと把握しておく必要があります。
まとめ
組込み技術からモバイル技術が主流になることで、製品開発からサービス開発へ軸足を大きく移すことになります。重要になるのは機能ではなく、ユーザ体験のインターフェースになります。このUI/UXに当たる部分は「最終的に何を作るか決まらない・継続的に改善する」箇所であり、自社内で開発可能な体制が必要になります。組込み開発よりも、エンジニアとデザイナーがエンドユーザの声を聞きながら開発していく。そういうスタイルになっていきます。ここを外部に委託するようだと開発のスピードやユーザ体験を創ることが上手くいかない可能性が高いと考えます。技術的にはHTML5の動向を押さえつつ、プロトタイプの開発から製品・サービス開発までのコアを支えるエンジニアの育成が急務になります。ブースセッションではその辺りの重要性を話させてもらったのですが、思ったより反応が薄く、ちょっと(´・ω・｀)ｶﾞｯｶﾘ…
組込み技術とモバイル技術の違い
ESECが終わりました。3日間説明員として立っていましたが、モバイルアプリ開発から、組込み分野に戻ってきて、今の組込み技術の課題とか、問題とか色々見えてきたので整理したいと思います。その上でAndroidなどのモバイル技術との違いを考えてみます。
課題
- とにかく現状のコードがスパゲティでどうしようもない。サイズも大きく、静的解析ツールとか使って何とかしたい
- アーキテクチャを誰もわかってないので、継続開発が困難になっている。ドキュメントをきちんと作れるようにしたい
- SysMLなどのエンジニアリングツールを使って記述したい
・・・正直10年前から何も変わってないなぁ・・・というのが第一印象（もちろん会社がコンサルティングだということもありますけれども）気になったのはSysMLとかに興味があるということで聞いてみると、UMLも導入していない。ドキュメントもない。という状況もあるようです。キーワードだけに踊らされている感が満載なのですが、どうやら上司がキーワードのみを調査命令しているようで、実際に聞いてみると遥かにハードルが高いということに「うーん」となることが多かったです。自分がUMLを導入したときは事前に個人で学習した後に、導入方法を検討したと記憶しています。今回のESECで聞く限りは、前向きな導入と言うよりは、上から言われたから検討しているという姿勢が多かったです。
問題
- 改善活動に取り組んでいる人に優秀な人材がアサインされている
- 過去のしがらみが多くて、ゼロから作ることができない
いや、優秀な人材がアサインされることは悪いことじゃないんですが(^^; これがなぜ問題かといえば、優秀な人が、ある意味後ろ向きな改善活動に取られるということは、新規開発に優秀な人がアサインできていない可能性が高いことでしょう。これはいくつかの連鎖が考えられます
- 現場はスパゲティコードを生産するので精一杯
- 現場にアーキテクト不在
- アーキテクチャ見られる人材がドコドコにいるぞ
- お前改善やれ
だいたいこんな流れだと予想できます。特に利益を生み出している現場がこの状況であれば、優秀な人材を投入するのはわからなくもないですが、いずれにしてもこの状況でゼロから新しい製品開発ができるような部署があるのかどうかは疑問です。この新しい製品開発に優秀な人材を投入するか、改善活動に投入するか、は経営層の思惑が見え隠れしますので、場合によっては危機感を持ったほうがいいでしょう。
潜在的な課題
- モバイル技術と組み込み技術の違いを理解できていない
Androidなどのモバイル技術を組込みに利用しようという動きは当然ながら加速しています。ただ気になるのは
- 今までの製品開発プロセスをそのまま使用しようとしている
- ソフトウェア品質やコード品質にも今までの組込み技術と同等のレベルを要求しようとしている
組込み技術とモバイル技術の違い
さて組込み技術の課題は10年前からあまり変わってないと言うことがわかりました。そして隆盛してきたモバイル技術が、組み込み技術に取って代わろうとしています。ところが、今まで組込みでやってきた人たちは頭が固いのか、モバイル技術を組込み技術でやろうとしています。いつまで経っても製造業の癖が抜けないのは大きな問題です。この辺りの笑えない話はこれがわかりやすいですね
米先輩「お前が成長しないのは、いつまでも製造業ばかり特別扱いして、『脱工業化』を悪いことのように決めつけて新しい仕事を憶えないからだ。昔覚えた仕事の改善提案ばっかりでお茶濁して、実はこの20年間、新しいことに一番挑戦してないのはオマエだよ。自覚してる？。」 「製造業は新入社員の仕事」
まずは「組込み技術」から「モバイル技術」へ徐々にでもシフトしていく必要があります。その際には今までのやり方を「捨てる勇気」が必要になります。では何を捨てるのか？
★コードを捨てる勇気！
足の遅い組込み技術と違ってモバイルでは3年周期で技術が変わっていきます。大きなソフトウェアを作成しないようにして、いつでも捨てられるようにします。また開発人数も少人数での体制になり、ゼロからコードを書ける優秀な人材を戦略的に投入することになります。
★プロセスを捨てる勇気！
現場に厳密なプロセスを要求するよりも、アジャイル開発が向いているでしょう。モバイルの場合はユーザのフィードバックも得られやすいので適しています。
★改善活動を捨てる勇気！
3年で変わるようなスピードに改善活動をやっている時間はありません。新しい製品開発やチャレンジに割く時間を多く取れるはずです。
★今までの技術戦略を捨てる勇気！
今はAndroidが組込み技術に採用され始めていますが、Androidはまだ（もう？）4年しかたっていません。しかしモバイルの先端を見るとHTML5の影がチラチラと見え始めています。今までのように10年も同じ体制と技術でやっていくことは不可能になるのは目に見えています。そもそもGoogleがAndroidの開発環境をいつJavaからHTML5にするかもわかりません。組込み技術は自分たちの技術を中心に、必要な技術を選択できたのですが、モバイル技術は標準的な技術を中心に、自分たちの技術を組み込んでいくことになります。これは技術戦略的に大きく変わりますので注意が必要です。
最後に
先日珍しく50RT以上されたので、貼り付けておきます。そろそろ日本の製造業もリセットボタンが必要なんじゃないかなぁと思い始めた今日この頃です。
アメリカはIT大国から、徐々に製造国へとシフトしようとしている。日本を横目に新しい製造業を造ろうとしている。ITベンチャーと同じ仕組みでハードベンチャー企業が最近現れてきている。彼らの強みはベースにITがあること、IT+ハードは大きな可能性があり、彼らはしがらみもない
— 這いよるひよこさん (@tomo_watanabe) 4月 15, 2012
今回のESECですが、TL上の友人が簡潔に纏めてくれました
今日の感想：サービス無きデバイスに命はない
— ようてんさん (@youten_redo) 5月 10, 2012
HTML5ですが、GClueの佐々木さんがTizenを評してTweetしていました（Tizenが成功するかは置いておいて、流れは出来つつある）
BlackBerry10のHTML5Testが391で、TizenのHTMl5Testが400。もう、スマフォのWebをひっぱってるのはAppleでもなく、Googleでもなく、RIMとSamsungとLinux Foundation。
— Akira Sasakiさん (@gclue_akira) 5月 9, 2012
一方で、ホンダが代々木八幡駅に出していたとfacebookで話題になっていた広告を載せておきます。正直涙出てきますね。今の製造業に足りないのは、前向きな開発とイノベーションのスピードだと思います。さぁ新しいことを始めましょう！
