Gridlocks in roundabouts

[MatteoFel]

Hi all,

I came across several occurrences of grid-locks in roundabouts.

As mentioned here

https://sumo.dlr.de/docs/Simulation/Why_Vehicles_are_teleporting.html

this is not uncommon. The priorities within the roundabout are correct. The cars within the roundabout edges positioned at the end of each of their respective edge want to exit the roundabout at an exit that is not their nearest exit. However since the next edge is at full capacity they cannot move onwards. I suspect this is the reason for the gridlock. Adding the command --time-to-teleport 5 (or any other small number) resolves this problem both in meso and micro.

My questions:

(1) I was wondering whether it would be possible to add a command of the sort --time-to-teleport.roundabout, that is vehicles are only teleported if they get stuck on such roundabout edges? (I think this would be in the same spirit as --time-to-teleport.bidi, right?)

(2) Or allowing even more freedom: would it be possible to pass a list of edges on which vehicles would be teleported if they get stuck?

(3) Are there other ways of dealing with gridlock, apart from those mentioned here in the documentation (https://sumo.dlr.de/docs/Simulation/Why_Vehicles_are_teleporting.html)?

SUMO-version: 1.18

operating system: Mac

Thanks so much!!

[m-kro]

As the exit edges are uncongested, there must be some problem with at least one vehicle inside the roundabout. Would you be willing to share your simulation scenario here on Github? You can attach a zip archive to your post.

[MatteoFel]

Sure, thanks for the quick reply. The gridlocks start at around 16:30, and the junction of interest is the roundabout that includes junction:2276702444.

roundabout_issue.zip

My guess is that due to the high demand, the edges within the junction are filled, and since no one wants to exit at their nearest exit, the gridlock occurs.

Thanks a lot!

[ambuehll]

hi @behrisch,
this is kind of an important issue for us. given that @m-kro looked into #13970 I thought maybe there is something going on this front as well :)
Any ideas on a workaround for this, would be very helpful.
Many thanks as always!

[aminissn]

After reading #15354 @namdre I can say "cars on the outside will always yield to cars in the roundabout thereby avoiding gridlock." doesn't work all the time in meso, but seems to work fine in micro.
I tested this scenario in more details. I can observe that sometimes vehicles inside the roundabout yield for other vehicles to enter the roundabout (not always, just at random some cases, I cannot generalize). But! this seems to happen in meso only. In micro it works fine.
I reduced the size of the sample network. In this attached video you can see an example in which the blue vehicle (473) is stopping inside the roundabout to let other cars enter. I first thought this could be caused by rerouting but doesn't seem to be the case since the vehicle is not rerouted. There is a second video from the larger network, the same phenomenon happens on another edge and cars from south are entering. I increased the length of the edge, moved some of the points to change geometries, but none worked.
Not sure what the problem is, but may a teleport option is still useful, because if vehicles get rerouted inside roundabout, gridlock can happen.

Archive.zip

Screen.Recording.2025-01-23.at.22.47.47.mov

Screen.Recording.2025-01-23.at.22.07.01.mov

[namdre]

• I've seen rare instances of vehicles coming to a standstill inside the roundabout in micro (5 times in 30k seconds):
  • the vehicle on the outside had accumulated a very high impatience value
  • the vehicle inside was quite slow, just having entered from the upstream arm
  • the network being without internal links puts the entering vehicle directly ahead of the inside-vehicle (otherwise, there would be the whole junction space between them to moderate the interaction)

I can confirm that there is a bug in the meso behavior. It's suppsed to be jam free when either option --meso-junction-control or --meso-junction-control.limited is set

[namdre]

regression in 1.4.0 via #5830
@ambuehll you may be familiar with that ticket

[namdre]

The test case provided by @aminissn was very responsive to the issue due to option --time-to-impatience 7

[ambuehll]

Thank you very much! If I understand correctly, meso-impatience was causing this and you turned it off in roundabouts now?

[namdre]

Thank you very much! If I understand correctly, meso-impatience was causing this and you turned it off in roundabouts now?

Yes. Avoiding roundabouts from jamming is an overriding concern. There is still potential for improvements (#16081) but the effect size of refinement is hard to guess.