[moveit2] move_group reports goal SUCCEEDED while end-effector is ~9mm from the planned target

[147258369ymc]

Description

For some goal sequences, the /move_action action returns terminal status
SUCCEEDED (4) for the final goal, but the end-effector (panda_hand),
computed via forward kinematics from the final /panda_arm_controller/state
actual.positions, is ~9.3mm away from the planned goal position. MoveIt's
default goal position tolerance is typically far tighter than 9mm.

To Reproduce

docker exec -it moveit_modify bash
source /ros_entrypoint.sh && cd /robofuzz/src
python3 replay_moveit_bug.py \
  --from-log /robofuzz/src/logs/20260618-150444 \
  --case endpoint_real --mode offline

Goal sequence (8 goals, all SUCCESS, action statuses [4,4,4,4,4,4,4,4],
nMPR == nStatus == 8 so there is no index-misalignment confound):

goal	x	y	z
1	0.6000	0.0000	0.5000
2	-0.5257	-0.0002	0.5129
3	0.0592	0.6000	0.5789
4	-0.5257	-0.0002	0.5129
5	0.5860	0.0220	0.4994
6	-0.5257	-0.0002	0.5129
7	0.0227	-0.6000	0.4722
8	-0.4859	-0.1728	0.7124

Expected Behavior

When the action reports SUCCEEDED, the end-effector should be within the
configured goal position tolerance of the planned target.

Actual Behavior

goal and actual pos deviation too high: 0.009324076078633982   # 9.3mm

Before trusting this (required ruling-out steps)

1. FK-model gap: recompute the deviation using MoveIt's own
   RobotState::getGlobalLinkTransform("panda_hand") instead of kinpy, on the
   same actual.positions. If the gap shrinks to <1mm, this is an FK-model
   artifact, not a MoveIt bug → close.
2. Goal tolerance: check the goal_constraints position tolerance in the
   /motion_plan_request; if it is ≥ 9mm, the behavior is correct → close.
3. Controller settling: confirm the sample is taken after the controller
   reached steady state (not mid-settle).

Analysis

The oracle computes:

final_ee = kinpy.forward_kinematics(actual_positions)["panda_hand"].pos
dist = || final_ee - last_MPR_goal ||      # 9.3mm here

Index alignment is verified correct for this frame (nMPR == nStatus,
best-matching MPR is the last one), so this is NOT the separate
aborted-last-MPR false-positive class we also observed. But the absolute number
is small enough that the FK-model caveat above dominates the confidence.

Additional Info

• ROS2 Foxy, moveit_core 2.2.3.
• Offline replay reads the exact rosbag from run 20260618-150444.
• Recommend resolving the FK-model question before treating this as a real
  upstream defect.