regression in FixStartStateCollision adapter

[rhaschke]

This reports issues observed with the FixStartStateCollision adapter in moveit/moveit_task_constructor#573 (comment):

• The adapter seems to interpolate between an in-collision start state and the found non-collision state. However, these states are usually in collision too, resulting in the plan validation to fail.
  MoveIt1 doesn't behave like that, it jumps to the collision-free state directly (and ignores the invalid start state during validation).
• If the adapter fails to find a collision-free state, it erroneously reports SUCCESS as its message.

[sjahr]

Thanks for reporting this issue! At a first glance I don't see any regression between moveit1 and moveit2 in the FixStartStateCollision adapter on the Humble branch. Do you see anything I am missing?

In main I replaced the FixStartState adapter in #2429 with a simple CheckStartStateCollision adapter. My rationale is that an adapter that introduces small jumps is un-intuitive and might lead to undesired behavior, especially given that is was used almost everywhere as a default. I think the decision about what to do when the start state is in collision should be made in a higher level logic than the planning pipeline.

We refactored the whole planning pipeline in moveit2 recently.

[rhaschke]

Do you see anything I am missing?

I see exactly the regression I described: In MoveIt1 it works, it MoveIt2 it fails as described.
If there are no code changes in the adapter itself, which would explain the interpolation to the new state, maybe time parameterization applies (now) to the whole trajectory (including both, the initial state and the added no-collision waypoint) and adds more waypoints in between? Maybe such kind of interpolation was added there?
I don't have the time to dig into this issue and I don't have an overview of changes applied to MoveIt2. That's why I just reported the issue.

[github-actions]

This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups.

[github-actions]

This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups.

[github-actions]

This issue was closed because it has been stalled for 45 days with no activity.

[mikeferguson]

#3143 fixes the second issue (erroneous "success" reported).