Our daily commute to work by bicycle has more than doubled in duration since our move. Instead of 20 minutes, we now spend 40 – 50 minutes riding our bikes to and from work. My wife is considering investing in an electric bicycle. Not only will it require less physical effort, but it can possibly also reduce the travel time. But does it really? We noticed that often our fellow commuters that use electric bikes are just faster to the next signal, but have to wait at the red light longer and in the meantime allow us to catch up. There seems to be very little time gain on the total journey. I wanted to know how real this effect is and if there is indeed still any potential for time savings even in urban areas, where traffic lights are abundant.

To find out, I have created a simple model that simulates a one-way bike journey for a given distance with the route divided into several legs, with each leg terminated by a traffic light. Because we don’t really know the exact distances between the traffic lights, I randomly distribute them along the route. Each traffic light runs on a preset cycle (red, green, yellow) with preset times for each phase. Every traffic light starts at a random phase in its cycle, because usually traffic lights are not synchronized along a random journey (there are systems such as the Green Wave that do synchronize lights over several intersections, but those are far from common, especially for cyclists). For simplicity, I have used the same cycle time for all traffic lights, but in practice this may vary from intersection to intersection as well.

## Modelling the bicycle and cyclist

To model the journey of a bicycle and its rider, we need to calculate its position along the route for every instance based on its momentary acceleration and velocity. For this we simply march through time step by step, and consider that its new position is equal to its previous position plus the distance we have travelled in the intermediate time:

$$s_{i} = s_{i-1} + v_i \Delta t.$$

In a similar way, the new velocity is equal to the previous velocity plus the velocity we have gained (or lost) in the intermediate time:

$$v_i = v_{i-1} + a_i \Delta t.$$

To determine the acceleration, we could model the bicycle and the rider and consider the balance of forces. Instead, I chose to simply use available data and hand wave the numbers as close enough approximations.

According to CROW (referenced by Parkin and Rotheram [11]), normal cyclists accelerate at a rate of 0.8 m/s2 to 1.2 m/s2 (I just use the average of 1.0 m/s2 in this model) and decelerate at a rate of 1.5 m/s2 comfortably to 2.6 m/s2 in case of an emergency. For cyclists on pedelecs, I couldn’t find any realistic data that was not behind a paywall. I therefore based my estimation on an old conference paper on the use of electric bikes on the latvian countryside [12]. For the acceleration, the range is 0.6 m/s2 for underpowered, relatively heavy pedelecs to 1.6 m/s2 for the more powerful variants. For the decelerations, I have assumed that they are identical to those of regular cyclists as the brake systems do not vary that much from regular bikes (although it is likely they tend to be on the beefier end of things).

To determine the top speed a rider reaches on its bike, we look at the available and the required power.

Let’s first consider the available power. According to Abbott and Wilson [2], the amount of power a healthy individual can sustain depends on the duration of the activity. Because we are mainly interested in our daily commute of 40 – 50 minutes, I have used the power that can be delivered comfortably for about an hour: approximately 100 W. This matches also what the Fietsersbond [3] uses in their estimations. For a pedelec we use the legal limit of 250 W.

For the required power, we need to consider several forces that need to be overcome. The biggest contributors (and the only ones I consider in this simulation) are the counteracting forces of rolling friction, air friction and gravity. When the wheels roll over the road, the friction between the rubber of the wheel and the road surface counteracts our forward motion. This force is proportional to a friction constant (cr) and to the total mass of bike and rider. Because we are interested in power, we have to consider the amount of force required over a given distance per unit of time (in other words: we multiply the force by the velocity):

$$P_{rolling} = c_r m g v.$$

The friction coefficient depends on the road type and the tyre type. Edwin Haas of Fiets.nl lists several values [5]. Based on these values, I have estimated that for normal road tyres for city bikes and pedelecs to be approximately 0.010.

For the air friction, we can have a look at aerodynamics/fluid dynamics and use the drag equation, which we again multiply with the velocity to get the required power:

$$P_{air} = \frac{1}{2} \rho C_d A_p \left(v_w + v\right)^2 v,$$

in which rho is the air density (1.225 kg/m3), Cd is the drag coefficient, Ap is the projected frontal area, vw is the wind speed and v is the speed of the rider on its bike. The drag coefficient is difficult to model with a simple simulation like this, and is even difficult to model accurately with complicated fluid dynamics simulations. We therefore rely on experimental research [10] to say that for an upright position of a rider on its bicycle, we can use

$$C_d A_p \approx 0.28$$

The wind speed varies constantly short-term (weather), medium long term (season) and long-term (climate) time scales and varies also with location. To get any reasonable number for the encountered wind speed, we have to consider the mean direction of our route and the locale. Therefore, I used historic data from the KNMI (Dutch Royal Metrological Institute) [9] to come up with a reasonable figure.

