[grandixximo]

With KINEMATICS_BOTH, motion starts the forward kinematics of the feedback (and, in joint mode, of the command) from the pose of the cycle before. After one failed forward it starts from world_home instead, every cycle until the forward solves again. For an iterative forward far from home, that start can fail again, or converge to another platform pose with the same joint positions. Because that pose is a real solution, the following cycles stay on it: the position reads wrong until the machine comes back near home. The joints do not jump, since the other pose has the same joints, but the DRO is wrong and so is the start of the next path in world coordinates.

With this change, home is the starting guess only until the forward has solved once since all joints were homed. A failed forward puts back the pose it was given, and that is the next guess.

How often it matters, in the hexapod-sim geometry (genhexkins defaults, home 0 0 20 0 0 0): over 23141 platform poses whose straight path from home the forward follows cycle by cycle (X and Y to 15, Z 8 to 38, tilts to 45 degrees, turns to 90), the forward started at home fails at 675 and lands on another pose at 319, all of them near the edges. In the middle of the workspace (X and Y to 10, Z 14 to 26, tilts to 30, turns to 45) it finds all 10765. A forward started from the previous cycle never failed, so the trigger is something else going wrong for a cycle: a bad joint reading, a strut at or below zero length, a near-singular pose.

tests/kins-forward-seed moves the platform to X-15 Y-15 Z32 A30 B15 C90, makes the forward fail for a few cycles with genhexkins.limit-iterations set to 0, and requires the feedback, and the command in joint mode, to come back to the platform. On master both stay on X-14.69 Y-14.81 Z31.67 A28.6 B18.2 C97.1.