NetLogo User Community Models

(back to the NetLogo User Community Models)

Download If clicking does not initiate a download, try right clicking or control clicking and choosing "Save" or "Download".(The run link is disabled for this model because it was made in a version prior to NetLogo 6.0, which NetLogo Web requires.)

WHAT IS IT?

This simulation was exended from the model "Gridlock" by Uri Wilensky & Walter Stroup, which comes with NetLogo 2.0.0 (see more info at the bottom)
Traffic lights try to "self-organize" for improving traffic.

Traffic is not so much an optimization problem, but an adaptation problem, since traffic flows and densities change constantly. Optimization gives the best possible solution for a given configuration. But since in real traffic the configuration is constantly changing, it seems that we would do better with an adaptive mechanism than a mechanism which is optimal some times, and some times creates havoc (and it is too expensive to try to find all possible optimal solutions, since the configuration space is too huge and uncertain...).

NOTES:

+ Only q's are quite adaptive, but do not generate "excessive" synchronization... what occurs is that "convoys" are formed, which can pass much faster at intersections, and in turn leave space for other convoys... but resetting T.L. does not create much difference...

+ By mistake, Working with "wrong" parameters (non integer pg's): it switches traffic light ONLY when "tolerance" is reached. Light changes only by "request", but no actual internal clock... In any case, through stigmergy, cars self-organize... It actually seems to perform better:
+It turns out that when the lights change by themselves, the algorithm is not
as good... (changes when noone needs it)
+Then only one parameter to deal with: tolerance

+ Adjusment of pg's (metatolerance > 0) decreases the performance of self-org... (too many attempts to self-org can cause noise... similar to overfitting in ANN's???)

+ different "tolerance" & p good for different densities? (shape the size of "convoys")

+ std deviations of speed & waiting cars increase probability of traffic jam... self-org strategies have much less std. devs...

+ for medium traffic density (100 cars) and several streets (9x9), sotl-request works better (this should be chosen if too much noise will affect the return of cars... since real cities are not toroidal, probably this would be a better option for implementation...). Also to reduce the tolerance improves performance (e.g. 18 cars*ts). For higher density (200 cars) both sotl request and phase similar... For very high density (300 cars), phase better than request. If tolerance is higher, then request better... Long platoons (convoys) can promote traffic jams... good to have them, but not too long... High traffic density will give long platoons no matter what, but sotl-request seems to be better at keeping them short.
For few streets (3x3) sotl-phase seems to be best. For higher densities request needs higher tolerance in order to work properly, but sotl-phase works fine with different densities and same tolerance...

+ With very high traffic density, sotl-phase behaves almost as marching, which is ok to avoid traffic jams... Higher tolerance or mingreen might be better for this method in high density... (Marching is best strategy to avoid deadlocks for very high traffic density (>300,400,600 cars in 5x5)). For these densities, more waiting times and stopped cars give more average speed, because of reaction times.

+ self-org platoons observed of 3<=cars<=15, for tolerance=41, p=43, cars=74, 5x4, 81x81 patches. It depends on distance between intersections and tolerance

+ %vertical seems not to affect much the avgs. of static strategies, but sotl improve, performance slightly, especially sotl-request, and this increases with the extremity of %vertical

+ optim is "designed" for optimizing south+eastbound traffic. The difference of all traffic goind SE vs. all going NW is less than 0.1 ptch/ts avg.

+sotl-phase also reaches full synch in 4-dir+torus

+sotl-platoon better at low densities -> more robust full synch, but gets more quickly into traffic jams...

+main idea: should keep platoons nor too short nor too long... and as stable as possible...

TODO's:

-could do different strategies per intersection, to compare the effect of one self-org in a meching system, or a marhcing in a s-o.s.... (how much noise would this last case propagate? Similar to faulty intersection...)
-something really nasty goes on with metatolerance>0...
-do "forgetting" of lambdas and kappas (~forgetting)
-try to reach some general adaptive synchronization: this seems to be required in order to avoid traffic jams when traffic is dense... well, the "request" model does that...
-Turns? MegaCLOC!
-Nice release when paper public in arXiv or sooner
-bug when 2dirs are created BEFORE a setup of 4dirs is run. Crappy temporal solution: do a setup of 4dirs, then play with 2dirs

CHANGELOG:

