FBX Import — Waypoint Axis Positions Don't Match Run Positions (Carts vs Axis Priority)¶

Summary¶

After importing a move from Unreal → Maya → Flair, all axes' waypoints read in correctly but the X-axis path appeared shifted, as if two overlapping Cartesian move paths existed simultaneously — the stored waypoint positions in the spreadsheet view did not match what the robot actually did on a run or browse. This looked alarming but is expected behavior when the import lands in Carts Priority: the operator switched the move to Axis Priority and the mismatch resolved. Simon Wakley confirmed the waypoint/axis-position disagreement in Carts Priority is by design, not a bug, when master axes have been directly edited.

Symptoms¶

FBX (or similar) move imported via Unreal → Maya → Flair.
All waypoints appear to read in with correct values, though translation/rotation had to be adjusted during import.
The X-axis path looks shifted from the intended move — as if two Cartesian coordinate sets are overlapping.
Stored waypoint positions shown in the waypoint "spreadsheet" view do not match the actual axis positions used when running forward, running backward, or browsing.
Every single waypoint shows this same discrepancy, not just one.
The amount of X-axis offset appears to change between test runs, adding to the confusion.

Community Guidance¶

[RESOLVED] Switch From Carts Priority to Axis Priority¶

Community — Simon Wakley — 27-29 June 2026

The reporting operator's own fix:

"We ended up just converting carts priority to axis priority and that seemed to do the trick!"

Simon Wakley's explanation of why this happens and why it's not a bug:

"With CG you're importing carts not axes usually and the listed waypoint axis positions can often disagree with the run axis positions especially if you have 'tinkered' with the move... Carts priority allows you to edit the master axes and then it will not match axis positions but that's fine it still works. You can convert but it doesn't change the move. It's a standard way or working with CG Import but you can always convert to axes if that makes you more comfortable."

Takeaway:

CGI/FBX imports bring in Cartesian (carts) data, not raw axis data — the move lands in Carts Priority by default.
In Carts Priority, the master axes can be hand-edited without the waypoint spreadsheet's axis-position column updating to match — this is expected, and the move still runs correctly.
If the waypoint-vs-run mismatch is confusing rather than harmful, converting the move to Axis Priority resolves the visual disagreement without changing the underlying move.
Converting priority does not itself change the move — it's a display/editing-mode change, not a re-solve.

confidence_score: 0.8

Supporting context — the "Convert" confirmation step, from a second tutorial¶

From tutorial video, added 2026-08-29

The tutorial "29 - The Waypoint View in Flair 7 explained" shows the same Priority to Axes / Priority to Cartesian switch from the opposite direction (Cartesian → Axis), and adds one detail not covered above: switching priority is not silent — Flair prompts for confirmation before recalculating the other representation, because it has to "take these and adjust all the other axes accordingly."

"Now if I want to go back to my priority to axis, it has to convert it — basically take these and adjust all the other axes accordingly... it says do you want to convert, yes, convert." — 29 - The Waypoint View in Flair 7 explained

Same underlying mechanism as the "19 - Axis vs Cartesian Priority" tutorial above, offered as general background only — not independent confirmation of the specific FBX import behaviour reported above.

confidence_score: 0.5

Confirmed By Official Tutorial¶

The "19 - Axis vs Cartesian Priority" tutorial demonstrates this exact mechanism on a generic move: once Carts/Cartesian Priority is active, editing any non-master axis (e.g. lift) has no effect and does not update the stored axis values — the master Cartesian XYZ values are what actually drive the move. This matches Simon Wakley's explanation above almost exactly and further supports treating the waypoint/run mismatch as expected, by-design behaviour rather than a bug.

YouTube 19 - Axis vs Cartesian Priority Flair 7

▶ 04:12 — Adjusting a non-master axis (lift) while in Cartesian Priority has no effect on the move — the stored axis value goes unused until priority is switched back to Axis