FERROMOTION · RUST → WASM

The Robot Is the File

Someone hands you a robot description. It parses, the articulation moves, every number is plausible, nothing warns. Where is the bug?

Price three conventions in a robot description in newton-metres, and find out that the pose you test in decides which of them you can see. You will read a joint limit that means something different depending on the joint type, watch a length-scale error change a torque by a factor that is not the length ratio, flip a header token and move gravity, and discover a pose where a hundred-fold error is exactly invisible. Pass = you state all three errors as numbers and explain why one of them cannot be undone by rescaling the answer.

01Challenge

Someone hands you a robot description and it parses. The articulation moves, the numbers look plausible, nothing warns. The Bench shows you that file with three tokens marked, and two buttons that change only those tokens. Your job is to make each one cost you something measurable, and then to find the configuration in which one of the three costs you nothing at all - not because it is fixed, but because you cannot see it from there.

Predict firstSomeone hands you a robot description. It parses, the articulation moves, every number is plausible, nothing warns. Where is the bug?

02Model

A robot description is source code you did not write, in a format whose conventions you did not choose, and the failures it causes are silent. Not wrong-looking. Silent. Take the joint limit. In UsdPhysics a revolute limit is in DEGREES. Write ninety, mean a quarter turn. A consumer that assumes radians gets ninety radians, which is fourteen full turns, which is no limit at all - off by a factor of fifty-seven point three. Now here is the part that catches the person who fixes it: the prismatic joint on the next line has a limit in the identically-named field, and that one is a LENGTH. Convert it and you have destroyed it. The same field name means two different things two lines apart, so there is no global fix, only a per-joint-type one. Take metersPerUnit. A stage authored in centimetres and read as metres is not merely small. Lengths enter dynamics through the moment arm and through the inertia, and they enter differently, so the gravity torque changes by a factor that is NOT the length ratio. In the Bench it moves by about zero point four three while the lengths moved by a hundred. That matters because it means you cannot rescue it downstream: there is no number you can multiply your torque by to undo a units mistake made at load time. Take upAxis. It defaults to Y. Roboticists assume Z. Gravity is ninety degrees from where you think it is, the file parses, and the robot falls sideways in a way that looks like a controller bug. And then the thing that is really about measurement rather than about file formats. In the default pose this arm's first joint rotates about Z and gravity points along Z, so the gravity torque is EXACTLY zero. Not small - zero. Which means the hundred-fold length error contributes nothing you can detect, because zero times anything is zero. Flip the up axis and the same error is worth almost five newton-metres. The bug did not change. Your ability to see it did. That is the general lesson: a test that does not load the thing you are testing cannot fail.

03Guided practice

Step A (worked, fully shown): defaults. metersPerUnit 1, upAxis Z. Read trap one: written 90, parsed 1.570796 rad, and a radians reader would be off by 57.2958x. Read the prismatic limit on the line below: 0.500, unconverted. Write down why a single global degrees-to-radians pass would be wrong. Step B (worked): look at trap three's declared-pose torque. It is 0.000000 Nm, and the readout tells you why: gravity is parallel to the joint axis. Now look at trap two in the same state and notice the loaded-pose numbers are being used instead, and why they have to be. Step C (you do it): press the upAxis button. Trap three's error becomes 8.528384 Nm from the same file. Nothing in the description changed. Say what a controller tuned in the other convention would do on this robot. Step D (you do it): press the metersPerUnit button and read the ratio. It is about 0.43, not 100. Explain in one sentence why that number being anything other than 100 means the mistake cannot be fixed downstream.

04Feedback

PASS WHEN PASS when you have read all three errors as numbers off the live readout, triggered the unloaded-pose warning and explained what it hides, and said why a torque ratio of 0.43 under a 100x length change means the error cannot be undone downstream. There is no code to submit.

If your run fails, check:

