Intel Edisonで遊ぶときの開発環境とか

Edison IoT mraa

前回のエントリでとりあえずの環境構築は終わってプログラミングの準備が出来たので、今回は実際にコードを書いていく環境についてまとめる。前回も書いたけど環境はある程度整っているので、そんなに身構えなくても大丈夫。

Edison+Arduino拡張ボードを使っていたので、Arduino IDEを使うという選択肢もあった(というか、実際少し使った)けど、今回はIntelさんのお勧めに従ってmraa(むらー、と読むらしい)を使うことに。

なお、mraaを使うためには前提ライブラリをインストールする必要があるので、opkgを使ってインストールしておくこと。こんな感じでパッケージマネージャ登録して、更新かけてからインストールすればOK。

$echo "src mraa-upm http://iotdk.intel.com/repos/1.1/intelgalactic" > /etc/opkg/mraa-upm.conf

$opkg update

$opkg install libmraa0

mraaはEdisonないしGalileoからIOを発行するためのライブラリといった感じのもので、これがあれば簡単にデバイスとインタラクションすることが出来る。mraaがサポートしている言語には C/C++, Python, JavaScript(nodejs) があるのだけど、今回はお手軽さと自分のやりやすさでnodejsを使うことにした。nodejsを選んでよかったのはREPLが使えること(Pythonでもいいけど)。とりあえずインタラクティブな環境立ち上げて、お手軽に試せるのはやっぱり分かりやすい。

あと個人的な感覚だけど、nodejsのこの辺りのコードはなんとなく自然な感じがして、Edison特有な話とそうではない部分の境界線みたいなのがあまりないような気がした。完全に感覚的なものだけど、そういったソースコードの一貫性というか繋がりの良さみたいなのは大事だと思う。

逆に悪かったことは、github見にいってもnodejsだけはドキュメントがなくて「サンプル読め」しか書いてないところ。そこはもうちょっと頑張ってくださいよ、ほんと。

ちなみに、nodejsとは言ってもC/C++向けのライブラリにnodejsを被せただけらしいので、デバイスIOが非同期で実行されるというわけではないみたい。このへんは非同期にしてくれると、デバイスアクセスのディレイとかあまり気にしなくてよくなるので、制御しやすくなったりしないかなぁとちょっと思った。今後に期待。

続いてサンプルコード。適当にコメントを付けておくまでもなくほとんど見たまま。後はdigital 8のところにブザーをつないで実行すれば1秒間音がなるし、LEDつなげば1秒間光らせることが出来る。簡単ですね。

sample io using mraa

なお、ソースコードの編集をEdisonでやるのは多分大変(一応viは入ってたけど、なんか挙動が怪しかったし、何より自分vimmerじゃないし)なので、PC側でコード書いて流し込むのがいいと思う。流し込み方は前回も書いたけどopkg経由でgitを入れて連携させるのが自分としては馴染みがあって楽だった。

別の方法としては、Intelが提供しているIoT向けのIDE(Intel® XDK IoT Edition | Intel® Developer Zone)もあるのでこちらを利用してもよい。IDE使うとデバッガが使えるのがいいのと、後はこのIDE経由で流し込んだコードはEdisonを再起動させても勝手に再開させてくれるのが楽なところかな。自分の環境ではやたら重くて固まりやすかったので、あまり使わなかったけど。

とりあえず、これで開発の準備は整ったかな。

Intel Edisonを触ってみた

Edison IoT

HackathonでEdison触ってた時の作業ログと触った感想など。

 

初期立ち上げとセットアップ手順はだいたいこんな感じ

  • 何はともあれ、電源を入れて外側のポートにマイクロUSBをつないでMacと接続 (内側につなぐと普通に記憶デバイスっぽくマウントされるっぽい。Arduino IDE使う時もこっちを使う)
  • tty接続。だいたいこんな感じ screen /dev/tty.usbserial-XXXXX 115200
  • 初期状態だとファームウェアが最新ではないので、最新版をDownloadしてくる。自分が使った時点では2014年10月版が置いてあった

    Edison - Software Downloads | Intel Communities

  • 最新版のzipを取得したら、展開して出てきたファイルをUSBマウントしたEdisonのルートディレクトリにコピー (上に書いたけど、内側のUSBポートにつなぐ)
  • 後はEdisonを再起動(電源引っこ抜いて刺し直せばOK)で更新される。簡単
  • ttyで接続してセットアップコマンド (configure_edison --setup) を実行。指示に従ってデバイス名/パスワード/wifi設定を済ませる

