Preconditions

• Robot turned ON, PC connected to the unit's WiFi AP.
• SSH access to the control PC (root@10.42.0.106).

Steps

1. SSH to the control PC and enter the ARU container:

ssh root@10.42.0.106
start                       # aru-profile.sh helper — enters the aru pod

1. Ask ARU whether it is ready:

aru ready

1. Read the last line of the output — that line, and only that line, carries the verdict.

Expected

• Last line is READY → pass — ARU is ready.
• Last line is NOT READY → fail — ARU is not ready.

Notes

• Tagged preflight so it runs first and is picked up by the Sanity campaign: there is

no point walking a campaign against a robot whose stack is not up.

• On NOT READY, automation/scripts/aru_bringup.py is the remedy — it starts the

missing launches and polls until the robot is commandable. Note the two look at different signals: this test reads what aru ready prints, while aru_bringup.py judges readiness from nio state get's current_control_mode. Do not treat one as a substitute for the other until they are shown to agree.

• Automated by automation/scripts/aru_ready.py (tool: repo-script), which performs

exactly the steps above and decides from the same last line: READY → exit 0 → pass, NOT READY → exit 4 → fail. The comparison is exact, because NOT READY ends in READY and any substring test would report a robot that just said no as a pass.

• Anything else — no Running aru pod, aru not found in the container, no output, or a

last line that is neither string — exits 5 → error, never pass/fail: a check that could not be *evaluated* says nothing about the robot and stays out of the pass rate (§4.7). An SSH failure is exit 3 → error, retry-eligible.

• The script reaches the robot over SSH, which is password auth today (§11), so it needs a

deployed key before it runs unattended. Run it manually with the steps above until then.