YouDuck.ai
≡

First run

Last updated

Getting from a powered robot to one you are driving is four steps. This page is the order, plus the check that belongs at each one.

1. Establish what the software is doing

The first command, every time:

robotctl version

It reports what every daemon is running against what is installed, and warns when they disagree.

Do not skip it. A daemon still serving old code after an update looks exactly like the fix you just shipped not working — ruling that out first saves the wrong investigation.

Then the overall picture:

robotctl health

Hardware and software in one report. It exits non-zero when the robot is unhealthy or unreachable, so it can gate a script directly. Note the deliberate exception: a hot motor or a pinned component is reported but does not affect the exit code — those are information, not a verdict.

2. Power the joints

sudo robotctl robot init

This powers the joints and ramps to the home pose over about two seconds. It moves every joint, so have the robot on its stand before you run it.

init needs no policy. The gamepad’s Start button does this on its way to driving, so running it by hand is mostly a bench thing.

To go back to limp:

sudo robotctl robot relax --yes

relax cuts power and the robot collapses if nothing is holding it — which is why it wants --yes. It is the only way back to limp short of pulling the plug.

Three ways to stop, which are not interchangeable:

Action Result
robot relax --yes Power cut, robot collapses
Press Start again Policy stops, robot keeps standing
robot.stop Velocity zeroed, robot keeps standing

3. Pair a gamepad

Pairing is once per pad. After that padd.service drives whatever pad connects, from boot.

sudo robotctl pad pair

No MAC address needed — the robot looks for a pad in pairing mode and takes the one it finds.

Then check it:

robotctl pad status
pad     Xbox Wireless Controller 78:86:2E:BB:13:28  connected
padd    active — driving whatever pad connects

Two lines, because they fail separately. A connected pad with a dead driver looks exactly like a working robot ignoring you.

4. Press Start

Nothing moves until Start is pressed. Start toggles the policy. With it off, the robot stands powered and ignores the sticks entirely — which is the single most common “it is broken” misdiagnosis.

When it will not move

In order:

  1. robotctl version — is the running code the code you think it is.
  2. robotctl health — is anything unhealthy, and why. A policy that failed to load is named here.
  3. robotctl monitor — the most informative of the three.

monitor puts what a client asked for beside what was actually applied, and names the reason when they differ. Safety clamps things constantly, and “the stick is forward and the robot is still” is unreadable without that reason spelled out:

deadman — no intent arrived recently, velocity zeroed

The bottom border names the policy that is loaded — the actual .onnx files, and whether a standing network is configured at all. This matters more than it sounds: walk is a mode that two releases with completely different gaits both report.

Down the right-hand side the robot is drawn as it is standing, posed from the measured joint angles and tilted by the IMU’s gravity vector — the same visual model the policies were trained against. A leg folded the wrong way is just numbers in the joints table; here it is obvious. It appears whenever the terminal is wide enough (about 110 columns). d turns it off, [ and ] orbit it.

Next