Obstacle stop planner causes slow creep and crash

[MrRubyRed]

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I'm convinced that this is not my fault but a bug.

Description

Creating a simple scene in scenario_v2 of ego trailing a fake agent via ACC where the fake agent eventually stops, it causes ego to stop pass the stop point and to slowly creep forward onto the stopped agent.

Expected behavior

After the other agent stops, ego should stop and not creep forward.

Actual behavior

Ego stops past the obstacle stop line and it subsequently starts to creep forward.

Steps to reproduce

1. Create an agent that goes forward at constant speed and then stops.
2. Have ego in the same lane trailing the vehicle with ACC.
3. Make agent stop.

Versions

• OS: Ubuntu 22.04
• ROS2

Possible causes

Condition if (node_param_.enable_slow_down && latest_slow_down_section_) inside ObstacleStopPlannerNode::insertVelocity is the culprit. The logic makes it so the condition is always satisfied.

Additional context

No response

[xmfcx]

Thank you for bringing this issue to our attention. Your detailed description of the problem provides a solid starting point for us to investigate.

In order to proceed efficiently and replicate the issue on our end, could you please share the exact scenario configuration you created?

This will allow us to simulate the same conditions and pinpoint the problem.

Our planning algorithm developers will take a closer look at this logic in ObstacleStopPlannerNode::insertVelocity and its implications on the ACC behavior.

[MrRubyRed]

@xmfcx I finally tracked the problem down. The issue happens in the searchPredictedObjects function, particularly this line: https://github.com/autowarefoundation/autoware.universe/blob/main/planning/obstacle_stop_planner/src/node.cpp#L904C1-L910C10

The issue is twofold:

1. The intersection polygon previously computed is not really a polygon. A quick debug_ptr_->pushPolygon shows that the intersection is actually a segment of the edge of the collision predicted object. I'm fairly sure the boost intersection geometry operations within the the searchPredictedObjects is not quite correct.

2. The collision_point computed as a result of the bg::intersection call is a point on the edge of the one_step_move_vehicle_polygon which will (with a bit of noise) cause the previously provided code snippet with the condition bg::within(collision_point, one_step_move_vehicle_polygon) to fail, which in turn causes the planner_data.found_collision_points to be false.

[mehmetdogru]

@MrRubyRed

Thanks for creating the issue.

Could you create a PR that solves the problem or could you share a scenario where the issue can be reproduced.

[MrRubyRed]

#5545

[brkay54]

Hi @MrRubyRed, I created a draft PR that may solve this problem. I wrote the idea behind this PR here. Can you try this PR for your case? And also, if you can create a scenario for this problem, I would be grateful.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity.

[mehmetdogru]

@MrRubyRed I will be closing the issue since it is stale. Please open up again if the issue is still there.