kdenologue

たまに何か作ります。

HackDay2017で作ったハードウェアの話

kden.hatenablog.com

(前略)IoTハンガーを作りたい、となった。


まず、何かインターネットとつながる機能がほしい。

無線機能としてはだいたい以下かな。
WiFi
・BLE
Zigbee
・サブギガ系
・他特定小電力無線局な無線モジュール

サーバーにデータを送るだけではなくて、サーバーの更新をなるべく即座にモーターに反映させたい。できればスタートポロジーなネットワークが作れてプッシュ機能みたいなものがある規格がいい。

24時間での開発で予算もそんなに多くはないということで、いつものESP-WROOM-02Arduinoとして使うことにした。サーバー→ハンガーへは、ポーリングで解決する。WebSocketのライブラリも公開されいたりするけど、ポーリングで数秒間我慢するのかリスクを取るかで前者にした。

ちなみに、これ単体で開発できるかというとそうではなくて、ESP-WROOM-02やらUSB-Serial変換やらそこそこの性能の3.3Vレギュレーターが必要である。幸いスイッチサイエンスで売られている開発ボードを1個持っていたので、実験機はそれを使うことにした。量産機は、スイッチサイエンスの商品を土曜日に手に入れることはできず仕方ないのでT字の変換基板とレギュレーターを購入することに。

www.switch-science.com

そういえば、RaspberryPi ZERO が日本でも売られるという話がありますが、どうなんでしょう。あの小ささと価格でLinuxが動いてくれるのはIoT系のプロトタイピングには万々歳なように思います。インターネットで行われていることをマイコン側からやるの大変なんだもん。

さて、コアとなるマイコンが選定されたわけで、モーターとか温度とかどうするか、という話になる。

まず、温度センサと発熱シート。発熱シートは秋月で売っている。温度センサは、I2Cで読み取れるものなどでも良いが、何故かこのときはアナログなICを選定。ESP(ryのアナログ入力が1Vまでなので、1℃10mV出力のLM35DZを適当にピックアップ。ヒーターを動かすFETは適当に2SK4150を選ぶ。ゲートしきい電圧の低さだけで選んだ気がする、今思えば微妙な選定である。あんまりFETの選定に知見がないのが露わになった。

あと、他のハンガーが選ばれたときに動くためのモータードライバを選ぼうとした。ここで大失敗を犯したのである。ロジックが3.3Vで、モーターの定格も3Vくらいであると考えて~~みたいな感じで行ったが、突入電流ナメてた。DRV8832というI2C制御のモータードライバを選定したものの、最終的には時間の都合もあってFET一個のTブリッジになってしまった。詳しくは後で。

さらにさらに、ハンガーが移動するときに距離測ってればスマートなシステムにならない?ということで、距離センサも選定。移動するときもそうだし、台数とハンガーラックの距離を測っておけば戻るときに等間隔な位置まで戻るというのもできそうである。数十センチの範囲が検知できれば良いので、GP2Y0E03を選んだ。4-50cmが測れるI2C制御。

あとは3.3Vレギュレーターとして結構余裕のあるPQ3RD23を選んだ。余裕あるしモーターも回ってくれないかなーとか思ってたけどそんなことはなかった。定格は満たしていてもピークがね。

とまあ仕様決定と部品の選定を開始2時間半くらいで行い、買い出しに行き、買ってきた。

まず距離センサとモータードライバを試す。というか、サーバーに定期的にアクセスしてJsonをパースするプログラムの基本形は、以前作ったことがある*1ため、ほぼ流用できるので、周辺部品をどうにかする段階にあった。

DRV8832は、電源がちゃんと供給されていないとI2Cバスを殺すから気をつけようね!!ACKが帰ってこないなら、マイコンは次の処理に入るはずなのに、何故かアドレスを送った状態でマイコンが止まる。結構悩まされた。(配線の問題だね!)

DRV8832は電源電圧低下を検知すると勝手に止まるから、余裕のある電源にしようね!レギュレーターの下に引っさげたモーターは、直付けでは動くもののドライバーを介すと動かず、エラーが出る。電源にコンデンサ並べればいいのかもしれないが、あいにくそういう計算は知見がないので、時間の都合もあってシンプルにTブリッジにした。しかもレギュレーター介さず電池直付けである。

距離センサは、値が読めたり読めなかったりで悩んでいたが、これは原因がよくわからなかった。エラーは「スレーブアドレスを送ったがACKが帰ってこなかった」だが、その通信前後は正常だったり。上記モータードライバをはずして、モジュールをちゃんと配線し直したら正しく読めたので、動作確認はした。

とまあ色々悩んでいたら、時間も過ぎ、4台作るにはそろそろ量産に入らないといけないという段階になった。

何より困ったのが、ESP-WROOM-02への書き込みである。書き込みモードは、IO0をLOWにした状態でRESETを一旦LOWに落とすという動作が必要なのだが、タクトスイッチがなかったためジャンパワイヤを手操作である。しかも、たしかに書き込みモードに入っているのに、書き込みに失敗する。なんでやーーー。ここは知見不足というか、もっとうまいやり方があるきがする。コンパイルも長いし書き込めないしで量産機はしんどかった。

あまり長々と書くのもあれだけど、ハードの開発というところで悩んだのはこのあたり。あとはマイコンに載せるソフトでも色々悩んで入るけど、基本的に僕がソフトを作るのが苦手なのが原因である。



以上がIoTハンガー「TOKICHIRO」の回路部分である。最後のほうはデモのために試行錯誤と微調整を行っている。口先だけみたいになってしまったのが本当に悲しい。一応色々考えて実装も半分できていたんですよ!!!!!

■できたこと
1. ESP-WROOM-02がサーバーに温度センサの値と自分に割り振られたIDを送る
2. サーバーは発熱するかしないか、ハンガーを移動させるかどうかのフラグなどを返す
3. ハンガーは、自分のフラグが立っていたら動かない
4. 他のハンガーのフラグが立っていたら、横に捌ける
■できなかったこと
・ハンガーがかけ直されたら、等間隔な位置まで戻る
距離センサと正転逆転できるモーターが必要だった
・全部を通した機能評価
発熱して、温度取って、サーバーに送って、サーバーが選ぶ というのを4台分動かせなかった(そもそも4台動かなかった
・安定した動作
ちゃんと動いたのは一台だけ、もう一台は通信はできているもののモーターが動かず、残り2台は謎の沈黙

ハードウェアはしんどいなぁと思う。思うのだが、今回悩んだことは十分な事前計画や「念のため」によって回避できた事が多い。熟考せず稚拙な手を使ってしまう上にトラブったときに焦って変な対策を取ってしまうのが僕の欠点である。もっと聡明な人がハードを作ればこんな風に悩んだりはしないのかなぁと思いつつ。

でもまあ、実際にものが動くっていいと思う。スマートフォンやパソコンによってモニタがインターフェイスデファクトスタンダードになってしまったかのように思われる今、必要なのはハードウェアの存在アピールなのだと思う。広い意味でのIoTっていうのは、そうした液晶の中にしかなかったUIを更に広げて物的な存在に落とし込めることが出来ることだと思っていて、いままでになかったテクノロジーと人とのコミュニケーションのチャンネルを生み出すことができると感じている。そんな細かい話はどうでもよくて、選ばれた服がハンガーラックの中央に寄ってきて、それ以外の服が横に捌けるとか面白じゃん。そういうことです。

*1:2016年3月のHackUでSilexという卓上ロボットを作ったときのもの