完全オフラインで動作！Jetson Orin NX搭載の自律型スーツケースロボット「Sparky」を自作してみた

同じく同意！

ケースはElecrowのJetson AIスターターキットを改造したものだよ。もともとセンサーボードのスーツケースと画面が付いてたやつね。センサー学習用のプラットフォームだったものを、「Sparky」に変身させたんだ。会話パイプライン、ペルソナ作り、顔のアニメーション、デバイス上のコントロールパネル、センサーからプロンプトへの統合、そしてキャッシュ安定化のためのプロンプトエンジニアリングまで全部自分でやったよ。Elecrowのキットはベースとして最高だから、もし探してる人がいればおすすめだけど、本来の用途とは違う使い方だね。

センサーと小さな画面だけで450ドルはかなり高いね。まあ、勉強代が含まれてるってことかな。
Jetsonじゃなくてスマホじゃダメなの？

僕が買った時はElecrowから直接で179ドルだったよ（関税は別だけど）。転売屋はかなり上乗せしてるけど、学習用としてはいいスタート地点だったよ。

スマホのCPUでも小さなLLMは動かせるけど、I²C、SPI、GPIO経由で全センサーを制御するのは無理だし、flash attentionと12KのKVキャッシュを使って14-15 tok/sの速度を維持しつつ、ビジョン、STT、TTS、キオスク表示を並行処理するなんてできない。それにUSB周辺機器をつないで長時間ヘッドレスで動作するように作られてないからね。Jetsonは産業用I/Oを備えたエッジAIコンピュートボードだし、僕がやりたかったことを実現するには不可欠だったんだ。

あ、AliExpressで450€で見つけた。Raspberry Piが余ってるからぶち込んで、スマホから推論させるのもアリだな。にしても、クールなプロジェクトだね！

それ最初思ったわ。バカなやつが爆弾だって騒ぎ出しそう。

いや、もっとすごい。「スマート爆弾」みたいなものだ。

いいじゃん、8GBで18 t/sはかなり優秀だよ。自分はNX SUPERで14-15 t/sくらいかな、LLMと他の処理を全部並列で回してるからそのくらいになっちゃうんだよね。

質問への回答だけど、Piper TTSは軽量な方だよ。中品質の音声モデルで常駐60-80MBくらい。生成速度も速いからOrinクラスのハードウェアなら実質タダみたいなもん。SenseVoiceSmall STTは重めで、ロードの仕方にもよるけど800MBから1GBくらい食うかな。自分とこではどっちもCPUバウンド（GPUじゃなくてCPU負荷が高い）だから、LLMとVRAMを取り合うことはない。合わせてもシステムRAMを1GB追加するくらいで、GPUメモリはほぼゼロ消費で済むはず。

8GBのNanoで予算的に考えなきゃいけないのは、画像認識にどれだけ余裕を持てるかだね。Gemma 4のネイティブマルチモーダルを使うなら、mmprojの重みでLLMの上にさらに2GBくらい上乗せされる。画像認識を諦めれば、音声パイプラインには十分な余裕ができるよ。自分が最終的に16GBのNX Superに乗り換えたのはそれが理由。

ちなみに、あえてヘッドレスで運用してるの？それとも単にディスプレイがいらないユースケースだから？

詳細な回答ありがとう！こっちはRAMを節約するためにヘッドレスで走らせてるよ。GNOMEだと600MB以上食っちゃうからね（8GB環境でそれを選ぶのはどうなのって思うけど）。Nano向けの公式LLMチュートリアルはollamaと0.9-1.8Bモデルを推奨してるけど、ollamaはRAM食い虫だし、llama.cppならスワップなしで4Bモデルを動かせることを考えると、かなり奇妙な選択だよね。

GNOMEは頭の痛い問題だよ。一度削除を試みたけどブートプロセスが崩壊してしまった。Yahboomのイメージではgdm3もgnome-shellもaccounts-daemonも、デスクトップなんて触らなくてもシステムに深く食い込んでいるんだ。Sparkyの顔がChromiumのキオスクモードで動いていて、ChromiumがXセッションを必要とするから外せないんだよね。自動起動で全画面のChromiumを立ち上げて、PixiJSの顔の裏に隠しているからユーザーはGNOMEの存在に気づかない仕組み。安全に無効化できるサービスを削るスクリプトはあるけど、グラフィカルなJetsonのベースラインはやっぱり重いね。Ollamaに対するイライラもよく分かる。同じハードウェアで同じモデルを動かしてもllama.cppの方が明らかに数値がいいし、公式チュートリアルがNanoで1BモデルにOllamaを使わせるのは、シリコンの性能というより「出荷のしやすさ」を優先した補助輪みたいなものに感じちゃうよね。

