Command Line

menlo: save a robot, check it, and stand, balance, walk and damp it from a terminal.

pip install menlo-sdk installs the menlo command. It saves robots for the SDK and drives one through the same verbs a script uses. stand, balance, walk and damp show what they are about to do and ask before they send anything. stand, balance and walk run the readiness check for their action first and say why when the robot cannot do it now. balance on a robot already in MOVE sends at once and refuses only when state is stale or the link is lost. damp has no readiness check: it sends DAMP whatever the robot's state. Every command is sent to the robot; none is an emergency stop.

menlo --robot NAME --mode {udp,hybrid,livekit} <command>
menlo --version
menlo <command> -h

--robot picks a saved robot, --mode overrides its connection mode for this command. Without them, the command uses MENLO_ROBOT, then the default saved robot, then the only saved robot.

Setup

menlo setup

The wizard asks for a name, a connection mode, and only the fields that mode needs: the robot's address for udp, the Asimov Manager URL and an SDK credential for livekit, both for hybrid. The credential is typed masked and never printed back. Each field is checked live before it is saved:

Check	What passes
Credential	`accepted, role control, room robot-...`; a credential with the Observe role saves with a warning: it can watch, not drive over livekit
udp	state arrives from the address; the message names the robot mode it saw
livekit	the room is joined; the message lists the tracks it found

A failed check asks "Save anyway?". When another robot is already the default, the wizard asks whether this one should be. --no-check skips the live checks. The wizard needs a terminal; without one it exits 2. SDK credentials come from the Developer page in Asimov Manager; Drive from Python shows the steps.

Saved robots live in ~/.menlo/robots.toml, readable only by you.

Robots

menlo robots                 # table: default mark, name, mode, address, manager, room
menlo robots add lab --mode hybrid --udp 192.168.1.20 --manager https://manager.example --credential ...
menlo robots add lab --limits 0.3,0.3,0.6
menlo robots use lab
menlo robots remove lab

add on an existing name keeps the saved values it is not given, so the second add above only sets limits. Flags it needs and does not have are asked for in a terminal; with --no-input, missing flags exit 2. --default makes the robot the default; --no-check skips the live check. With every flag it needs, or with --no-input, a failed check saves nothing and exits 1; in the wizard, you can choose to save despite a failed check. use and remove exit 1 on a name that is not saved.

Status

menlo status
menlo status --watch

Connects, reads state for a second, and prints a panel: the robot, its connection mode and address; a badge READY, NOT READY or FAULTED with the first blocking reason; the robot mode and whether it is armed; battery; the hottest joint; faults; the state rate; and whether the state is fresh. It sends nothing. --watch refreshes until q or Ctrl-C.

Stand, Balance, Walk, Damp

menlo stand
menlo balance
menlo walk --vx 0.2 --duration 3
menlo walk --vyaw 0.3 --duration 2
menlo damp

Command	What it does
`stand`	refuses from MOVE; a robot already in STAND is left alone; otherwise asks, sends `stand()` and waits up to 10 s for the robot to report STAND and arm, then prints `Armed: ready to balance, menlo balance`. Exit 3 when it does not arm
`balance`	from STAND, gives the robot up to 5 s to be seen armed, asks, sends zero velocity and waits up to 5 s for the robot to report MOVE, then prints `Balancing in MOVE: ready to walk, e.g. menlo walk --vx 0.3 --duration 3`. In MOVE, never asks: sends zero velocity twice, 0.1 s apart, and the robot stays in MOVE, balancing in place. Refuses on stale state. A script that holds a velocity re-sends it at 10 Hz and must itself be stopped
`walk`	runs in MOVE only. `--duration` is required, above 0 and at most 10 s; at least one of `--vx`, `--vy`, `--vyaw` must be nonzero. Asks, checks again, holds the velocity for the duration, then sends zero velocity: the robot stays in MOVE, balancing in place. Ctrl-C sends zero velocity and exits 130. A fault that ends the walk early is named, with a note that it latches until the firmware restarts, and exits 3
`damp`	asks, sends `damp()` and waits up to 10 s for the robot to report DAMP, then prints `Robot mode DAMP.`, or the fault that holds it

