Difference between revisions of "Simulation/Why Vehicles are teleporting"

From Sumo
Jump to navigation Jump to search
(updated teleport description)
Line 7: Line 7:
 
* the vehicle stood too long in front of an intersection (message: "''...'; waited too long, lane='...''")
 
* the vehicle stood too long in front of an intersection (message: "''...'; waited too long, lane='...''")
 
* the vehicle has collided with his leader (message: "''...'; collision, lane='...''")
 
* the vehicle has collided with his leader (message: "''...'; collision, lane='...''")
* the vehicle has not left the lane but the one behind did (message: "''...'; false leaving order, lane='...''")
 
* the vehicle landed beyond it's lane length (message: "''...'; beyond lane (X), lane='...''")
 
  
 
==Waiting too long, aka Grid-locks==
 
==Waiting too long, aka Grid-locks==
Grid-locks, jamming a simulated scenario are unfortunately something normal to traffic simulations. You can solve this only by assigning different routes. Some further approaches may be invoked in the future to make them occure more seldom.
+
In the case a vehicle is standing at the first position in front of an intersection, SUMO counts the number of steps the vehicle's velocity stays below 0.1m/s. These steps are the "waiting time". In the case the vehicle moves with a larger speed, this counter is reset. In the case the vehicle waited longer than a certain threshold value (default 300 seconds), the vehicle is assumed to be in grid-lock and teleported onto the next free edge on its route. The threshold value can be configure using the option {{Option|--time-to-teleport {{DT_INT}}}} which sets the time in seconds. If the value is not positive, teleporting due to grid-lock is disabled.
 +
Note that for vehicles which have a stop as part of their route, the time spent stopping is not counted towards their waiting time.
 +
 
 +
There are different reasons why a vehicle cannot continue with its route. Every time a vehicle teleports due to grid-lock one of the following reasons is given:
 +
* '''wrong lane''': The vehicle is stuck on a lane which has no connection to the next edge on its route.
 +
* '''yield''' The vehicle is stuck on a low-priority road and did not find a gap in the prioritized traffic
 +
* '''jam''' The vehicle is stuck on a priority road and there is no space on the next edge.
 +
 
 +
Unfortunately, grid-locks are rather common in congested simulation scenarios. You can solve this only by improving traffic flow, either by correcting junction priorities, traffic light timings or the traffic demand (route files).
  
In the case a vehicle is standing at the first position in front of an intersection, SUMO counts the number of steps the vehicle's velocity stays below 0.1m/s. These steps are the "waiting time". In the case the vehicle moves with a larger speed, this counter is resetted. In the case the vehicle waited longer than a certain swell, the vehicle is teleported, assuming a grid-lock occuren on the intersection.
 
  
The swell can be modified using a command line option. The option is {{Option|--time-to-teleport {{DT_INT}}}}. In the case a value lower than 0 is given, no teleportation is done, otherwise the given value will be interpreted as seconds to wait before teleporting a vehicle.
 
  
 
Also, besides plain grid-locks, the imperfection of the lane-change model sometimes yields in a situation where two vehicles try to get to the other lane, and each vehicle is blocking the other one. The simulation behaves as described in prior. An additional possibility to "solve" this is to allow vehicles to be swapped - they are exchanged. To enable this possibility, use the option {{Option|--lanechange.allow-swap}}.
 
Also, besides plain grid-locks, the imperfection of the lane-change model sometimes yields in a situation where two vehicles try to get to the other lane, and each vehicle is blocking the other one. The simulation behaves as described in prior. An additional possibility to "solve" this is to allow vehicles to be swapped - they are exchanged. To enable this possibility, use the option {{Option|--lanechange.allow-swap}}.
Line 24: Line 28:
  
  
==False Leaving Order==
+
=What is happening while a vehicle teleports=
A vehicle has driven over his leader and wants to get to the next lane, though his leader has not yet left his one.
 
{{Note|Leaving the lane in a false order is assumed to occur due to bugs in the simulation. Please report if you encounter one.}}
 
 
 
 
 
==Landing beyond the Lane's End==
 
