Raspberry Piを起点に、ロボットの脳と筋肉の分け方、Pi Zero、mechArmの実時間制御の正体、停電や電波断でも破綻しない縮退設計までを考察する

mechArm の中で毎日動いている Raspberry Pi を、部品ではなく設計対象として考え直す。

Pi は何を担うのか。何を担わせてはいけないのか。この線を引かないままロボットを増やすと、知覚、判断、実時間制御、安全停止、クラウド依存が一つの塊になる。

今回考えたのは、ロボットの「脳」と「筋肉」の分け方だ。

Pi は Linux が動く小さなコンピュータで、知覚、段取り、ネットワーク、上位ロジックに向いている。一方で、ミリ秒単位の実時間制御や、電源喪失時の安全動作を Pi に背負わせるべきではない。そこはマイコン、サーボ、ローカル安全層の仕事になる。

mechArm の制御階層を確認し、Pi Zero の位置づけを整理し、最後にハコブくんを停電や電波断でも破綻させない縮退設計へつなげる。

Pi を部品ではなく、設計境界として見る

あらためて Raspberry Pi について詳しく知りたい。mechArm にも使われ、これからもっといろんなところで活用すると思うので、一度よく考えたい。

Pi は既に手元で毎日触っている部品だ。だからこそ、部品としてではなく、設計の境界線として見直す意味がある。これから SO-101 やハコブくんへ広げるとき、「何を Pi に任せ、何を任せないか」を決める土台になるからだ。

歴史がその見直しを後押しする。Pi は2012年に教育用の安価なコンピュータとして始まったが、いまでは産業・組み込み用途にも深く入り込んでいる。2024年6月にはロンドン証券取引所へ上場し（Raspberry Pi Holdings plc）、産業インフラとして資本市場に評価される会社になった。入口として安く始めたものが、時間をかけて産業の土台になる。この筋は、Pixels to Motors の「安価なまま民主化する」という賭けと重なる。趣味のオモチャが消えるのではなく、産業に染み込んで残っていく。SIer に向けて「これは消えないプラットフォームだ」と言える材料になる。

Pi は脳であって、筋肉ではない

ロボティクスで Pi を考えるとき、ここを外すと設計を間違える、という一点がある。

——Pi は何を担い、何を手放すのか。

Pi は Linux が動く小さな PC（シングルボードコンピュータ）だ。OS が裏でいろんな処理を割り込ませるので、「1ミリ秒ぴったりでサーボに指令を出し続ける」ような硬いリアルタイム制御には構造的に向かない。だから Pi が担うのは、カメラ画像の処理や VLM 判定の橋渡しといった知覚、どのスキルを次にやるかを決める段取り、そして上位の Python ロジックだ。関節を実際に滑らかに回す層は、別のマイコンが持つ。これがロボットの基本形になる二層構造で、後で mechArm の実機がそのままこの形をしていることを確認する。

「脳」と「筋肉」を分けるという見立てを一度握ってしまえば、機種が変わっても「Pi をどこまで使い、どこから別のものに任せるか」の判断がブレなくなる。この比喩は、これから触る SO-101、ハコブくん、myAGV、そして手元の mechArm を横断して効く。

Pi の系列を、脳のサイズ違いとして読む

Pi は単一の製品ではなく系列だ。形が違うのは用途が違うからで、3つの形がそのままロボティクスでの役割に対応する。

フルサイズの Pi 5 は2023年9月発表で、Pi 4 比で CPU が2〜3倍、PCIe を備えていて NVMe や AI アクセラレータを挿せる。試作はフルサイズで回し、構成が固まったら Compute Module で自分のロボットに組み込む。この系列構造が、そのまま試作から製品化へのパスになる。

Pi Zero は小さな Pi であって、小さな Pico ではない

フルの Raspberry Pi と比較したとき、Zero で何が削ぎ落とされたのかを掴みたい。

名前が似ているので Pico（マイコン）と混同しがちだが、Zero は Linux が普通に動くフルの Pi だ。ただ小さく・省電力にしただけ。前の3層で言うと、Zero は Pico の「リアルタイム筋肉」層には降りてこなくて、フル Pi と同じ「脳・段取り」層にいる。層が増えるのではなく、「脳」のサイズ違いが増える、という理解が正しい。

——では、Zero で得るものと、諦めるものは何か。

current で意味があるのは Zero 2 W だ。1GHz クアッドコア 64bit Cortex-A53、RAM 512MB、サイズは65×30mm、重さ約10g。従来 Zero に対しシングルスレッド+40%・マルチスレッド5倍で、性能はざっくり Pi 3 相当になる。フル Pi と並べると、得るもの／諦めるものがはっきりする。

