うんこボタンハードウェア量産化までの道のり

144Labの入江田です。

先日@ITさんにてうんこボタン全体の仕組みが紹介されました。

www.atmarkit.co.jp

このうち回路回りの量産化までの道のりをもう少し掘り下げて紹介します。

プロトタイピングのころ

• 1ボタンデザイン
• 電池三本電源
• ハードコードでPOC

ここまでであれば、 既知の実装の組み合わせで動作可能なものが 手早く実現できました。

電源の仕組み選択

• レギュレータ電源であればは電池３本が必須だった。
• 軽量化のために昇圧電源回路を検討
  • 電池１本
    • 消費電力的に難しかった
  • 電池２本
    • 最終的に選んだ方法
    • 電池寿命に依って単3サイズか単4サイズか検討

省電力への取り組み

いろんなサンプルコードを動作させつつ、 CPUの状況別に消費電流を計測しました。

CPU稼働中は一定した電流をコードにかかわらず 平均80mAほど消費することがわかりました。

Wi-Fi通信中の消費電流は意外と大きくピーク時に400mAを超えます。 スリープ中ESPモジュールは十分消費電流を抑えてくれるので、 周辺の回路にて消費電流が大きくならないようにデザインに気を付けました。

あとは極力スリープ状態が長くなるように動作時の処理時間が短くて済むように ファームウェアの挙動を実装しています。

Wi-Fi設定を簡単にするための取り組み

ボタンデバイスのWi-Fi設定をスムーズに行う方法の模索。

案１

• デバイスに光学センサをつける
• スマホにバーコードを表示
• ユーザーはデバイスでスマホ画面をなぞる
• 実際に動作するPOCを作った
• 成功率が悪すぎた

案２

• スマホにバーコードをスクロール表示させてそれをデバイスに読ませる。
• 実際に動作するPOCを作った
• じっと持ってる時間が長すぎた

案３

• バーコード相当を点滅で表現する。
• 実際に動作するPOCを作った
• 案２よりは早くなった
• 目に悪いし「てんかん」持ちの人への懸念もある

案４

• スマホのスピーカーまたはヘッドホン経由で設定を投入する案。
• FSK変復調実装の検討
• 大がかりになりそうとのことで断念

これらの案を試していた頃の基板

右下の突起が光センサによる読み取り部分。

既製品の仕組みを再検討

Wi-FiのAP機器などのようにデバイスで設定用のWebサーバーを立てる方向で再検討。 個人との紐づけを行う必要もあり、Webサーバー経由でWi-Fiの設定と同時に個人との紐づけも行う方法を検討することになった。

最終的にこの手法が採用されたわけなんですが、

クラウドWebサービスのUIからボタンデバイス上のWebサーバーで提供されるAPIをつつけばOKと思っていたらそれは大間違いでした。

ほとんどのブラウザはhttpsコンテンツからhttpのAPIを呼び出すことを許可してくれない。

これは盲点でした。ただ、画面遷移だけは許されていたので画面遷移でボタンのWebサーバーが提供する画面に遷移する手段を採用しました。 しかし、ユーザーにWi-Fi接続先を切り替えてもらったり戻したりしながら画面遷移を確実に行うのは大変でした。切り替えた先と通信が可能かどうか「疎通確認」をとったり、あきらめた場合の復帰手順などが必要になりました。

そしてAPIを使わずにネットの疎通が可能かどうかをブラウザだけで確認するには・・・？！

とにかくこのあたりは次から次へ課題が発生してその解決をするというのを何度も繰り返していました。

ボタン１個を２個に変更する

ボタン１つをターゲットにすれば、電源とESPモジュールとスイッチだけで実現できたんですが、ボタンを２つにしたいというマーケティングからの要望から回路構成を再検討しました。

ボタン用のスイッチを２つにすればOK？と思ったんですが、CPUを眠りから起こすためにどちらのスイッチを押しても起こすようなロジック回路の追加が必要でした。

また、CPUの起動にはわずかな遅延がありました。この遅延の間にボタンを離されるとどちらを押したのかがわからなくなってしまうことがわかりました。 ユーザーに長めに押してもらうという妥協案もあったんですが、操作感をよくするためにどのボタンが押されたのかをメモリーするための回路も追加されました。

基板の変遷

OTA機能の追加

量産に入る前にファームウェアバグの修繕対応を可能にするため、OTA機能を追加することになりました。

OTAはユーザー操作のきっかけからデバイス上のファームウェアより新しいファームウェアが有効ならばインターネット経由でファームウェアアップデートを自動的に行う機能です。

幸い採用したCPUモジュールにはそれを支援するためのブートローダーを備えており、 その機能を利用する形で実装されました。

ファームウェア配布サーバーを実装し、ボタンからのイベント送信時には必ずファームウェアバージョンを送信するようにしました。

イベントを受け取るサーバーではファームウェアのバージョンを比較してより新しいファームウェアがあればその配布サーバーのダウンロード先URLがレスポンスに載せられます。 ボタンデバイスがそれを受け取ってかつ電池残量に余裕があればファームウェアをダウンロードして更新を試みます。

そして量産の準備

ファームウェアを書き込む際には個体識別のために埋め込む情報を別途埋め込んでおり、ファームウェアを書き込む作業は一定のバイナリを書き込むだけではダメで、専用のファームウェアライターを作りました。

問題発生時のトラッキングのために固有番号をラベルで基板に貼っておくことも実施したんですが、貼り間違えが起こりにくいようにファームウェアを書き込むと同時にラベルプリントする仕掛けを作りました。

まとめ

最初のPOCは１週間もかからない感じだったんですが、製品になるまではここに書いたもの以上の紆余曲折がありました。