apollo icon indicating copy to clipboard operation
apollo copied to clipboard

Apollo planner fails to resume moving forward when driving through closely-consecutive stop signs

Open tuanngokien opened this issue 2 years ago • 4 comments

System information

  • OS Platform and Distribution: Ubuntu 18.04
  • Apollo installed from (source or binary): source
  • Apollo version (3.5, 5.0, 5.5, 6.0): 7.0 (master branch - commit #13620)

Describe the bug

The bug happened when ego car drives through 2 controlled junctions with 2 closely-consecutive stop signs, so ego car will stop forever at the second stop sign because it cannot exit the planner state INTERSECTION_CRUISE attached on the first stop sign.

Typically, when Apollo recognizes a stop sign, its planner states are expected to change as a cycle from LANE_FOLLOW->PRE_STOP -> STOP -> CREEP -> INTERSECTION_CRUISE -> LANE_FOLLOW (back to regular state). See Apollo documentation

As Apollo's implementation, when the ego car is leaving stop sign, which tends to change from INTERSECTION CRUISE to LANE_FOLLOW, Apollo requires 1 of 2 following conditions to be satisfied:

(1) the reference line and corresponding traffic signal location is no longer overlapping.

(2) if overlapping, _the distance between start of reference line (ego car current location) and stop_line (of the first stop sign) needs to be greater than a constant value kIntersectionPassDist = 40.0(m). The basic idea is that this condition is true when the ego car go past the stop sign for more than 40 meters. https://github.com/ApolloAuto/apollo/blob/334d02d7c2e05ca882d7e635cc17f7a0f3b5fcb1/modules/planning/scenarios/common/stage_intersection_cruise_impl.cc#L88

Back to our scenario, when the ego car go pass the first stop sign and its state is being INTERSECTION_CRUISE, instead of back to regular state LANE_FOLLOW (by satisfying condition 1 or 2), ego car immediately bumps into the second stop sign (because two stop signs are located too closely). Because both condition 1 and 2 haven't been satisfied yet, and planner state is still at INTERSECTION_CRUISE of the first stop sign, so it cannot break the old cycle before start a new one on the second stop sign. Therefore, the ego car stuck forever at the second stop sign.

To fix this bug, developer should update the value of kIntersectionPassDist dynamically based on the length between intersections. I validated the root cause of this bug by hardcoding this value to 5.0m and the bug hasn't happened anymore.

...
static constexpr double kIntersectionPassDist = 5.0;  // unit: m
...

The fix means that when ego car's after just passing the first stop sign, even when still overlapping with first stop sign area, will satisfy condition 2 after the distance > 5.0m (which is easier to satisfy compared to 20.0m as original). Thus, planner state could switch to LANE_FOLLOW, end the cycle of the first stop sign and starts a new cycle of the second stop sign.

Attachments

Bug Video Demo: https://drive.google.com/file/d/1xdn13C62VqQiW2ULbZ25j3d7ewDwY-xe/view Bug Cyber Record: https://drive.google.com/file/d/1kQIHZqT3mN1mu-iEhV0x6eq-_N4y8Fgl/view After Fixed Video Demo: https://drive.google.com/file/d/1TJf-fO6LgKg57q3kplP8anb8YxYQeNTF/view HD Map - Shalun (released by LGSVL): https://drive.google.com/file/d/16U-D8tRju0FB0OAduV3ei69qCVhYSCmO/view

*All recorded simulations are configured with SimControl (and enabling Routing, Prediction and Planning modules)

tuanngokien avatar Aug 05 '22 11:08 tuanngokien

@tuanngokien I think INTERSECTION_CRUISE might not be the problem, CheckInsidePnCJunction will return true, when car is outside the junction.

daohu527 avatar Aug 21 '22 02:08 daohu527

@tuanngokien I think INTERSECTION_CRUISE might not be the problem, CheckInsidePnCJunction will return true, when car is outside the junction.

Hi @daohu527,

I've checked the condition you mentioned in the function bool StageIntersectionCruiseImpl::CheckDone, and actually it still cannot help planner to change from INTERSECTION_CRUISE to LANE_FOLLOW.

https://github.com/ApolloAuto/apollo/blob/183fbc22bde7750bdd83d6801d1885bf72d50eca/modules/planning/scenarios/common/stage_intersection_cruise_impl.cc#L104-L106

In the scenario I've uploaded in the original post, the ADC did not get out of PnC junction before bumping into the second stop sign, so planning::util::CheckInsidePnCJunction(reference_line_info) still returned True (then function CheckDone still returned False).

tuanngokien avatar Aug 21 '22 07:08 tuanngokien

So the question is why does it stop, In INTERSECTION_CRUISE mode have no problem.

Why does the creeping state cause it to stop?

daohu527 avatar Aug 21 '22 10:08 daohu527

Hi @daohu527 I could be wrong but my understanding was, that the stop decision is built by traffic_rules/stop_sign.cc https://github.com/ApolloAuto/apollo/blob/0789b7ea1e1356dde444452ab21b51854781e304/modules/planning/traffic_rules/stop_sign.cc#L79 and during the stop sign scenario, the STOP stage should remove that stop fence, and move onto the CREEP stage which builds a different stop fence. https://github.com/ApolloAuto/apollo/blob/0789b7ea1e1356dde444452ab21b51854781e304/modules/planning/scenarios/stop_sign/unprotected/stage_stop.cc#L234

Since in the scenario, the vehicle hasn't finished the INTERSECTION_CRUISE stage for the first stop sign, it will not enter the PRE_STOP nor STOP stage for the second scenario. So the stop fence for the 2nd stop sign will never be removed, and the vehicle will stop indefinitely. I don't think the CREEP stage caused it to stop because by the time vehicle stopped at the 2nd stop sign it has passed the first CREEP stage and hasn't entered the expected 2nd CREEP stage.

YuqiHuai avatar Aug 26 '22 15:08 YuqiHuai