[OpenArm Troubleshooting] Planning Fails from Collision Model vs Real Geometry Mismatch (Advanced)
OpenArm planning failures from collision model and real geometry mismatch: scene validation, mesh alignment checks, and advanced deployment gates.
A frustrating OpenArm planning issue appears when the robot, tooling, or fixtures change in the real world but the planning scene still believes an older geometry. Paths either fail for no clear reason or look safe in planning while clipping something real.
How are you diagnosing OpenArm motion-planning failures caused by collision models that do not match the real robot or workspace geometry?
Please share how you compare collision meshes to reality, detect stale tool geometry, and validate that the planner is using a trustworthy scene before blaming the planner itself.
If you reply, include one exact planning symptom and one exact geometry or scene check that exposed the mismatch.
Advanced context: Planner kept rejecting paths near a vise corner even though manual jog showed 12-15 mm real clearance. Symptom looked random until we compared planned scene geometry against current tool hardware.
Advanced context: What exposed it was overlaying the live point cloud and the collision mesh in RViz. The tool flange mesh was stale by about 12 mm in X after an accessory change, so planner was correctly avoiding a ghost obstacle.
Advanced context: Our sign-off now is 50 replayed trajectories in a refreshed scene plus two physical clearance probes at the tightest region. If either fails, we block deployment and rebuild the collision assets.
Advanced context follow-up: Follow-up question for advanced teams: when scene and reality diverge, do you gate deployment on point-cloud-to-mesh distance metrics, and what max distance do you allow?