How to model pedestrians and cyclists interactions with out-of-the-box features of Vissim?

The growing importance of multimodal traffic simulations

As transport and urban planners around the world consider cycling as an important mode of transport in the urban mobility mix, there is also a growing interest in software tools to support the planning of cycling infrastructure. While macroscopic transport demand models are commonly used to estimate future travel demand and loadings on a network level, microscopic traffic simulation software packages are a widely used for traffic engineering, e.g. to evaluate the performance of different street and intersection designs or traffic signal plans. While those models originally have been developed to model motorised individual traffic and public transport, more recently researchers and practitioners started to adapt those model to also feature active transport modes.

Limits of current microsimulation tools

The current traffic microsimulation software packages such as PTV Vissim, Caliper Transmodeller, Sumo or TSS Aimsun offer great possibilities to model complex but realistic multi-modal traffic situations and some of them also offer remarkable 3d visualisation features to communicate different planning scenarios to a non-technical audience. However, when it comes to the representation of cycling and shared space situations, there are also quite a few limitations.

Heather Twaddle, a researcher at TU Munich an here colleagues recently reviewed existing approaches (Twaddle et al. 2014) for modelling cycling behaviour in traffic microsimulations. While some of the existing software packages allow to model cyclists using the same behaviour models as for motor vehicle traffic, simply adapting the parameters of the vehicle behaviour models to reflect the lower speeds of bicycles does not work for all conditions. Since there exist several unique characteristics that are difficult or impossible to represent with such models, researchers have investigated in adapting car following models, cellular automata and the social force model to better fit the behaviour of cyclist.

However, for our research project that investigates our street design impacts the propensity for cycling, we are also interested in the simulation of mixed traffic conditions on shared spaces or sidewalks that include both space for pedestrians and cyclists.

While simulating two traffic flows (whatever if pedestrians, bicycles or cars) crossing with a sufficient angle can be easily modelled by specifying a conflict area (Figure 1) or a priority rule, the correct representation of interactions lengthwise (with an angle equal to 0 or 180) is very challenging.

Figure 1: 3D view of an intersection between pedestrians and bicycles managed with conflict areas
Figure 1: 3D view of an intersection between pedestrians and bicycles managed with conflict areas

To explore what can already be achieved by adapting the behavioural parameters of Vissim’s standard simulation models, we have done some tests. The basis for all tested scenarios is the same: we want to simulate pedestrians and bicycles sharing a narrow path of about 3m width (about 5m for scenario 3). The number of pedestrians and cyclists is proportional to the lane width and therefore the density is the same in all scenarios.

Pedestrians as small vehicles

In Vissim, there exist the possibility to simulate a pedestrian as a car. The advantage is, that pedestrians are recognized by cars and therefore, interactions are automatically generated. Logically, pedestrians behave also like a vehicle. They follow and overtake each other along defined lanes, which of course is not very realistic.

Figure 2 shows an extreme case, where two links with one lane each are created. If no rules are applied, pedestrians would just walk in middle of the lane, making an overtaking for cyclists difficult. Thus, the driving behaviour should be adapted such as pedestrians prefer to walk on the left. As a result, the observable behaviour resembles to a highway, where slow cars are driving on the sides (pedestrians) and fast cars are overtaking in the middle (bicycles).

Figure 2: Extreme scenario 1 with two links and two lanes (3D perspective of a cyclist)
Figure 2: Extreme scenario 1 with two links and two lanes (3D perspective of a cyclist)

Of course we were not satisfied with this setting. In Scenario 2, we tried to improve the driving behaviours, creating 2 links with 2 lanes each and assigning pedestrians and bicycles randomly to a lane (Figure 3). In addition, a possibility to overtake on the opposite lane was implemented and the width of the lanes reduced to the minimum, just enough that pedestrians and bicycle do not touch each other while overtaking. However, as a result bicycles are jammed behind slower pedestrians very frequently.

Figure 3: Scenario 2 with two links and 4 lanes (3D perspective of a cyclist)
Figure 3: Scenario 2 with two links and 4 lanes (3D perspective of a cyclist)

In Scenario 3 with two links and 6 lanes (3D perspective of a cyclist), the number of lanes were augmented to 6 (3 for each direction) in order to allow more flexibility and, therefore, reduce jam (Figure 4). All in all, this setting creates the most realistic interaction between bicycles and pedestrians if pedestrians are simulated in the car-following model.