This can only occur if a vehicle's right-of-way has changed from what the vehicle assumed. An example: the vehicle though it could pass a junction, but a second vehicle (surprisingly) disallows it from passing the junction. In order not to brake with a value larger than the vehicle's deceleration ability, the vehicle continues his ride, but is not able to enter the next lane - in some cases this yields in a position beyond the lane's end.
 
{{Note|Landing beyond the Lane's End is assumed to occur due to bugs in the simulation. Please report if you encounter one.}}
 
 
 
 
 
 
 
=What's happening=
 
 
A teleported vehicle is removed from the network. It is then moved along its route, but no longer being on the street. It is reinserted into the network as soon as this becomes possible. While being teleported, the vehicle is moved along its route with the average speed of the edge it was removed from or - later - it is currently "passing". The vehicle is reinserted into the network if there is enough place to be placed on a lane which allows to continue its drive.
 
A teleported vehicle is removed from the network. It is then moved along its route, but no longer being on the street. It is reinserted into the network as soon as this becomes possible. While being teleported, the vehicle is moved along its route with the average speed of the edge it was removed from or - later - it is currently "passing". The vehicle is reinserted into the network if there is enough place to be placed on a lane which allows to continue its drive.
  
 
{{Note|Please note that up to version 0.12, the teleporting speed was higher and that vehicles were reinserted into the network if there was free place on any of the lanes of the edge the vehicle was "above".}}
 
{{Note|Please note that up to version 0.12, the teleporting speed was higher and that vehicles were reinserted into the network if there was free place on any of the lanes of the edge the vehicle was "above".}}

Revision as of 09:27, 5 December 2013

When running a simulation, one may encounter the following warning:

Warning: Teleporting vehicle '...'; waited too long, lane='...', time=....

What does it mean?

Reasons

The following circumstances may force the simulation to "teleport" a vehicle:

  • the vehicle stood too long in front of an intersection (message: "...'; waited too long, lane='...")
  • the vehicle has collided with his leader (message: "...'; collision, lane='...")

Waiting too long, aka Grid-locks

In the case a vehicle is standing at the first position in front of an intersection, SUMO counts the number of steps the vehicle's velocity stays below 0.1m/s. These steps are the "waiting time". In the case the vehicle moves with a larger speed, this counter is reset. In the case the vehicle waited longer than a certain threshold value (default 300 seconds), the vehicle is assumed to be in grid-lock and teleported onto the next free edge on its route. The threshold value can be configure using the option --time-to-teleport <INT> which sets the time in seconds. If the value is not positive, teleporting due to grid-lock is disabled. Note that for vehicles which have a stop as part of their route, the time spent stopping is not counted towards their waiting time.

There are different reasons why a vehicle cannot continue with its route. Every time a vehicle teleports due to grid-lock one of the following reasons is given:

  • wrong lane: The vehicle is stuck on a lane which has no connection to the next edge on its route.
  • yield The vehicle is stuck on a low-priority road and did not find a gap in the prioritized traffic
  • jam The vehicle is stuck on a priority road and there is no space on the next edge.

Unfortunately, grid-locks are rather common in congested simulation scenarios. You can solve this only by improving traffic flow, either by correcting junction priorities, traffic light timings or the traffic demand (route files).


Also, besides plain grid-locks, the imperfection of the lane-change model sometimes yields in a situation where two vehicles try to get to the other lane, and each vehicle is blocking the other one. The simulation behaves as described in prior. An additional possibility to "solve" this is to allow vehicles to be swapped - they are exchanged. To enable this possibility, use the option --lanechange.allow-swap.

Collisions

Though SUMO uses a collision-free model, collisions have beed detected. As they yield in an undefined state of the simulation, a vehicle teleportation is performed for solving them.

Note:
Collisions are assumed to occur due to bugs in the simulation. Please report if you encounter one.


What is happening while a vehicle teleports

A teleported vehicle is removed from the network. It is then moved along its route, but no longer being on the street. It is reinserted into the network as soon as this becomes possible. While being teleported, the vehicle is moved along its route with the average speed of the edge it was removed from or - later - it is currently "passing". The vehicle is reinserted into the network if there is enough place to be placed on a lane which allows to continue its drive.

Note:
Please note that up to version 0.12, the teleporting speed was higher and that vehicles were reinserted into the network if there was free place on any of the lanes of the edge the vehicle was "above".