Some cars get stuck at intersections forever for no apparent reason

[belt-drive]

Sometimes cars get stuck at an intersection through multiple light cycles even when it seems like they have a clear path through the intersection. This issue is particularly bad at the intersection of MLK and Graham in Seattle. It is likely caused by the small one-car "intersections" here over the train tracks. However, the intersection seems to be blocked even when there isn't a car trying to take a left from Graham onto MLK.

Realistically, cars shouldn't be able to "stage" for the intersection on the railroad tracks. That area should be considered part of the signalized intersection somehow, so that it is only open when the surrounding signals are green and all cars have to clear before it is blocked again.

[dabreegster]

Thanks for reporting (and for continuing to try things out)! This is another case the uber-turn logic for reserving a sequence of turns is messing up. https://github.com/a-b-street/abstreet/issues/382#issuecomment-730794539 has a bit more explanation of how all of this currently works. @BruceBrown found another example of this problem recently and is exploring workarounds.

You could try to debug what's going on here by entering dev mode (ctrl+S), then debug mode (ctrl+D), then the blocked-by tool (b). If you hover over any car, it'll tell you the chain of why it's blocked. And if there are any cycles, it'll find them. This tool might be currently missing some of the dependencies caused by uber-turn reservation.

I think the real proper fix here is to merge these 8 "intersections" into one big piece. Recently (https://github.com/a-b-street/abstreet/issues/114#issuecomment-751918520) made progress on doing that in some cases, but the algorithm for producing the shape of the intersection and preserving all of the turns correctly has bugs still. I remember trying it along MLK a few weeks ago and hitting some major issue with it. I'll use this bug to try again and record what's going wrong.

[BruceBrown]

@belt-drive I'm trying to reproduce this. Did you modify any of the intersections in the South Seattle map? Does it happen every time at the same time? Here's what I've found so far. The intersection on West bound South Graham St and North bound MLK is part of an uber-turn with East bound South Graham St and North bound MLK. It seems to favor the west bound intersection for reservation, which seems to lead to the intersection south of it becoming locked. As long as there's a waiting west bound S. G. vehicle, nothing is moving from the other intersection. Even if the signal changes, and it appears that a vehicle can move through a series of green lights to complete its turn, its no allowed to. As has already been said, merging these is one solution. I'm not a fan as it involves manually manipulating it. I'd rather enhance the logic to deal with this kind of situation, maybe by round robin selection of which intersection has priority for reservation; with any intersection with demand being a participant.

[belt-drive]

As for repro, I just opened the "South Seattle" map with no edits and found this behavior at Graham and MLK with person 132644 starting at 5:45 a.m. See screenshot below from the blocked-by tool.

I don't have an opinion as to how this should be resolved, I'll leave that up to you all. I will say that one of the challenges is that the Open Street Map layout doesn't reflect the physical reality of some small intersections like these very well. The Open Street Map shows room for 2 or 3 cars to bunch into the intersection on top of the railroad tracks, but that's not consistent with the reality on the ground. I think the width of the tracks is exaggerated in the Open Street Map.

[dabreegster]

I tried merging, but it comes out awful, and still 2 intersections: Merging can be applied automatically, using heuristics about how short roads are. The shape and resulting turn connections aren't specified manually; an algorithm does it. But of course, that algorithm doesn't handle these kinds of cases yet. I'll keep working to improve it, but no idea how long/hard it'll be.

[BruceBrown]

I wonder what would happen is we used my lagging green logic on the uber turns? The only case I'm finding where it doesn't do well is when two oncoming lanes try to left turn -- for most cases it resolves to a protected turn -- however some cases where its a wide to narrow road one of the left turns must yield. I'm not sure if that's reality of just a rounding error in the turn validation logic( no pun intended).

[dabreegster]

Copying over some debugging messages with @BruceBrown from Slack:

This is 5:44:48 on the s seattle map:

I think I'm understanding the problem. The stuck blue car is c116586. at 5:44:30, the light switches green and they try to lock the UT to go north across the two intersections. But self.handle_accepted_conflicts prevents it, because of the second turn. The reason is the bike on the right managed to lock their UT first. They wind up in the right lane of the tiny middle road, then their second turn merges into l25623. The blue car's turn goes from the middle lane. The two turns conflict, because they have the same destination.

Per the docs on maybe_start_turn, since this whole function fails and returns false, the blue car will not retry on its own. For traffic signals, the retry is triggered either by the light changing or somebody finishing a turn in the first intersection. And indeed, the bike clears the first intersection at 05:44:33.3, but the red car behind it wins. Red car clears at 05:44:34.8, another try, but now the red car is in the middle of the second intersection, again doing that conflicting turn. The problem is that when the red car clears the second intersection, it doesn't wake up anybody waiting at the first intersection again!

I think it should always be "safe" to "spuriously" wake up cars at traffic signals and have them go through maybe_start_turn. The only cost is performance.

Possible resolution: In turn_finished, if the turn was part of an UT, wake up all intersections in the sequence. Or, if the turn belongs to an intersection cluster (the thing through which UTs go), wake up all intersections in the cluster

Another possible fix: use a slightly different definition of turn conflict when checking for UT compatibility. Allow turns that go between the same (src, dst) roads -- aka merges/LCs. That would mean more vehicles pack into the tiny middle road from the same direction, which is... maybe better for throughput? I dunno

[dabreegster]

Another issue here is just that OSM is wrong. MLK doesn't go from 3 lanes down to 1 here; it goes from 3 to 2, and the leftmost lane on the southbound side is a turn lane. https://www.openstreetmap.org/way/250169478 doesn't have lanes tagging. We likely wouldn't have seen this problem at all if there were 2 lanes, because the two queues of cars going nb would each stick to their lane due to @michaelkirk's heuristics for saner LCing in UTs.

@belt-drive if you have time and knowledge, it'd be super useful to go through MLK in OSM and fix up the lane tagging. This is another reason why picking a slightly smaller study area can be nice; it's less overwhelming to consider fixing "everything" in OSM.

[belt-drive]

I was wondering what was going on with that 1-lane stretch of MLK. I can do some on-the-ground research and work on correcting some of the lane classifications in OSM.

On Thu, Feb 4, 2021 at 9:50 PM Dustin Carlino notifications@github.com wrote:

Another issue here is just that OSM is wrong. MLK doesn't go from 3 lanes down to 1 here; it goes from 3 to 2, and the leftmost lane on the southbound side is a turn lane. https://www.openstreetmap.org/way/250169478 doesn't have lanes tagging.

@belt-drive https://github.com/belt-drive if you have time and knowledge, it'd be super useful to go through MLK in OSM and fix up the lane tagging. This is another reason why picking a slightly smaller study area can be nice; it's less overwhelming to consider fixing "everything" in OSM.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/a-b-street/abstreet/issues/497#issuecomment-773807621, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQEDTNCMVHCPB52E6KT4AMLS5OBL3ANCNFSM4XDGGP5A .

[dabreegster]

Another uber-turn bug discovered:

I've got a case where a car is both in the waiting BTreeSet and reserved BTreeSet. Is this expected? There could be a problem with wakeup_waiting. It doesn't wake up banned turns. Maybe it should wake up > reserved turns, even if banned?

I think waiting and reserved makes sense. A car reserves a turn as part of an UT. When they reach that intersection, they try to start the turn, but even though it's reserved, there's someone in the way or it fails for some reason, so they register as waiting You're right about waking up banned reserved turns. There's some code that explicitly "runs the red light" in case of reservations. So to honor that rule, we also have to wake those up