Figure 4: Scenario 3 with two links and 6 lanes (3D perspective of a cyclist)
Figure 4: Scenario 3 with two links and 6 lanes (3D perspective of a cyclist)

However, when modelling pedestrians as (tiny) vehicles, there always remains one issue: Because of the infrastructure constraints, the flows are segregated in two directions. This do not correspond to the reality, why we tried another approach.

Having said that, scenario 3 could also be simulated as two 2.5m cycle lanes with free overtaking. The problem in this case is that pedestrians behave very strange and conduct nervous overtaking actions.

Bicycles as big pedestrians

In order to avoid the very mechanical and automated behaviour of pedestrians, we were thinking about inverting the rules: let’s simulate the bicycles as pedestrians!

To this end, the work is done with PTV Viswalk, an add-on module of PTV Vissim. PTV Viswalk is mainly used for modelling railway stations, capacity planning, safety concepts or evacuation analysis and is based on the idea of the social force model.

For this scenario, we just adapted the behavioural parameters of those pedestrians that represent cyclists and used a bicycle 3D model for their visual representation. As Figure 5 shows, the pedestrians are walking more randomly on the assigned surface and there are no clear (directional) flows observable.

Figure 5: Scenario 4 with bicycles simulated as pedestrians (3D perspective of a cyclist)
Figure 5: Scenario 4 with bicycles simulated as pedestrians (3D perspective of a cyclist)

We adapted the behavioural parameters of pedestrians and bicycles as follows:

  • Tau: The greater this value, the lower is the acceleration strength and therefore, the time to reach the desired speed is increased. Tau should be lower for pedestrians than for cyclists.
  • React to n: It is important that the number of considered n is low for bicycles. This yields to a smoother trajectory of the cyclists.
  • VD: Increasing VD for pedestrians provoke a greater reject effect from the cyclists (and other pedestrians).
  • Noise: In order to avoid a deadlock between two cyclists, this value should be greater than the default value (1.2).
  • Grid size: Since we do not have to deal with surfaces, but with narrow on long paths, the grid size has only a moderate influence.

Even if the bidirectional flows are much more realistic than with the strategy ‘pedestrians as little cars’, the main issue with this approach remains the very late reaction of pedestrians or bicycles to other agents. In reality, especially cyclists would react much earlier if another cyclist is approaching in opposite direction. Instead, the reaction occurs very late, only few meters before the collision (Figure 6). Hence, the cyclists should have a main force influencing the pedestrians and other bicycles much further ahead.

Figure 6: Basic problem of scenario 4: late reaction of riding in the opposite direction
Figure 6: Basic problem of scenario 4: late reaction of riding in the opposite direction

An adaptation of the 3D Model of bicycles is also needed, because the legs of the cyclists are always moving at constant (fast) speed, even if they stop, making them look like a nervous insect.

Last but not least, the bicycles cannot be simulated anymore with car traffic (e. g. bicycle lane in parts on sidewalks and road). This restriction leads to problems, especially if you plan to simulate a whole network, where a cycle lane merges in a shared space.

We have also a youtube video resuming the main aspects of this article.

Alternative approaches

Since possibilities to simulate a proper interaction between pedestrians and bicycles on a narrow path in Vissim are limited, further research work is needed. One of the most promising approach is shown by a group of researcher s around Prof. Dr. Martin Fellendorf from the Graz University of Technology in Austria. They propose to extend the Social Force model to vehicles in order to model shared including all vehicle and pedestrian types. The so called Social Force based Vehicle Model was presented at the Transport Research Board Conference in 2012. The methodology, explained in this paper, features a multiple model architecture including an Infrastructure Model (shared spaces without spatial separation), Operational Model (Social Force Model with added vehicle dynamics) and Tactical Model (conflict detection and handling using game theory).

Liang, Mao & Xu proposed in 2012 the psychological-physical force model, an adaption of the social force model which represents the cyclists as ellipses and utilizes two regimes, free flow traffic and congested traffic, to model bicycle traffic. While the model generated realistic results for traffic flow on separated cycling lane, the model has not been tested for mixed traffic conditions.

Bani Anvari and her colleagues presented in 2015 the development of new three-layered mathematical model for heterogeneous agents (vehicles and pedestrians) in a shared space environment with single surface pavements, no lane discipline and identical priority for all road users.

