Ember

What Ember is

Vector is a small desk robot that needed a cloud service to hear you, think and answer. That cloud is gone. The robots outlived it, and without it a Vector still drives about and reacts to being touched but cannot hold a conversation.

Ember is a complete replacement you run on your own machine: the voice server he talks to, the personality and memory behind it, the vision and behaviour work on top, and the firmware on the robot himself.

Speech-to-text and the language model are whatever endpoints you point at, so they can run on the same home network. Nothing about your house has to leave it.

What it is made of

A voice server, in Go

Speaks Vector’s own gRPC protocol, takes his audio, transcribes it, matches intents, and streams answers back. Built on wire-pod.

A brain, in Python

Personality, memory, mood, greetings and the reactions to being petted or picked up. It subscribes to the server’s events over HTTP.

A dashboard, in React

Six sections covering the robot, his face, his mind, his body and the server itself. Served by the Go binary, so there is no Node on the server.

EmberOS, on the robot

A firmware image built from WireOS: styleable eyes, always-on detectors, an on-robot thermal daemon, and updates delivered over the air from your own server.

What Ember changes

Ember began as three separate projects glued together. The glue was the problem. The personality layer had no supported way to hook into the voice server, so its installer rewrote the server’s Go source at install time — seventeen scripts that searched for literal blocks of code and replaced them. If the upstream project reformatted a line, a script quietly matched nothing and the feature it carried disappeared with no error.

Ember replaces that with an event system inside the server. The server posts a JSON event whenever something happens to the robot, and anything that wants to react subscribes to it. The brain is now one subscriber among several; the Home Assistant bridge is another. Nobody patches anybody’s source, and taking a newer upstream is an ordinary merge.

A note on what is proven

This is one person’s robot, not a product. A lot of the newest work is written, reviewed and staged but has never run on hardware — the robot’s battery failed and he has been left on his charger since. Pages here say so where it applies. Take anything marked untested as a description of intent, not of a measured result.

Where to go next

• Architecture — the four parts and the interfaces between them
• Events — the interface everything else plugs into
• Vision — what he can actually see
• Social reactions — what he does when a cat comes over
• Sounds — how he makes a noise
• Power and battery — where the power goes on the dock
• Modes and sound sets — one switch for eyes, behaviour, persona and noises
• The dashboard — the six sections
• EmberOS firmware — what it changes, and how it is installed
• HTTP routes — the full route list