一番効くのは512MB の壁だ。デスクトップ用途やブラウザは実用にならず、画面なしの Lite を headless で回すのが前提になる。ローカルで VLM や重い画像処理を回すのは無理と思っておく。Zero は「重い処理はしない、軽い Linux ノード」と割り切る石だ。供給は不安定な時期が続いていて、価格事情も現時点では Pi 5 / 4 とは違う可能性があるので、採用するなら入手性は都度確認したほうがいい。

このプロジェクトでの居場所は、「身体の上に小さな Linux が欲しいが、計算はいらない」場面だ。自作の小型ロボットに載せる薄い Linux ブリッジ。あるいは StackChan のような顔・人格プロトタイプ。Python が動き、対話 API を直接叩け、ネットワークも持てるので、マイコンより表現の自由度が高い。「身体と人格の設計」という UX 文脈に、一番フィットする使い道かもしれない。

mechArm の実時間制御は Pi の外にある

mechArm の中でリアルタイムのモーター制御機は何が担っているのか、具体的な仕様を確認しておきたい。

mechArm の中で実時間モーター制御を担っているのは、Raspberry Pi ではない。Pi はあくまで send_angles() を投げる上位レイヤーで、実際にモーターを握っているのは別の MCU とサーボ自身だ。Elephant Robotics の公式ドキュメントと pymycobot のドキュメントで裏を取った構成を、下位ほど実時間に近い順で並べる。

まず Raspberry Pi 4B（quad-core Cortex-A72、1.5GHz、実機は Ubuntu 18.04）。Linux 上で pymycobot が send_angles(degrees, speed) を送るだけの上位制御で、モーター制御ループは持たない。通信は /dev/ttyAMA0、baud 1000000。Mac から Pi へは別途 daemon TCP（192.168.2.1:5555）で繋いでいる。

その先にいるのが M5Stack Atom（ESP32 系・AtomMain ファーム）だ。pymycobot のドキュメントは「Atom を上のモジュールに焼く」構成を明記していて、API も「Atom と接続できているか確認」という形になっている。Pi が喋っている相手は、この ESP32 だ。これが Pi からの指令を解釈してサーボバスを駆動する MCU になる。最後に各関節の6個のスマートサーボ。繰り返し位置精度 ±0.5mm。角度や温度をサーボ単位で読み戻せることから、各サーボが自前のエンコーダと電子回路を持ち、位置保持ループを内部で回していると見るのが妥当だ。

M5 版と並べると構造がはっきりする。M5 版の myCobot/mechArm は、ベースの M5Stack Core Basic と先端の M5Stack Atom の2モジュールで動く。下の Basic に minirobot、上の Atom に atommain を焼く、という分担だ。Pi 版は、このベースの Basic を Raspberry Pi が置き換えた格好になっている。先端の Atom（ESP32）はそのまま残って、サーボを叩く役を続けている。

前に整理した「脳と筋肉」で言えば、Mac と Pi 4B が脳・段取り、Atom（ESP32）が筋肉のコーディネータ、各サーボが反射を内蔵した筋肉だ。Pi Zero の回で「Pico 相当のリアルタイム MCU が別に要る」と話したが、その層は、実は手元の mechArm の中にすでに具現化していた。

——測れる手段を先に。推測で焼かない。

ここは「測れる手段を先に持つ」という原則の出番だった。「たぶんこうだろう」で書くと、過去に何度も繰り返した機構の作り話に逆戻りする。だから公式ドキュメントと pymycobot で裏取りしてから書いた。一つだけ残った未確定は、サーボの正確な型番と、閉ループが完全にサーボ内部で閉じているかどうかの切り分けだ。get_angles() やサーボ温度をサーボ単位で読み戻せる事実から推定はできるが、断定はしない。実機の servo info 読み出しか公式の仕様で裏を取ってから確定させる。

境界が分かると、原因を探す場所が変わる

この階層が分かると、いくつかの判断が変わる。

Mac/Pi 側のループ（ビジュアルサーボなど）は監督ループであって、モーター制御ループではない。だからカメラレートでゆっくり回っていても問題ない。実時間で位置を握っているのは下流の Atom とサーボだ。send_angles(degrees, speed) の speed も、Atom／サーボ側が補間して動くための指令であって、Mac が逐次モーターを回しているわけではない。

把持の「握り続ける」もグリッパーサーボの仕事だ。これまで悩んできた、再リフトでグリップが緩む現象を、この層構造で見ると当たりをつける場所が変わる。Pi/Mac のコードではなく、サーボへの保持指令・電流・タイミング側を疑うほうが筋が良い。GRIP コマンド後にサーボが保持トルクを維持できているか、撮影のための再リフトで何かが保持指令を上書きしていないか。境界線を引けたことで、原因を探す場所が一段下に降りた。

ハコブくんは、ネット無しでも最低限動くべきだ

