Riser oled

katanori（カタノリロボ）

Gemini Live API と音声で対話する小型ロボット。実機で会話が成立する状態まで到達済み（2026-07-26）。 電池で起動・会話・ミュートリレーまで通った（2026-09-02）。

⚠ 2026-09-15 に全体を書き直した（2026-08-19 の状態のまま止まっていて、「筐体 v2 を設計中」「電池はまだ」と書いてあった）。

📖 かたのりの歴史 — 筐体 8 版の形と死因、燃えた・壊れた・また鏡だった事故の記録

筐体 v6.1（レジン・板 6 枚）の分解図。天板（つまみ・会話ボタン・スピーカー）・左右の壁・フロント（紫）・床の間に、 ハブ基板 katanori61・ReSpeaker Lite・OLED・電池が入る。

組む順の当たり検査（hardware/tools/sweep_movie.py・2026-09-18）— 部品を実際の入れ方で動かし、当たりを色で出す。 青＝空き・橙＝了承済みの当たり・赤＝新しい当たり。

ハブ基板を左の窓から差す	ReSpeaker を上から降ろす	蓋をたわませて降ろす

元の mp4 と判定の表は docs/_img/sweep/2026-09-18-nylon/。

[ユーザーの声]
   ↓ マイク
ReSpeaker Lite (XMOS XU316, ハードウェアAEC)
   ↓ I2S
XIAO ESP32S3 ── OLED 128x64（顔の表示）
   │                └ ハブ基板（ミュートリレー・電源・INA226・つまみ AS5600）
   ↓ WebSocket over TLS
Cloudflare Durable Object（中継・音声変換）
   ↓
Gemini Live API（音声in / 音声out）

現在の状態

ハードウェア（いまここ）

🔒 現フェーズは「最小単位で動かす」 — 1台が電源から会話・安全機構まで通ること。

残りの全量は docs/TODO.md にフェーズ順で集約してある。

Wi-Fi未設定の機体を渡せば、スマホでQRを読む → 設定画面が自動で開く → 設定 → 会話、 という流れが通ります。設定済みの機体は、電源を入れるだけで自動でWi-Fiへ繋ぎ、 ボタンを押した時点でサーバーへ接続します（シリアルコンソールは不要）。

リポジトリ構成

firmware/
├── core/          純C++14のコアロジック。Arduino依存禁止。実機とシミュレーターで共有
│                  DisplayBuffer / StateMachine / Face / RobotCore
├── hal/           IHal.h（プラットフォーム抽象）
├── esp32/         実機ファームウェア（PlatformIO）   ★詳細は firmware/esp32/README.md
│   └── src/       main.cpp / NetLink / AudioIo / Provisioning / RootCa.h
│                  Battery（INA226）/ BootLog（再起動の理由・ウォッチドッグ）/ Console（Wi-Fi 越しのシリアル）
│                  Settings（利用者の設定・katanori.local の設定ページ）/ VoiceClips.h（焼き込み音声・自動生成）
├── serlog.py      実機のシリアルを読み続けてログに落とし、cmd.txt からコマンドも送る道具
└── blank/ i2sprobe/ xmosver/   切り分け用の小さなファーム（空スケッチ＝発熱の切り分け／I2S の探り針／XMOS ファームの版数読み取り）

katanori-backend/  Cloudflare Worker + Durable Object  ★詳細は katanori-backend/README.md
├── src/           index.ts（中継とプロトコル）/ resample.ts（24k→16k）/ fillers.ts（つなぎ言葉の音源）
└── tools/         gen-fillers.mjs（つなぎ言葉）/ gen-voice-clips.mjs（実機の焼き込み音声 → VoiceClips.h）/ tts.mjs

simulator/         Windows用シミュレーター（Win32 GDI、外部lib不要）
├── win32/         main_win32.cpp
├── wrapper.py     PC上でマイク・スピーカー・DO接続を担うPythonラッパー
└── tuner.html     ロボットボイスの調整UI

hardware/          筐体・つまみ・基板の CAD（OpenSCAD）。直下の .scad は case_v5（いまの実機）・case_v6_1（レジン）・case_v6_1n（MJF・現行）
├── pcb/           KiCad の板（katanori61/ ＝ v6.1 のハブ・発注待ち。katanori61_audio/・_hub/ は保留中の音声の板）と、
│                  回路図 → 配置 → 自動配線 → 製造ファイル → 検算のスクリプト。読み方は docs/PCB-V61.md
├── parts/         部品ライブラリ（parts.scad / respeaker_lite.scad / knob_v61n・spk_v61n・btn_v61n ほか。

docs/ の読み方

動かし方

実機

cd firmware/esp32
pio run -e xiao_esp32s3 -t upload
pio device monitor -e xiao_esp32s3 --port COM4   # ポートは pio device list で確認

ポート番号はPCごとに変わります（この機体は環境によって COM3〜COM5 になっています）。 USBドライバは不要です（ネイティブUSBなので挿すだけで見えます）。

シリアルで ? を打つとコマンド一覧が出ます。会話は wifi → c → 1（喋る）。 抜き差しの多い作業では python firmware/serlog.py がポートを待ち続けてログに落とします。 筐体に入れて USB が挿せないときは、同じ Wi-Fi から katanori.local の TCP 23 番（telnet・PuTTY の Raw）で 同じコンソールが使えます。2 回目からは pio run -e xiao_esp32s3_ota -t upload で Wi-Fi 越しに焼けます。 詳細・配線・トラブルシューティングは firmware/esp32/README.md。

バックエンド

cd katanori-backend
npm install
npm run deploy

プロトコルの詳細は katanori-backend/README.md。

シミュレーター（PC単体で顔と会話を試す）

