Autoware ignores obstacles located vehicle_length away after goal

[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

When an obstacle is in front of the vehicle, on the path:

When an obstacle is in front of the vehicle, more than vehicle_length away from the goal pose

It seems that obstacle_stop_planner is not considering the obstacle in the second situation, because the obstacle is further away than vehicle_length. I don't know if it is necessary to keep the same safety distance in both situations. However, we definitely need a bigger margin in the second case

Expected behavior

Keep some safety distance from obstacle, even for the goal.

Actual behavior

Autoware stops and touches the vehicle in front

Steps to reproduce

planning simulator

Versions

No response

Possible causes

No response

Additional context

No response

[ismetatabay]

@VRichardJP Hi, at obstacle_stop_planner package, there is a parameter for extending trajectory to consider after goal obstacle.

Please check:

autoware.universe/planning/obstacle_stop_planner/config/obstacle_stop_planner.param.yaml

Line 18 in c7d3b7d

extend_distance: 0.0 # extend trajectory to consider after goal obstacle in the extend_distance [m]

At this case below (yellow borders describes vehicle footprint on goal_pose), i updated extend_distance parameter to 5.0 meter. According to this parameter, obstacle_stop_planner stops the vehicle before it reach goal_pose.

[VRichardJP]

I see! Should we then change the default value? Anything is better than 0 at this point.

[ismetatabay]

It also makes sense to me to set the default value of extend_distance to 1.0 [m] or 2.0 [m] to avoid undesirable situations. What do you think? @satoshi-ota

[satoshi-ota]

@VRichardJP @ismetatabay I think so too. We set the parameter at 5.0 in other project.

[brkay54]

Should it be set as parameter? I think extend_distance should depend vehicle's dimensions and should be calculated in node like: distance_base_to_front + margin.

[satoshi-ota]

@brkay54 cc @kosuke55 I agree with you. I think we can remove the parameter. On ther other hand, I also think It might be better to add a new parameter (e.g. stop_for_obstacle_behind_goal) to indicate whether the vehicle stops for obstacles behind the goal.

[ismetatabay]

@brkay54 @satoshi-ota @VRichardJP If its okay for you, I will create PR for this issue. I think adding stop_for_obstacle_behind_goal (default value is true) parameter for the indicate extend trajectory along vehicle length or not extending trajectory after goal for obstacle checking.

[VRichardJP]

I am not sure I get everything. Is it the current behavior?

1. when on the path, ego keeps some distance from obstacles = base_link to front + fixed margin
2. for the goal case, obstacle search distance is increased by another parameter (currently 0.0). If an obstacle is on the extended path, the behavior is the same than 1.

With the PR, 1. is unchanged, and 2. is replaced by a bool which, if true, defines the distance automatically (based on the value from 1.)

Is it correct?

[ismetatabay]

@VRichardJP Hi, In the current implementation, there is a certain trajectory where the objects will be checked. This is equals to : path trajectory + goal pose + (base to front). With this PR, we extend the obstacle detection area by an extra vehicle length.

For example, let the object on the trajectory and obstacle stop planner set a stop point from 20 meters away and its stops the vehicle. If this point far away from goal pose than base to front length of vehicle, object will not be detected and vehicle doesn't stop.

In other words, we extend the detection area twice with PR (base_link to front + rear_overhang + base_link_to_front):

1. when on the path, ego keeps some distance from obstacles = `base_link` to front + fixed margin

[stale]

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

[ismetatabay]

hi @satoshi-ota @VRichardJP @brkay54, sorry for late (i am busy with field testing). I updated the extending algorithm according to the osbtacle stop planner's max_longitudinal_margin param (see).

[kosuke55]

@ismetatabay @satoshi-ota @VRichardJP @brkay54
Hi, thanks for your PR, I added a specific margin for behind the goal same to obstacle_cruise_planner in #2953
This parameter assumes parallel parking behind another car like in pull_over