Bus priority without TraCI

[aminissn]

I am working on a function to add bus priority by modifying tllogic mainly using next and earlyTarget attributes. It is working on single intersections coming with certain limitations, but I would like share my code and ask for anyone to contribute and improve it. There are certain cases where it doesn't work, for example if two buses come from two directions, or when time since detection is shorter than required minimum green + amber times from conflicting approaches. This function also requires some extra functionalities from sumolib for which I will create pull request. Hopefully, they won't causes any backward compatibility or test failures. bus_priority.py.zip

[namdre]

Looks useful. My first thought is on the feasibility of adding this code within SUMO to the actuated controller and activate it with params. (#9163 or even #9595). But having this out there as a well-contained tool is a good start and with a bit of polish could be included in the distribution.

[aminissn]

I wasn't aware of these issues. Would be nice to push this. I also think this can be a tool of its own and maintained in the future distributions. How could I better share the code? I still think it is not clear enough what is happening in the code because I was testing a few things on the network and of course there are special cases in there.

[ambuehll]

cc: @AlessioRimoldi

[aminissn]

I made a pull request to add the code to tools/tls/busPriority.py. Maybe on a new branch would have been better until the code gets an acceptable state for distribution? see https://github.com/eclipse-sumo/sumo/pull/15230

[namdre]

Here would be my criteria for acceptability:

1. add an option module so that no relevant parameters/paths are hard-coded
2. have test cases for the stuff that works. Two levels of tests make sense:
   • a test in tests/tools that compares the generated .add.xml
   • a test in tests/complex that generates the .add.xml and runs a simulation in which different types of preemption occurs
3. clean up typos in code

Nice to have:

4. have (complex) test cases for the stuff that doesn't work yet (as a form of documentation)

[aminissn]

To agree on the logic and to suggest ideas to improve my initial logic, I would like to ask for your opinion if I can already improve it. This is what I have currently in mind: 1) bus signin, 2) phase transition and 3) bus signout we have signin detectors x meters upstream of a tls that detect incoming buses, and then a phase transition starts to accommodate the bus going through the tls with a specific and dedicated green phase with a maxDur (60sec). This is important because, in offline mode, we cannot know in which direction the bus might turn at the tls, therefore we need a phase that has green for all lanes for that edge from which the bus is approaching the tls. Downstream of the tls, we have signout detectors that immediately switch back to the original tls logic. Limitation 1: once a priority transition starts, we cannot consider another bus coming from another approach. Limitation 2: If there is a long queue or a bus stop and the bus cannot pass through the tls in 60sec, it cannot be re-detected. Limitation 3: Switching back to normal tls logic may not be ideal, to compensate the conflicting phases.

[namdre]

• the (as of yet) undocumented detector attribute 'nextEdges' (#9927) can be used in all detectors to filter by route. This means we could have detectors that "know" where the bus is going even in the absence of dedicated turn lanes. The real-world correspondence would a b a sign-in that provides line/route information
• limitation 1 is fine for now, I guess
• with respect to long queues, the sign-in should switch early enough to clear any queues (or at least this could be an optional feature)
• approaches with a busStop after sign-in could get special treatment in the future (phase transition is delayed by the stopping duration) but for now this is fine I guess
• I suppose the 60s limitation is a work-around for busses that have unforseen delays. If this happens rarely enough I wouldn't fret about this.
• switching back to normal logic could at least consider the next phase that would have been due before switching to the bus phase. Presumably this phase has the worst queue at that point in time.