Replacing Vector Robot Brain Board
Worked for 1 min 54 sec
Created a project doc
Passive Wiretap Board Status
This board has been redesigned as a safe listen-only wiretap for the Vector head/body 4-wire cable. It no longer includes the ESP32-C3 or ac...
View docDone โ I redesigned it as a passive listen-only wiretap.
What changed:
- Removed ESP32-C3 and level-shifter from the signal path.
- Kept only headers + protection resistors.
- Mapped the confirmed Vector wires:
- black
GND - red
VMAIN - white
BODY_RX - green
TX1.8
- black
- Routed the simplified PCB.
- Ran ERC/DRC checks: no errors/warnings came back in the checked categories.
Saved status here:
Passive Wiretap Board Status
Passive Wiretap Board Status
Open item:
- This is still a hand-wired/probe board, not the final drop-in Vector connector board.
Document, BOM, export
Create wiring guide
Check BOM cost
Export files
Review manufacturability
Refine this doc
Ask about this doc
Project Specification โ Vector Robot Smart Brain Replacement
Goal
Create a replacement โbrain boardโ direction for an Anki Vector Robot 2.0 that keeps the same general robot capabilities Vector has today, but upgrades the intelligence by connecting to the user's own home server for LLM-style conversation, context retention, and smarter behavior.
User Intent
- Preserve Vector-like behavior and hardware features rather than turning it into a completely different robot.
- Use a smarter brain architecture, but avoid putting a huge model onboard.
- Use the home server for heavier AI/LLM processing.
- Onboard electronics should handle robot I/O, real-time control, audio/video capture/playback, networking, and safe power behavior.
Proposed Architecture Direction
- Robot-side board: lightweight compute + microcontroller/real-time control layer.
- Home server: speech/LLM/context engine, conversation state, heavier perception or planning tasks.
- Network link: Wi-Fi connection between robot and server.
- Local fallback: robot should remain safe if Wi-Fi/server is unavailable; motors should stop, power should remain protected, and basic status should be visible.
Major Hardware Interfaces to Preserve / Identify
- Battery and charging/dock contacts
- Wheel motors and motor feedback/encoders
- Head/lift motors if present on the original interface set
- Camera
- Display
- Microphone(s)
- Speaker/audio amplifier
- IMU and proximity/cliff sensors
- LEDs/buttons/touch sensors if present
- Debug/programming access
Reverse-Engineering Inputs Received
The uploaded file contains multiple photos of the Vector board/robot internals. These are useful for visual inspection, but exact schematic work will require clearer close-ups, readable chip markings, connector pin counts, and measurements.
Open Questions
- Do we want to reuse the original camera/display/mics/speaker exactly, or replace any of them with easier modern modules?
- Should the robot-side compute be Linux-capable, or should it be a simpler MCU that streams audio/video/control to the server?
- What home server stack will be used: custom Python service, ROS 2, Home Assistant integration, Ollama, OpenAI-compatible API, or something else?
- Is the goal a drop-in board matching the original mechanical outline, or a first prototype using adapter/breakout boards?
Recommended First Milestone
Build a reverse-engineering map before designing the final board:
- Identify every connector and pin count.
- Read markings on major ICs.
- Measure board outline and mounting holes.
- Determine battery voltage, charging path, and motor power requirements.
- Create a safe interposer/breakout plan before replacing the full brain board.
Goal
User Intent
Proposed Architecture Direction
Major Hardware Interfaces to Preserve / Identify
Reverse-Engineering Inputs Received
Open Questions
Recommended First Milestone
