• Conversation
• Long-term or session context
• LLM responses
• Custom commands
• Optional memory/personality features
• Optional local speech-to-text / text-to-speech / vision processing

• Main repo: https://github.com/kercre123/wire-pod
• wire-pod is a local Vector server / Escape Pod replacement.
• wire-pod uses/descends from Digital Dream Labs' open-sourced chipper voice-server work.
• wire-pod already supports custom commands and LLM-style integrations through providers such as OpenAI, Together, and Ollama.

1. Head board
   • Qualcomm APQ8009 Linux-class processor.
   • Handles high-level software, display, camera, audio, network, and robot behavior.
2. Body board
   • STM32F030C8T6TR microcontroller.
   • Approx. 2.8 V logic.
   • Controls motors, encoders, sensors, battery/charging, and body communication.
3. Home server
   • Target host for smarter behavior.
   • Should run wire-pod plus custom LLM/context services.

Text
Vector Robot
  |
  | existing Vector protocol / voice-server connection
  v
wire-pod on Home Server
  |
  | custom intent / unmatched speech / API bridge
  v
Local LLM Service
  |
  | optional providers
  +--> Ollama local model
  +--> OpenAI-compatible API
  +--> custom memory database
  +--> custom home automation commands

Text
ESP32-C3 / helper MCU
  |
  | UART/I2C/GPIO with level shifting
  v
Vector body/head debug or accessory interface
  |
  v
Home server API over Wi-Fi

• Clone/read kercre123/wire-pod.
• Identify where custom commands/intents are defined.
• Identify how transcribed user speech becomes an intent or LLM request.
• Document how to add a new custom command.
• Document how to route unmatched speech to a local LLM such as Ollama.

• Python with FastAPI, or Go if modifying wire-pod directly.

Http
POST /vector/chat
Content-Type: application/json

{
  "robot_id": "vector-name-or-id",
  "user_text": "what the user said",
  "session_id": "conversation-session-id",
  "timestamp": "iso timestamp",
  "context": {
    "location": "optional",
    "battery": "optional",
    "robot_state": "optional"
  }
}

Json
{
  "reply_text": "short response for Vector to speak",
  "emotion": "neutral|happy|curious|concerned",
  "action": null,
  "memory_update": "optional memory note"
}

• Store recent conversation turns.
• Store basic user facts and preferences.
• Store robot personality/system prompt.
• Keep responses short enough for Vector speech.
• Allow clearing/resetting memory.

• SQLite for simple local storage.
• Optional vector database later, but not required at first.

Sql
CREATE TABLE conversations (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  robot_id TEXT,
  session_id TEXT,
  role TEXT,
  content TEXT,
  created_at TEXT
);

CREATE TABLE memories (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  robot_id TEXT,
  key TEXT,
  value TEXT,
  confidence REAL,
  created_at TEXT,
  updated_at TEXT
);

• Ollama on the home server.

• llama3.2:3b
• qwen2.5:3b
• phi3:mini
• Any small model that responds quickly enough on the user's server.

• Logic analyzer
• Multimeter
• Oscilloscope if available
• UART decoder
• I2C decoder

• BODY_TX
• BODY_RX
• TXD
• RXD
• SCL2
• SDA2
• GND
• 2.8 V

• Use level shifting when connecting 3.3 V hardware like ESP32-C3 to 2.8 V Vector logic.

• Wi-Fi connection to home server
• Simple UART bridge
• Simple sensor/LED accessory controller
• Watchdog/failsafe helper
• Telemetry sender

• Replace Qualcomm APQ8009
• Run camera/display/audio stack
• Run local LLM
• Directly drive motors without a verified motor-driver design

• Connect to Wi-Fi.
• Connect to home server WebSocket or MQTT endpoint.
• Support OTA update if possible.
• Support serial debug logging.
• Use level-shifted UART/I2C when connected to Vector logic.
• Fail safe if server disconnects.

Json
{
  "device": "vector-helper-esp32c3",
  "type": "telemetry",
  "battery_mv": 4100,
  "status": "online"
}

Text
You are an expert robotics software engineer helping me reverse engineer and extend an Anki / Digital Dream Labs Vector Robot 2.0.

My goal is to keep the robot behaving like Vector, but make it smarter using my own home server. I want LLM-style conversation, retained context/memory, custom commands, and short natural responses. I do NOT want to put a huge model onboard the robot.

Important background:
- The main open-source project is kercre123/wire-pod: https://github.com/kercre123/wire-pod
- wire-pod is a local Vector voice/cloud replacement based on DDL's open-sourced chipper / Escape Pod work.
- wire-pod already supports custom commands and LLM-style providers such as Ollama/OpenAI/Together.
- Vector hardware appears split between a Qualcomm APQ8009 head board and an STM32F030C8T6TR body board.
- The body board appears to use about 2.8 V logic and handles motors, encoders, sensors, battery/charging, and body communication.
- I also have ESP32-C3 chips, but they should only be used as a helper/bridge MCU, not the whole robot brain.