ハコブくんを作るとなると、ローカル環境でも動くような設計にする必要があると感じている。基本はネットに繋いで動くが、停電や電波環境が悪くても最低限の動きは保証する設計にしておかないと、病院のような環境では使い続けてもらうことは難しい。

これは単なる安全要件である前に、採用され続けるための要件だ。病院のスタッフは忙しくて、ネットのブリップ一回で固まるロボットをデバッグする気はない。「電波が悪い日は使えない」が一度でも起きると、信頼が切れて棚に戻される。だから「停電・電波断でも最低限動く」は、技術の話である前に「使い続けてもらえるか」の話になる。

設計の言葉にすると、目指すべきは graceful degradation（段階的縮退）だ。全部か無かではなく、上の機能から順に落ちて、下に行くほど絶対に落ちない、という階層を作る。ここで一つ、混ぜてはいけない区別がある。「電波断」と「停電」は別の故障で、別の答えが要る。電波断は計算機が動いていてクラウドに届かないだけだから、ローカルにフォールバックを置けば吸収できる。停電はロボット自身が電気を失うので、フォールバックでは救えない。ここで必要なのは「止まらないこと」ではなく、安全側に倒れることだ。電源が落ちる瞬間に、止まる・荷物を落とさない・通路を塞がない・できれば寄せて知らせる。病院だと「倒れるときに非常口や廊下を塞がない」は本物の要件になる。

——全部か無か、ではなく、どこまでが落ちるのか。

これまで積み上げた「脳と筋肉」「実時間境界」が、そのまま縮退の設計に効いてくる。下の層ほどネットから独立していて、絶対に落ちない。

縮退は「気をつける」では崩れる。実装中にうっかりクラウド依存を主ループに混ぜてしまう（たとえば「次どこ行く？」を毎回 LLM に聞く）と、そこが切れた瞬間に止まる。だから決め事を一本だけ置くと固い。主制御ループは、ネットワーク呼び出しゼロで完走できること。クラウド呼び出しは全部「任意・タイムアウト付き・ローカル既定値あり」にする。どのクラウド呼び出しにも、タイムアウトで発火するローカルのデフォルトを必ず一つ用意する。ネットは性能を上げるために使うが、安全と最低限の任務はネット無しで完結する。

各層に何を入れるかを整理すると、こうなる。

• 反射・安全層（常時ローカル）：停止・障害物回避・荷物保持・電源喪失でのフェイルセーフ。マイコンと LiDAR が担い、ネットに一切依存しない。

• ローカル自律層：地図ナビ・既知ルートの完遂・基地への帰投・状態の発話・ログの退避。機体の Pi 上で動き、offline でも完結する。

• クラウド拡張層：対話・VLM 判定・配車・学習。ネット必須で、落ちても安全。あくまで上に足す層。

縮退する機械は、自分の状態を説明する

縮退する機械は、自分の状態を読めるように伝えないと信頼されない。ナースから見て「なぜ止まったのか分からないロボット」は、安全に止まっていても怖い。ここで StackChan の顔と声が、飾りではなく正直なステータスチャンネルになる。「ネットが切れたので、この配達だけ終えて基地に戻ります」と offline でも言える。これは前から温めてきた「意図の可読性（readability of intent）」そのもので、しかも縮退時の意図表現という、まだ誰もちゃんとやっていない Motion UX の領域だ。普通のロボットは「正常時にどう動くか」しか設計しない。こちらは「壊れかけのとき、人にどう振る舞うか」を設計対象にできる。failure を隠さず公開して学ぶ、というプロジェクトの姿勢と、これ以上ない一貫性がある。

見落とせない副産物もある。病院でカメラ画像をクラウド VLM に投げるのは、電波以前にプライバシー・規制で引っかかる可能性が高い。患者や廊下が写るからだ。ローカルファーストは耐障害性だけでなく privacy-by-design でもあって、「なぜ全部クラウドに出さないのか」の説明が二重に立つ。これは導入先に効く言葉になる。

土台はすでにローカルファースト寄りだ、というのが朗報だった。myAGV（Pi 版）は、SLAM と経路ナビを機体の Pi 上でローカルに回す設計で、LiDAR で障害物を見て止まるのも機体側にある。図の内側2層は、プラットフォームとして概ね手元にある。クラウドが要るのは一番外側だけだ。だからやることはゼロからの作り直しではなく、三つに絞られる。ナビと安全を絶対にクラウドに依存させない規律。ネット無しでも喋れる最小の状態発話セットをローカルに持つこと。電圧閾値で安全側に倒す、電源喪失の安全停止。この三つが設計の芯になる。

頭脳はネットの向こうに置いていい。だが、安全と最低限の任務は、ネットの無い場所で完結していなければならない。

ロボットの脳を考えるというのは、何を賢くするかではない。何を絶対にクラウドへ預けないかを決めることでもある。