> /mcpAuthentication successful. Connected to alloy.
alloy - query_mesh
-- robot-12 events around 2pm
SELECT time, event
FROM robot_events
WHERE robot_id = 'robot-12'
AND time BETWEEN '13:45' AND '14:15'
ORDER BY time;
14:03:18 fall_detected · 14:03:31 recovered · 14:08:41 fall_detected
The robot recovered after the first fall, then failed again five minutes later. I'll query left knee pitch in the three seconds before each fall.
alloy - query_mesh
-- left knee pitch before each fall
SELECT time, motor_current_a, commanded_torque_nm
FROM joint_telemetry
WHERE robot_id = 'robot-12'
AND joint = 'left_knee_pitch'
AND (
time BETWEEN '14:03:15' AND '14:03:18'
OR time BETWEEN '14:08:38' AND '14:08:41'
);
current clips at 18 A before both falls while commanded torque keeps rising
That looks like a current limit, not a one-off stumble. I'll compare the same joint and gait phase across the fleet.
alloy - query_mesh
-- fleet peaks during walking support
SELECT robot_id, max(motor_current_a) AS peak_current_a
FROM joint_telemetry
WHERE joint = 'left_knee_pitch'
AND gait_phase = 'walk_support'
GROUP BY robot_id;
robot-12 peaks at 18 A · comparable robots peak around 34-38 A
The Problem:
Robot-12 is falling because its left knee pitch motor is hitting a 18 A current limit during walking support. Comparable robots in the fleet use roughly 2x that current in the same gait phase, so this looks like a robot-specific exception.
robot-manager - update_config(robot_id="robot-12", component="gait_controller", key="joints.left_knee_pitch.motor_current_limit_a", value=36)
config updated · validation passed
robot-manager - deploy_config(robot_id="robot-12", mode="on_restart")
staged for next restart · rollback saved
Done
Robot-12 will use the standard fleet current limit for left knee pitch after its next restart.