Before asking a model, we needed an arm that could reach a target

Our first moving task was deliberately plain: put the simulated SO-101's tool point near a target and keep it there briefly.

The initial scope change gave us the sequence. The implementation on September 18 made it concrete. We used MuJoCo for physics and an SO-101 model from MuJoCo Menagerie, rather than building either ourselves.

The interesting work was making three operations agree: finding joint targets, executing motion and deciding whether the reach succeeded.

A point, a tolerance and a clock

One fixed development target was [0.18, 0.08, 0.20] metres in the scene's world frame. The second was on the other side at [0.18, -0.08, 0.20]. These were two declared development cases, not a random sample of the arm's workspace.

The evaluator measured the tool center point, or TCP, against the target. It required a distance of at most 12 mm for 250 ms continuously. The attempt stopped after at most ten simulated seconds.

In simplified pseudocode:

if distance(tool_point, target) <= 0.012 metres:
    dwell += elapsed_simulation_step
else:
    dwell = 0

success when dwell >= 0.250 seconds

A single frame inside the tolerance was insufficient. So was a tool point that repeatedly entered and left the region without staying there. The continuous interval made a fleeting crossing distinguishable from a completed reach.

Solving a pose is not moving the arm

The reference controller used inverse kinematics to find joint targets for a desired tool-point position. That calculation happened in scratch state. It had to converge to a position residual within 0.5 mm before its answer could be used.

These were the selected criteria for this development fixture, not recommended tolerances for positioning a physical arm. The retained record does not establish how the exact values were optimized.

The tighter solver threshold and the 12 mm task tolerance had different jobs. The former checked whether the proposed joint solution matched the requested point. The latter scored what happened during execution.

Credited movement used the simulator's position actuators and physics steps. It was not earned by assigning the solved joint positions directly to the live scene. Reset and scratch calculations could assign state, but that was separate from an executed attempt.

This gave us specific places to look when something went wrong. An IK failure was a preparation problem. A valid joint target followed by the wrong movement pointed toward execution or model conventions. A movement that never held the tool point near the target failed the task criterion.

Development reaches and the final guard

The dated development record logged reference-controller reaches in both cases using actual simulator actuators. It also recorded later managed-model reaches, along with failed model attempts. Those paths used different controllers and observation/tool interfaces.

These were development reaches, not a controller comparison or evidence of general manipulation. The final adapter then blocked managed-model runs on that host because a global instruction source remained loaded. The tightened configuration still lacked a final live adversarial isolation probe. A successful reach had not settled whether the agent's effective tool and file access was sufficiently restricted.

The development record gave us two paths to inspect. Before another managed-model attempt, the blocked instruction boundary and the remaining tool/file isolation checks needed resolving. Moving the arm and qualifying that boundary were different checkpoints.