Sudden steering on late object classification and avoidance planning

[VRichardJP]

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

I am running Autoware on a golf cart (max 20km/h).

Today, there were quite a few bikes parked on the side of the road. Bikes are annoying because they are usually detected but not classified until the ego vehicle is very close to them. In particular, I observed the following behavior when obstacle avoidance is enabled :

target.webm

In the situation above, the golf cart is driving straight on the left lane. There is a bike parked on the left part of the road. What happens is:

1. The ego vehicle moves forward and detects a few obstacle points on the left side of the road (the big red dots)
2. Since the road is large enough, the obstacles points are not found on the path, so the obstacle_stop_planner ignores the points (I use the default lateral margin = 0.0)
3. When the vehicle is very close from the obstacle, autoware finally identifies the points as part of an obstacle object (actually here the bike is classified as 'unknown'). You can see a very brief tracked object at 00:10.
4. The obstacle_avoidance_planner kicks in and generates an avoidance path, forcing the vehicle to turn quite sharply.

I understand it is difficult to define what is the "correct" behavior to adopt when an obstacle is suddenly detected very close to the ego vehicle. However, in the situation above, the bike points had been detected from very far away.

I have 2 problem with the situation above:

1. There is the behavior gap between the unclassified and classified situations:

• if points are detected, not classified/tracked -> the obstacle is ignored if not on the path
• if points are detected, classified/tracked -> the obstacle is avoided if within ~1.0m of the path. If autoware needs to keep its distance from a pedestrian/bike/car/etc, it should be extra careful for obstacle it can't identify. In other words, it should avoid with bigger safety margins, or simply stop.

2. Generated avoidance path turns way too fast for the speed.

Expected behavior

Transition from untracked to tracked obstacle should be smooth. For example, in the situation above, the default behavior should be something like:

1. Autoware drives forward, detects points on the road shoulder
2. It decides to stop in front of this unknown cluster of points (or pass slowly if margin is big enough)
3. As the vehicle gets closer, autoware manages to identify and classify the obstacle as something that can be avoided
4. Autoware generates a new path to avoid the obstacle smoothly

Constraints on avoidance path generation should be more strict than normal lane driving (since behavior is less predictible). Basically parameters such as max speed, curvature, acceleration, etc should be lower than their normal lane driving counterpart. Furthermore, avoidance clearance distance should be longer as the vehicle drives faster. The faster the vehicle is, the earlier it should avoid the obstacle.

Actual behavior

inconsistent behavior transition from obstacle_stop_planner to obstacle_avoidance_planner.

Steps to reproduce

See the video

Versions

No response

Possible causes

No response

Additional context

No response

[takayuki5168]

@VRichardJP You set enable_avoidance True in obstacle_avoidance_planner, right?
The function is under development and is not supported. For now, I recommend you trying avoidance in behavior_path_planner which has rule-based avoidance.

[VRichardJP]

@takayuki5168 I see. I didn't know there were 2 competing avoidance algorithms. The behavior_path_planner alone is indeed working fine in my case.

[takayuki5168]

The architecture of avoidance is not well-organized at all. At least, TIER IV is developing rule-based avoidance in behavior_path_planner for now.

[xmfcx]

https://github.com/orgs/autowarefoundation/discussions/3097 Needs to be discussed after the planning arch is updated again.

[stale]

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