1.00 2005-02-02 completed Information on how to use it....
0.23 2005-01-24 tested with faulty interesections, no big difference for any method...
0.22 2005-01-19 added cut-off method (so so...)
0.21 2004-12-10 added cut-platoon slider... sotl-platoon not good for high densities...
0.20 2004-11-28 improved sotl-platoon method, now better for high densities...
0.19 2004-11-28 added sotl-platoon method, get more robust full synch...
0.18 2004-11-24 added no-corr method
0.17 2004-11-22 added avgCars in graph
0.16 2004-11-17 changed to 10x10 grid
0.15 2004-10-13 implemented turns
implemented plots? switch
0.14 2004-10-12 fixed initial %'s
0.13 2004-10-12 implemented 4 dirs. sotl rules!
0.12 2004-10-12 adjusted non-torus to include %vertical
0.11 2004-10-11 non-torus implemented. sotl strategies still better
0.10 2004-10-11 moved interesections a bit, begining to implement non-torus
0.09 2004-10-07 Did first stats, found full synch, fixed bug of yellow lights in ResetTL
0.08 2004-06-16 ???
0.07 2004-06-15 Added "optim" strategy: it sucks! it's crap! worse than march
Fixed sotl-request (sotl-phase with mingreen works bit better)
0.06 2004-06-08 Added switch for different control strategies (now marching, sotl-request, sotl-phase (last better))
Added mingreen, not to have constant changes of lights, seems to work good.
0.05 2004-06-04 Added means to plot, shows more clearly that SOTL work better than half on, half off.... need to compare with real control techniques
0.04 2004-03-30 fixed some bugs... it wasn't working properly
(previous bugs turned out to be features...)
0.03 2004-03-29 added lambdas and adjustment of pg's
fixed yellow-light bug (no change of q when yellow-light?)
0.02 2004-03-26 added yellow lights
added %vertical for different traffic densities
0.01 2004-03-22 included pg1 and pg2 for different lights
added kappas and adjustment of q
already does better than "all on or off"
0.00 2004-03-22 just removed Hubnet functions

HOW TO USE IT

QUICKSTART INSTRUCTIONS:

Run "Setup" before starting simulation. Then start and stop with "Go". Some parameters, such as grid-sizes and four-dirs? will be applied only after pressing "Setup".

Tip: you can "freeze" the display (on top of the "city" display) and/or switch off the plots to accelerate simulations.

For model details, consult the paper "Self-Organizing Traffic Lights" http://uk.arxiv.org/abs/nlin.AO/0411066

BUTTONS:

"Setup"- Initializes simulation

"Re-run"- "soft" and quick "Setup" (just clears variables, doesn't change street topology)

"Reset-TL"- Turns phases of adaptive control methods ("sotl"'s and "cut-off") to zero, so that they need to adapt again (to check robustness)

"Go"- Start and stop simulation

CHOOSERS:

-control- select control method for traffic lights
+when changing methods during the same run, resetTL. (If one was yellow, can cause problems...)

SLIDERS:

"grid-size-x"- number of vertical streets

"grid-size-y"- number of horizontal streets

"number"- initial number of cars for "Setup" and "Re-run", maximum number of cars when torus? is off

%vertical- percentage of cars flowing in vertical roads (%horizontal= 100-%vertical)

%southbound- percentage of cars flowing in southbound roads (%northbound= 100-%southbound)

%eastbound- percentage of cars flowing in eastbound roads (%westbound= 100-%eastbound)

prob-turn- probability of turning at an intersection

simulation-speed- regulates processing speed

speed-limit- maximum speed of cars

p- phase period for cyclic control methods ("marching", "optim", and "no-corr")

mingreen- minimum green phase for "sotl-phase" and "sotl-platoon" controls

keep-platoon- "omega" distance at which carsh are checked from green light in "sotl-platoon" control

cut-platoon- "miu" cars approaching a green light at which platoons can be cut in "sotl-platoon" control

queue-cut- lambda queue length for "cut-off" control

tolerance- "theta" threshold for all "sotl" control methods

metatolerance- attempt of metaadaptive regime. Doesn't work, keep set to zero...

SWITCHES:

torus?- switches cyclic boundaries on and off

four-dirs?- toggle between two and four directions (needs "Setup")

power?- makes traffic lights work

yellow?- include yellow phase (1 timestep) between green and red phases

crash?- monitor crashes at intersections

plots?- switches plotting (off increases simulation speed)

CREDITS AND REFERENCES OF ORIGINAL "GRIDLOCK"
This activity and associated models and materials was created as part of the projects:
PARTICIPATORY SIMULATIONS: NETWORK-BASED DESIGN FOR SYSTEMS LEARNING IN CLASSROOMS and INTEGRATED SIMULATION AND MODELING ENVIRONMENT. These projects gratefully acknowledge the support of the National Science Foundation (REPP & ROLE programs) -- grant numbers REC #9814682 and REC-0126227.

Copyright 2002 by Uri Wilensky & Walter Stroup. All rights reserved.

Permission to use, modify or redistribute this model is hereby granted, provided that both of the following requirements are followed:
a) this copyright notice is included.
b) this model will not be redistributed for profit without permission from the copyright holders.
Contact the copyright holders for appropriate licenses for redistribution for profit.

To refer to this model in academic publications, please use: Wilensky, U. & Stroup, W. (2002). NetLogo HubNet Gridlock model. http://ccl.northwestern.edu/netlogo/models/HubNetGridlock. Center for Connected Learning and Computer-Based Modeling, Northwestern University, Evanston, IL.

In other publications, please use: Copyright 2002 by Uri Wilensky and Walter Stroup. All rights reserved. See http://ccl.northwestern.edu/netlogo/models/HubNetGridlock for terms of use.