こんにちは、 JavaScript Robotics Advent Calendar 2016 13日目の記事です。
趣味でWebGPIO/I2Cのpolyfillを実装し、実際にいろいろな人々に使ってもらいフィードバックを受けての感想と今後についてつらつらと書きたいと思います。
W3CのBrowsers and Robotics Community Groupグループで仕様策定中のセンサーや物理デバイスをJavaScriptから制御するためのAPIです。
実際に遊んでみる場合現時点ではSwitch Scienceさんで販売されているEchigo Rev.1を購入する必要があります。
で、こちらのWebGPIOがどのような仕組みで動いているのかと言うのをざっくりと図にすると以下のような関係をもっています。
- アプリ
- その名の通りアプリケーションです。開発者の方はWebGPIO/WebI2Cを利用してハードウェアを制御するアプリを書きます。
- webGPIO(polyfill)
- W3C提案中の標準仕様に基づいたインタフェースを持つAPIのpolyfillです。
- mozGPIO
- ブラウザ上でとりあえずハードウェア制御を行うために作られた仮APIです。
- CHIRIMEN
- CHIRIMEN Open Hardwareコミュニティーで作られたWeb技術のみでセンサーを動作させるためのデバイスです。
- センサー
- 開発者が制御したいハードウェアセンサーのことです。
今回お話に上がるのは、この図にある「webGPIO(polyfill)」にあたる部分です。
今までソフトウェアを中心に開発してきた私ですが、今回WebGPIO/I2Cのpolyfillを書いて、様々な問題に直面しました。
CHIRIMENボードには18 x2 の36pinのポートはGPIOが14、I2C２つになっています。 (詳しくはこちら)
I2CやGPIOポート制御にはまずポートの開放(exported)という手順が必要なのですが、現在はアプリケーションの読み込み時に全ポートの開放を行っています。
このときに全ポートのexportが上手くいかないと言う問題がありました。
原因は少し考えれば分かる内容でしたが「polyfill側のexportがノンブロッキングになっていた」というお話。
polyfill側からはexportを並列で開放を指示するのですが、mozGPIO <--> CHIRIMEN間では上手く開放ができておらず一部のGPIOが開放フラグが立っているにもかかわらず制御不可能という事象が発生していました。
ここで問題に気づかなかった原因として mozGPIO <--> CHIRIMEN のexport処理で正常にexportが終了しない場合でも例外が発生しないために発見が遅れてしまったという経緯があります。
ライブラリやフレームワークに依存したソフトウェア開発をしていると気づきにくいのですが、外部リソース(ネットワークやその先のリソース)と連携する場合には handshakingのように接続後その先で正常に意図したことが行われているかの確認手順を設ける必要があると実感しました。
現在はその点を改善し、同期的にportを開放する処理を行っています(起動時間がかかるという問題が残りましたが・・・)
上にもありましたが、もう一つの問題としてソフトウェア+ハードウェア開発を行っていると「例外の切り分け」と言うものがとてつもなく大変で経験が物を言う作業になっていると言う問題が残っています。
これは、現時点で「ソフトウェアもハードウェアも両方共動作するものを作ってから」でないと動作確認ができないということが問題です。
ソフトウェアの開発に例えると、今時はいきなり本番機にのせないとアプリケーションの動作確認ができないとうことはなく、モックや検証環境などのスタブやドライバなどを用いで小さく開発していくことが容易になっています。
しかし、現状のCHIRIMENではセンサーを扱ったアプリを作った場合ソフトウェアだけ物理デバイスだけの構築というのが不可能なため両方を一気に作る必要があり、 動作しなかった場合そのどちらに問題があるのかを経験からしか切り分けできないという問題があります。
こちらの問題を解決する手法として、個人的に今取り組んでいるのが以下２つです。
- CHIRIMENエミュレーター
- CHIRIMEN port制御Tools
CHIRIMENエミュレーターは名前の通りCHIRIMENを持っていなくてもある程度のセンサーエミュレーションをしてくれるライブラリです。 こちらができれば、センサーを組まなくともソフトウェアだけを先に書き、動作確認を取ることが可能になるとともに実際にpin出力したデータのロギングまでを可能にします。
こちらはCHIRIMENエミュレーターとは逆のアプローチで、pinから出力する電気信号操作に特化したdevToolsを作ることでアプリを作る前からある程度のハードウェア構築を可能にします。
単純な電気信号の1/0を操作するWebGPIOですらこのように四苦八苦しています、WebI2Cによるシリアル通信についてもまだ色々な問題が残っている状況ですが、コミュニティーのみなさんの活動により改善や提案がなされて着実によくなっていっています。 私個人エンジニアとしては問題解決は好きな部類なので、コミュニティーメンバーとして今後ともWebGPIO/WebI2Cの問題を色々と解決するのに力になればと思っています。