Your tasks:
1. Inspect the wire-pod repository and wiki.
2. Identify the exact code paths where voice transcription becomes an intent or command.
3. Identify how custom commands are registered and executed.
4. Identify the existing LLM/knowledge-graph/intent-graph integration path.
5. Propose the smallest safe modification that routes unmatched speech to a local home-server LLM endpoint.
6. Build or sketch a local LLM bridge service using Python FastAPI and SQLite memory.
7. Make the bridge compatible with Ollama first.
8. Keep Vector's spoken replies short and robot-friendly.
9. Add a simple memory system that stores conversation turns and user facts.
10. Provide install/run instructions for Linux.
11. Do not assume any hardware replacement is needed unless wire-pod cannot support the behavior.
12. If hardware reverse engineering becomes necessary, create a separate plan using a logic analyzer on BODY_TX/BODY_RX/SCL/SDA with 2.8 V-safe level shifting.

Expected output:
- A concise architecture summary.
- The relevant wire-pod files/functions to modify or configure.
- A minimal patch or new plugin/service design.
- FastAPI service code for /vector/chat.
- SQLite schema for conversation and memory.
- Ollama integration code.
- Example config values.
- A safe hardware reverse-engineering checklist, but only as a later phase.

Constraints:
- Prefer using existing wire-pod extension/config features before modifying core code.
- Keep the system local-first and home-server based.
- Avoid cloud dependencies unless optional.
- Avoid replacing the Vector brain board until software behavior is proven.
- Do not connect ESP32-C3 GPIO directly to Vector 2.8 V logic without level shifting or verified tolerance.

Python
from fastapi import FastAPI
from pydantic import BaseModel
import sqlite3
import requests
from datetime import datetime

DB = "vector_memory.sqlite3"
OLLAMA_URL = "http://localhost:11434/api/generate"
OLLAMA_MODEL = "llama3.2:3b"

app = FastAPI()

class VectorChatRequest(BaseModel):
    robot_id: str
    user_text: str
    session_id: str | None = "default"
    timestamp: str | None = None
    context: dict | None = {}


def db_init():
    con = sqlite3.connect(DB)
    cur = con.cursor()
    cur.execute("""
    CREATE TABLE IF NOT EXISTS conversations (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      robot_id TEXT,
      session_id TEXT,
      role TEXT,
      content TEXT,
      created_at TEXT
    )
    """)
    cur.execute("""
    CREATE TABLE IF NOT EXISTS memories (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      robot_id TEXT,
      key TEXT,
      value TEXT,
      confidence REAL,
      created_at TEXT,
      updated_at TEXT
    )
    """)
    con.commit()
    con.close()


def add_message(robot_id, session_id, role, content):
    con = sqlite3.connect(DB)
    cur = con.cursor()
    cur.execute(
        "INSERT INTO conversations(robot_id, session_id, role, content, created_at) VALUES (?, ?, ?, ?, ?)",
        (robot_id, session_id, role, content, datetime.utcnow().isoformat())
    )
    con.commit()
    con.close()


def get_recent_context(robot_id, session_id, limit=8):
    con = sqlite3.connect(DB)
    cur = con.cursor()
    cur.execute(
        "SELECT role, content FROM conversations WHERE robot_id=? AND session_id=? ORDER BY id DESC LIMIT ?",
        (robot_id, session_id, limit)
    )
    rows = cur.fetchall()[::-1]
    con.close()
    return "\n".join([f"{role}: {content}" for role, content in rows])


def ask_ollama(prompt):
    response = requests.post(OLLAMA_URL, json={
        "model": OLLAMA_MODEL,
        "prompt": prompt,
        "stream": False
    }, timeout=60)
    response.raise_for_status()
    return response.json().get("response", "").strip()

@app.on_event("startup")
def startup():
    db_init()

@app.post("/vector/chat")
def vector_chat(req: VectorChatRequest):
    session_id = req.session_id or "default"
    add_message(req.robot_id, session_id, "user", req.user_text)
    recent = get_recent_context(req.robot_id, session_id)

    prompt = f"""
You are Vector, a small friendly robot. Reply briefly, naturally, and with personality.
Keep the response under 2 short sentences because it will be spoken aloud.

Recent conversation:
{recent}

User said: {req.user_text}
Vector reply:
"""

    reply = ask_ollama(prompt)
    if len(reply) > 240:
        reply = reply[:237].rstrip() + "..."

    add_message(req.robot_id, session_id, "assistant", reply)

    return {
        "reply_text": reply,
        "emotion": "curious",
        "action": None,
        "memory_update": None
    }

Text
You are helping reverse engineer the hardware interface between Vector Robot's Qualcomm head board and STM32F030 body board.

Known facts:
- Body MCU: STM32F030C8T6TR.
- Body logic rail: about 2.8 V.
- Labeled signals include BODY_TX, BODY_RX, TXD, RXD, SCL2, SDA2, BAT+, BAT-, VBAT, GND, USB D+/D-.
- Body board handles motors, encoders, charger, battery, IR/proximity sensors, and touch.
- Do not drive motors or inject signals until the protocol and voltage levels are verified.

Create a safe reverse-engineering procedure:
1. Identify ground and 2.8 V rail.
2. Use high-impedance probing only.
3. Capture BODY_TX/BODY_RX at multiple baud rates using a logic analyzer.
4. Capture boot sequence, idle state, wake word/voice command activity, movement command activity, charging dock activity, and error states.
5. Decode UART framing, message lengths, checksums, and repeated packets.
6. Build a Python parser for captured Saleae/CSV logs.
7. Infer command/response packets.
8. Do not transmit onto the bus until passive decoding is reliable.
9. If transmitting later, use 2.8 V-safe level shifting and current-limited test setup.
10. Document every packet with timestamp, direction, raw bytes, guessed meaning, and confidence.