Control plane and data plane

Microduck splits inter-process communication into two layers, and knowing which is which saves a lot of searching.

Control plane: JSON-RPC 2.0 over Unix sockets

All daemons speak one JSON-RPC contract. One property of it matters to anyone using the robot:

Every client — the phone app, the web console, the gamepad, your own script — sends exactly the same calls.

There is no private interface. Whatever the official app can do, a script can do.

Data plane: sensor streams do not go through it

Sensor data is published by the daemon that owns it, and consumers subscribe on that daemon’s own socket:

• ToF depth → tof.stream on tofd
• Raw pad input → padd

Never relayed through robotd.

What that means when debugging

To see raw pad input, go to padd — it is not in the robot state stream. robotctl monitor’s p view is that separate subscription.

Likewise ToF data lives on tofd, which publishes the sensor’s own view and does not pretend to geometry it cannot compute: reprojecting a depth frame into the robot’s frame means combining it with joint state from robot.state and the head forward kinematics in the kinematics crate.