理論上は、Gemma-4-e4bはマルチモーダルサポートでSTT（音声認識）をネイティブに扱えるはずなんだけど、こういうビルドだとあえて別のSTTパイプラインを組み合わせているのをよく見かけるんだよね。理由はよく分からないけど、多分ツールやドキュメントが足りてないせいじゃないかな。

両方使ってるよ。メインのテキストパスはSenseVoiceSmallに任せて、Gemma 4のオーディオエンコーダー（mmprojのgemma4a）は、Sparkyに「今の声のトーンどう？」とか「今何語で喋ってる？」みたいに聞かれた時に、口調やアクセント、言語、背景音を判断するオンデマンド用として使ってる。

ほとんどのビルドでメインのSTT（音声認識）にGemma 4が使われない理由はレイテンシだと思う。マルチモーダルオーディオエンコーダーは、LLMがトークンを認識する前のエンコードパスだけで1ターンあたり約700msかかるんだ。SenseVoiceSmallなら約150msで、VAD（音声区間検出）が常時動いてるからエンドポインティングは実質タダみたいなものだし、ユーザーが喋り終わる頃には文字起こしもほとんど完了してる。llama.cppのオーディオパスはワンショット形式だから、クリップ全体を渡して待たなきゃいけない。チャンクストリーミングの実装は1～2週間かかるパッチが必要だけど、700msの価値があるとは思わなかったんだ。

だからSparkyはハイブリッド構成にしてる。毎ターン安くて速いSTTを使いつつ、単に何を言ったかだけでなく、どう喋っているかを聞き取る必要がある時だけ、ネイティブなマルチモーダルオーディオを使うようにしてるよ。

サンクス！そう、温度センサーは、彼（ロボット）に毎ターン状況を伝える30個くらいのセンサーのうちの1つだよ。光、湿度、気圧、IMU、超音波、PIR、環境マイク、それにカメラからの顔認識と感情解析も入ってる。時刻データもね。公開してないカスタマイズ用インターフェースがあって、個別にセンサーをオンオフできるようにもなってる。

メモリに関しては、セッション内だと12Kのコンテキストを持てる。セッションをまたいでも顔IDは保持されるから、誰が戻ってきたかは名前で認識できるんだけど、会話の記憶はリブート時にリセットされる仕様にしてある。長期間覚えておくべきことのためにローカルのベクターストアも考えたんだけど、何を記憶して何を忘れるかの判断が難しいんだよね。チャットログを全部保存してモデルのファインチューニングも試してみたけど、結果には満足できなかった。

もともとは、周りに漂ってるメタデータを全部かき集める小さなハッカーオウムみたいに作ってたんだよね。WiFiのプローブ要求、BLEの広告、サブGHz帯のリモコン、航空機のADS-B、通り過ぎる車のTPMS、気象観測所、ポケベル、FOB、NFC/RFID、一時はMid-360S LiDARで部屋の形状データまで取ってた。全部アグリゲーターデーモンに送って[SIGNALS]コンテキストブロックとして蒸留してたんだけど、彼が自分を「生きてる」と思い込み始めて、カメラで見たものに対する妙なコメントの方がRFデータよりずっと面白くなったんだ。だからハッカーオウムの役割は降格ってわけ。

その通り、プロジェクトはかっこいいんだけど /u/CreativelyBankrupt 、兄弟、一体何やってんの？死ぬのが怖くないのは勝手だけど、他人を巻き込んで殺すようなことすんなよ。

おいおい……マジかよ！この二面性よ！

でしょ？あの異質な感じが気に入ってるんだ！

Sparkyはかなり限界に達してるから、今はAGX Thor 128GB Blackwellアーキテクチャを使って別のロボットを組み立ててるところだよ。真の自律性、永続的なメモリ、もっと深い視覚認識を実現したいんだ。Sparkyでコンセプトと技術スタックは実証できたから、次は記憶して進化できるレベルを目指すよ。

