update.まとめ駐輪場のシャッターを開けるのに、ビルのエントランスから入ってボタンを押さないといけなくて面倒だったのでSlackでつぶやくとbotが開けてくれるようにした会社の駐輪場は、恐らく車庫として使われてた場所を流用しているのですが、シャッターを開けるためのスイッチが車庫内にしかなくて、自転車を入れるためにはいったんビル内に入ってから中から開ける必要があり面倒でした。会社の先輩の発案で、「このボタンをサーボで押せればいいんじゃね?」ということでサーボでボタンを押すようにして、ビル内に入らなくても外からシャッターを開けられるようにしました、というお話です。ちなみに外にテンキーで開けられるスイッチを付けてもらうと数十万円、みたいな見積もりだったそうな。これを押すだけアーキテクチャざっくりした設計ほんとに最初に書いたざっくりした設計だけど、実際に運用に入ってもほぼ構成はこのままでした。紙に構成を書いて、その筋に詳しいメンバーにもレビューしてもらっています。そんなに複雑なことはしてなくて、共通のDBに書かれたメッセージを見て動作する、ただそれだけです。ドキュメント普段のプロジェクトでやるような、簡易なドキュメントを作りました。いつも使ってるフォーマットでドキュメントを書くと、やること・やらないことが整理できるのと、同じフォーマットで長い間運用されているのでレビューもしやすい、と言ったメリットがあります。共有もしやすいし、引継時にもこれがあるとだいぶ楽です。プロトタイプいくつか段階を踏んで開発をする必要があって、下記のようなステップに分けて開発し、それぞれを結合していくという進め方をしました。bot側のコードソフトならなんとでもなるという感覚はあるので、最も難度が高そうな1のハードの構成と開発から着手しました。プロトタイプのときは、当時いろいろ使ってみたい技術やサービスがあっていろいろナウなイケてるものを盛り込んで作ろうとしていました。'error'携帯電話の組込みソフトウェア開発を4年ほどやっていたこともあるので、簡単な電子回路なら問題がないのだけど、サーボをいじったことがまったくありませんでした。サーボがどういうものかに慣れるために、サーボを買ってきていじりながら感覚を掴んだ、と思っていたのですがサーボは他の部品と比べて個体差が大きい電圧などの回路要件が厳しいというのに全く気づいてなくてドハマリしました。個体差が大きい個体差が大きい、と言うのは複数同じ型番のサーボを買ってきたにもかかわらず、同じコードで同じ回路構成でサーボが動いたり動かなかったりする、というのに悩まされたり、冬に開発をしていたので、室内だったら問題なく動く個体が駐輪場(ほぼ外気温)に持っていくと動かなかったりと、ハードらしいトラブルが続出しました。piからIO直結だと駆動させる電流が不足することが原因で、サーボドライバーボードを挟むことで安定して動作するようになりました。試した段階でIO直結で問題なく動いていたので油断していて、サーボの個体によって瞬間的に流れる電流が違っていたりするというのに思い当たらず苦労しました。問題点の切り分けがなかなかできなくて、オシロスコープを買ってSPIの波形をチェックしたりしてみたのだけど、結局は電圧・電流の不足で詳しい人が見ればすぐわかったのだろうと思いますが、そういうノウハウがありませんでした。サーボが動かなかったりして苦労している人はサーボドライバボードを使うのがおすすめです。少なくとも電圧・電流絡みの問題は切り分けが簡単にできて、ソフトの制御の問題だけに集中できます。サーボドライバボードが微妙に高くて(3000円ぐらい)、動いてるしいらないだろう・・・とケチったのが間違いでした。金で解決できるところは金で解決したほうが結局安くあがるというのが教訓です。最終的な構成(現在はこの構成で運用中)いろいろと深い挫折や妥協の結果、この構成で半年ほど運用していました。slack間のメッセージのやりとりも愚直にポーリングして監視しています。MQTTもカッコイイんですが、簡単なことを簡単にやるには大仰でした。phanto.ioはsparkfunが運用してるIoT向けのDBaasで、簡単なkey/valueの読み書きがHTTP経由でできてとても便利です。難点はパフォーマンス的に遅い時があるのと、あまり安定していないことなのですが、GETで読み書きができるデータストアとしてとても使いやすいので採用しました。意図しないタイミングでうっかりシャッターが開いてしまうことで、これは設計当初からうっかり開かないような仕組みを入れていました。会社の駐輪場ですが、自転車が好きな人は1台xx万円みたいな自転車を止めていて、うっかり開いて自転車が持っていかれるとダメージがでかいので安全側の設計をしています。2016/12に意図しないタイミングで開いてしまうことがあり、回避できないので運用をやめました)。piなので動体検出してカメラで撮って記録する、というもパワフルで簡単にできるのでやってあります。スイッチサイエンスUSBカメラ開閉センサジャンパケーブル合計2万円ぐらいでしょうか。開発とメンテナンスの簡便を考えると十分にペイすると思います。開発していくなかでボツにした技術・サービスなどなぜ、使わなかったのか、という理由って意外と大切だと思うので開発段階で使ってみたけど採用しなかったものを挙げておきます。今回の用途にはフィットしなかったというだけなので、プロジェクトの性質によって合う合わないはあるとおもうので試してみて下さい。milkcocoahttps://mlkcca.com/milkcocoa、すごい好きなんですが、ハマった時に情報が少なくて自分だけしかはまってる人がいない状態になるのが辛くて使うのをやめました。シンプルで、データを入れたい、見たい、グラフにしたい、という用途が明確でわかりやすいので使いやすいです。プロトタイプとして使う分には良いのですが、長期間それなりに安定して稼働させようとするとちょっと不安があるかな、という感覚でした。今は変わっているかもしれません。MQTTちょうどAWS/IoTが出始めだったので早速飛びついて使ってみたのですが、どうにもやりたいことに対して大仰で、簡単なことを簡単にやりたい場合にはリッチすぎてむしろ使いづらいな、という印象でした。データをkey/valueで読み書きしたいだけで、リアルタイム性もそんなにいらない(秒単位で良い)ので不採用にしました。証明書ありの通信とかそこまでやらなくても良いということもあり、クライアント側それぞれにもライブラリが必要で、セットアップが大変だったのもボツにした理由です。SORACOMこちらも少量のパケットしか流さないし、1日10円で使える!と思って飛びついたのですが、1時間は安定して動くのだけど2日ぐらい経つと回線が切れたりして苦労しました。piから直接繋いでいたのですが、結局モバイルルータにSIMを指してWifi経由でつなぐようにして安定しました。従量制なので、制御にバグがあってリトライ無限ループしてパケ死しそうになりましたwパケ死しそうになってもAlertを適切に設定してればすぐに気がつけるようになっています。SORACOM、すごく良くできていて、やりたいことわかってるなぁ、と感じます。速度の調整がコンソールからできたり、回線切断ができたりと、遠隔に設置した機器の制御に欲しいものが揃っています。失敗こそなかなか共有されないけれど、共有するのが価値があることではないか、と思っているので列挙します。サーボが動かない→駐輪場寒すぎ?室内だと動く・・・サーボが動かない→ソフトは正しいはず。モノがあると試行錯誤の1イテレーションに時間がかかる。運用開始その後2016/3から運用を開始して、大きな問題もなく2016/11月まで運用してきました。1日に20-30人ぐらいが出社時に使用していて、それなりの頻度で使われていた割に安定していたのではないかと思います。2016/11月頃に、DBaasとして使っていたphanto.ioが瞬断を何回か繰り返したり、タイムアウトになったりすることが増えてきて、想定外のタイミングで一度開いてしまったことがあったので運用をやめました。完全にダウンしてしまうエラーは想定していたのですが、断続的にデータを書けたり読めたりを繰り返す状態になるのは想定していませんでした。botが応答してる限りはfailが書き込めるのでシャッター側が開けようとはしませんでした。シャッター側も”done”を書けない、で最新の指示が”open”のままになってしまって、DBaasが時折復旧してシャッター側が”open”を見て開けちゃう、という不具合です。phanto.ioが有料でもいいから安定してくれればそのまま使えたのですが、無料のものしかなくてSLAは期待できないのでやむなく運用を止めました。ボタンを押したい、既製品を使うなら既製品もパラパラと出ているみたいです。普通の電気のスイッチみたいなやつなら既製品を使うほうが楽そう。upLoginユーザーは見つかりませんでした。