Skip to content
Pages of the documentation

Satellites

Devices that give Nestor a voice and a body, and how a person pairs them.

A satellite is a device paired with the Nestor server: a Raspberry Pi with a speaker, a tab on a wall tablet, a Reachy Mini robot. People type on it, talk to it, or both: a keyboard and a screen are enough, and so are a microphone and a speaker. A camera or motors are optional capabilities too: the device declares them, a person allows them, and nothing in Nestor assumes they are there.

Satellites connect to the server’s satellites channel, on port 8471 (its port in nestor.yaml). In writing they need nothing more; to talk aloud, give the channel a voice, with the voice extra (see Providers).

What a satellite does

  • It pairs once and keeps its token.
  • It declares in a manifest who it is and what it can do.
  • It holds a link to the server, a WebSocket that carries every message.
  • It talks with the assistant in writing, aloud or both: typed text and written answers on the link, audio both ways over WebRTC.
  • It carries out the server’s intents and acknowledges each one.
  • It reports the observations it was allowed to (speech activity, a person detected).

The server asks for intents, never for motions. With intent.expression and joy, a robot moves its head and antennas, a screen could draw a face, a plain speaker ignores it.

Capabilities

Capability The device…
text.input sends what a person typed
text.display shows the assistant’s answers
audio.capture sends its microphone to the server
audio.playback plays the server’s voice
audio.speech_activity reports when someone starts and stops speaking
vision.person_detection reports a person it sees
expression.emotion shows an emotion (intent.expression)
motion.head moves its head with the beats of speech (intent.beat)
device.identify makes itself noticed when a person looks for it

Pairing

Pairing needs a proof that a person meant it. The proof travels one of two ways, and the first one accepted wins:

  • a device code, six digits the device presents, which the person types in the admin;
  • an enrollment code made in the admin (K7QF-2M9X), which the person gives to the device, usually as a pairing URI: nestor+http://nestor.local:8471/?code=K7QF2M9X.
Method The person…
device_code.display reads the code on the device’s screen and types it in the admin
device_code.speech hears the device say its code and types it in the admin
enrollment.input types the enrollment code on the device
enrollment.provisioning puts the pairing URI in the device’s configuration (flag, environment, file)
enrollment.qr shows the pairing URI’s QR code to the device’s camera

Every device supports enrollment.provisioning; the others follow from what it has (a screen, a speaker, a keypad, a camera). The SDKs declare them for you.

Add a satellite

In the admin, open Satellites, then Add, and pick a method. You can name the device, put it in a room and narrow the capabilities it gets. With an enrollment method, the admin shows the code and its pairing URI; with a device code, it lists the devices waiting and you type the code of the right one (Identify makes a device blink or chime to tell them apart).

The same from the server’s command line, while Nestor runs:

nestor satellites add --room salon --name "Living room speaker"   # prints the code and the pairing URI
nestor satellites approve 042917                                  # the device code a device presents
nestor satellites revoke enceinte-salon                           # unpairs a device

approve --only audio.capture,audio.playback grants fewer capabilities than the device declared. Then, on the device, hand it the pairing URI:

NESTOR_PAIRING_URI='nestor+http://nestor.local:8471/?code=K7QF2M9X' nestor-satellite run --room salon

Ready to run

  • nestor-satellite run: this machine’s microphone and speaker, from the Python, TypeScript or Rust SDK.
  • nestor-reachy: Reachy Mini, whose head and antennas follow the conversation (its simulated twin for now).
  • A browser tab, with the TypeScript SDK.

To write your own, the protocol is the reference, the schemas give each message’s shape and the conformance suite checks a device against both.