かなりのこだわりだね！いいよ！バッテリーは何を使う予定なの？

あと、この冒険の記録ってどこかで公開してる？あなたの経験から学びたいな。

ありがとう！バッテリーは一番手こずった部分だね。NVIDIAが4月にThorの開発キットからMicrofit DC入力を公式に非推奨にしたから、「LiFePO4パックを直結すればいい」という当初の算段は白紙になったんだ。今は28V/140WのUSB-C PD 3.1 EPRが必須条件。だから高出力のAnker Prime 27,650mAh（250W出力、PD 3.1 EPRで140W）を最有力候補にしてる。約100Whで、Thorフルパワーなら1時間、40W運用なら3時間持つ計算。BMSと過電流保護が内蔵されていて、普通のUSB-C PDアダプタで充電できるしね。自作パックよりはスマートじゃないけど、NVIDIAお墨付きだし、バッテリー・BMS・充電器・マルチレール配電を一つのパーツでまかなえる。カスタムのマルチセルLi-ionやLiFePO4も作れるけど、専門家じゃない自分が安全認証まで取るのは無理だしね。家で動くロボットに未加工のセルを積むよりは、商用のUL認証品を使う方が安心だよ。Microfitの道もNVIDIAの指示を無視すれば物理的には可能だけど、保証は無くなるし安全設計も自己責任になっちゃうからね。ドキュメント化について聞いてくれたけど、今のところ予定はないんだ。自分はロボット工学者というより映像制作者だから、このプロジェクトは仕事の合間の夜や週末を使って進めていてね。この野心的な次のステップを完成させるために、ハードルを下げておきたいんだ。無事に動くようになったら分解の投稿くらいはするかもしれないけど、期待しないで待っててくれ。君が作っているものも上手くいくよう応援してるよ！

こういう詳細について誰かと話せる機会がなかなかないから嬉しいよ。まさに僕がセンサーデータをプロンプトに組み込み始めた時にハマった罠そのものだね。Sparkyは既にその戦術で動いてるよ。ENV（環境情報）はシステムプロンプトじゃなくてユーザーメッセージに入れるようにしてるから、ペルソナや会話履歴のKV（キーバリュー）は変動する末尾部分に関係なくキャッシュされたままになる。それにクールダウン付きのイベントゲート（閾値を超えた時だけ送信して、カテゴリに応じて1〜10分間は静かにする）を設けてるから、ほとんどのターンではENVブロックが発生せず、きれいなキャッシュ済みプレフィックスにヒットするんだ。

数値はすべてフォーマット前に丸めてるよ。華氏、湿度、光、気圧は整数だし、距離もセンチ単位の整数だ。唯一小数点以下1桁を残してるのは、ユーザーから「今の気温は？」と聞かれた時用のパスの摂氏だけで、これこそ君が指摘してた精度を保つべきケースだね。

唯一の懸念は、整数の境界線で発生する銀行丸め（22.5°Cが72°Fに、22.51°Cが73°Fになるようなやつ）だけど、クールダウンゲートのおかげで最悪でもセッションごとに1回で済むから、今はそのままにしてる。君の環境ではキャッシュヒット率がどれくらい改善したか測定した？実際どれくらい効果があったのか興味があるよ。

正直に答えると、自分の方で正確なヒット率を計測したことはないんだ。ただ、定性的には明らかで、vLLMの長文コンテキストにおけるTTFT（最初のトークン生成時間）が十分に下がったから、回避策として短いプロンプトを使う必要がなくなったよ。

Anthropic APIを使うなら、レスポンスのメタデータでcache_readとcache_creationのトークンが確認できるから、数値が欲しいならそれが一番確実な方法だと思う。イベント発生時にクールダウンを挟むのはうまい抜け道だね。この手のイベントタイプを個別に分類する手法は初めて見たよ。

そう、cache_readの分割が一番分かりやすい指標だよね。llama-serverにもリクエストごとのログ行にそれと似たものがあって、プロンプト評価を見ると新しいトークンとキャッシュされたプレフィックスの長さが分かるけど、まだセッション全体をスクレイピングして割合を計算するところまでは手が回っていない。リストには入れておくよ。イベントタイプの分類自体は別の問題から生まれたものなんだ。Sparkyが直近の [ENV] の内容にこだわりすぎちゃうから、天気について延々と独り言を言わないようにクールダウンを導入したのが最初。キャッシュの効率が上がったのは、その後の副次的なメリットとして気づいたんだ。