When riding up an incline, gravity pulls down on us. The required power to overcome this is a function of the total mass of rider and bicycle and the inclination angle (theta):

$$P_{inclination} = vmg\sin\theta.$$

The sum of the required powers balance with the available power and result in the maximum velocity we can attain. A pedelec has to stop assisting the rider at a speed of 25 km/h according to dutch law. Being law abiding citizens, I have capped the pedelec speed at that value (in my search for data, I read somewhere that over 40% of dutch pedelecs have been modified to remove this restriction).

As you may note, the total mass of the rider and its bike is required for some of these components. For the rider, we can use statistical data made available by the CBS (Statistics Netherlands) [1] to find that in 2016, the average mass of a dutch male was 84.5 kg and for an average dutch female was 71.3 kg. For the bicycles, we use some reference numbers published by bicycle manufacturer Union to find that a city bike has a mass of approximately 18 kg, and a pedelec of roughly 26 kg.

For the motion profiles, I have used the following behaviors: accelerate at constant acceleration to the maximum velocity, cruise at maximum velocity (there is no holding us back!) and then decelerate at a constant rate again. This is more than accurate enough for the purposes of this simulation, although maintaining maximum velocity is a somewhat moot assumption when compared to real traffic of course.

## Modelling the traffic lights (signalized intersections)

Along a route there are many obstacles that influence your velocity, e.g. other traffic, road works and intersections. Most of these are too complex to integrate into a simple model like this. One that can have a significant contribution to the travel time, however, are signaled intersections. They force you to a complete halt, and typically have you waiting for quite a while. Especially in urban areas, where signalized intersections are abound, all those brief (or long) interruptions can add up to a significant fraction of the travel time.

In the Netherlands, signalized intersections have a maximum waiting time of 2 minutes [6]. They come in various flavors, ranging from rigidly timed to complex adaptive systems that take into account traffic flow and can prioritize certain lanes. The rigidly timed versions, run on a fixed cycle in which all directions of the intersections are cycled. The Ministry of Infrastructure classifies three quality grades of signalized intersections for cycling traffic in terms of their average maximum waiting time [6]:

Depending on the importance and total volume of traffic on the intersection, the designer of the intersection chooses the required quality level. Because the same source lists a cycle time of 90 s for signalized interections for mixed traffic including slow traffic (such as cyclists), I have used a cycle time of 90 s.

Each cycle has three phases for each direction: the red phase (stop), the green phase (go), and the yellow/orange phase (stop if you reasonably can, go if no longer can). Based on several sources, I have settled on a green phase of 8 s [6, 7], a yellow phase of 3 s [8] and a red phase of 79 [s]–a Normal grade signalized intersection.

Along a random route, signals between two different intersections are not synchronized. There are of course exceptions to this rule, such as the Green Wave (starting at a green signal, you will continue having green signals for the entire Green Wave Route as long as your average speed is within certain bounds), but it is unlikely a route will consist of only Green Waves. I therefore model each signalized intersection as one of a rigid cycle, but start the cycle at a random phase. A cycle is divided into three phases: the first 79 s of a phase is the red phase, from 79 s to 87 s is the green phase and from 87 s to 90 s is the yellow phase. A signalized intersection can start for example at 82 s into its cycle, so that it starts of green. As time marches on in the simulation, each signalized intersection is updated and compared against its new point in its own cycle. A cyclist can approach a signalized intersection that is already partway one of its phases and have a reduced waiting time, or run into a light that is about to switch phases.

With this model, signalized intersections can be modelled realistically enough or the purposes of this simulation.

## Cyclist behavior when approaching an intersection

When a simulated cyclist approaches a signalized intersection, it is confronted with a decision: keep going, stop or ignore the traffic light. The programmed behavior is:

• If the distance to the traffic light is larger than our comfortable breaking distance (based on our maximum speed and a comfortable deceleration rate), keep cruising or accelerating no matter the phase of the signal.
• When we are within the comfortable breaking distance:
• if the signal is green, keep cruising or accelerating;
• if the signal is orange, start braking;
• if the signal is red, start braking.
• When braking is initiated, the required deceleration rate is calculated. If the deceleration rate is larger than the emergency rate (i.e. we have to brake harder then we can), we ignore the traffic light and keep accelerating or cruising.

## Partitioning in objects

The code is built object-oriented around two main classes: Bicycle (which contains the logic for the bicycles) and the Trail class. The Trail class keeps track of the state of all SignaledIntersection. Each SignaledIntersection object takes care of the behavior of a single traffic light.

## Simulating a single journey

My wife’s one-way commute is a bikeride of 11 km with 16 signalized intersections (17 legs in total). With the rider mass adjusted for her, the following results follow from a simulation for a single journey with no wind and no inclination.

As you can see, the city bike and pedelec go head to head for most of the journey. They both have to stop at the same intersections. The pedelec just reaches the red light faster. In the end, the pedelec reaches the destination sooner, because of its speed advantage in the final stretch.

