Inside one walking decision

A policy is a function, not a script of footsteps

The velocity policy receives the robot’s current observations and requested motion. It computes a vector of actions. It repeats this decision as the state changes. The exported ONNX file stores the learned computation; ONNX Runtime executes it. It does not contain a complete hardware startup procedure, validated wiring map or a promise to recover from every disturbance.

Running inference uses the existing policy. Training changes its parameters through experience. Reading a new reward configuration does not modify an old ONNX file, and renaming a policy does not tell you which robot model originally produced it. Hash the file to identify the exact bytes used in a run.

A simple software check runs inference with an input vector filled with zeros. If it returns an output, you have shown that the saved computation executes for that particular input. You have not run a robot through a feedback loop, checked a sensor calibration or demonstrated walking. A zero-filled input is also not automatically a meaningful standing observation: each slot still has the meaning specified by the policy.

Every input slot has a meaning

The ordinary new.onnx velocity policy has 51 input values: three body angular velocities, three projected-gravity values, fourteen joint-position offsets, fourteen joint velocities, fourteen previous actions and three movement commands. The order comes from metadata and the runtime. Projected gravity describes the direction of gravity expressed in the robot’s body frame; it helps describe tilt without requiring an absolute compass heading.

A vector of the correct length can still be wrong. Degrees in a radians slot, a left knee value in a right knee slot, or gravity expressed in a sensor frame instead of the body frame can all produce a valid-looking array. Treat the contract as names, units, order, coordinate frames, scale and timing together. The imitation policy needs additional reference/phase meaning and cannot be substituted just because a dimension happens to match.

Turn an action into a physical target

For this deployment path, the action is an offset scaled around a default joint position. If a joint’s default is 0.1 rad, the exported scale is 0.2 rad per action unit and the policy outputs −0.5, the target becomes 0.0 rad. That target then enters the low-level position controller. An action is not automatically a torque, and an arbitrary neural output must not be sent directly to an unrelated motor interface.

The joint-name mapping connects policy order to model actuator order. Inspect that mapping instead of assuming the arrays already align. In the simulation backend, actuator behavior and gains are configured before targets are applied. Physical motor IDs add another mapping layer that must eventually be measured and checked.

The previous action has a precise timestamp

The audited upstream runner assembled observations with a buffer containing an action from two decisions ago after startup. The current training observation definition expects the latest applied action. Our course runner exposes both modes: previous supplies the last applied action, while upstream reproduces the older ordering for comparison.

This finding illustrates why debugging a learned controller often starts with ordinary software. If the input meaning changes, the network is being asked a different question. Correcting integration can change behavior dramatically without retraining. It still does not establish the exact original training environment of every historical exported policy.