はじめに
AIの開発環境として、pythonが多く使われています。特に開発環境では、VS-code, jupyter-labで開発されている方も多いのではないでしょうか？さらにAIの応用例として、Roboticsが上げられます。先に言っておきましょう、ロボは漢[おとこ]のロマンであると。
SBCジャンキー
SBCとはSingle Board Computerの略称です。ラズパイとかそんなのをイメージしてもらえば良いと思います。これ、自分がそうなのですが、新しいのを出るとつい買ったりしませんか？すぐに「勉強」とか「Armの新しいSoCには常に触れておかねば！」とか適当な理由を付けて買います。期末に予算が微妙に余ると、「じゃ、買っておくか!?」って感じで。SDにイメージを焼くとこまではやるんですが、その後は特に使うまでもなく。のべつまくなしに買うのも大人げないので、もっともらしいルールを自分の中で設けます。「64bit以上のSoCとOS」、「サイズはラズパイと同一」とか。でも、なぜか予算にはあまり縛りを設けず、割と高めのSBCを買ってしまったりします。最近だとJetson-Nanoとか…。
応用と運用のたたかい
最初のうちは、Home-AutomationとかIoTの勉強とかをそれなりにやるんですが、SBCの増殖の方が導入より圧倒的に速く、運用が追いつかかなくなります。しまいには「なんで、こんなボード買ったんだろ？」ってなります。買ったのは自分なのに…。
意味のあるスケールとは?
IoTをはじめとしたシステムのPoCが成功すると、二言目には「それ、スケールできるの？」って話になります。売上だったり、導入台数だったり、その時の営業やコンサルの立ち位置で文脈は変わりますが、PoCの後にこの言葉が来るのは皆さんの皮膚感覚でしょう。なぜかスケールが先に来て「投機的実行」がなされた皆さんのSBCを意味のあるものにしましょう。だからと言って、各SBCにセンサを１個だけ付けて、廊下に50cm毎に設置しても意味ないですよね？
で、ロボ軍団
数が多ければ多いほど楽しくうれしいのは軍団を作ることです。古では春秋戦国時代、現代では社内派閥がそれですね。個性に溢れた個で構成されていると魂が揺さぶられます。様々なSBCで構成されたロボ軍団はこの文脈をそのままトレース出来ます。ついでにセンサもつけちゃいましょう。赤外線とか紫外線とか温度とかも。熱源(赤外線)探知が出来るロボに索敵させて、ヘビー級ロボから発射されるミサイル攻撃。妄想が広がりまくリングですね。
で、jupyter-lab
やっとjupyter-labまで来ました。自分より皆さんのほうがjupyter-labには詳しいと思うので、そのものの説明はしません。応用例のみ、簡潔に記述します。一言で言うなら、
ロボットにそれぞれ、jupyter-labのサービスを実行させ、手元のPCに接続されたゲームコントローラで制御する。
これを行うためには、FrontEnd(PC)のブラウザでゲームコントローラの入力値を読み取り、jupter-lab上で実行されているpythonスクリプトに入力値を渡し、ロボの動作にします。
リアルタイム制御
ロボをはじめとした組み込みシステムの制御になると、この言葉が不可分のように出てきます。誤解を恐れずに言えば、どんなシステムにも「リアルタイム制御成分」はあります。リアルタイム制御とはリアルタイム性が成立しているかどうかになります。リアルタイム性とはその時間内での動作実行を運用上、許容出来るか、どうか？になります。Linux, クライアント・サーバ, インタプリタとリアルタイムとは程遠い三連コンボが今回のシステムです。
Trade-off
先程述べたスケールがPoC後の話なら、Trade-offは設計・開発・実装時に使われる言葉です。今回のシステムにももちろんあります。代表的な例としては、アナログスティックを切り捨てたことです。アナログスティックの読み取り速度(Sampling-rate)とイベントの発生回数(Frequency)が遅すぎました。ロボの移動速度についていけずに制御不能です。ここでのトレードオフとして、リアルタイム性を確保するためには、Sampling-rateとFrequencyを上げるか、ロボの移動速度を下げるしかありません。前者はシステムの構成上、不可能ですし、後者は利用していて面白く有りません。
最後に
こんな中二病が結晶化したプロジェクトの顛末記を最後まで読んでいただいて、本当にありがとうございます。システムを作っているうちに、妄想が広がりました。ついでにリアルタムシステムの端緒を知っていただきたく書いてみました。