Improving Bus Stop Departures in Autoware

[MertClk]

Background

In Autoware, ego vehicles can perform parking maneuvers in shoulder lanes or roadside areas and depart safely while considering surrounding traffic. However, these features may not fully meet the requirements for large vehicles, such as buses, due to limited parking space, the need for predefined stop points, and other field-specific constraints.
Currently, goal_planner and start_planner can be used for pull-over and pull-out maneuvers. While they support roadside docking and departure, their performance is limited in certain scenarios, especially for buses. To accommodate the constraints of large vehicles, bus stops are often annotated as regular lanes. However, this approach reduces the effectiveness of goal_planner and start_planner, leading to the need for alternative solutions to ensure safe and efficient bus stop departures.
The goal of this discussion is to establish a common understanding for future developments that ensure safe departures from bus stops.
Depending on road geometry and integration requirements, multiple approaches could be used for bus stop departures. Potential solutions include enhancements to start_planner, leveraging intersection module, or utilizing the blind_spot feature with additional safety checks. While these methods offer working solutions, our aim is to develop a standardized implementation that aligns with best practices within Autoware.

Problem Statement

• Bus stop departure requires a controlled and safe re-entry into the main lane.
• Ego vehicle should only depart when there is no risk of collision with approaching traffic or obstacles.
• Ego vehicle should be able to identify and respond to yielding behavior from vehicles behind, even when other vehicles are moving.

Disadvantages of the Current Implementation

• It lacks an optimized and standardized approach for bus re-entry.
• It reacts to every vehicle approaching from behind without considering their interactions with each other, which may lead to unnecessary delays.
• When the bus stop area is annotated as a road lane, collision checking may ignore the sibling lane of the bus stop, depending on the map configuration.
• It does not account for moving objects in adjacent lanes when performing collision checks.
• Roadside pull-out is possible, but if the lanelet has a centerline, start_planner will not be triggered due to the lateral distance to the centerline. Since the centerline is often required for optimal docking, this can be a significant limitation.

Example Bus Stop Lanelet2 Map Annotations

Scenario	Image
Example -1
Example -2
Example -3
Example -4

Example Bus Stop Departure Scenarios

Scenario Description	Scenario Image
Ego should depart when it is safe.
Ego should yield to the vehicle coming behind if there is a collision risk.
Ego should depart if the vehicle behind decreases its velocity to give the right of the way.
Ego should depart if the vehicle behind stops to give the right of the way.
Ego should check forward direction as well for safety.
Ego should depart when there is enogh space between objects.

Open Questions

• How can start_planner be adapted to support bus stop departure scenarios above?
• Are there any constraints or limitations in start_planner that we should consider for this use case?
• What additional parameters or conditions should be incorporated for safe re-entry?
• Are there alternative approaches that might be better suited?

Next Steps

1. Gather feedback from the Autoware community on the feasibility of this approach.
2. Identify potential development approach to support this use case.
3. Develop a proof-of-concept implementation and validate its performance.
4. Iterate based on test results and community input.

[MertClk]

cc. @shmpwk @mebasoglu @mehmetdogru @TakahikoHasegawa97 @soblin

[kyoichi-sugahara]

@MertClk
Thank you for the clear structural explanation. And sorry for late response.

Based on the current specification of start_planner, safety judgment for vehicles behind does not trigger a stop if the ego vehicle has sufficiently entered the adjacent lane and determines there is no room for the following vehicle to pass.
However, since the vehicle is currently driving in the driving lane, start_planner's completion condition of "merging into the driving lane" is satisfied and it terminates. It seems that vehicles in adjacent lanes are not being included in the detection targets.

The map definitions and use cases you've presented are not included in start_planner's supported use cases, so it seems the safety judgment for adjacent lanes is not working correctly.
Therefore, I believe we need the following changes:

• Modify start_planner to not terminate in sections where we want safety judgment to continue operating
• Include both dynamic and static obstacles in the safety judgment targets for the presented use cases

[MertClk]

@kyoichi-sugahara
Thank you for your contribution to this discussion. I had following ideas in my mind when I was writing the proposal.

Modify start_planner to not terminate in sections where we want safety judgment to continue operating

Bus stop area regulatory element might be integrated to the start_planner and by this way we can continue having safety check as long as the bus stays in the bus stop area.

Include both dynamic and static obstacles in the safety judgment targets for the presented use cases

I agree. However, the interaction between predicted objects are also important. The ego shouldn't wait for moving vehicles when the closest vehicle behing give the right of the way.

[kyoichi-sugahara]

@MertClk
sorry for late reply.

Bus stop area regulatory element might be integrated to the start_planner and by this way we can continue having safety check as long as the bus stays in the bus stop area.

Sounds good to me 👍

The ego shouldn't wait for moving vehicles when the closest vehicle behing give the right of the way.
I really agree with this idea, and many modules are having this kind of problem not only start_planner module. So I recommend having this feature in autoware_behavior_path_planner_common package so that other behavior path planner module can use this feature if you will implement.

[MertClk]

Thank you! I haven't started do any development now. I'll share updates with you when the development is on-going.