Another, more straightforward approach to model shared spaces was proposed by traffic engineer Stuart Gibb in 2015. He only focussed on the interactions between pedestrians and cars. The innovative idea is to replace the cars with groups of closely-packed dummy pedestrians, so that the real pedestrians recognise the vehicles and walk around them instead of simply cross them. In order to recognise precisely where the vehicle stands and replace it with dummies, a fine-meshed grid must be created. In addition, priority rules, links, detectors, pedestrian areas and pedestrian routes have to be built. Kindly, he shared his code that directly implements this approach through Vissim’s COM interface in this report.

Implementing a new behavioural model as the magic bullet?

As already mentioned, a realistic simulation of pedestrians and bicycles interactions on narrow paths is challenging to reproduce using out-of-the-box Vissim, and probably in all other traffic microsimulation tools.

Our tests were of course quite basic as they only tested how Vissim can be configured to simulate mixed traffic conditions between pedestrians and cyclists without actually changing exsting behavioural models. But it became clear that the results or not very satisfying and that there is a need for implementing a new behavioural model to simulate traffic on paths that are shared among pedestrians and cyclists, but also shared space situations in general.

Therefore, we also join the race to develop models and code for simulating such situations. This will ultimately allow us to combine it with parametric 3D models and create interactive Virtual Reality scenarios of shared urban. We are looking forward to work on this quest, stay tuned!

New ways to count pedestrians

Experiences from a pedestrian counting experiment with Placemeter

As soon as a pedestrian or cycling planning project appears in the pipeline, you have to think about counting methods. Knowledge of flows and densities is essential for an intelligent and safe infrastructure design and before and after evaluations. The traditional method to perform such evaluation is to conduct manual counts: a labour intensive and therefore costly endeavour. Emerging technologies promise to cut down on counting cost. The folks at Alta Planning did a great job and published a White Paper which covers key emerging technologies in addition to the existing NCHRP 797 guidebook on pedestrian and bicycle volume data collection.

For our ongoing research project Engaging Active Mobility at the Future Cities Laboratory in Singapore, we are interested in testing the viability of some of those new technologies to count pedestrians and cyclists.  Four our first test, we used sensor products of Placemeter, a startup founded in 2012 in New York. Placemeter positions itself  as an ‘urban intelligence platform’, which ‘ingests any kind of video to analyse pedestrian and vehicular movement, revealing hidden patterns and strategic opportunities’, to help ‘build stronger businesses, efficient cities, and innovative neighbourhoods worldwide.’

Placemeter’s counting technology

Placemeter currently supports two types of counting devices: the Placemeter Sensor, which contains a camera and on-board processing unit, and an off-the-shelf IP camera (see Figure 1). In the case of the Placemeter Sensor, the video data is directly processed in the sensor, while the video stream of the IP camera is broadcasted to the Placemeter servers which run the algorithms that extract the count information. In both cases, the algorithms are able to identify counts by the direction of movement across used-defined measurement points. However, currently the Placemeter products do not allow to differentiate whether a pedestrian, cyclist and motorized vehicle crossed a measurement line.

fig_1
Figure 1: Placemeter Sensor (left) and IP camera (right)

Installation Set-up

We ordered both type of Placemeter Sensor products in October 2015 at the price of USD 90$ each. Delivery to Singapore was another 30$ each. While Placemeter promises that measuring with your very first sensor will be free forever, for any additional sensor they charge 100$ per measurement point and month, but allow you free counting during the first month.

The Placemeter Sensor arrived within a few days in beautifully custom-designed cardboard box while the IP camera by DLink got shipped in the standard wrapping.

The technical equipment is principally very easy to install. Nevertheless, some issues appeared when connecting the Placemeter Sensor to our WLAN. This step is necessary to connect the sensor to to Placemeter’s servers and to specify the measurement points through Placemeter’s web-based interface. We then tried to narrow down the problem by setting it up within other WLANs, but without success. Raising the issue to the helpful Placemeter customer care, they offered to replace the sensor at free cost and to cover any shipping expenses.

The setup with the replacement sensor was then straightforward and did not take more than 10 minutes. After connecting, the live stream of the sensor is displayed online and user-defined measurement points can be drawn as a line direct on the picture.

Besides access to WLAN, both the IP camera and Placemeter Sensor require electric power supply. The  enclosed power cable for the Placemeter Sensor is about 5m long, the standard cable delivered with the DLink IP camera is about 2m. While you obviously always can use a cord extension to extend your setup range, it also means that you need to have access to a power outlet near your count location.

First results

IP Camera

