NetLogo User Community Models
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 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...).
+ 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:
+ 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.
+ 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...
-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...)
1.00 2005-02-02 completed Information on how to use it....
HOW TO USE IT
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
"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
-control- select control method for traffic lights
"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...
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"
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:
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.
(back to the NetLogo User Community Models)