damp is not an emergency stop

DAMP makes every actuator compliant: a standing robot folds to the ground. Use the Asimov Manager E-Stop in an emergency; see Stopping the Robot.

Confirm Before Sending

stand, balance, walk and damp print one line: the robot, its connection mode and address, its robot mode, battery, and what will happen. Then they ask Proceed? [y/N].

$ menlo walk --vx 0.2 --duration 3
lab (hybrid, 192.168.22.32) · MOVE · battery 82 % → walk vx 0.20 m/s, vy 0.00 m/s, vyaw 0.00 rad/s for 3.0 s, then balance in place
Proceed? [y/N] y
Walking. Ctrl-C ends the walk.
Walk done. Robot mode MOVE, balancing in place.

$ menlo stand
lab (udp, 192.168.22.32) · DAMP · battery 82 % → stand, then wait until armed
Proceed? [y/N] y
Standing. Waiting for the robot to arm (0.5 s upright)...
Armed: ready to balance, menlo balance

$ menlo balance
lab (udp, 192.168.22.32) · STAND, armed · battery 82 % → balance: MOVE at zero velocity, the walking policy balances the robot
Proceed? [y/N] y
Balancing in MOVE: ready to walk, e.g. menlo walk --vx 0.3 --duration 3

$ menlo damp
lab (udp, 192.168.22.32) · MOVE · battery 82 % → damp: every actuator stops holding its position and a standing robot falls, so the robot must be supported. Not an emergency stop: use the E-Stop in Asimov Manager, or cut power at the battery unit.
Proceed? [y/N]

Read the line. A speed above the robot's velocity limits shows the value that is sent, then the one you asked for, for example vx 0.40 m/s (asked 0.60).

Type y and press Enter to go ahead. Enter alone, or anything else, cancels: the command prints Cancelled; nothing sent. and exits 4.

-y or --yes prints the line and goes ahead without asking. With no terminal to ask on and no --yes, the command sends nothing and exits 2.

Not Feasible

When the readiness check refuses, stand, balance and walk do not ask. They print Not feasible:, the robot mode, the reason and the fix on stderr, and exit 3:

Not feasible: lab is in DAMP, not balancing. Run `menlo stand` first.
Not feasible: lab is in STAND. Run `menlo balance` first.
Not feasible: lab is in STAND, not armed. STAND has not been held upright for 0.5 s; the firmware accepts MOVE after that. Run the command again once `menlo status` shows it armed.
Not feasible: lab is in MOVE, balancing. `stand` only runs from DAMP; end a walk with `menlo balance`.
Not feasible: lab is in DAMP, faulted. The firmware latched DAMP (FALL_DETECTED); it stays latched until the firmware restarts.
Not feasible: no fresh state from lab: the latest state is 1.2 s old (limit 0.5 s). Check the link with `menlo status`.

The robot can change while you read the line. stand(), balance() and set_velocity() run the check again after you answer; if the robot can no longer do it, the command prints Not feasible: and sends nothing.

For Scripts and Agents

menlo robots --json and menlo status --json print one JSON object and nothing else. --yes runs stand, balance, walk and damp without a question; branch on the exit code.

menlo status --json | jq '.ready, .problems'
menlo walk --vx 0.2 --duration 3 --yes

status carries robot, mode, host, verdict, ready, problems (each with code, message, blocking), robot_mode, armed, battery_percent, faults, error_flags, max_joint_temp_c, state_rate_hz, state_age_s and fresh. robots carries default and a robots list with name, default, mode, udp_host, manager_url, room, credential_saved and limits; the credential itself is never printed.

Exit Codes

Code	Meaning
0	done
1	an error; the message is `menlo <command>: <message>` on stderr
2	usage: a missing flag, a bad value, a wizard without a terminal, or a question with no terminal and no `--yes`
3	not feasible: the readiness check refused (`Not feasible:` and the reason are printed), the robot did not become ready, or a fault ended a walk
4	cancelled: you answered no; nothing was sent
130	interrupted with Ctrl-C

Connection Modes: what each mode needs

Safety: the stand, balance, walk, damp sequence and why

Check Before You Move: every readiness code

Reference: the store the CLI writes

On this page