Re-routing for a static obstacle that blocks the road

[ahmeddesokyebrahim]

Abstract

Introduction

It is likely to happen in driving situations where the vehicle finds a static obstacle that is blocking/covering the road.
It is totally annoying when it comes to the point when vehicles are not able to navigate around this obstacle to reach the desired destination and have to wait until the road is cleared. It becomes a bigger problem when this obstacle is not easy to remove and it may take longer to have the road open.

Autoware Status Que

• Currently Autoware has obstacle_stop_planner which is able to let the vehicle slow down when there is static obstacle near to the vehicle trajectory and let the vehicle stop when there is a static obstacle represent a collision point with vehicle. More details can be found here.
• As well, Autoware has rerouting ability in its mission_planner represented in rerouting service.
  However, this rerouting ability currently is not handling the situation of dynamic map information, similar to our case, as mentioned here.

Purpose

The following image explains the target situation :

Proposed Solution

As obstacle_stop_planner is currently able to detect static obstacles in near and on vehicle's trajectory, I propose the following :

• In case there is a static obstacle detected by obstacle_stop_planner, we search for an alternative route that avoids that static obstacle.
• If we are successful to find an alternative route, a rerouting request is sent to mission_planner by giving the new lanelets sequence for reaching our goal_lanelet.
  • If there are multiple possible alternative routes that avoid the static obstacle, we choose the shortest one.
• If we are not able to find alternative route (e.g., we are very close to the obstacle) or rerouting response was not successful, obstacle_stop_planner is till handling the situation.

Conclusion

• I would like to present this proposal for extending autoware ability of rerouting to handle any static obstacle that blocks the road.
• I would be very grateful to get your comments, contributions, and ideas to fix any shorting with my proposal or come to a better solution.

[maxime-clem]

A similar feature was previously requested: https://github.com/orgs/autowarefoundation/discussions/3250
Once it is implemented we can also answer that other discussion.

[TakaHoribe]

It is reasonable that Autoware detects a blocked lane and suggests an alternative route to the user, then a user can select the proposed route.

However, it is a challenging task to recognize that a lane is blocked automatically. The obstacle_stop_planner alone cannot determine if the blocking is temporary or permanent. Although, in the first implementation, it is enough to have a simple functionality like counting a stopped time and rerouting when the vehicle is stuck for more than a certain time.

On the other hand, it would be beneficial to provide an interface where users can inform about lane closures to Autoware.

For instance, as a user story, users can click on a lane in the Rviz and choose an option like "Road Closed" to request rerouting.

[ahmeddesokyebrahim]

Thanks @TakaHoribe san for your contribution and comment.
I totally agree with you regarding the challenges in this task. Not only from algorithmic point of view, but architectural and design as well to have with clean and correct implementation.

I have a question regarding this part :

On the other hand, it would be beneficial to provide an interface where users can inform about lane closures to Autoware.

Do you think the output of this interface will be coming from perception context ? or do you mean the planning modules should be doing that ?
I guess as well you mean that this interface will satisfy what you have mentioned above regarding temporary or permanent blockage. Did I get it right ?

[purewater0901]

@ahmeddesokyebrahim
Currently, autoware has provided several interfaces for rerouting a new route. You can find these interface functions in this package. However, we do not expect these functions are called from the obstacle_stop_planner.

As @TakaHoribe suggests, it would be great if you can call reroute (and find a new route as well) from a different node or package, which is outside of the obstacle_stop_planner. At the moment, autoware reroute functons are called by ad_api package, which is shown below
(In the future, MRM also can call the same functions). So it might be great if you can request the reroute from ad_api pacakge.

In short, my suggestion is like
obstacle_stop_planner → reroute node (This would be a new package) → ad_api → mission_planner

[mitsudome-r]

@ahmeddesokyebrahim
Before I post my idea, is it possible to answer the following questions? I think we need much more feature development than improving obstacle_stop_planner to request rerouting.

• What is your idea to decide whether Autoware is stuck or if it is just waiting for a temporary stopping vehicle?
  • Obstacle_stop_planner only stops for existing pointcloud on it's trajectory, and it doesn't know whether it is going to be cleared soon or not. Do you plan to look at the duration of vehicle being stopped, or do you also plan to consider information like the obstacle information (whether it is stopped for vehicle or construction cones, etc.)?
• When vehicle stops for rerouting, do you want the vehicle to stop before entering blocked lane (as in Case 1) or do you expect the vehicle to do U-turn within the blocked lane (Case 2).
  • If you expect case 1, then we need improvements in perception modules to detect blockage in long range and also make planner to stop before entering the lane
  • If you expect case 2, then we need update in routing algorithm to support U-Turns as well.
    
    

[armaganarsln]

I appreciate the discussion on the topic, although it is not an area I am well-versed in or particularly interested in. If we have available resources, I would prefer to allocate them toward addressing the immediate challenges we are currently facing with our planner. Its performance in crucial areas such as overtaking, swerving, following vehicles, pull-ins/outs, and parking is not yet ready for public driving. It would be more prudent to focus our efforts on resolving these issues first before delving into the mentioned prototype. Once we have successfully tackled the current public road driving problems, we can then shift our attention and resources toward exploring those specific areas. Thank you for considering this perspective.

[ahmeddesokyebrahim]

The following implementation approach can be disucssed in planning and control WG meeting :