Difference between revisions of "Lane-merge optimization"

From Simulace.info
Jump to: navigation, search
m (missing comma)
(work in progress: Parameters, Results)
Line 47: Line 47:
 
* Min/max range for desired speed
 
* Min/max range for desired speed
 
* Min/max range for acceleration (this covers both technical possibilities of a cars and agents' reaction time)
 
* Min/max range for acceleration (this covers both technical possibilities of a cars and agents' reaction time)
* Early-merge method inclination (%)
+
* Early-merge method inclination (may merge sooner than cars in front of him, %)
 
* Willingness to let another car zip-merge (%)
 
* Willingness to let another car zip-merge (%)
 
* Min/max range for distance to lane end at which agent ideally wants to merge
 
* Min/max range for distance to lane end at which agent ideally wants to merge
Line 57: Line 57:
  
 
== Results ==
 
== Results ==
 +
 +
Because of the dependence on a wide variety of parameters, it is difficult to isolate the effects of individual factors and to conclude a definitive result from the simulations. One basic and primary indicator of performance of a setup is the exit throughput of cars (in other words the number of cars that successfully exit the simulation per unit of time). However, an important aspect to keep in mind is that given an average car exit speed and average distance between cars, there is only a limited car throughput we can achieve and unless we also consider other performance indicators, there is no point in trying to optimize beyond this value. Still, there are also other indicator values that would be important in real life, but for simplicity, they were not numerically measured in this simulation, such as evenly distributed throughput across the lanes (so some drivers do not wait in a traffic jam significantly longer than the others).
 +
 +
=== Merge distances, early merge ===
 +
 +
One of the most noticeable factors affecting the final throughput turned out to be the merging distances, i.e. the distance to lane-end at which an agent stars to merge (and eventually might stop to do so, obstructing the traffic behind him). This is quite easy mistake we may commonly see in the real-life: individual cars merging and slowing-down the traffic at different places lead to under-utilizing the final (right) lane, while on the other hand, the leftmost lanes may get completely hindered or start creating extensively prolonged waiting queues. The difference between this setup and setup where all cars merge at the same point at the end of the lane '''amounted up to 20% in our simulation case'''. Small remedy to this situation is if we enable an early merge (this means that the cars waiting in queue may take advantage of an opportunity to merge earlier than the cars waiting in the queue ahead of them).
 +
 +
<gallery>
 +
File:Lane_mergers41_merge_distances_A_interface_small.png|Cars merging at different distances
 +
File:Lane_mergers41_merge_distances_B_interface_small.png|All cars merging at the end of the lane
 +
File:Lane mergers41 merge distances A early interface.png|Cars merging at different distances, early merge enabled
 +
</gallery>
  
 
== Conclusion ==
 
== Conclusion ==
  
 
== Code ==
 
== Code ==

Revision as of 20:35, 17 January 2016

  • Project name: Lane-merge optimization
  • Course: 4IT496 Simulation of Systems course at University of Economics, Prague
  • Author: Martin Zima (xzimm000, mailATzimamartinDOTcz)
  • Model type: Agent-based simulation
  • Software used: NetLogo 5.3

The model presented by this paper is simulating the situation of car multi-lane merging.

Preface

During the past centuries, once technologies became advanced enough to start the industrial revolution, the importance of transportation became obvious. Companies need efficient means of transport for their manufacturing logistics just as much as regular passengers for their every-day travels do. Managing an efficient traffic flow has always been a challenging task ever since these days, as it encompasses lots of aspects and requirements: it is necessary to provide a performant (efficient), reliable, safe and sustainable traffic flow control, and figuring-out the best rules or configuration, let alone ensuring the adherence to them, has not ever been an easy task. One of the most complicated transportation types for this has been the road (car) traffic - not only for its limitation regarding the spatial dispositions (roads vs. air, sea, etc.), but also for the amount of its interacting agents and their nature.

In comparison with other means of transport, car traffic has many peculiarities of its own: for starters, there is usually a significantly higher of agents interacting at one moment a place on the road. Furthermore, the agents are usually not trained specialists: the usual requirement for their involvement in the system is the possession of a driver's license, which guarantees only an obligatory minimum experience and knowledge of the traffic rules. As any other human beings, these agents are even more prone to making mistakes while driving and making bad decisions, leading to even worse performing traffic (and finally, to situations commonly dubbed as traffic jams or congestions). There is a number of specific critical scenarios, where determining the optimal traffic control becomes even harder or is depending on so many external parameters and influences that we cannot predict a single, simple general rule, that would be best for the agents to follow. On the other hand, technology has become nowadays so advanced, there are already many ongoing projects analyzing and developing smarter computer-based systems, that could save resources (transportation costs, time...) and moreover, actually relief the traffic. Self-driven autonomous cars or interconnected smart traffic signalization are just a few of the examples of optimizations we might be hoping for in the near future.

This is where comes an opportunity for this paper - to be able to implement such optimizations, we first must know at what areas of the problem to focus on (there is this saying, 'premature optimization is the root of evil'...). One of typical examples of the aforementioned critical road traffic scenarios is the lane-merge. In simple words, a lane-merge is a situation, where two or more lanes (of one direction) merge into one. The reasons for a lane-merge are numerous - ranging from a simple street narrowing to various traffic obstructions (car accident, roadworks...). Due to its nature (lower number of lanes will always lead to theoretically lower maximum throughput), but also possibly due to human error, different agents' driving opinions, inexperience and perhaps also different law regulations (generally, sub-optimal behavior of agents), lane-merges tend to be one of the most typical traffic jams causes. Because of the multitude of possible factors, it is almost impossible to analyze this in a mathematical (hand-computation) fashion, but is quite well suited for a computer-assisted simulation.

Problem definition

The primary goal of this paper is to create a plausible real-world model of car lane merges to study and determine factors and circumstances that influence the continuity of traffic flow and cause traffic jams, and in consequence how to avoid them, and to determine the best settings for an optimized traffic performance. Primarily, the model should take into account the common inefficiencies of human agents (human error...) and also offer another solution utilizing agents that act in a more consistent, rule-coherent, autonomously-driven-, computer-based-car-alike way. To verify and deliver the results of such model, a computer-based simulation will be developed. Based on the results of this simulation, we should be able to compare the different approaches and configurations and to measure (at least in orders of magnitude) their impact on the traffic fluency. The paper should conclude how observed phenomena affect the car traffic and whether it might be worth to enforce certain rules for the lane merges (or to implement them in the future autonomous computer-based agents).

Method

World visualization in NetLogo 5.3

Software environment

Because of the multi-agent and spatial nature of the model, whose representation should be able to convey the traffic flow phenomena, NetLogo 5.3 software has been chosen as the simulation environment, being deemed suitable for the considered task.

Simulation world

The simulation space (world in NetLogo terminology) itself has been used as one continuous area of the road, heading uni-directionally from bottom to the top, and being horizontally split into a number of parallel lanes (the number is a configurable parameter). The first (first as in the sense of the part, where the cars appear first, i.e. the bottom) part of the world is the full-width section of the road; from the middle and further, the lanes start to merge (for simplicity, we consider only right-to-left merges, but in our case scenario, the results should be similar even with left-to-right, which are not that common). There is configurable (but fixed during one simulation run) number of cars spawning per unit of time (which is measured using fixed timesteps, which NetLogo calls 'ticks'). These new agents, randomly (but uniformly) distributed across the lanes, start at the beginning of a lane and try to get to the end of the road (as a result of which, some of them must change the lane in the end) as fast as possible (although obeying certain rules and simulation settings and affected by some of their own preferences, of course). Once an agent gets past the end of road (end of the world), he disappears from the simulation and no longer affects its further progress.

Behavior of agents

The objective of this paper was to primarily simulate the natural behavior of human agents driving cars. To achieve this, the model tries to mimic number of aspects of the typical human driver behavior. First of all, because our goal is not to simulate car crash accidents (we simply assume no agent makes such a crude error - otherwise we would be simulating a completely different thing), the priority number one of every agent is maintaining a safe speed and distance between cars (i.e. him and the possible car ahead of him). If circumstances allow (environment and other surrounding agents), the agent will also then accelerate up to his desired speed. For the simplicity of this simulation and also to reduce possible undesired effects, we assume the agents have an immediate reaction while braking and are able to decelerate to zero instantly (unlike the positive acceleration, which takes time).

Moreover, unless there is a lane merger nearby (which would prevent him from doing it), he may also overtake a slower-driving agent in front of him, using the lane to the left (if there is one). Once he finishes this maneuver, he pulls back to his original lane (and eventually any other lane to the right of him as long as there is enough free space and he reached his desired speed). Presented simulation better corresponds to the situation of a city street road than other multi-lane roads (like highways), because it allows a faster agent to overtake another agent also using the lane on the right of him (which is usually forbidden in many countries), as long he was in that lane first.

Agent switches to a slightly different behavior once he approaches a line merge (the point, where a lane ends, and he is forced to switch the lane). From certain distance to the lane end, the agent starts to check if there enough space in the lane he wants to merge to, and in case there is, then if he is the last one in his lane or if he prefers an early merge, he starts to switch the lane. If the agent does not succeeds with this, then, after another certain distance-to-lane-end value, he starts to 'worry' he might not make it in time, resulting in a sudden deceleration to lower speed. During this period, if there happens to be another agent to his right willing to let him merge ('zip'), the agent to the right slows down and lets him merge. If he does not succeed with this either, he might eventually get to a point, where he is forced to stop the car completely (speed set to zero).

Parameters

There is a number of different parameters that configure the model values and affect the overall outcome of the simulation. Moreover, many of these parameters are simply ranges with every agent randomly picking his own value falling inside this range (agent's preferences influencing his decisions).

Environment parameters

  • Number of lanes
  • Car inflow (car spawned/time unit)

Agent behavior

  • Min/max range for desired speed
  • Min/max range for acceleration (this covers both technical possibilities of a cars and agents' reaction time)
  • Early-merge method inclination (may merge sooner than cars in front of him, %)
  • Willingness to let another car zip-merge (%)
  • Min/max range for distance to lane end at which agent ideally wants to merge
  • Min/max range for distance at which agent starts to slow-down if unable to merge
  • Speed slow-down ratio if agent is unable to merge
  • Min/max range for distance at which agent stops if unable to merge
  • Inclination to overtake slower drivers (%)
  • Min/max range for safe distance between cars required by an agent

Results

Because of the dependence on a wide variety of parameters, it is difficult to isolate the effects of individual factors and to conclude a definitive result from the simulations. One basic and primary indicator of performance of a setup is the exit throughput of cars (in other words the number of cars that successfully exit the simulation per unit of time). However, an important aspect to keep in mind is that given an average car exit speed and average distance between cars, there is only a limited car throughput we can achieve and unless we also consider other performance indicators, there is no point in trying to optimize beyond this value. Still, there are also other indicator values that would be important in real life, but for simplicity, they were not numerically measured in this simulation, such as evenly distributed throughput across the lanes (so some drivers do not wait in a traffic jam significantly longer than the others).

Merge distances, early merge

One of the most noticeable factors affecting the final throughput turned out to be the merging distances, i.e. the distance to lane-end at which an agent stars to merge (and eventually might stop to do so, obstructing the traffic behind him). This is quite easy mistake we may commonly see in the real-life: individual cars merging and slowing-down the traffic at different places lead to under-utilizing the final (right) lane, while on the other hand, the leftmost lanes may get completely hindered or start creating extensively prolonged waiting queues. The difference between this setup and setup where all cars merge at the same point at the end of the lane amounted up to 20% in our simulation case. Small remedy to this situation is if we enable an early merge (this means that the cars waiting in queue may take advantage of an opportunity to merge earlier than the cars waiting in the queue ahead of them).

Conclusion

Code