ここまで来れば普通にLinuxマシンとして見えるので、上と変わらずttyでつないでもいいし、sshでの接続も可能になるのでEdisonと戯れることが出来るようになる。opkgというパッケージ管理もあるので、そこから普段のツール類(gitとか)もインストール出来てしまうので、手元のPCでgithubにソースコード上げてEdisonでpullとかもできちゃう。Edison側をリモートに設定して、手元からpushしたら勝手にマージさせて実行するとかも出来ちゃう。とても気軽。いや、ほんと気軽。

 

自分の組み込み経験の大部分は学生の頃の研究ネタから来ているのでだいぶ古い話だけど、基本はPC側でクロスコンパイルかけてからバイナリをデバイスに流し込んで実行・・・う、動かないぜなんでだ？とかいいながら、とりあえずオシロつないで電気が流れてるの確認出来なくて泣きそうになったり、通電確認出来たけどプログラム動いてる雰囲気ねーなと思ってバイナリ確認してミスってて凹んだり、ようやっと動いたと思ってもロクに標準出力すら出てこないからデバッグも進まなくてそこの環境構築に必死になったり・・・ついに、ついに動いたぜって頃にはもう満足感でいっぱいなので、そこからが本番なはずの実装が進まないとかとか。まぁ、とにかく苦労しかしない印象があるので、USBでサクッと接続してLinuxにログイン出来るなんて夢のような環境のわけですよ。しかも、Edisonの場合はnodejsとかpythonが入ってるので、簡単にREPL環境が実行出来て、LEDピカピカさせるとか、ブザーを鳴らすみたいなのを、簡単にトライ＆エラーで遊べてしまうわけ。これはホント楽。

 

正直に言うと、あまりに苦労がなさすぎてちょっと物足りなさはあるのだけど、それはおいといて・・・これだけ手軽で普通に扱えるなら、色んな人に使ってもらえて色んなアイディアが出てきそうだなぁと思った次第。遅まきながらIoTな世界が広がる要素の片隅をのぞいた気分になりましたとさ。

 セットアップ系の話はここまで、プログラミング系の話はまた別途だな。

 

-- 追記 --

写真をアップロードしようと思ってて忘れたので追加。EdisonをArduino拡張ボードに接続して、更にGrove Starter Kitを付けたのがこの状態。EdisonはほぼほぼSDカードサイズなのでとてもコンパクト。

f:id:tamaxyo:20141119105516j:plain

TechCrunch Hackathon2014に参加してきた

hackathon

週末の二日間まとめて家をあけるという暴挙に打って出て、好きに時間を使ってきたというお話。最初に書いておきたい、時間をくれた家族にありがとう。

 

TechCrunch本編に先立って週末に行われたhackathon、200人も集まるなら面白いネタとか面白い人と会えるんじゃないかと思って参加してきた。特に"これ"と言って作りたいものが決まってたわけじゃないのだけど、漠然とtwilioを使ってコミュニケーション系の何かを作るか、Edisonを使ってIoT的な何かをやろうかなぁと思ってた。

結果として、自分が参加したチームはこれ。名札に組み込みエンジニアというのをこっそり書いておいたのを目にしたチームに誘われたので、そこにデバイス系のエンジニアということで参加してきた。

 

実際に作ったものとしては、自転車車載機器として距離センサを使って後方から接近するものがあればディスプレイと音で危険をお知らせするというもの。センサ関連の入出力はもちろんEdisonを使って実現している。さらに危険を検知するとBlueTooth経由でそれを出力するので、iPhoneで信号を拾って危険が発生した位置情報と時間を即時サーバに送信することも出来る。これを使うと自転車走行時のハザードマップ的なものが作れるという寸法(サーバ側のアプリもちゃんと出来たよ)。