GPIO周りは一番いじってて楽しいよ。コツは、センサーの生データをそのままプロンプトに流し込まないこと。本当に伝える価値がある時にだけ、自然言語に変換してSparkyに伝えるようにして、かつ同じ内容を連発しないようにクールダウンを設けるんだ。「temp=48F, humidity=22%, distance=12cm, pir=1」って送る代わりに、モデルには「目の前12cmに誰かの顔があるぞ！」とか「48°Fで凍えそう」って教える感じ。イベントが発生したターンのユーザーメッセージに[ENV]プレフィックスとして追加してる。何も起きないターンが大半だから、キャッシュもいい感じに保てるよ。

カメラも同じで、キーワード連動型にしてる。「見て」「説明して」「何が見える？」と言われた時だけ、直近のフレームをそのターンに添付するんだ。これで他のターンの負荷を大幅に抑えられるし、モデルが画像の描写だけで詰まってしまうのも防げる。

ペルソナはテンプレートシステムで、6つの声（デフォルトのSparky、コメディアン、不機嫌、ストーリーテラー、思想家、SFオタク）をセッション中に切り替えられるようにしてる。一番甘く見てたのは、モデルが自分のパターンをエコーしちゃうのを防ぐためのポストプロセッシング（後処理）かな。これがないと、Gemma 4は30ターンも経つと毎回同じ文体で返答を始めるからね。

あと、Sparkyの妹分としてSparkleも作ったんだ。CrowPi 3の学習ステーションをベースにしてて、4インチの顔ディスプレイ、カメラ、マイク、オンボードセンサー/IOボード、64ピクセルの光るLEDハートマトリックスなんかを搭載してる。RPi5ベースでWiFiとクラウド推論を使ってるんだけど、マイクで拾った会話をGroqホストの120B LLMに送って推論させて、Llama 4 Scoutでカメラのオンデマンドビジョンを処理して、温かい女性の声で返答する。その間、PixiJS/WebGLの顔やLEDハート、ステータスライト、ブザー、ハプティクスで感情や状態を表現するんだ。物理的な体は可愛いサイバネティックな実験台って感じで、小さくてセンサー満載で表情豊か。わざとアート作品っぽくしてて、フロスト加工のカバーを被せると休止中は光るインテリア照明になるよ。

今はまさにワイルド・ウエスト状態で、やれることは山ほどある！ぜひ何か理由を見つけて始めてみてよ。

AIとロボット工学の組み合わせは最高に楽しいよね。ただ、頭脳をRaspberry PiやJetsonみたいな小さなボードに詰め込むのは結構限界があると思う。RAMやパワーが足りなくて動作を滑らかにするのに苦労するのは正直しんどい。クローズドループ回路もいいけど、ワイヤレスで脳と接続するフル機能のロボットも最高にクールだよね。自分自身で考えて動けるものを作ってみたい。メモリやキャッシュの面では、ちゃんとした推論サーバーを使ったほうが圧倒的に楽だしね。

チーズと油分が多すぎる！

ああ、それなら絶対いけるよ。2070の8GBならE4BをQ4で動かす余裕は十分にある。デスクトップクラスのCUDAは低バッチ環境だとJetsonよりもワットあたりの性能が高いから、たぶん20 tok/s以上は出るはず。

まずは外装とかのハードウェアはスキップしていいと思う。とりあえずローカルでllama.cppを使ってE4Bを動かして、USBマイクの音声をSenseVoiceSmallでテキスト化（STT）して、それをPiper経由で音声合成（TTS）する。これで完全にオフラインな音声ループが完成するよ。

結局のところ、肝心なのはプロンプトとキャラ設定の作り込みだね。Sparkyがうまくいってるのは、システムプロンプトでキャラクターになりきらせて、周囲の情報（センサー、視覚、履歴）をすべてそのフレームワークの中に落とし込んでアドリブを利かせているから。それを学ぶにはノートPCで十分だよ。

E4BとPiperとマイクを用意して、キャラになりきるプロンプトを作って、10回やり取りしてもキャラ崩れしない環境が作れたら、どんなチュートリアルより勉強になると思う。