You are looking for the bug in the file. There isn't one. The file is valid, the parse succeeds, and every number in it is a number someone meant to write. The bug is in the agreement between the writer and the reader, and that is why no validator catches it.
You converted the prismatic limit along with the revolute one. Read the two values again: 1.570796 and 0.500. The first is an angle in radians and the second is a length in metres, and they arrived in fields with the same name. A global unit pass corrupts exactly half of them.
You expected the metersPerUnit torque ratio to be 100, matching the length ratio. It is about 0.43. Lengths enter the gravity torque through the moment arm and through the inertia tensor, at different powers, so the composite factor is neither the length ratio nor its square. That is the whole reason you cannot patch this after the fact.
The declared-pose torque reads 0.000000 and you assumed the lab was broken. It is not: the joint rotates about Z and gravity points along Z, so the moment arm is zero by construction. This is the most important screen in the lesson - you are looking at a test that could not have failed.
You flipped upAxis and the torque jumped from zero to 8.53 N*m, and read that as the Y convention being wrong. Neither convention is wrong. The point is that the same file means two different physical systems and nothing tells you which one you loaded.
You want to know why the branched tree is in this lesson. Because a chain loader reading this hand base-to-fingertip returns a valid 2-dof robot and silently discards the other finger. It does not error. You get a robot that moves, and half of it is missing from your model.
The fingertip separation changes from 0.045 m to 0.074 m as the fingers close. Notice that a chain loader cannot compute that number at all, at any pose, because it only ever holds one fingertip.

05Retrieve & space

The degree trap (typed): a UsdPhysics revolute limit written as 90 is ____ radians, and reading it as radians is off by ____ x -> 1.570796 (pi/2), and 57.2958x.
The same field, twice (short answer): why can a degrees-to-radians fix not be applied globally to a .usda file? -> Because physics:lowerLimit is degrees on a revolute joint and a length on a prismatic one. Converting globally destroys every prismatic limit.
The ratio that is not 100 (multiple choice): a stage authored in centimetres is read as metres, a 100x length error. The gravity torque changes by about 0.43x. Why not 100x? -> Lengths enter through both the moment arm and the inertia tensor, at different powers, so no single factor undoes the mistake downstream.
The default nobody expects (typed): the UsdPhysics upAxis default is ____ , and roboticists assume ____ -> Y, and Z. The file parses either way and gravity is 90 degrees from where you think.
The invisible bug (short answer): the declared pose gives a gravity torque of exactly 0.000000 N*m. What does that do to your ability to detect a 100x length error, and why? -> It makes it undetectable, because the torque is zero at both scales. Gravity is parallel to the joint axis so the moment arm is zero by construction, and a test that does not load the thing under test cannot fail.
What a chain loader loses (typed): a two-finger hand has 4 dof, 2 fingertips and a deepest chain of 2. A chain loader silently drops ____ joints and cannot compute ____ at all -> 2 joints, and the fingertip separation (any quantity involving two tips at once).

06Mastery & project

You treat a robot description as an interface with a specification rather than as data, and you verify a load by computing a physical quantity two ways rather than by checking that the parse succeeded. You know that unit errors at load time are not rescalable downstream, and you can say why. And you check that your test pose actually loads the quantity you are testing, having seen a hundred-fold error read as exactly zero.

Not a capstone lesson. It is the input-validation half of Module 8: the calibration lesson fits a model to data and the grasp lesson fixes what you measure, and this one makes sure the model you loaded is the one on disk.

GO FURTHER · THE LIVE PLAYGROUND

The .usda parser and the three conventions it prices ↗ · A recursive-descent reader for UsdPhysics, with each convention trap recorded as a test carrying the error it causes. Also where a "#usda" magic line was eaten by the comment skipper, silently dropping metersPerUnit and upAxis together.
Branched trees, pinned against the serial loader ↗ · A (joints, parent[]) tree with multi-target damped-least-squares IK, agreeing with the chain loader to 4.6e-17 on a description both can read. Fixed-joint welding is literally shared code.
Round-tripping a robot through OpenUSD ↗ · Writes a Robot to .usda and reads it back, which is how each convention was priced: the same robot, two representations, and a subtraction.

← The Grasp Number Lies Twice When coefficients break →

FERROMOTION · RUST → WASM

The Robot Is the File

Live ferromotion-core: the stage is generated, parsed by the real recursive-descent .usda parser, and turned into a Robot with link inertias, and every torque is a genuine gravity_vector call on that robot. The two-finger hand is loaded by the branched-tree loader, which is pinned against the serial chain loader to 4.6e-17 on a description both can read.

You read

the readout: what the Rust crate computes, recomputed as you change things

You change

the bench controls, and with them the assumption the measurement rests on

Fixed

the ferromotion crate doing the computing, and the check that decides pass