Static avoidance planner generates wrong trajectory when tries to avoid obstacles on two sides

[firemark]

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

When the two obstacles are on two sides around narrow lanelet and one obstacle is "parked" then generates wrong trajectory that triggers obstacle_stop by the obstacle cruiser planner.

Preview

avoidance.mp4

Expected behavior

Due to sufficient space for both sides, trajectory should be not modified.

Actual behavior

The avoidance planner generated trajectory too close to the obstacle that triggers obstacle_stop from the obstacle cruise planner.

Steps to reproduce

I tested on carla in Town03.

I generated two vehicles on both sides around lanelet.

The first vehicle should collide with the lanelet (it should be tagged as parked vehicle).

The second should be on the adjacent lanelet.

Versions

• OS: Ubuntu 24.04
• ROS: humble (docker image)
• Autoware commit id: a967adb

Possible causes

What I understand:

1. To avoid an obstacle, it's generated shift points as single shift line
2. For both sides, they're generated two shift lines (negative and positive) and merged into one.
3. Due to some reasons (e.g. not sufficient space for hard margin_ or an obstacle is near goal/vehicle) generating shift points are discarded for the obstacle (or side?)

Case A

Two shift lines are generated properly.

Case B

Due to not sufficient space for the obstacle on the left side, shift line for left side is not generated properly and merged shift line is equal to right shift line. This generates wrong trajectory which is too near the left obstacle.

Additional context

No response

[satoshi-ota]

@firemark Thank you for you bug report.
In current implementation, the static_obstacle_avoidance module doesn't support fine adjustment in such a case explicitly.

Btw, have you tried using this module...? You can enable this module from this flag.
This module cut drivable area based on object position and footprint, and this module push the path into the modified drivable area. The latter one uses optimization logic, so it's good at fine adjustment.

Hopefully, I think it can pass through between the two obstacles.