While the Placemeter Sensor was being replaced, we started to install our IP camera and decided to place it in front of our main meeting room, the ValueLab. Figure 2 shows the indoor setting and the three measurement points (screenlines) placed in order to count people coming from left and right and entering the meeting room. We can see that our office is brightly lit with artificial light, but also bright daylight as is typical for equatorial regions. However, the combination of the dark floor, white walls and bright windows plus some obstructing furniture create a situation that is characterised by high contrasts.

fig_2
Figure 2: Screen shot of the IP camera live stream and fixation on the ceiling

The ValueLab, also serves as a venue for public lectures. These lectures offer the perfect opportunity to conduct manual counting and compare the results with the counts produced by Placemeter. Figure 3 shows the number of people counted at the door (horizontal screenline) with the IP camera as well as the manual counts. In order to simplify the manual counting, we simply counted the number of people who attended a lecture. By multiplying this number by a factor of two, we obtain a minimum value of the number of people who traversed the measuring point at some point during the measurement period.
In other words, the real value of the manual counts should be higher, taking into consideration that some people would enter and exit the room few times (e. g. to take a phone call or so). Nevertheless, in almost all cases the manually counted ‘minimum value’ was higher than the amount of participants recorded by the IP camera.

Figure 3: Comparison of results from IP camera and manual counts

Another test was to compare the monthly data obtained from Placemeter for the IP camera. Since the ValueLab has a single entry point, we just compared the number of persons entering and leaving the room. During the period of 30 days, the IP camera counts in average 13% more people entering than leaving the room. We think this is because the arrival process is different from the departure process. People trickle in before a lecture, and rush out simultaneously to grab a coffee, challenging the Placemeter counting logarithms.
We also suppose that the IP camera has problems to count pedestrian just before or after a door, since in this case the camera angle is reduced and only one side is visible.

Placemeter Sensor

Not being truly convinced by the counting performance using the IP camera, we also tested the newly arrived replacement Placemeter Sensor in this challenging indoor setting. However, results showed similarly inconsistent patterns. Apparently, the the high contrast setting is beyond the operational limits of Placemeter’s video processing count algorithms.
Disappointed to not being able to automatically count the popularity of our main meeting room, but not disheartened with the potential of the technology altogether, we set out to give the Placemeter Sensor a second chance in a more conducive environment. The setting for the second experiment is the entrance to one of the CREATE buildings. The video frame is characterised by a rather homogenous contrast as shown in Figure 4.

Figure 4: Screen shot of the Placemeter Sensor live stream and list of measurement points

The measurement points (which actually are lines) were drawn to form a measurement square which means that people entering the square should exit it again within a few seconds. This allow us to do a quick accuracy test of the Placemeter Sensor.
Figure 5 shows an overview of the manual count results and the data delivered by the Placemeter Sensor. Different to the outcome of the first experiment, the manual counts are exact (no minimum values). Manual counting was performed for the duration of one hour at three different days. Except for the measurement points ‘Door_Create_In’ and ‘Door_Create_Out’ the results match pretty well with the Placemeter Sensor outputs.
In general, the results from the horizontal measurement points are less accurate then the data from vertical ones. Thus, we suppose that the video processing algorithms can recognise pedestrians better on vertical measurement points, not least because of a favourable angle between pedestrian flow and measurement point.

Figure 5: Results of manual and automated counts on an outdoor setting
Figure 5: Results of manual and automated counts on an outdoor setting

Similar to the IP camera, we made also in this case a second sanity check by comparing the number of people entering and leaving the area between the four measurement lines; over a period of two weeks, the Placemeter Sensor counted in average 10% more people entering this area than leaving this area. Apparently, we have some sort of Bermuda square here 😉 !

Conclusion

In general, with both Placemeter Sensor and IP camera, the detected pedestrian count is lower than the actual count. With our small sample, we made the following observations:

  • Both the IP camera and Placemeter Sensor seem to have problems to deal with groups of persons.
  • Especially in the cases where people are walking through a door, the sensors seem to be less accurate than manual counting.
  • The accuracy of vertical screenlines is better than horizontal measurements screenlines.
  • Likewise, both sensors have problems in indoor settings consisting of furniture, high colour contrasts and changing lighting conditions.

Even though we see a demonstrable utility in the conceptual idea of Placemeter, we learned that the field of application of Placemeter Sensors seems to be limited by the visual setting and the requirement of having access to a power outlet and a WLAN. For peak hour pedestrian flows and public transport measurements, a shorter time interval might be necessary. However, if the situation where you want to count fulfils those criteria, you should definitely consider Placemeter’s products for your counting project as the setup is straightforward and data can be easily collected for long periods of time at marginal additional cost.