Coordinate-Frame Consistency Check¶
Verification check — instantiates Symmetry-Commuting Transformation Design
Verifies that when the reference frame moves, geometric outputs transform by the same rigid motion — so a pose or velocity means the same thing in every frame.
Geometry is the domain where "the answer should move with the frame" is most literal. A Coordinate-Frame Consistency Check verifies that a map producing a spatial quantity — a position, orientation, velocity, or force — is frame-equivariant: if you express the input in a shifted or rotated reference frame, the output must come out expressed in that same shifted or rotated frame, related to the original output by the exact same rigid motion. Its defining ingredient is an explicit alignment map between the two coordinate frames — the change-of-basis or rigid transform that connects them — which the check uses to translate one frame's output into the other's before comparing. It works entirely with continuous geometric transforms and needs no notion of discrete relabeling; that continuity, and the alignment map, are what set it apart from a permutation-style audit.
Example¶
An autonomous vehicle runs a perception map (F) that takes a LiDAR point cloud and outputs the pose of a nearby car — position and heading. The point cloud arrives in the sensor frame, but the planner needs the obstacle in the vehicle frame, and logging wants it in the world frame. Each pair of frames is related by a known rigid transform (rotation plus translation) — the alignment map.
The consistency check runs both paths. Path one: transform the raw point cloud from the sensor frame into the vehicle frame, then run F. Path two: run F in the sensor frame, then apply the same sensor-to-vehicle transform to the resulting pose. If the perception map is frame-equivariant, the two poses coincide. On a test scene they don't: the position agrees but the heading is off by a fixed offset. The check localizes it to a sign convention in how the map applies the rotation part of the transform to orientations — a bug that would have put every obstacle's heading a few degrees wrong the moment the planner consumed a vehicle-frame pose. Because the two paths agree on where the obstacle is but disagree on which way it faces, the team can read the failure as living in the orientation transform specifically, not in the whole pipeline.
How it works¶
- Fix the alignment map. Write the explicit transform relating the two frames — rotation and translation — and confirm it is invertible and applied consistently to points, directions, and orientations, which do not all transform the same way.
- Run the two paths. Transform-input-then-map versus map-then-transform-output, using the alignment map on the appropriate side.
- Compare in a common frame. Bring both results into the same frame via the alignment map and check they coincide within the geometric tolerance.
- Apply the correct transform law to each quantity type. Positions translate and rotate; directions and velocities rotate but do not translate — each co-varies under the rigid motion by its own rule. A mismatch in one quantity but not another points straight at the buggy piece.
Tuning parameters¶
- Frame set — how many frame pairs you check (sensor/vehicle/world, plus calibration frames). More pairs catch composition errors; each adds an alignment map to maintain.
- Transform family — pure rotation, rigid motion, or a full similarity including scale. Wider families test more but demand the output action be defined for each.
- Geometric tolerance — how much position/angle disagreement counts as a pass, and in what units. Tighter tolerances catch subtle convention bugs but flag benign numerical noise.
- Quantity coverage — whether you check only positions or also orientations, velocities, and covariances, each of which has its own transform law.
When it helps, and when it misleads¶
Its strength is catching the silent, systematic geometric bug — a swapped axis, a sign error in a rotation, a translation applied to a direction that should ignore it — that leaves average metrics fine while corrupting every downstream spatial computation. It rests on the tensor transformation law: quantities carry a definite rule for how their components change under a change of basis, and a correct map must obey that rule component for component.[n1]
Its failure mode is that the check is only as right as the alignment map it trusts. A wrong or stale calibration transform can make a correct map look broken, or — worse — make two compensating errors cancel so a broken map looks correct. The classic misuse is validating against a hand-derived transform that itself encodes the same convention error as the map under test, so both agree and both are wrong. The guarding discipline is to source the alignment map from an independent calibration and to test round-trips (frame A → B → A) so an inconsistent transform reveals itself as a failure to return to the start.
How it implements the components¶
Coordinate-Frame Consistency Check fills the geometric-alignment slice of the archetype:
representation_alignment_map— the explicit change-of-frame transform is the check's core artifact: it is what makes the two frames' outputs comparable at all.input_output_action_pair— the rigid motion applied to the input point cloud and the same rigid motion applied to the output pose are the paired actions the check exercises.
It does not partition outputs into invariant versus variant classes across a discrete symmetry — that partition, for relabelings and reorderings, is the job of Permutation Equivariance Audit; this check assumes a continuous frame motion and needs no invariant_variant_split.
Related¶
- Instantiates: Symmetry-Commuting Transformation Design — this check is the geometric specialization of the commutation test.
- Sibling mechanisms: Commutative Diagram Review · Transformation-Pair Test Suite · Permutation Equivariance Audit · Data-Augmentation Equivariance Probe · Schema and Label Relabeling Harness · Equivariance Tolerance Matrix · Symmetry Exception Register
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Coordinate-Frame Consistency Check operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it verifies that when the reference frame moves, geometric outputs transform by the same rigid motion — so a pose or velocity means the same thing in every frame.
Independent corroboration: The frozen evidence defines Coordinate-Frame Consistency Check as 'Verifies that when the reference frame moves, geometric outputs transform by the same rigid motion — so a pose or velocity means the same thing in every frame', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Robotics & Automation
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Robotics established frame-consistency tests for poses and velocities across rigid coordinate transformations.
Related originating lineages:
- Mathematics — Group actions and change-of-basis algebra define the equivariance relationship the test checks.
- Physics — Physical coordinate-frame invariance and transformation practice provide a foundational lineage for frame-consistency reasoning.
Review resolution: The artifact is a behavior test for implemented sensor and transformation pipelines, so robotics is the best primary. Its correctness criterion is jointly grounded in mathematical transformations and physical frame invariance, making cross-disciplinary provenance appropriate.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Under a change of coordinate basis, a quantity's components transform by a fixed rule tied to its type — scalars are unchanged, vectors rotate, positions rotate and translate, and higher tensors follow the corresponding law. A frame-equivariant map must reproduce that rule exactly, which is why checking each quantity type separately isolates convention bugs so precisely. ↩