ちょっと違う用途を考えてるんだけど。2016年モデルの13インチMacBook Proがキーボード故障した状態で転がってるんだよね。捨てようと思ってたんだけど、これを見て、小さなスタンドに固定して古いルンバの上に乗せたら面白いんじゃないかと思いついた。そうすれば「ロボット」が地下室をうろついて、出会った人に話しかけたりできるだろ？「脳」の部分は自宅のWiFi/LANでAI用に動かしてる別のマシンに任せて、このノートPCは顔を表示してI/Oを担当するだけにする。ルンバは少し改造が必要そうだけどね。会話中はちゃんと静止してくれるといいんだけどな。

その通り。モデルがある程度の性能に達すると、生のトークン/秒（tok/s）なんて気にならなくなって、再プリフィル（re-prefill）ではなくキャッシュされたプレフィックスをどれだけ活用できているかが重要になるんだ。Jetsonの場合、キャッシュされたTTFTは240ms前後だけど、8Kコンテキストでコールド状態からのプリフィルだと数秒はかかっちゃう。Sparkyの最近の進歩のほとんどは、モデルの変更じゃなくて、この変化しやすい状態をどこに配置するかを調整したことで得られたものだよ。あと、あまり話題にのぼらないけど重要なのはコンテキストが一杯になった時の挙動だね。Sparkyが話し終わった直後のバックグラウンドのウォームアップサイクルでプリエンプティブなトリミングを行っているから、ユーザーが返信する頃にはキャッシュの整理が完了していて、古いターンが追い出された後でもフォアグラウンドのTTFTを1〜3秒以内に収められているんだ。

正確なヒット率は出していないけど、平均的なTTFTは1.8〜2.6秒の間に収まっているよ。プレフィックスがキャッシュされていて、新しいユーザーのトークンだけをプリフィルすればいい状態だからね。キャッシュミスが発生するのはセンサーイベントで [ENV] が動くターンに集中するけど、それらは次の静かなターンで自己解決する。もう一つのミスは履歴のトリミングで、だからこそ前述のプリエンプティブなトリミングをウォームサイクルで実行して、フォアグラウンドのTTFTに影響が出ないようにしているわけ。バッテリーについてはまだ正式な検証をしていないけど、50,000mAhのポーチをケースに詰め込んでいて、Jetsonは処理負荷に応じて15-25〜40Wくらいを消費する。一日中オン・オフを繰り返しながら会話する分には十分快適だよ。スタジオに一日持ち込む時も、ACアダプタを持っていくことはほとんどないね。

知らないネタを教えてくれて助かるよ。ミレニアムの頃はPCゲームばかりで、N64の波はあまり通ってこなかったんだ。コンソールへの再入門はGameCubeからだったね。

Riveじゃなくて、PixiJSでレンダリングしてるよ。口の動きはPiper TTSから出力された音声をRMS駆動で直接制御してる感じ。Piperが音声を生成して、こっちで512サンプルのサブウィンドウ（43Hz）ごとにRMSを計算して、その値をWebSocketで顔側にストリーミングしてるんだ。口の形は3次ベジェ曲線を使ってて、上唇はキューピッドボウの形。RMS値を6段階の振幅にマッピングして開閉具合を制御してる。閉じるときは80msの減衰時間を持たせてるから、音節の合間でパッと閉じることなく、ちゃんと喋ってるように見えるんだ。音素のアライメントもビセーム合成も不要で、生の音声さえ取れればどんなTTSでも使えるよ、RMSさえあればいいからね。面白いことに、もともとの計画ではDuolingoのキャラリップシンクを参考にRiveを使うつもりだったんだ。最初はスプライトベースのビセームにしてたし、プロジェクトが落ち着いたらRiveに移行する予定だった。でも、3次ベジェとRMS、それに感情表現の口角変化を追加して実装したら、画面上での見栄えが十分良くて、結局Riveはロードマップから消えたよ。わざわざ別のランタイムを追加してまで品質が上がるわけでもないしね。

そう、あの3秒のラグっていうのが、まさにキャッシュミスが発生してる状態なんだよ。一番難しいのは、機能を追加するたびに新しい値がプレフィックスに紛れ込んでくるのをいかに食い止めるかっていう管理の部分だね。