【概要】
IDCFさんのハッカソン、Morio Quest Vol.1に絡んで、ツールド東北に参加(走ったわけではない)したので、簡単にまとめ。今覚えていることをざっくりメモしておいて、詳細については後日ブログで、という感じ。このメモとしては自分と身内用。思い出したら追記するかも。
ライダーさんと一緒に走ったデバイス
Morio Questに出したのは、こんな感じのもの(slideshare)で、主な機能は
- 自転車の傾きが一定以上になると応援する
- タイヤの回転数が一定以下になると応援する
- Twitterで特定のハッシュタグが呟かれると応援する
の3つの機能を持ったデバイス。ただし、デバイスとしてのウリは、それぞれのデータの正確性というよりも「女子たち(うちのムスメたちとヨメの人)の声で応援してくれる」という若干色物風味 ^^;
結果
ぶっちゃけ、結果が成功だったかといえばNoと言わざるをえない。
- デバイスは2個用意していたが1個しか装着できなかった
- 回転数を取得するセンサーは現地で断念せざるを得なかった
- かなり早い段階で通信途絶してデータが拾えなくなった
…という有様。7月末から8月中旬まで、仕事の合間を見つけて作業時間を捻出してきたことを考えると残念な結果だった。
とはいえ、多くの反省点とともに得られたものは(少なくとも個人的には)大きかった。
【得られた知見】
アクションに反応して画像が返ってくることの高揚感
先に書いた「Twitterで特定ハッシュタグが呟かれるとデバイスが音声で応援する」機能には、オマケ的に「そのタイミングでオンボードカメラで撮影してTwitterにアップする」機能をつけていたんだけど、これはかなり面白かった。撮影した画像は、Twitterのメディアタイムラインで見れるようになっているんだけど、あいにくの雨の中、力走するライダーさんの写真が、それなりにいい感じに撮れているように思う。
写真そのものも面白かったんだけど、「こちらで起こしたアクション(ハッシュタグつけて呟く)が、離れたところでのアクション(カメラ撮影)のトリガーになって、こちら側にフィードバック(写真つきのメンションが飛んでくる)」というのは、なんだかとても不思議な感覚で、大変に興奮した。
リアルタイムな可視化も非常に面白い
デバイスから得られたセンサーの値やGPSの位置情報をリアルタイムに可視化する仕組みも実装していたのだけど、これも非常に面白かった。特に位置情報は、今デバイスがどこにいるのかということが手に取るようにわかり、ライダーさんが出発待機列に並んでいるところからスタートしてぐんぐん進んでいくところ(タイミングよくこの瞬間を目撃できた)のもとても興奮できたひとときだった。
準備したデバイスが「手の届かないところ」に行くという感覚
ライダーさんたちがスタートした後、会場で待つハッカソン組で「なんか、はやぶさみたいだねぇ」という話になった。もちろん、あのはやぶさの話である。
一緒にやっていた、チーム「ヒルクライマー」さんはアプリ側からのアプローチだったのだけど、こちらもデータが取れたり取れなかったり…というか、たまに地図上にライダーさんの存在と現在の心拍数を示すピンが立つような状況で、この「たまに生存確認が取れる」感覚がはやぶさっぽいよね、というようなお話。
私のデバイスの方は途中で完全に通信ができなくなった(デバイスは帰ってくるまで生きていた)ので、その意味でははやぶさ的という表現が妥当かわからないが、とにかく、もう出発してしまった以上、デバイスの不具合に対して手が出せなくなる、というのは、普段クラウドサービス方面に従事していて、最悪納品後であろうと設定変更がこちら側からできるような領域での常識や感覚とは非常に異なる点が多くて、これは大変勉強になった。
【反省点】
たくさんある。とてもたくさんある。
圧倒的な準備不足
今回、スケジュールの問題もあって、デバイスを自転車につけたのが前日(データを取れる状態にしたという意味では当日)という、文字通りのぶっつけ本番だったわけだが、そもそもこれが失敗の最も大きな原因だった。
今思えば、どう考えても自転車にデバイスをつけてのテストをやるべきだった。時間的にいつそれができたかといえば、今思い返してみてもそんな余裕はなかったのだけど、それでもテストは絶対に実施すべきだった。テストしておけば、少なくとも以下に書くような問題について事前に認識し、対応策を講じる事ができたはず。
それと、あとで書く「封入後のインターフェイス」のところとも関連するが、今回は結構ギチギチにハウジングしたので、設定にいちいち時間がかかった。テザリングとかもしかり(しかも最終的にテザリングは失敗だったというオチまでついて)。このあたり、特に今回のようなレース物の場合、ライダーさんたちは走るのが本来の目的で、こちらは「つけさせて頂く」立場なのであまり時間をとるのが申し訳なく、そのあたりがデバイスの装着を1つ断念したことにも影響している。事前に設定できるものはしておいて、当日あるいは前日の作業量を最小限にする事が必要だったと思う。
通信について
一番悔しかったのはこれ。上でも書いたとおり、出発してしばらくしたところで通信途絶し、そこから先のデータが取れなかった。
ログを見てみると、センサーからのデータが最後に取得できているのは10:17になっている。先頭ライダーのスタートが09:00ごろ、実際にデバイスをつけたライダーがスタートできたのは09:30ごろと思われるので(この辺は位置情報とあわせて改めて詳細に確認する)、データの送信ができているのは1時間程度となる。
なお、何故かTwitterのアップロードについては、センサーからのデータが取れなくなった10分後、10:28にも成功しているので、この理由についても後日詳細に確認する必要がある。
通信が途絶した原因は、おそらく、デバイス(ラズパイ)とライダーが物理的に離れた時にテザリングが外れてしまったのではないかと思われる。これも、後日、最後に取得できた座標から確認したい。
今回、リアルタイムなやり取りはともかくとしても、位置情報と紐付ける形でコースの情報を取得したいという思いがあったのだけど、通信ができなくなったため、このデータはほとんど取得できていない。これが本当に残念。
今後に向けては、ソラコムなどの「デバイスにくっついて通信できるもの」の利用が必要そう。というか、そもそも、ライダーさんとデバイスが離れる可能性なんて十分に想定できたので、私の想像力が足りてなかった。想像力が追いついていれば、通信ができなくなったことを検知して再接続、などの手段がとれたのではないかと思うと非常に悔しい。
「傾斜を測る」ということの難しさ
あとでグラフにするけど、三軸加速度センサの値は路面の凹凸による上下動が相当に大きくて、「傾斜を測る」という目的にはほぼ使えない状態。
これは、センサの取付がそもそも甘い、という問題が大きいのだけど、仮に自転車に対して完全に固定できても、やっぱり上下動は拾っちゃう気がするので、傾きを取得するなら別の手段を検討しなくてはいけないかもしれない。
くしくも、チーム「傾斜計」さんからは「何故か地点ごとの傾斜角度のデータというのはあまりない」というお話があったけど、実際、取得が相当に困難なものなのかもしれない。
外部インターフェイスの重要性
今回は設置場所の問題もあり、かなりギチギチのハウジングだったため、比較的コンパクトではあったけど、例えばモバイルバッテリーの電源を入れる、とかHDMIとUSBキーボード＆マウスのドングルつける、とかそういう時にいちいちハウジングをバラすのが結構な手間だった。
このあたり、今後に向けての改善策として今の時点で考えているのは2つあって、1つはメインのハウジングとは別にインターフェイスだけ集めた箱を作ってそちらだけで本体の電源ON／OFFとかケーブルの接続とかが完結するように作るという方向、もう1つは、帰りにサービスエリアのトイレで気づいたんだけど(トイレにそういう機能がついてた)、例えば特定の場所に磁石をあてると再起動する、とかそういうギミックがあってもいいかもしれない。
1つ目の方法については、情報の出力(Wi-Fi拾えてるか)とかの確認もあるので、LCDモジュールもあったほうがいいのかもしれない。
データをローカルに残す配慮
今回、実は通信部分については全く心配していなかった(かえすがえすも自分の認識の甘さに腹が立つ)ので、計測データはローカルには保存せず、全てサーバ側に上げる予定…つまり、今回6時間ほどデバイスをつないで(しかもデバイス自体は生きていて)走っていただいたにも関わらず、取得できたデータはごくわずか、という非常に申し訳のない結果になってしまった。
次回以降、最悪通信ができなくても後から活用できるように、ローカルにもデータを保存しておくことが必要。
告知の必要性
今回の機能の一つに、Twitterのハッシュタグをトリガーに処理するものがあったが、スケジュール的に「動く保証」が得られたのが当日という体たらくだったため、ハッシュタグの告知が大変遅れた。先に書いたテストとも関連し、早い段階で動作の確認をし、イベント当日よりも前の時点で告知をしておかないとこの手のものは盛り上がらないということを痛感した。
そもそも重い
あとで総重量を量ってみるが、相当重かったはず。ライダーさんたちがあちこちで工夫して「ここで何グラム、あっちで何グラム」と軽量化された努力を一発でひっくり返すだけのポテンシャル(違)があるので、次回に向けては軽量化も重要な課題になる。
【その他メモ】
自転車✕IoTはけっこう大変だった
今になって思うけれど、自転車ってIoTデバイスをつける相手としてはなかなか手強かった。電力は発生させないし、風雨から守られた場所もない。ケーブルが何処かに引っかかれば即事故になる可能性もあるので、難易度高めだったのだなぁ、と今更思う。
サドルの後は泥対策が必要
帰ってきたライダーさんたちを見ると、腰から背中にかけての部分にだいぶ泥がかぶっていた。今回は雨が降っていて路面状況が悪かったこともあり、後輪がかなり泥を巻き上げていたらしい。当初そこにデバイスつけようと思っていたけどあそこにつけていたらかなりドロドロになったことが想像される。
防水はダクトテープで相当行ける
今回のデバイスの防水は、容器そのものの密閉性にかなり依存していたのだけど、その容器に穴をあけてケーブルを入れていたのでそこがどうなるかかなり不安だった。
結果としては、その部分からの浸水はなかった。一応テープを貼る時に重なりが下向きになるように配慮はしていたが、それ以前の問題としてダクトテープの防水力は相当期待できる。
穴あけ加工の手間暇
上記と関連して、今回、かなり色々なパーツを切ったり削ったりした(採用に至ったのは全体の3割くらいか)。特に穴を開ける加工は、その穴を四角くしようとすると相当に難しく、今回はドリルで開けた穴をリーマーで広げて、それでも足りない部分はリーマーに横方向の力を加えながら削るという荒っぽい方法で対応した。
今後のことを考えると、糸鋸盤の中古をヤフオクなどで入手したら随分加工に関する工数を減らせそうな気がする。
ラズパイ3でも電源は意外と大丈夫
今回は、12000mAhのバッテリーを使ったが、テストでは14時間連続稼動させてもまだ動いていた。ラズパイにはUSBのGPSとカメラを繋いでいたが、少なくともこのくらいであれば、1秒に1回の通信を発生させていてもかなりの時間バッテリー駆動できることがわかった。
もろもろ、追って検証が必要
そちらはblogの方でまとめる予定