Software Architecture Notes — wire-pod / Vector Home Server
Primary Repository
- GitHub:
kercre123/wire-pod
- Purpose: free, fully-featured server software for Anki / Digital Dream Labs Vector robots.
- Intended use: allows Vector 1.0 / 2.0 voice commands to work without the paid official cloud service.
Acknowledgements Captured from README
The README credits:
- Digital Dream Labs for open sourcing
chipper and creating Escape Pod.
- bliteknight for making wire-pod more accessible with pre-setup Linux boxes.
- dietb for rewriting chipper and giving tips.
- fforchino for localization, multilanguage, and other features.
- xanathon for publicity and web-interface help.
- Contributors who opened issues or pull requests.
Repository Layout Observed
Top-level folders/files include:
chipper/
vector-cloud/
docker/
compose.yaml
dockerfile
setup.sh
update.sh
The chipper/ folder includes:
cmd/
epod/
intent-data/
jdocs/
pkg/
plugins/
session-certs/
webroot/
go.mod
go.sum
start.sh
Relevant Features for This Project
wire-pod already matches much of this project’s software goal:
- Acts as a local Vector voice/cloud replacement.
- Supports custom commands.
- Supports knowledge-graph / question-style commands through providers such as Houndify, OpenAI, Together, or Ollama.
- Supports direct LLM routing / intent-graph behavior with supported providers, where unmatched transcribed text can be sent to an LLM without requiring a special phrase first.
- Maintains compatibility with Vector SDK configuration when a bot is authenticated.
Home Server Runtime Notes
Supported host environments include Linux, macOS, Windows, Android, and Docker Compose. For this project, a Linux home server is the best target.
Important assumptions:
- Vector and wire-pod should be on the same LAN.
- The web UI generally runs on port
8080.
- Some setup paths expect
escapepod.local / mDNS behavior.
- Only one active wire-pod instance should be running on the LAN.
- Production robots need the appropriate Escape Pod firmware path; regular Vector firmware alone is not enough.
Hardware Implication
This reduces the need to replace the whole brain immediately. A safer path is:
- Use stock Vector hardware + wire-pod to establish local-server voice/LLM behavior.
- Add custom commands/LLM routing on the server side.
- Only replace or augment hardware after the desired behavior is proven in software.
ESP32-C3 Role with wire-pod
ESP32-C3 is still useful, but mostly as an auxiliary controller:
- Extra sensors/accessories
- Simple telemetry bridge
- Debug/status interface
- Experimental motor/sensor control outside the stock Vector stack
It should not be the main Vector replacement brain if the goal includes camera, display, audio, and stock-like behavior.
Recommended Project Direction
Use wire-pod as the baseline home-server brain first. The custom PCB should initially be an interposer/expansion or body-controller experiment, not a full Qualcomm head-board replacement. This keeps the robot functional while enabling custom LLM behavior faster and with much lower risk.