Vehicle stops in front of non-existing obstacle on the path

[WJaworskiRobotec]

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

While testing current Autoware in AWSIM for ITRI BusODD scenarios, the following problem was discovered :

The vehicle stops because the obstacle on the path is reported, but when detected objects are visualized, it seems that the objects are not really blocking the path.

• the only detected object is far from the vehicle, and nnot on the path
  

• detected object is on the side of the vehicle, and is not blocking the movement

Location of the observed problems:

Expected behavior

The vehicle should not stop if there are no objects detected on the path

Actual behavior

The vehicle stops with no objects on the path

Steps to reproduce

Run AWSIM binary with Autoware - description to be updated once binary is publicly shared

Versions

No response

Possible causes

No response

Additional context

No response

[maxime-clem]

An "obstacle on the path" can also be caused by an obstacle point.
Have you checked the pointcloud in rviz ? I am afraid the points from the tree leaves are what is causing your issue.
Here is the related open discussion: https://github.com/orgs/autowarefoundation/discussions/2981

[shmpwk]

@WJaworskiRobotec
This problem may comes from this PR.
Could you change these parameters https://github.com/autowarefoundation/autoware.universe/blob/main/launch/tier4_perception_launch/config/obstacle_segmentation/ground_segmentation/ground_segmentation.param.yaml#L14-L15 ?

before:

max_z: 10.7 
min_z: -8.7

After

max_z: 4.5 # in case 50m continuous slope at 5deg
min_z: -4.5# in case 50m continuous slope at 5deg

[shmpwk]

cc. @badai-nguyen

[WJaworskiRobotec]

@maxime-clem so what is the input to the planner from sensing/perception modules ? I thought it's only list of detection objects, but from your comments I understand that it's a pointcloud after some segmentation/cropping as well, right ?

[maxime-clem]

@WJaworskiRobotec You are right that the obstacle_avoidance_planner only uses the list of detected objects but some other planning modules uses the obstacle pointcloud (most notably the obstacle_stop_planner).
This page gives a good overview of which planning nodes uses which inputs.

[yukkysaito]

cc @takayuki5168

[xmfcx]

https://www.thinkautonomous.ai/blog/occupancy-networks/

This is Tesla's approach on treating non-classified objects and points in space.

I think our perception stack should generate a similar result for planning stack to act on. @yukkysaito @kaancolak @TakaHoribe are you also familiar with the outputs of occupancy networks?

[shmpwk]

Reflected #2213 (comment) by

• chore: sync awf-latest tier4/autoware_launch#543
• fix(ground segmentation): change crop box range and add processing time #2260

[lchojnack]

I've found the root cause of stopping the vehicle presented in the issue, and also in the discussion https://github.com/orgs/autowarefoundation/discussions/2981. I've noticed that in these two situations there are tree branches and tree leaves on the EGO path. The tree branches are higher than the vehicle's height and do not cause danger or reason to stop the vehicle. The node which is responsible for detecting points that are on the path is obstacle_stop_planner. The obstacle_stop_planner is checking if any point from a point cloud is within the polygon trajectory, and decides to stop the vehicle. Checking points only within a polygon (2d information) and not taking into account the vehicle height could cause stopping the vehicle when an obstacle is above and below the vehicle. There is an example of detecting tree branches above the vehicle in the picture below.

My proposition is to extend checking if the point is within a polyhedron (3d information) instead of if is within a polygon (2d information). The idea is presented in the picture below.

[xmfcx]

This is being worked on #2296

[xmfcx]

@WJaworskiRobotec is this issue now resolved with #2296 merged?

[WJaworskiRobotec]

@xmfcx , Yes, this problem doesn't happen anymore, at least in the situation that was reported here. Issue can be closed.