当初購入した距離センサが全然動かなくて二日目に買い直して時間ギリギリでなんとか動くようになったり、BlueTooth使うためにOS入れ直そうにも上手く入らなくて結局Advertiseで誤魔化したり、そもそもEdisonとPC接続しようにも手持ちのUSBケーブルじゃつながらなくてIntelさんからもらったのだったら動いたり、最初に配布されたGrove Starter Kitのボードに不良(分からんけど、ボードだけ入れ替えたら直ったから多分)があったり・・・とにかく初めて触るハードウェアだったので遠回りしてかなり時間を消費してしまって危険な状態だったけど、二日間でちょっとした形にはなったのでよかったと思う。というか、自分はこのへんの地雷を踏み抜く役割をひたすらやっていて最終的なところはBlueToothでの通知くらいしか作ってないので、アイディアから開発までほとんどをチームメイトのお世話になってしまった感じ。Intelの担当者の方々にも多くの支援をいただきました。多謝 m(_ _)m

 

そんなこんなでなんとか形には出来たのだけど、反省点としてはサーバ側のコンテンツ活用に時間を割けなかったこと。ハザードマップを個人で活用とか、自転車乗りでシェアするところまでのソーシャル感は容易にイメージしてもらえたと思うけど、この情報は歩行者にも役立つだろうし、車の運転手にも有効なはず。今時の地図アプリであれば道の太い細いは分かるし、車なら交通量を知ることも出来るけど、そこにどの程度自転車が通っててどの程度危ないかという情報はまだ多くないんじゃないかな。なのでナビゲーションと組み合わせた時の情報の価値というのも本当はもっと可能性があったはず。

何よりこのデバイスは使ってる本人の危険をリアルタイムにお知らせするので、一人称である本人が使うメリットがちゃんとあって、更にそこで収集した情報がより広い範囲で活用出来るという形になってるので、ある意味ではIoTとはかくあるべし的なことをちゃんと押さえてた気がする。でも、そこのアピール弱かったなぁと・・・正直、他チームと比べてもそういう議論が少なかった気がするのはほんと反省点。プランナーさんとか居たら違ったのかもしれないなぁと思うと、チームビルディングの時点でもう少し頑張れたらよかったのかもしれない。

 

何はともあれ、二日間楽しく過ごすことが出来ました。運営の方々、スポンサーの方々、参加者のみなさん、どうもありがとうございました。お疲れ様でした

PaaS勉強会 - OpenShiftスペシャル - に参加してきた

paas openshift

ブログ作ったので、何か書かないとと思ったのも何回目か・・・今回は頑張れるかなぁ。

 

 PaaS勉強会 - OpenShiftスペシャル - に参加してきた。

ぶっちゃけOpenShiftってリリース直後にお試しだけしてから二度と触ってなかったくらいに興味がないのだけど、Kubernetesの名前を見かけて興味を持ったので行ってきた。

結論から言うと、次のバージョン(V3)ではDockerとKubernetesを全面的に採用していて、実行環境のコアな部分にしっかり組み込まれてて驚いた。

Kubernetesを組み込んだ理由に関しては、こんな感じの話が聞こえた。

これだけアーキテクチャ変えてもユーザから見た使い勝手は変わらないということらしいが、さすがに変更がでかすぎて既存資産で使えなくなるものあるだろ？と思ったら、やっぱりそこは未定なんだそうだ。きっと何かしら準備はしてくるだろうけど、どちらかというとそういう大きな変更にもしっかり踏み切った決断力を評価したい感じ。

 

ちなみに、OpenShiftのV3に関してはこのへんを読むといいのかな。DockerとKubernetesがしっかりレイヤに組み込まれてるのが分かる。


OpenShift v3 Platform Combines Docker, Kubernetes, Atomic and More – OpenShift Blog

 

ふむ、今後の動きは気にしておいた方がいいなぁと思った次第。