# w64devkit を PATH に前置してから
simulator\build.bat
python simulator\wrapper.py

顔は実機と同じ firmware/core が描き、DOへの接続も実機と同じPCMバイナリモード （?voice=Achird&pcm=16000）を使います。バックエンドやプロンプトの変更は、 実機へ焼く前にここで確かめられます。 一方 I2S・AEC・Wi-Fi は実機でしか出ません。 詳細は docs/SIMULATOR.md。

実機で判明した重要な事実

公式ドキュメントに書かれておらず、実機で踏んで初めて分かったものです。 同じ罠を二度踏まないよう、詳細は各READMEに記録してあります。

未着手の一覧

会話は動くが、自立ロボットとしての土台（筐体・認証）がまだ空白。 何が無いかは docs/TODO.md に集約してある。 🔒 A章＝現フェーズ（最小単位で動かす）／ B章＝人に渡す ／ C章＝フェーズ2（Stackchan） の順で並ぶ。

次にやること

🔒 いまはハードウェアの段である。ソフトの新機能は現フェーズに入っていない。

1. 発注（docs/TODO.md A 章）— ハブ基板 v6.1 を JLCPCB へ、筐体 v6.1n の MJF 7 点を JLC3DP へ、一緒に出す （ユーザー判断で来月。出す前に hardware/pcb/check_fab.py で在庫と価格を取り直す）
2. ピーク電流の実測（スピーカーが鳴った瞬間）— 次の板の昇圧を 1A にできるかの決め手
3. 音量の上限を耳で決める — 天井 0.70 はイヤホンの頃の値。下げるだけなら設定の「おんりょうMAX」
4. 届いたら組み替える — E リングを実物で嵌める

その先（人に渡すため）: 肩への固定・重量 → 認証・費用の上限・QRペアリング → 実使用者テスト。 フェーズ2: 遠隔モジュール（Stackchan）を BLE で足す（docs/ARCHITECTURE.md）。

呼びかけ（「カタノリ」固定）は機体の中で聞き分けて動く。2026-09-24 に own_a で完成 （docs/WAKEUP.md）。⬜ 保留中: 証明書の有効期限検証は CONFIG_MBEDTLS_HAVE_TIME_DATE が無効で未検証だが、ピン留め済みなので実害は薄い。 自前の音声の板は量産の計画が立つまで保留（docs/VOICE-BOARD.md）。

済んだもの

• 時刻の注入（2026-07-26）— LLMは時計を持たず、聞かれると嘘の日時を答えていた。 DO側で接続時に日本時間を systemInstruction へ埋める（buildSystemInstruction()）。 Workers の Date は常にUTCなので timeZone: "Asia/Tokyo" の明示が必須。
• つなぎ言葉（2026-07-26）— 応答までの1.3秒の沈黙を埋める。DO側で完結し、 ファームの変更は不要（audioStreamEnd を受けた時点で音声を先に返す）。 音源は katanori-backend/tools/gen-fillers.mjs でTTS生成し src/fillers.ts に格納。 声名は実機が要求している Achird に合わせること（DO既定値の Aoede で焼いて 別人になった経緯あり）。詳細は katanori-backend/README.md。
• ミュートリレー（2026-08-03 決定 → 2026-08-08 駆動合格 → 2026-09-02 スピーカー線で確認）— 再生中の電池切れ・ブラウンアウトで ROM ブートログが耳元で鳴る経路を、ソフトではなく接点で塞いだ。 無通電で開くので、ファームが守っているのは「普段どおり動いているときに閉じる」だけ（docs/POWER.md 3章）。
• 電池駆動（2026-08-01 旧ボードで 20 分 → 2026-09-02 現行機で起動・完全停止・再起動）。
• 再起動の理由を残す（2026-09-12）— 2026-09-11 夜の勝手な再起動で理由が何も残らなかったため。 リセットの理由と直前 1 秒ごとの様子を RTC メモリに、前回の最後のログ約 3KB を lastlog で。固まったら 30 秒で再起動。

既知の弱点

• 設定用APは開放（暗号化なし）でページもHTTP。 入力されたWi-Fiパスワードは 設定中の数分間、近くの第三者から傍受されうる。市販IoT機器でも一般的な方式だが弱点。
• 設定ページ（katanori.local）に合言葉が無い。 同じ LAN の他人が明るさや音量の上限を変えられる。 上限より上には上げられないので耳は傷めない（Wi-Fi 越しのコンソールは OTA と同じ合言葉を最初の 1 行で求める）。
• ルートCAをピン留めしている。 接続先が発行元CAを変更すると繋がらなくなる。 更新手順は firmware/esp32/src/RootCa.h のコメント参照。
• 耳元の音圧の上限はミュートリレーが担っている。 再生中のクラッシュ・電池切れ・ブラウンアウトで コーデックが解除のまま残っても、コイルが落ちれば接点が開いてスピーカーは切れる（2026-09-02 実機確認）。 ⚠ 接点が溶着した場合は守れない。v6 で「2 極目を使い、接点 1 つが溶着してもスピーカーの回路が切れる形にする」と決めた （docs/POWER.md）。v6.1 の板のリレーは 2 極（G6S-2F）だが、そう配線してあるかは docs/PCB-V61.md に書いていない。 音圧そのものの上限（WHO-ITU H.870 / EN 50332）は未調査。
• 勝手に再起動する（2026-09-11・原因未特定）。起動の声が 5〜15 分おきに鳴り、電池を使い切った。2026-09-24 にユーザー判断で追わないことにした（クローズ）。2026-09-25 の稼働時間の実測で、電池が減ると同じ形でブラウンアウトの再起動を繰り返すのを見た（docs/POWER.md 6章）。 次に起きたら boots / lastlog で理由が読める。