System Info
Apollo side
- OS: Ubuntu 20.04.1 LTS
- GPU: NVIDIA GeForce RTX 2080 Ti
- Apollo version: 7.0, with a self-patched modification to the Pull Over feature (fixes an issue where the vehicle fails to merge into the rightmost lane and instead stops in the current lane)
- Modules enabled: Localization, Perception, Transform, Routing, Prediction, Planning, Traffic Light, Control, Recorder
- Prediction module modification: Perception input replaced with 3D ground truth (gt_perception)
- Map: SanFrancisco_correct, with a correction applied to several lanes whose width was incorrectly set to 3.5m instead of the standard 3.7m
Simulator side
Bug Description
In this scenario, the Ego vehicle is required to change from the right lane to the left lane in order to perform a left turn at the upcoming intersection. However, due to an NPC vehicle driving in the adjacent lane, the Ego vehicle is unable to complete the lane change before reaching the intersection. As a result, it enters the intersection still in the wrong lane, undergoes several rerouting events while traversing the intersection, and eventually comes to a stop mid-turn, inside the intersection.
From the attached video, it can be observed that the planning stage transitions from TRAFFIC_LIGHT_UNPROTECTED_LEFT_TURN back to LANE_FOLLOW during this sequence.
To Reproduce
Our Scenario
- Ego initial pose: (-426, 10.2, 414.18)
- Ego goal pose: (-509.35, 10.2, 444.73)
- NPC initial pose: (-422.2, 10.2, 403.37)
- NPC maneuver: Starts from a stationary state and accelerates. In our case the NPC performs a lane change, but any NPC behavior that prevents the Ego vehicle from completing its own lane change in time should be sufficient to reproduce this issue.
Video and rosbag are attached below.
Expected Behavior
Since the lane change was not completed in time, the Ego vehicle should reroute to first turn right, then come back around and re-attempt the left lane change followed by the left turn, rather than continuing to attempt the original left turn from the wrong lane and stalling inside the intersection.
Suspected Root Cause
(Note: given the complexity of ADS planning logic, this may not be the sole factor. We are sharing our analysis in case it is useful, but a full fix likely requires closer review from maintainers familiar with this code path.)
|
double current_time = Clock::NowInSeconds(); |
|
if (rerouting->has_last_rerouting_time() && |
|
(current_time - rerouting->last_rerouting_time() < |
|
config_.rerouting().cooldown_time())) { |
|
ADEBUG << "Skip rerouting and wait for previous rerouting result"; |
|
return true; |
|
} |
|
if (util::IsDifferentRouting(last_routing_, *local_view_.routing)) { |
|
last_routing_ = *local_view_.routing; |
|
ADEBUG << "last_routing_:" << last_routing_.ShortDebugString(); |
|
injector_->history()->Clear(); |
|
injector_->planning_context()->mutable_planning_status()->Clear(); |
|
reference_line_provider_->UpdateRoutingResponse(*local_view_.routing); |
|
planner_->Init(config_); |
|
} |
In modules/planning/traffic_rules/rerouting.cc (lines 101-107), once a rerouting is triggered, subsequent reroutings are suppressed for a cooldown_time of 3 seconds. However, in modules/planning/on_lane_planning.cc (lines 322-329), whenever the routing changes, the previous PlanningContext stored in injector_ is cleared entirely, including last_rerouting_time(). This effectively resets the cooldown check in rerouting.cc, allowing a new rerouting to be triggered immediately.
In this scenario, this appears to cause a rerouting to fire while the Ego vehicle is already mid-execution of the left turn, reverting the planning stage to the default LANE_FOLLOW. With the vehicle already misaligned relative to this new stage's expected state, path optimization subsequently fails, resulting in an emergency stop.
Suggested Fix Direction
Preserving last_rerouting_time() independently across PlanningContext resets (rather than clearing it along with the rest of the context) would restore the intended cooldown behavior for cases like this one. That said, we believe the more fundamental issue may be that rerouting is triggered too late relative to the vehicle's committed maneuver, so a narrower fix around the cooldown handling may address the symptom without fully addressing the underlying timing issue.
System Info
Apollo side
Simulator side
Bug Description
In this scenario, the Ego vehicle is required to change from the right lane to the left lane in order to perform a left turn at the upcoming intersection. However, due to an NPC vehicle driving in the adjacent lane, the Ego vehicle is unable to complete the lane change before reaching the intersection. As a result, it enters the intersection still in the wrong lane, undergoes several rerouting events while traversing the intersection, and eventually comes to a stop mid-turn, inside the intersection.
From the attached video, it can be observed that the planning stage transitions from TRAFFIC_LIGHT_UNPROTECTED_LEFT_TURN back to LANE_FOLLOW during this sequence.
To Reproduce
Our Scenario
Video and rosbag are attached below.
Video: Google Drive link
Bag: Google Drive link
Expected Behavior
Since the lane change was not completed in time, the Ego vehicle should reroute to first turn right, then come back around and re-attempt the left lane change followed by the left turn, rather than continuing to attempt the original left turn from the wrong lane and stalling inside the intersection.
Suspected Root Cause
(Note: given the complexity of ADS planning logic, this may not be the sole factor. We are sharing our analysis in case it is useful, but a full fix likely requires closer review from maintainers familiar with this code path.)
apollo/modules/planning/traffic_rules/rerouting.cc
Lines 101 to 107 in 463fb82
apollo/modules/planning/on_lane_planning.cc
Lines 322 to 329 in 463fb82
In modules/planning/traffic_rules/rerouting.cc (lines 101-107), once a rerouting is triggered, subsequent reroutings are suppressed for a cooldown_time of 3 seconds. However, in modules/planning/on_lane_planning.cc (lines 322-329), whenever the routing changes, the previous
PlanningContextstored ininjector_is cleared entirely, includinglast_rerouting_time(). This effectively resets the cooldown check in rerouting.cc, allowing a new rerouting to be triggered immediately.In this scenario, this appears to cause a rerouting to fire while the Ego vehicle is already mid-execution of the left turn, reverting the planning stage to the default LANE_FOLLOW. With the vehicle already misaligned relative to this new stage's expected state, path optimization subsequently fails, resulting in an emergency stop.
Suggested Fix Direction
Preserving
last_rerouting_time()independently acrossPlanningContextresets (rather than clearing it along with the rest of the context) would restore the intended cooldown behavior for cases like this one. That said, we believe the more fundamental issue may be that rerouting is triggered too late relative to the vehicle's committed maneuver, so a narrower fix around the cooldown handling may address the symptom without fully addressing the underlying timing issue.