This is a typical result in case there is no wind. In plenty of cases, the pedelec and the city bike both stop at the same intersection for many intersections in a row. This also matches our own experiences on our commutes so far.

The next results show the same simulations, but now with a 10 km/h head wind included. We see that the head wind reduces the maximum speed of the city bike, but does not affect the pedelec due to its larger amount of available power to support the rider. There is no drop in the maximum speed in moderate wind speeds. In such a scenario, the pedelec has a significant advantage in term of time to destination.

## Monte Carlo simulation

The results above are merely examples of possible outcomes of the simulation. The randomness of the signalized intersections throws in quite a bit of variance in the results. To get better grips on the results, we can repeat the simulation several times and have a look at the average time reduction. I repeated the simulations shown above each a 100 times.

The first preliminary conclusions discussed above turn out to be true. The pedelec is only marginally faster on this route, and most of the time the pedelec is just quicker at the next red signal.

When we add a head wind of 10 km, however, the results no longer overlap and the pedelec is always faster.

The results don’t lie. In terms of time reduction a pedelec has an edge over a conventional city bike, at least in windy conditions.

## Conclusions

A fairly simple model like the one described in this post can give interesting insights in the advantages of choosing a pedelec over a regular city bike. With the influence of wind and inclination included, the maximum speed of a cyclist on a city bike will drop, while that on the pedelec can maintain it for broader band of parameters.

For our specific case, the potential time saving is large enough to consider a pedelec, but we’ll have to discuss if it is worth the money and also consider other elements of such a purchase, such as for example disposables such as the battery (you need to replace them after a few hundred charging cycles), the placement of the motor and the control behavior of the bicycle on the riding experience.

## Source code

Want to play with these simulations for yourself? You can download the source code here.

Copyright 2022 R.J.F. Bijster

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

## References

[1] Centraal Bureau voor Statistiek, “Lengte en gewicht van personen, ondergewicht en overgewicht; vanaf 1981”, URL: https://opendata.cbs.nl/statline/#/CBS/nl/dataset/81565NED/table?dl=8566, Accessed: 17 June 2022

[2] Abbott & Wilson, “Human Powered Vehicles”, Human Kinetics (1995), Accessed via the Princeton University Website, URL: https://www.princeton.edu/~maelabs/hpt/pro/human_3.htm, Accessed: 17 June 2022

[3] Fietsersbond, “Snelheid 5 verschillende type fietsen vergeleken”, URL: https://www.fietsersbond.nl/snelheid-5-verschillende-type-fietsen-vergeleken/, Accessed: 17 June 2022

[4] Union, “Wat weegt een fiets?”, URL: https://www.union.nl/blog/gewicht-fiets, Accessed: 17 June 2022

[5] Edwin Haas, “De invloed van rolweerstand”, 19 October 2015, URL: https://www.fiets.nl/uitgelicht/de-invloed-van-rolweerstand/, Accessed: 17 June 2022

[6] Ministerie van Infrastructuur en Milieu, Groene Golf Team, “Basis voor een Nota Verkeerslichten – Handvatten voor wegbeheerders om hun verkeerslichtenbeleid vorm te geven”, 26 March 2014, URL: https://www.crow.nl/downloads/pdf/verkeer-en-vervoer/verkeersmanagement/basis-voor-een-nota-verkeerslichten-versie-1-2_tcm.aspx?ext=.pdf, Accessed: 17 June 2022

[7] Wegenwiki, “Groenfase”, URL: https://www.wegenwiki.nl/Groenfase, Accessed: 17 June 2022

[8] Verkeerskunde, “Betere geeltijden (VK 2/2016)”, 25 March 2016, URL: https://www.verkeerskunde.nl/artikel/betere-geeltijden-vk-2-2016, Accessed: 17 June 2022

[9] KNMI, “Klimaatviewer – Gemiddelde windsnelheid, Periode 1991 – 2020”, URL: https://www.knmi.nl/klimaat-viewer/kaarten/wind/gemiddelde-windsnelheid/jaar/Periode_1991-2020, Accessed: 17 June 2022

[10] P. Debraux, F. Grappe, A.V. Manolova, W. Bertucci, “Aerodynamic drag in cycling: Methods of assessment”, Sports Biomechanics, 10:3, 197-218, DOI: 10.1080/14763141.2011.592209

[11] J. Parkin and J. Rotheram, “Design speeds and acceleration characteristics of bicycle traffic for use in planning, design and appraisal”, Transport Policy, 17:5, 335-341 (2010), DOI: 10.1016/j.tranpol.2010.03.001

[12] I. Dukulis, D. Berjoza and Z. Jesko, “Investigation of electric bicycle acceleration characteristics”, Engineering for Rural Development, Jelgava, 23-24 May 2013