Maker Faire Tokyo 2019に自動積荷システム「Salaie」を出展してきた！
毎年見に行っていたMaker Faire Tokyoですが、今年は出展してきました！
何を出展したの？
「Salaie」 と名付けた、自動積荷システムを社内の有志と作りました。
「Salaie」 は、ベルトコンベアで流れてきた荷物をカメラで撮影します。 次に、撮影した画像を推論し、アーム側へ箱の分類情報を渡します。 最後に箱の推論情報を受け取ったアームが指定の場所へ荷物を運びます。 これで一つの処理が完了し、それを続けていきます。
どのようなシステム構成なの？
「Salaie」 のシステム構成ですが、Raspberry Pi上のKubernetes（k3s）がMQTTブローカーの役割と全体の制御をおこなうNode-REDを実行しています。 Kubernetes（k3s）を使用している理由ですが、正直家でRaspberry Piを使用を想定するとクラスタリングをする必要はありませんが、今回は業務用を想定したため「冗長性」「負荷分散」「Infrastructure as Code」の点からKubernetes（k3s）で実装しました。
また、学習済みのモデルはGoogle Colaboratoryを使って作成しました。その学習済みモデルをJetson TX2に配置し、撮影した画像を推論しています。 また、学習済みモデルはFlaskでローカルサーバーをたて、GETリクエストから推論を実行できるようにしておき、デバッグもおこないやすくしておきました。
その他のデバイスは、Arudino YUNを使い制御しています。
- ステッピングモーター
- 光センサー（ベルトコンベアの停止判定用）
- アーム
トラブルはあったの？
準備段階
準備段階では、学習済みモデルをFlaskで読み込む処理が正常に実施できませんでした。 Tensorflowの特定のバージョンで起こるバグのせいでFlask起動時に学習済みモデルを正常に読み込めず苦労しました。 GitHubのissueに載っていた回避スクリプトを実行したら動きました。 （該当のissueが見当たらないため見つけたら記載） 色んな場所で相談させてくださった方ありがとうございます。
本番当日
本番では、会場の光度と練習していた社内の光度に大きな違いがあり、デモがうまく動きませんでした。 モバイルのライトを緊急で購入し、光センサーの周りの光度をあげて対応しました。
他には、各デバイスが持ってきたルーターに繋がらないところもトラブルとなりました。
IoTにおけるデモ・リハーサルの大切さ
社内で電源を抜き再びつけるところからリハーサルを3回ほど実施したにもかかわらず、想定外のトラブルに合いました。 この3回リハーサルの間にもトラブルがあり、それらを解消できたので当日のトラブルを必要最小限に抑えられたのかなとも思います。素振り大切。 例えば、Kubernetesがコンテナイメージを取得する際、持参予定のルーターが外部へ接続されていないために、コンテナイメージ取得待ちになっていたことがありました。
まとめ
IT企業ではありますが、プログラミングをガリガリ書かない企業であるため、どれだけ簡単に実装できるかにこだわりました。その反面、今回の展示のためではなく、その先の業務用を意識した構成にし最後まで完成させられたところは良かったと思います。
また、会場でのトラブルを見学に来てくれた方に説明すると、「展示会場ではネットワークと光系のトラブルが多い」と教えていただけたり、出展しなければわからないことも多く知れたところが自分にとって多くプラスでした。
興味はあるけど普段の業務では触れない技術も触れて、知的好奇心を大きくくすぐられる準備期間とMaker Faire Tokyo 2019になりました。
見学してくださった方、質問してくださった方、実装に困っていたときに相談に乗ってくださった方、最後まで一緒にやり遂げてくれたメンバーの方、ありがとうございました。
