Simulation/Pedestrians

generated on 2014-06-12 00:24:11.124788 from the wiki page for Simulation/Pedestrians for SUMO 0.21.0

Contents

Pedestrian Simulation

This page describes simulations of pedestrians in SUMO. To build an intermodal simulation scenario with propper interactions between road vehicles and pedestrians, additional steps have to be take in comparisson to a plain vehicular simulation.

Building a network for pedestrian simulation

When walking along an edge, pedestrians use sidewalks where available. A sidewalks is a lane which allows only the sumo vClass pedestrian. When crossing a road at an intersection, pedestrians use special lanes of type crossing. The area that connects sidewalks with crossings is modeled by special lanes of the type walkingarea. In the following, we describe how to build a simulation network that contains sidewalks, crossings and walkingareas.

Generating a network with sidewalks

Sidewalks may be defined explicitly in plain XML input when describing edges (plain.edg.xml). This is done by defining an additional lane which only permits the vClass “pedestrian” and setting the appropriate width.

When importing edges with defined types, it is also possible to declare that certain types should receive a sidewalk. This can be used to automatically generate sidewalks for residential streets while omitting them for motorways when importing OSM data. An examplary typefile can be found in <SUMO_HOME>/data/typemap/osmNetconverPedestrians.typ.xml.

<types>
   <type id="highway.motorway" numLanes="3" speed="44.44" priority="13" oneway="true" disallow="pedestrian bicycle"/>
   <type id="highway.unclassified"   numLanes="1" speed="13.89" priority="5" sidewalkWidth="2" disallow="pedestrian"/>
   <type id="highway.residential"    numLanes="1" speed="13.89" priority="4" sidewalkWidth="2" disallow="pedestrian"/>
   <type id="highway.living_street"  numLanes="1" speed="2.78"  priority="3"/>
   <type id="highway.service"        numLanes="1" speed="5.56"  priority="2" allow="delivery pedestrian"/>
   ...
</types>


A third option which can be used if no edge types are available is a heuristic based on edge speed. This is activated by using the following options:

Option Description
--sidewalks.guess <BOOL> Guess pedestrian sidewalks based on edge speed
--sidewalks.guess.max-speed <FLOAT> Add sidewalks for edges with a speed equal or below the given limit
--sidewalks.guess.mim-speed <FLOAT> Add sidewalks for edges with a speed above the given limit

Generating a network with crossings

Crossings may be defined explicitly in plain XML input when describing connections (plain.con.xml) using the new XML element crossings.

The second available method adding crossing information to a network is with the option --crossings.guess <BOOL>. This enables a heuristic which adds crossings wherever sidewalks with similar angle are separated by lanes which forbid pedestrians. If the edges to be crossed have sufficient distance between them or vary a by a sufficient angle, two crossings with an intermediate walking area are generated. To use this option sidewalks should be defined for the network.

Note:
To ensure proper generation of crossings, road lanes need to prohibit pedestrians either by setting disallow="pedestrian" or by explicitly specifying all other allowed classes using attribute allow

Generating pedestrian demand

Pedestrian demand may be specified explicitly as described at Specification/Persons#Walks or it may be generated. The tool Tools/Trip#randomTrips.py supports generating random pedestrian demand using the option --pedestrians. The option --max-dist <FLOAT> may be used to limit the maximum air distance of pedestrian walks.

Pedestrian Models

The pedestrian model to use can be selected by using the new simulation option --pedestrian.model <STRING> with the available paramters being nonInteracting and striping (default is striping). The interface between the pedestrian model and the rest of the simulation was designed with the aim of having a high degree of freedom when implementing new models. It is planned to implement models with a higher level of interaction detail in the future.

Model nonInteraction

This is a very basic walking model. Pedestrians walk bidirectionally along normal edges and “jump” across intersections. They maybe either be configured to complete a walk in a fixed amount of time or to move along the edges with a fixed speed. No interaction between pedestrians and vehicles or other pedestrians takes place. This model has a very high execution speed and may be useful if the pedestrian dynamics are not important.

Model striping

This model assigns 2D-coordinates within a lane (of type sidewalk, walkingarea or crossing) to each pedestrian. These coordinates which are defined relative to the leftmost side of the start of the lane are updated in every simulation step. This is in contrast to the coordinates of vehicles, which (generally) only have 1D-coordinates within their respective lane. Pedestrians advance along a lane towards the next node which may either correspond to the natural direction of the lane (forward movement) or it may opposite to the natural direction (backward movement). Thus, the x coordinate monotonically increase or decreases while on a lane. Once the end of a lane has been reached, the pedestrian is placed on the next lane (which may either be unique or determined dynamically with a routing algorithm).

The most important feature of pedestrian interactions is collision avoidance. To achieve this, the “striping”-model divides the lateral width of a lane into discrete stripes of fixed width. This width is user configurable using the option --pedestrian.striping.stripe-width <FLOAT> and defaults to 0.65 m. These stripes are similar to lanes of a multi-lane road are used by vehicles. Collision avoidance is thus reduced to maintaining sufficient distance within the same lane. Whenever a pedestrian comes too close to another pedestrian within the same stripe it moves in the y-direction (laterally) as well as in the x-direction to change to a different stripe. The y-coordinate changes continuously which leads to situations in which a pedestrian temporarily occupies two stripes and thus needs to ensure sufficient distances in both. The algorithm for selecting the preferred stripe is based on the direction of movement (preferring evasion to the right for oncoming pedestrians) and the expected distance the pedestrian will be able to walk in that stripe without a collision. During every simulation step, each pedestrian advances as fast as possible while still avoiding collisions. The updates happen in a single pass for each walking direction with the pedestrian in the front being updated first and then its followers sorted by their x-coordinate. The speed in the x-direction may be reduced by a random amount with the maximum amount defined as a fraction of the maximum speed, using the global option --pedestrian.striping.dawdling <FLOAT> (defaulting to 0.2). As a consequence of the above movement rules, pedestrians tend to walk side by side on sidewalks of sufficient width. They wait in front of crossings in a wide queue and they form a jam if the inflow into a lane is larger than its outflow.

Interaction between pedestrians and other modes

A pedestrian wishing to cross the street at an uncontrolled intersection can only do so if its expected time slot for using the intersection does not interfere with that of an approaching vehicle. It should be noted that the dynamics at unprioritized crossings are conservative in estimating the time required gap. In the simulation, pedestrians will only use such a crossing if the whole length of the crossing is free of vehicles for the whole time needed to cross. At priority crossings, pedestrians cross without regard for vehicles.

Vehicles are prevented from driving across a pedestrian crossing which is occupied by pedestrians. If a pedestrian is found which is not yet past the intersection point (between the crossing and the vehicles trajectory) but within a threshold distance to that point (currently hardcoded as 10m) the crossing is considered to be blocked.

Note:
Using the model 'nonInteracting', no interactions between pedestians and other modes take place.

This page was last modified on 14 May 2014, at 08:25.