Skip to content

Rebuild flattened-model schemas on FrameSystem.UnmarshalJSON#5961

Draft
NickPPC wants to merge 1 commit into
mainfrom
diagnose-missing-dof
Draft

Rebuild flattened-model schemas on FrameSystem.UnmarshalJSON#5961
NickPPC wants to merge 1 commit into
mainfrom
diagnose-missing-dof

Conversation

@NickPPC
Copy link
Copy Markdown
Member

@NickPPC NickPPC commented Apr 23, 2026

Summary

A FrameSystem round-tripped through JSON lost the derived lookup tables (componentSchemas, flattenedModels, mimicFrames) that map a component's flat input vector onto its flattened per-joint sub-frames. After UnmarshalJSON, any Transform that reached a namespaced sub-frame (e.g. arm1:joint_1) would fall through resolveFrameInputs, find no schema, and panic with NewIncorrectDoFError(0, 1) — so every serialized PlanRequest with a multi-DoF arm panicked inside validatePlanRequest before planning could start.

Repro: go run motionplan/armplanning/cmd-plan/cmd-plan.go -v <any PlanRequest JSON with a 6-DoF arm>panic: array length does not match frame DoF, expected 1 but got 0.

Changes

  • referenceframe/frame_system.go: UnmarshalJSON now initializes mimicFrames (was left nil) and calls a new rebuildFlattenedSchemas() pass. The helper walks restored frames, unwraps *namedFrame wrappers, and for each *SimpleModel with DoF > 0 repopulates flattenedModels / componentSchemas / mimicFrames from the inner model's already-restored inputSchema and mimicMappings. Guarded on the namespaced sub-frames actually being present in fs.frames, so models attached directly via AddFrame (which flattenModelIntoFS never touched) are left alone — this preserves TestSerialization's behavior where FrameNames() would otherwise try to subtract sub-frames that don't exist.

Testing

  • Added TestFlattenedFrameSystemJSONRoundTrip in referenceframe/frame_system_flatten_test.go: builds a NewFrameSystem with a real flattened arm + child frame, round-trips through JSON, then drives Transform (camera → world) and ComputePoses with component-level inputs. Both paths panicked before the fix and pass after. Also compares the post-unmarshal transform against the original FS to catch silent divergence.
  • Full ./referenceframe/... and ./motionplan/... suites pass locally (two referenceframe tests — TestUR20URDFWithMeshes, TestMeshGeometrySerialization — failed on artifact-fetch auth and are unrelated).
  • Verified the original motivating repro: the panic is gone and PlanMotion now runs through, surfacing the actual content-level IK/collision result for the input file.

Claude Code Prompts Used

  • "Hi Claude I am hitting an issue with the following command, can you trace down what is going on? `go run motionplan/armplanning/cmd-plan/cmd-plan.go -v erroring_file_missing_dof.json`"
  • "option 1" (in response to the diagnostic-path choice — capture the full error stack via a one-line edit in cmd-plan.go)
  • "Let's go with option 1" (in response to the fix-design choice — rebuild the schemas on unmarshal rather than serialize them explicitly)
  • "yes open a draft pr"

A FrameSystem round-tripped through JSON lost the componentSchemas,
flattenedModels, and mimicFrames lookup tables. These are populated
at construction time by flattenModelIntoFS but are not part of the
on-disk format, so after UnmarshalJSON any Transform that reached a
flattened per-joint frame (e.g. "arm1:joint_1") would hit
resolveFrameInputs, find no schema, and fail with
NewIncorrectDoFError. Every serialized PlanRequest with a multi-DoF
arm was affected — validatePlanRequest would panic before planning
could start.

Rebuild the maps from the restored SimpleModel's inputSchema /
mimicMappings, guarded on the namespaced sub-frames actually being
present in fs.frames so models added directly via AddFrame (which
are not flattened) are left alone.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@viambot viambot added the safe to test This pull request is marked safe to test from a trusted zone label Apr 23, 2026
@github-actions
Copy link
Copy Markdown
Contributor

Availability

Scene # viamrobotics:main viamrobotics:diagnose-missing-dof Percent Improvement Health
1 100% 100% 0%
2 100% 100% 0%
3 100% 100% 0%
4 100% 100% 0%
5 100% 100% 0%
6 100% 100% 0%
7 100% 100% 0%
8 100% 100% 0%
9 100% 100% 0%
10 100% 100% 0%
11 100% 100% 0%

Quality

Scene # viamrobotics:main viamrobotics:diagnose-missing-dof Percent Improvement Probability of Improvement Health
1 1.31±0.00 1.31±0.00 -0% 46%
2 0.94±0.01 0.94±0.01 0% 62%
3 6.13±0.00 6.13±0.00 -0% 50%
4 1.98±0.27 1.98±0.27 0% 50%
5 8.78±1.87 8.78±1.87 -0% 50%
6 8.60±2.52 8.94±2.48 -4% 46%
7 1.95±0.38 1.95±0.38 -0% 50%
8 0.94±0.01 0.94±0.01 -0% 50%
9 4.54±0.41 4.53±0.37 0% 51%
10 12.63±0.03 12.63±0.03 -0% 50%
11 0.62±0.00 0.62±0.00 -0% 34%

Performance

Scene # viamrobotics:main viamrobotics:diagnose-missing-dof Percent Improvement Probability of Improvement Health
1 0.02±0.00 0.02±0.00 3% 62%
2 0.04±0.00 0.03±0.00 13% 91%
3 0.02±0.00 0.02±0.00 13% 87%
4 0.29±0.06 0.26±0.03 11% 67%
5 1.26±0.18 1.31±0.21 -3% 44%
6 1.54±0.39 1.51±0.33 2% 53%
7 0.74±0.09 0.71±0.08 4% 60%
8 0.03±0.00 0.03±0.00 -2% 41%
9 1.23±0.22 1.26±0.33 -2% 48%
10 3.55±0.41 3.55±0.40 0% 50%
11 0.55±0.08 0.53±0.04 3% 57%

The above data was generated by running scenes defined in the motion-testing repository
The SHA1 for viamrobotics:main is: 34f56ff99b6db31130a351e0791da3dc0fabb01c
The SHA1 for viamrobotics:diagnose-missing-dof is: 34f56ff99b6db31130a351e0791da3dc0fabb01c

  • 11 samples were taken for each scene

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

safe to test This pull request is marked safe to test from a trusted zone

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants