regression in FixStartStateCollision adapter about moveit2

[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.

[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.

[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.