PRE2016 3 Groep11: Difference between revisions
No edit summary |
|||
(194 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
= Introduction = | |||
[[File:RingVEindhoven.jpg | thumb | The ring of Eindhoven | 400 px]] | |||
Every day a lot of people are waiting before a traffic light some point in their drive. This can causes frustration for the drivers, and more pollution for the environment. After all, driving the same speed continuously is a lot less intensive than stopping and then go again. So, it would be quite optimal if these drivers can continue driving past these traffic lights. Obviously, this is not possible for all traffic lights in the world, however, there are quite some traffic trajects where this could certainly be improved. A continuously connected traffic road, for instance a ring around a city, is a good example. For this reason the project took as basis to improve the ring around Eindhoven, a city in the Netherlands. | |||
One of the methods to improve traffic flow is through the use of green waving. Here cars can continuously get a serie of green lights when they drive at an appropriate speed. For this project it was decided to try to implement green waving in a ring system. This was modelled through the use of the program Netlogo, where eventually a ring of twelve crossings was achieved. The algorithm of the individual traffic lights were based on a previous group’s work in order to eventually create an even better system. In order to register the presence of a car in front of a light the efficiency difference between chips in the cars themselves and sensors directly build into the traffic system itself was researched during the literature studies. To connect as it were all the traffic lights into one overreaching system for the green waving effect, a periodic time interval reminiscent of a clock was introduced. This can trigger the start of a green wave on the ring. From the results it could be concluded that the new system was indeed better on some improvement points in comparison to the reference traffic system. | |||
=Authors= | =Authors= | ||
Line 18: | Line 15: | ||
*0945501 Lars Verstraelen | *0945501 Lars Verstraelen | ||
= | =Objectives, Focus and Approach= | ||
==Objectives== | |||
The goal of this project is to ultimately improve the traffic system which consists of several crossings by trying to add functionality to the individual traffic lights crossings to smartly create and use green waves. The new system tries to use this through the use of a time based order, similar to the path of a clock hand. In order to make sure that the new system compared to the old system is indeed better, it gets compared on five different variables: | |||
*The average time it takes for an individual to drive to its destination | |||
*How often a car has to stop during their trip | |||
*How long a car has to stop when stopped | |||
*How long a car has to stop on average for all cars | |||
*The throughput of the system: How many cars pass the system within a set amount of time | |||
These variables should lead to be able to answer the main question: Is the new system an improvement over the old traffic system? | |||
Additionally, to answer this particular question, it has been divided into different sub-questions, which will ultimately lead to the conclusion to the final main question. The following sub-questions has been deemed interesting to | |||
answer: | |||
*How does the old system work? | |||
**How does the system take its different users into account? | |||
*How does the old system work for more intersections? | |||
*What exactly is a green wave? | |||
**What exactly is the purpose of creating a green wave? | |||
*What sensors are needed for this to work in the traffic system? | |||
==Focus== | ==Focus== | ||
===Requirements=== | |||
*The traffic system is a ring | |||
*2-lane road, with near traffic lights left and right turn lanes | |||
*Sensors in road around traffic lights to detect cars | |||
**Speed and location of the cars can measured | |||
===Preferences=== | |||
*Using green waving as much as possible | |||
*The simulation needs to be as realistic as possible | |||
*The spawning of the cars in the simulation needs to represent by realistic distribution | |||
===Constraints=== | |||
*Cars cannot wait too long | |||
*Emergency vehicles will not be simulated | |||
*Each traffic light needs to make an estimation to determine the next traffic light state. This can be done with the Cost function of the previous group or an upgraded version of this. | |||
===Assumptions=== | |||
*Cars do not drive through red | |||
*All vehicles will stay below speed limitations | |||
==Approach== | |||
The project needed to be divided into several milestones: | |||
*The old traffic system that was to be used as baseline needed to compare the new traffic system to needs to be extended to include more than one intersection. | |||
*A first simple system using the new ‘clock’ based algorithm needs to be implemented. | |||
*The simple system needs to be extended to a more advanced system, which is more realistic like. | |||
*For every milestone background information and other relevant knowledge needs to be found, in order to successfully fulfil every milestone. A milestone should be completed before work on the following milestone can begin, however, in reality a lot of the background information and such will happen in parallel. | |||
=USE aspects= | |||
The situation that is developed in this Wiki is reminiscent of a situation that can be found in real life. Obviously, it is a simplified model of such a real life situation, but suitable for this project. However, even if the model is simplified, the different aspects of the real life equivalent should not be ignored. For instance, the role of the pedestrians that can be found trying to cross the ring are practically reduced to the assumption that that only happens when the light is red for the automobiles. However, to just ignore a such significant user of the traffic system in the Netherlands is quite brash. Thus, in this section the different USE aspects that are important to the specific simplified model of this project will be discussed, but also those in a similar real life situation, where the stakeholders should be the same. | |||
===Users=== | |||
The users of the traffic system in the Netherlands consist of everyone participating in traffic. This ranges from users on wheels, such as automobiles and lorries, to pedestrians and cyclists. Even within these user groups there are different preferences and wishes to how the traffic system should look like. For instance, automobilists want to drive as fast as possible, while never having to stop for something else. Pedestrians want to safely walk alongside the faster traffic, such on curbs, and be able to cross the road where they need to. Obviously, this contradicts each other in a way. So, an overview of these different groups need to be made, such as can be seen in the list below. | |||
''Car Owners'' | |||
*Drive as fast as possible | |||
*Nothing that slows down or stops their journey (such as traffic lights) | |||
*If there is a waiting time, let it be as short as possible | |||
*Good quality roads | |||
*To pay as less as possible on fuel | |||
*Everybody keeps to the traffic rules | |||
''Pedestrians'' | |||
*Safe place to walk | |||
*Safe place to cross the road | |||
*If there is a waiting time, let it be as short as possible | |||
*Everybody keeps to the traffic rules | |||
''Cyclists'' | |||
*Safe place to cycle | |||
*Wants to cycle as fast as it can | |||
*Nothing to slow down or stop their journey | |||
*If there is a waiting time, let it be as short as possible | |||
*Good quality roads | |||
*Everybody keeps to the traffic rules | |||
''Special types of vehicles (ambulances, fire trucks)'' | |||
*Being able to pass regular traffic in an emergency in a safe way | |||
*Travelling time as short as possible | |||
*Always green lights for any traffic light | |||
Unfortunately, not all of these wishes can be granted, nor can all wishes be considered in this projects simplified model. For instance, a constraint of the model is that special vehicles, pedestrians, and cyclist will not be modeled into the system. Pedestrians and cyclist will be present, they will just not be separately simulated, as the assumption is that when the light is red for the ring users, then those two groups can safely cross the ring. Furthermore, since the simulation is based around optimising a traffic light-based system, it is difficult to grant the wish to all users that they never have to stop during their journey. However, the goal of this project is to try to optimise the waiting time, making it as short as possible for all present users. Additionally, this should also create a safer traffic environment for all involved, granting at least a few of the wishes of every user. | |||
===Society=== | |||
The next important stakeholder in the ring-based traffic system is Society itself. Society also consists of the previous mentioned users, but also users that do not participate (at the moment) in the traffic system, thus keeping their wishes in mind as well. Furthermore, Society also has different interests and smaller stakeholders within, such as the environment, the economy, and ranking compared to other Societies (such as in a different country). An overview of the wishes in the Society needs be made, but it also needs to be clear what kind of different groups are represented in this projects Society, | |||
''Environment'' | |||
*The CO2 emission should be lowered | |||
*There should be less pollution | |||
*No destroying the environment | |||
*Society needs to be green, and look/see green (think planting trees and such) | |||
''Economy'' | |||
*The quality of the traffic system should be at a minimum level, preferably higher | |||
*Any change to the traffic system should be as cheap as possible | |||
*Everybody needs to be able to reach their destination as fast as possible, since any delay costs *money | |||
''Compared to other Societies'' | |||
*This Society needs to be the greenest | |||
*It needs to have the safest roads | |||
*It needs to have the highest quality of roads | |||
''Other User groups'' | |||
*The roads need to be as safe as possible | |||
*The roads need to be clean (think, no garbage from cars and such) | |||
*The traffic should preferably be as far away from Society as possible | |||
As can be seen, there are quite a few wide ranging wishes coming from Society. Some, such as the wish to have the highest quality of road material to be used in the roads are not relevant to this project in that it will not be simulated. However, the wish to make changes to the existing traffic system as low-cost as possible, and of course preferably even zero, is quite interesting. It will not be necessarily simulated or the goal of this project, but if the traffic system can be optimised using the concepts within this project without or barely changing the existing traffic system, then that would be quite a feat. | |||
===Enterprise=== | |||
The last type of stakeholder are the entrepreneurs they are just as important to the traffic system as the User and Society stakeholders. The main stakeholders are the following: | |||
* Car Manufacturers | |||
** they want to make as much money as possible | |||
** they want their product to be the most user friendly | |||
* Oil companies | |||
** They want to sell their oil for the highest rate | |||
** They want cars to use much oil so they can sell more | |||
** They do not want cars to be energy sufficient | |||
* Garages | |||
** They want to create trust between their customers | |||
** They want cars to be more fragile | |||
* (GPS-manufactures) | |||
* (Sensor-manufactures) | |||
====Car Manufacturers==== | |||
Car manufactures like BMW, Audi, Kia, Tesla, and more all make new cars with new technology in them. One of these technologies is camera’s and park sensors, most new produced cars have them. These sensors can also be used to the to measure the distance between two cars. Some companies even use these kind of sensors to make the car semi self driving. These semi self driving cars have adaptive cruise control which works like a normal cruise control but now the car slows down when it comes to close to another car. This technology can be used to form a platoon. As we draw down to a conclusion it can be concluded that car manufacturers show their interest in these more autonomous kind of cars. To make sure their product stays top of the business. | |||
The companies that will design and build the autonomous cars for instance, or the ones that will build any new updated traffic system will have quite an interest in an improved traffic system. | |||
=Literature research= | |||
For a project to be successful, research needs to be done. It is important to know what needs to be researched, which in this case includes information on how traffic lights gather information and how autonomous cars gather information. | |||
== Information gathering of traffic lights == | |||
=== History green waves=== | |||
A green wave is implemented mostly in big cities to provide a more efficient traffic flow. This green wave is generated through sending a signal through successive traffic lights, so when traffic is about to pass by, the light will be turned to green. Note that a green wave will only head in one direction on a continuous road. Green waves are a solution to still retain a stable traffic flow, which allows for the cars on the road to not wait too long to drive further. | |||
One of the first reported cases of the use of the term ‘’Green Wave’’, was already in the 1960s in Germany. Here the German Federal Railway utilized an advertising campaign where the proposition of a green wave was made. This was made by handing out the possibility to traverse the speed and open track blocks to their travelers, so they could choose between traveling by use of the railways or by car. Moving way further into time, Green waves were in the 2000s first implemented in big cities like San Fransisco <ref> Sterbentz, J., “Valencia Signals Re-timed to Improve Traffic Flow and Safety”, Streetsblok SF, 2-3-2009. Available at: http://sf.streetsblog.org/2009/03/02/valencia-signals-re-timed-to-improve-traffic-flow-and-safety/ </ref>, where the first both lane Green wave was introduced for cyclists. | |||
'''Protest on Green waves''' | |||
The late 2000s were also times of debate surrounding around green waves. These waves would result in a reduction of cars stopping, and thus a reduction in leaving from a stop-position. Leaving from stop is a fuel consuming task for the car. So the protest was coming from the Department from Transport, who stated that it would be bad for the sale of gasoline. <ref> Author unknown, “Drivers catch green lights 'wave'”, BBC News, 14-4-2009. Available at: http://news.bbc.co.uk/2/hi/uk_news/7998182.stm </ref> Because of the fact that gasoline has a piece of its price being tax, it would be a loss of revenue for tax funds and the government. Over the years this debate has been silenced and also made vague, so it’s not sure whether this discussion is still taking place. | |||
===Sensors=== | |||
Something that has to be taken into account, is the way the traffic lights have to interact or gain information from the moving vehicles. This means that there has to be a device which can communicate to the traffic light. Some ways of achieving this, might be to have a chip that interacts between the cars and the traffic lights, which may provide information both ends of the communication-cycle. However, the GPS chips at the time are not well-equipped for handling situations such as Eindhoven, as it is a big city.<ref> Jae-Hoon J., Min K. and Gi-Sig, B. “Position recognition for an autonomous vehicle based on vehicle-to-led infrastructure”, Lecture Notes in Electrical Engineering, Vol 415 LNEE, 2017, p.p. 913-921. </ref> The focus of this project lies on the present day, so this limits the choice. | |||
the main | As the non-autonomous cars cannot be interacted with via signaling or other means of digital communication, it being a humanly driven vehicle, the requirements the device should have, can be reduced to it just scanning the environment. This can be done via sensors that exist in the world of today, but also in other ways. This includes ways such as a ultrasonic sensor system, image sensor system or the far infrared sensor system. Each of these has its perks and downfalls, but the image sensor system, while being least efficient on power usage, has the ability to check for the velocities of vehicles and the length of a jam, aside from just the number of vehicles and the occupancy, along with being able to check multiple lanes at once.<ref>Hayama, K. and Minakata, T. “A far infrared vehicle sensor for a traffic signal control”, 15th World Congress on Intelligent Transport Systems and ITS America Annual Meeting 2008, 2008, Vol 1, p.p. 99-104</ref> One of the main subjects that is to be implemented and researched in this project, is the efficiency in terms of velocity, CO2 emission and more. As such, the most reliable way of scanning the environment in front of a traffic light, is the image sensor system. | ||
The | The current system used in the Netherlands is by ways of a metallic sensor, that detects if a certain mass has been reached before allowing the detected object to be seen as a vehicle. This is not sufficient in terms of checking for velocity, or other important matters that need to be determined. | ||
== Information gathering of autonomous cars == | |||
Before implementing autonomous cars into the model and ultimately the real world, some background information is needed. So what are now a day cars capable to send and receive from the world ? To do so Tesla's autopilot was considered the best option since it is modern and gives a lot of open information. Unlike the WAYMO project of google. So what makes it possible that the Tesla model s , x and 3 all have semi-autonomous driving? The answer to that is sensors and a computer. All the Tesla’s are equipped with 8 different sensors: rear facing side cameras , front facing overview camera , main front facing camera , front facing distance camera , camera to drive backwards , ultrasonic system , front facing side cameras and radar. These sensors have the following properties: | |||
* rear facing side cameras | |||
** max range of 100 meters <ref name=autos>Lambert, F., "A look at Tesla’s new Autopilot hardware suite: 8 cameras, 1 radar, ultrasonics & new supercomputer", 2016, Available at: https://electrek.co/2016/10/20/tesla-new-autopilot-hardware-suite-camera-nvidia-tesla-vision/ </ref> | |||
** keep track of the blind spots | |||
** is used to safely switch lanes | |||
* Front facing overview camera | |||
** max range is 60 meter <ref name=autos></ref> | |||
** a 150 degree view <ref> Author unknown, "Hardware voor volledig zelfrijdende besturing in alle auto's", date unknown, Available at: https://www.tesla.com/nl_NL/autopilot?redirect=no </ref> detects traffic light signs and obstacles that are on the route the vehicle is taking | |||
* Main front facing camera | |||
** max range is 150 meters <ref name=autos></ref> | |||
** is mainly used to stay in lane and detect obstacles | |||
*front facing distance camera | |||
** max range is 250 meters | |||
** this camera is handy when driving at high speed to spot a difference in environment ahead. | |||
* camera to drive backwards | |||
== | =Algorithm= | ||
'''Contemporary traffic light algorithm''' | |||
Currently a very standard model is being used for the structuring of traffic. 90% of the traffic lights (in big cities as well as small villages) work as follows: when a car approaches a traffic light, it is either green or red. When it turned red, the traffic light waits for the traffic lights in the area to either turn red or to accommodate to a situation in which both this traffic light as well as the others can work. Then it will turn green with an initial green time. When no more traffic is passing through, the light will turn to red in less time than the green time was supposed to last. If traffic is passing continuously, then the green light will turn red after the green time has passed. | |||
==Algorithm by previous group== | |||
PRE2016 1 group 2 <ref name=WikiGroup2> PRE2016 1 group 2, Vehicle Intersection Control, Updating the Current Intersection System to be Compatible with Autonomous Vehicles, 2016, Available at:http://cstwiki.wtb.tue.nl/index.php?title=PRE2016_1_Groep2 </ref> was a group of students who were already working on creating on a new traffic system at intersections. This group didn’t necessarily concentrate on a system where lights are turned green or red when a car is waiting in front of it. They instead made a system in which the greentime and the moments when a light is turned green, is dependent off of the amount of cars that are waiting in front of the traffic light. | |||
===Content of Algorithm=== | |||
====States==== | |||
To turn this system into a practise, the previous group first defined all state (in there case 18) that are possible. With a state is meant the combination of red and green lights at the intersection at a certain time. These state are: | |||
*All pedestrians green, all car lights red; | |||
*4 rotations of one right turn car lane green, 2 pedestrian routes green; | |||
*4 rotations of two right turn car lane green, 1 pedestrian route green; | |||
*All right turn car lanes green, all pedestrians red; | |||
*4 rotations of one left and straight car lane green, one right turn lane green and one pedestrian route green; | |||
*4 rotations of one left and straight car lane green, two right turn lanes green and all pedestrian routes red. | |||
Of course this are not all states available but these are the states where no other light can’t be added without causing an accident. | |||
====Cost function==== | |||
For each of the state the cost will be calculate by the costfunction. This cost function was defined which determined whether a light has a priority on other lights to turn green. This function is defined as follows for the car lanes: | |||
*''Cost_Lane'' = ''Cost_traffic'' + ''Cost_waittime'' + ''Cost_waitlimit'' = ''N'' + ''B'' + ''C_1'' * ''t'' + ''P'' * ''e_1''(''t'') ; | |||
And for the pedestrians: | |||
*''Cost_Pedestrianlane'' = ''Cost_waittime'' + ''Cost_waitlimit'' = ''C_2'' * ''t'' + ''P'' * ''e_2''(''t''); | |||
Here are: | |||
*''N'': The amount of autonomous vehicles. The traffic system get this amount through communication with the autonomous vehicle.; | |||
*''B'': the number of normal cars in the turn lane as reported by the autonomous cars (R is smaller or equal to the total number of normal cars in the turn lane).; | |||
*''C_1'': The constant to provide the severity of the waiting time in front of a traffic light; | |||
*''t'': The waiting time; | |||
*''P'': A large value (in the order of thousands); | |||
*''e_1''(''t''): A function switching to 0 if ''t < T_maxcar'' and to 1 if ''t > T_maxcar''; | |||
**''T_max'': the maximum time a vehicle can be expected to wait at a intersection; | |||
*''e_2''(''t''): A function switching to 0 if ''t'' < ''T_maxpedestrian'' and to 1 if ''t'' > ''T_maxpedestrian''; | |||
**''T_maxpedestrian'': the maximum time a pedestrian can be expected to wait at a intersection; | |||
So the bottom line of this function is: a green light is provided to the biggest row of cars in combination with their waiting time. This function is implemented in each traffic light at the intersection. | |||
===Algorithm in simulation=== | |||
====Packet loss==== | |||
Due to the fact that the algorithm counts the amount of cars by communicating with the autonomous vehicles on the road, there is a chance that error in the communication. There for a packet loss was implemented in the simulation. This needed to make the simulation more realistic. | |||
====Spawning of Cars==== | |||
In simulation the algorithm was implemented no real traffic data was used. The spawn time of new vehicles was composed out of three components: a base time that defines the minimum time between vehicles, a slider dependent time that allows the user of the simulation to determine the number of vehicles that arrive at the intersection and a random number, because vehicles arrive at an intersection in an unpredictable manner, or at least one should not assume it is predictable. This random number is a Gaussian distributed random variable. | |||
====Green wave==== | |||
A Green Wave effect with several intersection wasn’t implemented in the simulation. However, a Green Wave like effect can be used in another way by just the one intersection that the autonomous vehicle is approaching. The car will receive an estimation of what state the intersection will be in when it arrives at the intersection. This method was used in the simulation. | |||
==The new Algorithm== | |||
[[File:ClockSystem.gif | 700 px | thumb | The clock system]] | |||
The amount of states in the system is improved upon by adding multiple more states to the system. The new system makes use of the proposed sensors in chapter 5.1 to detect all cars in front of the traffic lights, instead of only using autonomous cars to detect the cars around them, which also make communication errors. For the traffic light system a new algorithm was imagined where all traffic lights are connected to a “clock system” as described in chapter 6. This clock system is integrated into the cost function for the states where the people on the ring can drive. This makes the clock system not 100% effective in creating green waves but it will increase the cost of the states to try and keep a green wave in effect. The system should in theory improve the efficiency of the system by allowing the cars on the ring, which have further to travel, to have more chance to be driven on. | |||
===Content of Algorithm=== | |||
In this chapter the contents of the algorithm will be explained in more detail. | |||
====States==== | |||
In the new algorithm all possible states are still included. Due to the difference in simulation the amount of states also changes. This change comes due the fact that the previous group just one lane for going forward and left. Well the new simulation uses two different lanes. The new states are: | |||
* All pedestrians green, all car lights red; | |||
*4 rotations of one right turn car lane green ,one right turn lane green and 2 pedestrian routes green; | |||
* 4 rotations of two right turn car lanes green, one straight car lane green, 1 pedestrian routes green; | |||
* All right turn car lanes green; | |||
* 2 rotations of two right turn car lanes green and two straight car lanes green; | |||
* 4 rotations of three right turn car lanes green and one straight car lanes green; | |||
* 4 rotations of two right turn car lanes green, one left turn car lane and one straight car lane green; | |||
* 4 rotations of three right turn car lanes green and one left turn car lane green; | |||
* 4 rotations of one left and straight car lane green, one right turn lane green and one pedestrian route green; | |||
* 4 rotations of two straight car lanes green, one right turn car lane green and one pedestrian route green; | |||
* 2 rotations of two straight car lanes green and 2 pedestrian routes green; | |||
====Clock==== | |||
The system that we are looking into, is mainly targeted to be used on rings of big cities. To describe this idea, an analogy with a clock is being proposed: a clock has a cursor which turns around its own axis. This pointer slides along the circumference of the clock. One can imagine the end of this cursor to be a car, which passes over a road with a constant speed. This is what we assume of a green wave: a state in which cars are allowed to pass sequent green traffic lights by traveling at a constant speed (within a degree of error in reality). This means that the traffic system can easily be corresponded with the speed of the car. The only thing for this system that we need to know, is what the speed limit should be of the road it’s traveling on. For instance when the speed limit is 60 km/h, and one has just past a green traffic light, and the next one is appearing in about 1 kilometer, then the next traffic light should turn green one minute after the previous one has turned green. This time is set that way because within this time, assuming a car will drive with a speed equal to the speed limit, then it will cover that one kilometer in one minute as well. This way, when the car is driving at a constant speed, it can always pass a green light. This is all because the moment the next light turns green, is slightly earlier (due to accelerating from 0 to the speed limit) then the moment where the car arrives at the traffic light. This way the car can drive further without pressing the brakes to slow down. This now introduced traffic system, will be crossed with the traffic system made by the previous groups. So on one hand, at the intersections the main focus is to give advantage to the longest row of vehicles. This whilst a green wave is being forced through the ring, so this green wave has a priority on the intersection system when it is about to pass through an intersection. This means that an alternate cost function needs to implement green waves as well. | |||
====New Cost Function==== | |||
The new cost function looks a lot like the old cost function but works quite different. The new cost function for a car lane is update to implement the new “clock”. Well the function for calculating the cost for pedestrains stayed the same. The new function for a car lane is: | |||
*''Cost_Lane'' = ''Cost_traffic'' + ''Cost_waittime'' + ''Cost_waitlimit'' = ''A''^''T''(''t'') + ''C_1'' * ''t'' + ''P'' * ''e_1''(''t''): | |||
And for the pedestrians: | |||
*''Cost_Pedestrianlane'' = ''Cost_waittime'' + ''Cost_waitlimit'' = ''C_2'' * ''t'' + ''P'' * ''e_2''(''t''); | |||
Here are: | |||
*''A'': The total amount of cars in an intersection row; | |||
*''T''(''t''): A function that shows whether a row is in a green wave, and where; | |||
*''C_1'': The constant to provide the severity of the waiting time in front of a traffic light; | |||
*''t'': The waiting time; | |||
*''P'': A large value (in the order of thousands); | |||
*''e_1''(''t''): A function switching to 0 if ''t < T_maxcar'' and to 1 if ''t > T_maxcar''; | |||
**''T_maxcar'': the maximum time a vehicle can be expected to wait at a intersection; | |||
*''e_2''(''t''): A function switching to 0 if ''t'' < ''T_maxpedestrian'' and to 1 if ''t'' > ''T_maxpedestrian''; | |||
**''T_maxpedestrian'': the maximum time a pedestrian can be expected to wait at a intersection; | |||
In this function it is implemented that a light is turned green earlier when a row at an intersection is in a green wave. | |||
As stated and defined above, a new cost function is presented to create the traffic algorithm. As one can see, there are a few differences. First of all ''N'' + ''B'' is being replaced with just a regular capital ''A'', which stands for the total amount of cars, with include autonomous cars if they are on the road. Secondly “A” is powered by “T”(‘’t’’). The rest of the constants that were already in the cost function made by group PRE2016 1 group 2 are still in the formula and have the same function. Depending on how big the value of ''C_1'' is, the waiting time of the cars will also be weighed in the cost function. The same goes with ‘’C_2’’ for the pedestrians .When this value is made larger, priority is given to the row which has the cars that are waiting the longest. So the weight will proportionally grow with the implementation of waiting time. ''P'' is a large value (like 10000) which will only be put into the cost function, when the longest waiting car in the row had waited for ''T_maxcar'' seconds or longer (for pedestrains this is ''T_maxpedestrain''). This is obviously implemented to prevent one car from waiting too long, when a large amount of cars are on the other roads. | |||
=====The power ''T''(''t'')===== | |||
[[File:TentFunction.jpg | 700 px | thumb | Tent function]] | |||
T(t) is obviously a function that provides a transformation for the power to which the amount of cars waiting in a row is raised. This function is built up from a so-called tent function or a triangular function. This means that most of the time, the function stays the same. But for a certain interval the function will take form of that of a triangle pointing up. So it rises linearly to a maximum, and from that maximum it decreases linearly with the same rate as the rising. We used this function as the basic for the function that we wanted to use as a power for A. Suppose you select a point where the green wave signal is about to begin, so at t=0 the green wave starts to pass by. We use C_end as the time at which the green wave signal stops. We use C_middle as the time at which T(t) has its maximum. C_middle is the average of C_end and the beginning of the green wave signal. We dub this as C_begin. So C_middle in this example will be C_end/2. Since the clockpower can be changed, we need to install the parameter λ, which denotes the chosen clock power. At last we also have to take care of the possibility to choose a different amount of clocks. When a new clock begins, the previous clock signal stops. Since the ‘’previous’’ clock is being described here we call this ending time C_next, which is the ending time of this clock, and the starting time for the new clock. So the function is stated as follows: | |||
''T''(''t'') = | |||
* 1 , if c is in [c_e , c_n] | |||
* λ + ((c_m - t) * λ)/(2 * (c_m - c_b)) , if c is in [c_b, c_m] | |||
* λ + ((c_e - t) * λ)/(2 * (c_e - c_m)) , if c is in [c_m, c_e] | |||
Here λ is either 2, 2½, 3, 3½ or 4; c_e is C_end; c_m is C_middle; c_b is C_begin and c_n is the length of the beginning of a clock signal to the next one divided by the speed of the clock signal. Also note that the tent formed starts at the value of lambda, so it ‘’levitates’’ above 1. | |||
So now, when a green wave passes by, it has to seem, to the traffic light, that there are a lot of cars waiting to cross the street. This will have the traffic system which throughputs the green wave, give a priority on crossing in relativation to the the rows which have a relatively fewer amount of cars waiting. | |||
=Simulation= | |||
==Netlogo== | |||
To simulate the traffic situation a road plan which will symbolize the “ring of Eindhoven” with a reduced amount of intersections will be simulated. There will be 12 intersections in the simulation to test how the old system will work over several intersections, as well as how our new system compares to the old one. A simulation was made in netlogo <ref name=Netlogo> Netlogo, a multi-agent programmable modeling environment, Available at:https://ccl.northwestern.edu/netlogo/ </ref> <ref name=NetLogoDictionary> Netlogo Dictionary, user manual, Available at:https://ccl.northwestern.edu/netlogo/docs/dictionary.html </ref>to figure out the different systems compare to one another. | |||
Netlogo was chosen since it is a modeling environment which can be programmed in lots of different ways. The netlogo program also has the behaviorspace module which can be used to simulate a written program with different settings. This came in useful in testing for which settings our system is the biggest improvement to the old one. | |||
A link to the simulation can be found here:[[File: Simulation files.zip]] | |||
==Program description== | |||
[[File:GUI new.PNG | thumb | GUI of the new program | 600 px]] | |||
There are a few things that can be changed in the simulation. Before the simulation is set up, one can change the distribution of the directions from spawn by using the RealDistribution button. This RealDistribution button is based on the data that was gathered from the 'Berekuil' intersection in Eindhoven. <ref name=DataBerekuil> | |||
H. Nijmeijer, A.A.J. Lefeber, B. van der Bijl, Anticipative flexible traffic light controller design and network stability, February 2017 </ref> ''True'' means that the directions choosing is quiet similar to the real choosing in the 'Berekuil' and ''False'' means using a distribution that would make the green wave effect more visible. The amount and power of the clock hands can also be changed before setup. The speed of the clock and the amount of cars on the road can be manipulated during the simulation. The amount of ticks that will be run can be set in the runfor box. | |||
A car can also be spawned on the ring to investigate how a car driving a full circle on the ring is affected by the systems. It is also possible to run the simulation for one tick with the button GoOneTick. Setup sets up the simulation and its variables, after which go can be used to start and stop the simulation. The last button of interest is a button to export the data to a csv file. It will be output to a file named 1Clocks(clocamount)Power(clockpower).csv with (clockamount) being the amount of clocks set in the silder and (clockpower) being its power set in the slider. If the file name exists the number in front of the name will be incremented by one, up until 10, after which a message is printed to the command center warning that the data was not exported. | |||
The data that is of importance to the model is displayed in the box in the top left of the screen. The simulation can also be viewed, the first intersection is shown in screen on setup, and the other intersections can be seen when the simulation is scrolled of screen. | |||
==Outputs== | |||
As outputs on the simulation a few values are important: | |||
*Cars that got to their destination | |||
*Average speed of cars | |||
*Average times stopped per car | |||
*Average time stopped per stop | |||
*Average time stopped per car | |||
*Average finish time driven per car | |||
Each of these values were also split between cars just crossing the ring, and thereby not actually driving on the ring itself, and cars that at least move a bit on the ring, since the cars that actually move on the ring should be more affected by the green waves. These outputs are also the ones which are in effect when the data is exported by the export data button. | |||
==Testplan== | |||
As seen in the ‘’dashboard’’ of the Netlogo program, some of the variables can be changed. The ones that matter the most in our program are focused on the use of the clock algorithm. Clocks are, in our program, expected to deliver positive changes in most of the parameters that can be measured, such as the total time stopped, the amount of cars stopped, the amount of cars on the road etc. In our clock system it is obvious that we needed to factor in two questions: how powerful should a clock be, and how many clocks should be on the ring? For this reason we implemented the following sliders in the program: Clock power and amount of clocks. For the test plan we needed to figure out how to run the program efficiently. | |||
The clock power can be slid between 2 and 4, with a deviation of ½ . These numbers represent the power to which the amount of cars is raised at the start of the green wave. In the middle of the green wave this power will be 1½ times bigger. So the power will be raised from beginning to middle, and will be reduced from middle to end. | |||
The amount of clock signals can be changed between 0 and 10 with a deviation of 1 clock. 0 meaning that there is no influence from green waves on the traffic on the ring, because there is no green wave signal. 10 meaning that 10 of these power function signals are sent through the intersection system, at the same speed as the cars in the program. | |||
For the test plan of this program we decided to run the program as follows: | |||
For 0 green wave signals we measure the parameters in one run. No green wave signal naturally means that there is no need for this amount to run in with different clock powers, because they won’t have effect when there is no green wave signal at all. This allows us to take a partial look into the results the previous group would have gotten, when the traffic lights with their cost function would be chained to more intersections. The rest of the results are obtained through running the program for 100.000 ticks for all remaining possible combinations of clock power with the amount of clocks. So every setting with a clock power between 2 and 4 and the amount can be changed between 1 and 10. This will give us 50 more results (5 power setting, 10 amount settings). The results of these runs are being put in an excel file which hands us the possibility to quickly see the best outcome per measured parameter. together, there are 51 different setting states that are worth exploring into. These are all ran twice. This is due to the random spawning of the cars on the road. By running them twice, we can take the average, so the deviations in spawn rate can be cancelled out a bit. The simulations are also ran with a focus on the parameters concentrating on ‘’cars at least a bit on the ring’’. This means that we exclude cars that just cross the ring from their spawn street to the opposite street. | |||
The simulations with the lowest setting (0 green wave signals and any power) and the highest settings (10 wave signals and a clock power of 4) are being ran with test cars, which drive along the full ring once. These test cars are spawned every 1000 ticks. This is done because we want to obtain specific results for one car as well. We choose for these cars to be spawned after fixed times, so we can make an average, mainly because of the change of states at the intersections. | |||
=Results= | |||
* | During the simulation, the results were obtained through running the NetLogo program as described above. The simulation would run for every combination of the clock power and the amount of clocks. Plots and tables for the results were made for the following outputs: | ||
* | *Average finishing time | ||
* | **Cars traveling a full lap around the ring | ||
* | **Cars traveling a part of the ring | ||
**All cars | |||
*Average time stopped per car | |||
**Cars traveling a full lap around the ring | |||
**Cars traveling a part of the ring | |||
**All cars | |||
*Average times stopped per car | |||
**Cars traveling a full lap around the ring | |||
**Cars traveling a part of the ring | |||
**All cars | |||
*Average time stopped per stop | |||
**Cars traveling a full lap around the ring | |||
**Cars traveling a part of the ring | |||
**All cars | |||
*Amount of finished cars | |||
**Cars traveling a full lap around the ring | |||
**Cars traveling a part of the ring | |||
**All cars | |||
Some hypotheses were made before looking into these results too much. These are the following: | |||
*The average stopping time per car would be decreased with the implementation of clocks for all cars. The most cars are on the ring for a bit after all, and therefore should be able to travel more fluently with a working clock signal. | |||
*The amount of finished cars would be higher. Since we predict a better throughput for more clocks/higher clock power, we expect more cars finishing for every specific time span. | |||
*A higher clock power is beneficial for the cars traveling a full lap in terms of the finishing time. These cars are supposed to travel along with a green wave. So when the clock power will be higher, we expect these cars to have a priority on the rest of the cars. Which means that we expect these cars to have a shorter finishing time due to traveling longer (in terms of distance) with a green wave. | |||
*Average time stopped per stop would not differ that much between the cars for different clock powers/amounts. This thought came up because of the supposed fact that a higher clock power/clock amount would result in a bit longer of a waiting time for cars of the side roads. This would result in an increase of the waiting time for cars waiting to get on the ring, which increases the overall average. | |||
*The average times stopped per car will overall decrease. Most of the cars are supposed to, at least once, travel along the green wave signal, which already means certainly one stop less in comparison to a system without this signal. This would build up since cars will most likely be in a green wave for a longer distance than two intersections. | |||
*The average times stopped per full lap car will be a bit larger than the average among all cars. This is mainly because of the proposition that these cars will catch more green wave signals and thus very likely will travel more with a green wave. This will result in not very many stops. | |||
The output data, such as the finishing time, time stopped etc. were put automatically into an Excel file, after the simulation had stopped for a certain amount of ticks (in our case 100.000). From this file, a proper analysis of the trends that were occurring was done. From this Excel file, it was possible to make some graphs as well. This would be more meaningful for analysing the results because a visual of the results is easier and more comfortable to work with than a table with hundreds of numbers. | |||
[http://cstwiki.wtb.tue.nl/index.php?title=File:RESULTS.zip The whole table of the results is referenced in this link] | |||
= | [http://cstwiki.wtb.tue.nl/index.php?title=File:Plots_Results.zip The plots for these results are also put in a file]. | ||
As a leap towards the analysis: the plots show decreasing trends which is something that we predicted for some of the outputs. In the analysis, short versions of the tables, so tables with less but more significant and important results, are presented and discussed. | |||
==Analysis== | |||
Now that some results have been gathered, some analysis can be done to see whether the implementation of a new system has improved in some sort of way. For this, the several different aspects will be judged, as written in section 3: | |||
*The throughput of the system: How many cars pass the system within a set amount of time | |||
*How often a car has to stop during their trip | |||
*How long a car has to stop on average for all cars | |||
*How long a car has to stop when stopped | |||
*The average time it takes for an individual to drive to its destination | |||
The results can be split into several different categories before looking into the different evaluation aspects. These categories are: all cars, the cars making one full lap on the ring and the cars who travel along the ring at least one intersection. After this, there can also be made the difference between the clock powers ranging from 2 until 4. To begin with, the best clock power and amount will be determined, after which the most improved category will be determined, all of which are based on the five aspects. | |||
===Clock power and amount=== | |||
First the optimal clock amount will be determined. For this, the difference in the aspects will be checked, generally speaking. Doing this, the following can be concluded: | |||
*The average time it takes for an individual to drive to its destination seems to be less when adding more clocks, while the clock power does not seem to have a direct impact. | |||
*The average time a car stopped also decreases as more clocks are added, and the clock power seems to help this decrease as well, but not as substantial of an impact as the addition of more clocks. | |||
*The average time stopped per stop seems to be increased or decreased as more clocks are added, and even more with a higher clock power, depending on which category is being looked into. | |||
*The average time a car had to stop, however, overall decreases as more clocks are added and does not seem to depend on the power of the clocks. | |||
*The amount of cars that pass through the system seems to be slightly decreased as more clocks are added, while the power of the clock does not have an influence. | |||
Thus the final conclusion is that more clocks is better, generally speaking, while more power does not influence it negatively (but not always positively either). As the power of the clock is not of a substantial influence on all aspects, aside from how much time a car spends stopped and the average time it stops per stop, it suffices to just look at the average of all clock powers with highest amount of clocks, as will give a more accurate depiction of how the results actually vary between systems. | |||
===Most improved category=== | |||
In this section, the three categories will be looked into individually to see which one has been influenced the most by the new system. All of the data can be summarised in the next tables: | |||
- the | {| style="border: 1px solid black; border-spacing: 0; margin: 1em auto;" | ||
|+ '''Table 1: Summarised results''' | |||
|- | |||
! style="border: 1px solid black; padding: 5px; background: #efefef;" | All cars | |||
! colspan="1" style="border: 1px solid black; padding: 5px; background: #ffdead;" | Cars a bit on the ring | |||
! style="border: 1px solid black; padding: 5px; background: #11eeee;" | Cars going a full lap | |||
|- | |||
| style="border: 1px solid black; padding: 5px;" | | |||
- | {| border ="1" style = "border-collapse: collapse;" | ||
! Clocks | |||
! 0 | |||
! 10 | |||
! Difference (%) | |||
|- | |||
! Cars that finished | |||
| 87071,4 || 86697,6 || -0,429 | |||
|- | |||
! Average times stopped per car | |||
| 0,6922164 || 0,656613 || -5,143 | |||
|- | |||
! Average time stopped per stop | |||
| 151,2183286 || 156,2851091 || 3,351 | |||
|- | |||
! Average time stopped per car | |||
| 105,8954501 || 104,0837588 || -1,711 | |||
|- | |||
! Average finish time | |||
| 1122,56263 || 1112,6247334 || -0,885 | |||
|- | |||
|} | |||
| style="border: 1px solid black; padding: 5px;" | | |||
{| border ="1" style = "border-collapse: collapse;" | |||
! Clocks | |||
! 0 | |||
! 10 | |||
! Difference (%) | |||
|- | |||
! Cars that finished | |||
| 51933,4 || 51636,2 || -0,572 | |||
|- | |||
! Average times stopped per car | |||
| 0,8982215 || 0,8500527 || -5,363 | |||
|- | |||
! Average time stopped per stop | |||
| 150,2130625|| 150,7533405 || 0,360 | |||
|- | |||
! Average time stopped per car | |||
| 137,5629334|| 131,2303453|| -4,603 | |||
|- | |||
! Average finish time | |||
| 1709,580975|| 1685,214118|| -1,425 | |||
|- | |||
|} | |||
| rowspan="2" style="border: 1px solid black; border-bottom: 3px solid grey; padding: 5px; vertical-align: top;" | | |||
{| border ="1" style = "border-collapse: collapse;" | |||
! Clocks | |||
! 0 | |||
! 10 | |||
! Difference (%) | |||
|- | |||
! Cars that finished | |||
| 94|| 93,4 || -0,638 | |||
|- | |||
! Average times stopped per car | |||
| 8,0702127|| 6,5082446 || -19,355 | |||
|- | |||
! Average time stopped per stop | |||
| 107,2291591 || 95,9187199 || -10,548 | |||
|- | |||
! Average time stopped per car | |||
| 865,4702127 || 625,5409332 || -27,838 | |||
|- | |||
! Average finish time | |||
| 5732,030851 || 5478,009623 || -4,432 | |||
|- | |||
|} | |||
|- | |||
|} | |||
As can be seen in the tables, the average times stopped per car is decreased by at least 5.1% in all of the cases, and by 19.4% when looking only at cars that go one full lap. This seems to be the largest difference on average between the two clocks, while the smallest is the amount of cars that finished, being around a 0.4% to 0.6% decrease in the three cases. The most interesting of the criteria most certainly is the average time stopped per stop. For all cars, this is an increase of around 3.3%, for cars that travel along at least one intersection it is an increase of around 0.4%, while for cars going a full lap it is a decrease of 10.5%. This means that if you travel along the ring, you will experience less time stopping each time you have to stop. This is also noticeable via the average time stopped per car, as this is decreased by 27% if you travel one full lap, and by 4.6% if you only travel a little bit. The travel time decreases by around 4.4% for a full lap and decreasing to 1.4% if taking a part of the lap. | |||
These results can be compared to real life situations in the following way: there is a substantial decrease in the amount of time spent on the lap or distance in general, if you travel along the ring for long enough, while the cars that do not travel there, do not experience much hinderance. Besides this, there is also a decrease in stops that someone has to perform during the trip. | |||
=Conclusion= | |||
== Influence on USE- aspects == | |||
As we saw in the results that the total travel of all the cars are not affected by the green waves. So the main user aspect (fast to destination) is not realised. However it can be seen that there are 5% less cars that come to a full stop. This results in a more convertible ride , as well as less energy consumption and CO2 emission . Since acceleration is more energy demanding than driving at a contrant speed. | |||
This brings us to a improvement of the Society since their main goals where the create a greener environment, with less pollution. As well as not spending too much money on it. This is also true since we do not use expensive ways to communicate with cars. | |||
At the end The enterprise is not affected by green wave technologie. Since traffic systems do not have the option to communicate with cars in the model that was created. Therefore car manufacturers have no need to build a communication system in the cars. | |||
==Improvements when compared to the old system == | |||
As seen in the analysis of the results, the new system makes an improvement in almost all of the different aspects that we looked into. The model that was utilized proved to be a real improvement on the old system when it comes to the waiting times. The only time that was slightly increased was the time per stop. But even this was only for the total amount of cars and the cars traveling a portion of the ring. Proven is that cars that travel the most around the ring, for instance a full round, pick up the biggest benefits with the most amount of clocks as well as the highest clock power. When it comes to solely the differences of using different clock powers, is was proven that the clock power had only marginal (but increasingly improving) benefits. This means that just giving some kind of priority on green waves is already enough. The severity of its priority, thus, is not that much of a case. So: for the traffic lights to know about the signal is already enough. This means that the huge improvements, are mainly because of the amount of clocks. Having more green wave signals traveling along the ring is resulting in an improvement on general waiting times, which even decrease more when a car travels a greater distance around the ring. This means that the general conclusion of the model, can be stated as follows: | |||
*Cars experience more benefits from green wave signals when a greater portion of the ring is crossed.; | |||
*A rise in the clock power does not significantly improve the total waiting time.; | |||
*Having more green wave signals running through the ring system, allows the throughput to be better and suggests a decrease of overall waiting time.; | |||
So this project has proven that the previous system made by the previous group (which already was an improvement when projected on one intersection), can be made into a ring system/chain of intersections around a city center, and that the implementation of green wave signals in this system will result in improvements on the overall waiting times generally speaking. | |||
=Discussion= | |||
As we saw in the conclusion green waves help to lower the pollution of cars in the city's. But how trustworthy was our model ? Are there things that can be added to the model to make it more realistic ? Are there models that may be more efficient using more advanced technologies ? What was changed in the model during the program and why did it change? These are the questions that will be discussed in this section. | |||
To start with the last question: What was changed in the model during the program and why did it change? | |||
At the start of the project we wanted to make a model that showed us the effect autonomous cars would have on the traffic system. But after a while we came to the conclusion that this was too complex. So we decided to narrow our reaches down to: what are the effects of platoons which are formed by autonomous cars, and what fraction of the autonomous cars is needed to make the platoon effective. A week later we came to the conclusion that platoons where too complex and that autonomous cars were also a little too complex. After this decision we decided to only focus on smart green waves on a city ring road. | |||
Are there things that can be added to the model to make it more realistic ? | |||
In order to simulate the model, assumptions were made to make the model programmable. However these assumptions also make the model a little less realistic. | |||
For instance the choice was made to not include emergency vehicles in our model. Looking back at the program it was possible to integrate this in the cost function, but on the other hand the chance that an emergency vehicle driving over a crossing point is less than 0.1%. this is the reason to not put so much effort in implementing the emergency vehicles in the model. | |||
There is also an assumption that probably made the model less realistic. In the model every car has the same driving properties. They may have different destinations but there are no tailgaters , hogs or slow old grandmas in our model. Another point is that that there is no difference in car types , brands or models. A full electric car has no CO2 emission where most old timers do not even have a filter on there exhausts, so different cars have different pollution rates . | |||
It may be possible to integrate by giving every car a different acceleration , reaction time , maxspeed , social drive level and pollution rate parameter. Those parameters are picked from some distribution (could be binomial , normal , exponential, chisquare etc.). However one downside is that this is a lot to program and it asks for a lot of the memory from the computer, which will result in a much longer running time when the simulation is turned on. | |||
Are there models that may be more efficient using more advanced technologies ? | |||
As discussed in the literary study new evolving technology can give the traffic system way more data through sensors as well as through communication with autonomous cars. If the traffic system has this data, the cost function can be more specifically defined. For instance if a car has a higher amount of CO2 emission when accelerating, It may be an idea to give these cars more value in the cost function. Also a model with autonomous cars could have been more efficient. The last group did literary research on autonomous cars, and concluded that they could keep track of their distance in relation to other cars. This means that platooning could have arised if we implemented this in our model. However, we chose not to implement this because of the difficulty of the implementation of this in the program code. | |||
How trustworthy was our model? | |||
Despite of all of the assumptions that were made in our model, the focus was still put mainly on the throughput of the traffic system, as well as the decreasing of the total waiting time. One thing that was understood is that rings need to keep up with an almost unpaused stream of loads of traffic. Since we accepted lots of traffic on the ring in our model, together with the assumptions of cars that are operated by humans (such as cars later in a row in front of a traffic light having more delay on driving further), it can be said that this model is trustable when it comes to the density of real life rings. Implementing the previous group's work together with the implementation of handing out priority to green waves, it can be seen that through the chaos created by the amount of cars, still an improvement could be made. These improvements were focusing on the reduction of waiting time, and most of these, except for one type of waiting time (the averga time stopped per stop), were indeed improved with significant results. Since traffic on rings is mostly driving in straight lines, and only a few exceptions of people who ''can't drive'' are on the road, it can be stated that the results that were obtained are (within a degree of error) very assumable. So overall, our newly created system is on these degrees trustworthy. | |||
==Future Research== | |||
As stated further above, and as mentioned in the discussion, there are factors that we had to drop out of our model due to time and workload related issues. One of these things is for instance the CO2 emission. This project started of with this feature but was later dropped because a focus was needed for the objectives that were proposed. | |||
CO2 emission researched asked for factors such as the fuel power of cars as well as the content of CO2 in the fuel inceneration process. These things should be researched in order for it to be omplemented in the model that we used. So this is something that could be further looked into. | |||
Also the phenomenon of platooning is something that we wanted to initially implement in our model and simulation. Platooning is something that happens more easily when autonomous cars would have also been introduced. Some small research in autonomous cars was done but creating a different driving and communication pattern for autonomous cars would have also costed a lot of work, which there was not time for whe the end of this project was in sight. This means that platooning was also not that easy to install in our program, since you needed more specific conditions for human controlled vehicles to form platoons (such as mutual knowledge on the distances between the cars on the road, and the speed at which cars drive away to name some conditions). These things would have made the model not much more complex but the implementation into the program would have costed more work. Cars had to be made rational thinking machines, which is not something that cars naturally are. So the adding of autonomous cars, and thus the possibility of creating platoons is something that can be looked into even further from this position. | |||
Also some assumptions in our model that made it less realistic could have gotten rid off. For instance: the implementation of bad drivers was possible. This could have been done in a way in which these drivers could create delay for the drivers behind them for instance. This part could have made the program more realistic, but was not built into our model because of complexity of the running of the program and it would even pose problems for the creating of the code as well. So the installing of bad drivers, or at least disturbance in the system, is something that should definitely be looked into, in order for our model to be a more realistic represntation of real life city rings. | |||
Also we did have formulas for the pedestrian traffic lights implemented. However we did not have time to focus on the results that would come out of these formulas. So we also did not have the capability to compare the benefits or worsenings of the new system to pedestrian throughput. This is also something that should be looked into further into the future. | |||
=References= | =References= | ||
<references/> | <references/> | ||
=Planning and project information= | |||
In the beginning of the project, we had a certain planning that said what everyone had to do in a specific week. This was abbreviated with letters for the different people. The planning can be seen in table 1. | |||
{| border ="1" style = "border-collapse: collapse;" | |||
|+ Table 1: Initial planning | |||
! | |||
! week 3 | |||
! week 4 | |||
! week 5 | |||
! week 6 | |||
! week 7 | |||
! week 8 | |||
|- | |||
! Understanding the current traffic system | |||
| All || All || || || || | |||
|- | |||
! The effects of autonomous vehicles on the traffic system | |||
| || K M T || F T || || || | |||
|- | |||
! What makes an autonomous vehicle better in traffic | |||
| || S F L || S L || || || | |||
|- | |||
! How are humans in the traffic affected | |||
| || || S F L || S L || S L || | |||
|- | |||
! What can be changed to optimise traffic with autonomous vehicles | |||
| || || K M T || M T || M T || | |||
|- | |||
! Model of the new traffic system | |||
| || K F || K F || K F || K F || | |||
|- | |||
! Complete the article | |||
| || || || || All || All | |||
|- | |||
! Work on final presentation | |||
| || || || || ? || All | |||
|- | |||
|} | |||
After a couple of weeks, there were some complications, and certain deadlines were not met. Because of this, and the fact that our initial approach turned out to be wrong, we changed our entire planning so that we could still finish the project in time and have time remaining to give some finishing touches. This can be seen in table 2. | |||
{| border ="1" style = "border-collapse: collapse; width: 800px;" | |||
|+ Table 2: Eventual planning | |||
! | |||
! 25-3 | |||
! 27-3 | |||
! 30-3 | |||
! 2-4 | |||
! 4-4 | |||
! 5-4 | |||
! 8-4 | |||
! 10-4 | |||
! 13-4 | |||
|- | |||
! Programming in Netlogo | |||
| T K || T K || T K || T K || || || || || | |||
|- | |||
! Rewriting focus, objectives, approach | |||
| F S || F S || || T K || || || || || | |||
|- | |||
! Literature study green waves, platooning, sensors vs chips, autonomous cars | |||
| M L|| M L || || || L F || || || || | |||
|- | |||
! Results of program | |||
| || || || L K T || L K T || L K T || L K T || || | |||
|- | |||
! Testplan | |||
| || || || L K T || || || || || | |||
|- | |||
! Final presentation | |||
| || || || S || M L || M L || || || | |||
|- | |||
! Description old system | |||
| || || || T || T || || || || | |||
|- | |||
! Description new system | |||
| || || || K || K || K || || || | |||
|- | |||
! Peer-review | |||
| || || || All || All || All || All || All || | |||
|- | |||
! How the program works | |||
| || || || || T || T || || || | |||
|- | |||
! Description clock system | |||
| || || || || S || || || || | |||
|- | |||
! Influence on the USE aspects | |||
| || || || || F || || || || | |||
|- | |||
! Analysis of results and conclusion | |||
| || || || || M || M || M || M || | |||
|- | |||
! Writing discussion | |||
| || || || || || F || F || F || | |||
|- | |||
! Rewriting introduction | |||
| || || || || || || || S || | |||
|- | |||
! Finalisation | |||
| || || || || || || || || All | |||
|- | |||
|} | |||
Because everyone writes their own parts, it still needs to be updated to the wiki. This has been delegated to Matthijs, while the final checker of for example grammar mistakes and of the wiki itself, has been delegated to Lars. | |||
As part of the task division, there were not really special tasks that were given to certain people; everyone did their part of the project. There is however a small difference in the way people acted during meetings, or how they performed in the group itself. |
Latest revision as of 23:05, 13 April 2017
Introduction
Every day a lot of people are waiting before a traffic light some point in their drive. This can causes frustration for the drivers, and more pollution for the environment. After all, driving the same speed continuously is a lot less intensive than stopping and then go again. So, it would be quite optimal if these drivers can continue driving past these traffic lights. Obviously, this is not possible for all traffic lights in the world, however, there are quite some traffic trajects where this could certainly be improved. A continuously connected traffic road, for instance a ring around a city, is a good example. For this reason the project took as basis to improve the ring around Eindhoven, a city in the Netherlands.
One of the methods to improve traffic flow is through the use of green waving. Here cars can continuously get a serie of green lights when they drive at an appropriate speed. For this project it was decided to try to implement green waving in a ring system. This was modelled through the use of the program Netlogo, where eventually a ring of twelve crossings was achieved. The algorithm of the individual traffic lights were based on a previous group’s work in order to eventually create an even better system. In order to register the presence of a car in front of a light the efficiency difference between chips in the cars themselves and sensors directly build into the traffic system itself was researched during the literature studies. To connect as it were all the traffic lights into one overreaching system for the green waving effect, a periodic time interval reminiscent of a clock was introduced. This can trigger the start of a green wave on the ring. From the results it could be concluded that the new system was indeed better on some improvement points in comparison to the reference traffic system.
Authors
- 0960493 Tim Houthuijs
- 0934016 Kevin Jenniskens
- 0958509 Matthijs van Raaij
- 0948190 Sarah Rohder
- 0903327 Floris Tulner
- 0945501 Lars Verstraelen
Objectives, Focus and Approach
Objectives
The goal of this project is to ultimately improve the traffic system which consists of several crossings by trying to add functionality to the individual traffic lights crossings to smartly create and use green waves. The new system tries to use this through the use of a time based order, similar to the path of a clock hand. In order to make sure that the new system compared to the old system is indeed better, it gets compared on five different variables:
- The average time it takes for an individual to drive to its destination
- How often a car has to stop during their trip
- How long a car has to stop when stopped
- How long a car has to stop on average for all cars
- The throughput of the system: How many cars pass the system within a set amount of time
These variables should lead to be able to answer the main question: Is the new system an improvement over the old traffic system?
Additionally, to answer this particular question, it has been divided into different sub-questions, which will ultimately lead to the conclusion to the final main question. The following sub-questions has been deemed interesting to answer:
- How does the old system work?
- How does the system take its different users into account?
- How does the old system work for more intersections?
- What exactly is a green wave?
- What exactly is the purpose of creating a green wave?
- What sensors are needed for this to work in the traffic system?
Focus
Requirements
- The traffic system is a ring
- 2-lane road, with near traffic lights left and right turn lanes
- Sensors in road around traffic lights to detect cars
- Speed and location of the cars can measured
Preferences
- Using green waving as much as possible
- The simulation needs to be as realistic as possible
- The spawning of the cars in the simulation needs to represent by realistic distribution
Constraints
- Cars cannot wait too long
- Emergency vehicles will not be simulated
- Each traffic light needs to make an estimation to determine the next traffic light state. This can be done with the Cost function of the previous group or an upgraded version of this.
Assumptions
- Cars do not drive through red
- All vehicles will stay below speed limitations
Approach
The project needed to be divided into several milestones:
- The old traffic system that was to be used as baseline needed to compare the new traffic system to needs to be extended to include more than one intersection.
- A first simple system using the new ‘clock’ based algorithm needs to be implemented.
- The simple system needs to be extended to a more advanced system, which is more realistic like.
- For every milestone background information and other relevant knowledge needs to be found, in order to successfully fulfil every milestone. A milestone should be completed before work on the following milestone can begin, however, in reality a lot of the background information and such will happen in parallel.
USE aspects
The situation that is developed in this Wiki is reminiscent of a situation that can be found in real life. Obviously, it is a simplified model of such a real life situation, but suitable for this project. However, even if the model is simplified, the different aspects of the real life equivalent should not be ignored. For instance, the role of the pedestrians that can be found trying to cross the ring are practically reduced to the assumption that that only happens when the light is red for the automobiles. However, to just ignore a such significant user of the traffic system in the Netherlands is quite brash. Thus, in this section the different USE aspects that are important to the specific simplified model of this project will be discussed, but also those in a similar real life situation, where the stakeholders should be the same.
Users
The users of the traffic system in the Netherlands consist of everyone participating in traffic. This ranges from users on wheels, such as automobiles and lorries, to pedestrians and cyclists. Even within these user groups there are different preferences and wishes to how the traffic system should look like. For instance, automobilists want to drive as fast as possible, while never having to stop for something else. Pedestrians want to safely walk alongside the faster traffic, such on curbs, and be able to cross the road where they need to. Obviously, this contradicts each other in a way. So, an overview of these different groups need to be made, such as can be seen in the list below.
Car Owners
- Drive as fast as possible
- Nothing that slows down or stops their journey (such as traffic lights)
- If there is a waiting time, let it be as short as possible
- Good quality roads
- To pay as less as possible on fuel
- Everybody keeps to the traffic rules
Pedestrians
- Safe place to walk
- Safe place to cross the road
- If there is a waiting time, let it be as short as possible
- Everybody keeps to the traffic rules
Cyclists
- Safe place to cycle
- Wants to cycle as fast as it can
- Nothing to slow down or stop their journey
- If there is a waiting time, let it be as short as possible
- Good quality roads
- Everybody keeps to the traffic rules
Special types of vehicles (ambulances, fire trucks)
- Being able to pass regular traffic in an emergency in a safe way
- Travelling time as short as possible
- Always green lights for any traffic light
Unfortunately, not all of these wishes can be granted, nor can all wishes be considered in this projects simplified model. For instance, a constraint of the model is that special vehicles, pedestrians, and cyclist will not be modeled into the system. Pedestrians and cyclist will be present, they will just not be separately simulated, as the assumption is that when the light is red for the ring users, then those two groups can safely cross the ring. Furthermore, since the simulation is based around optimising a traffic light-based system, it is difficult to grant the wish to all users that they never have to stop during their journey. However, the goal of this project is to try to optimise the waiting time, making it as short as possible for all present users. Additionally, this should also create a safer traffic environment for all involved, granting at least a few of the wishes of every user.
Society
The next important stakeholder in the ring-based traffic system is Society itself. Society also consists of the previous mentioned users, but also users that do not participate (at the moment) in the traffic system, thus keeping their wishes in mind as well. Furthermore, Society also has different interests and smaller stakeholders within, such as the environment, the economy, and ranking compared to other Societies (such as in a different country). An overview of the wishes in the Society needs be made, but it also needs to be clear what kind of different groups are represented in this projects Society,
Environment
- The CO2 emission should be lowered
- There should be less pollution
- No destroying the environment
- Society needs to be green, and look/see green (think planting trees and such)
Economy
- The quality of the traffic system should be at a minimum level, preferably higher
- Any change to the traffic system should be as cheap as possible
- Everybody needs to be able to reach their destination as fast as possible, since any delay costs *money
Compared to other Societies
- This Society needs to be the greenest
- It needs to have the safest roads
- It needs to have the highest quality of roads
Other User groups
- The roads need to be as safe as possible
- The roads need to be clean (think, no garbage from cars and such)
- The traffic should preferably be as far away from Society as possible
As can be seen, there are quite a few wide ranging wishes coming from Society. Some, such as the wish to have the highest quality of road material to be used in the roads are not relevant to this project in that it will not be simulated. However, the wish to make changes to the existing traffic system as low-cost as possible, and of course preferably even zero, is quite interesting. It will not be necessarily simulated or the goal of this project, but if the traffic system can be optimised using the concepts within this project without or barely changing the existing traffic system, then that would be quite a feat.
Enterprise
The last type of stakeholder are the entrepreneurs they are just as important to the traffic system as the User and Society stakeholders. The main stakeholders are the following:
- Car Manufacturers
- they want to make as much money as possible
- they want their product to be the most user friendly
- Oil companies
- They want to sell their oil for the highest rate
- They want cars to use much oil so they can sell more
- They do not want cars to be energy sufficient
- Garages
- They want to create trust between their customers
- They want cars to be more fragile
- (GPS-manufactures)
- (Sensor-manufactures)
Car Manufacturers
Car manufactures like BMW, Audi, Kia, Tesla, and more all make new cars with new technology in them. One of these technologies is camera’s and park sensors, most new produced cars have them. These sensors can also be used to the to measure the distance between two cars. Some companies even use these kind of sensors to make the car semi self driving. These semi self driving cars have adaptive cruise control which works like a normal cruise control but now the car slows down when it comes to close to another car. This technology can be used to form a platoon. As we draw down to a conclusion it can be concluded that car manufacturers show their interest in these more autonomous kind of cars. To make sure their product stays top of the business.
The companies that will design and build the autonomous cars for instance, or the ones that will build any new updated traffic system will have quite an interest in an improved traffic system.
Literature research
For a project to be successful, research needs to be done. It is important to know what needs to be researched, which in this case includes information on how traffic lights gather information and how autonomous cars gather information.
Information gathering of traffic lights
History green waves
A green wave is implemented mostly in big cities to provide a more efficient traffic flow. This green wave is generated through sending a signal through successive traffic lights, so when traffic is about to pass by, the light will be turned to green. Note that a green wave will only head in one direction on a continuous road. Green waves are a solution to still retain a stable traffic flow, which allows for the cars on the road to not wait too long to drive further. One of the first reported cases of the use of the term ‘’Green Wave’’, was already in the 1960s in Germany. Here the German Federal Railway utilized an advertising campaign where the proposition of a green wave was made. This was made by handing out the possibility to traverse the speed and open track blocks to their travelers, so they could choose between traveling by use of the railways or by car. Moving way further into time, Green waves were in the 2000s first implemented in big cities like San Fransisco [1], where the first both lane Green wave was introduced for cyclists.
Protest on Green waves
The late 2000s were also times of debate surrounding around green waves. These waves would result in a reduction of cars stopping, and thus a reduction in leaving from a stop-position. Leaving from stop is a fuel consuming task for the car. So the protest was coming from the Department from Transport, who stated that it would be bad for the sale of gasoline. [2] Because of the fact that gasoline has a piece of its price being tax, it would be a loss of revenue for tax funds and the government. Over the years this debate has been silenced and also made vague, so it’s not sure whether this discussion is still taking place.
Sensors
Something that has to be taken into account, is the way the traffic lights have to interact or gain information from the moving vehicles. This means that there has to be a device which can communicate to the traffic light. Some ways of achieving this, might be to have a chip that interacts between the cars and the traffic lights, which may provide information both ends of the communication-cycle. However, the GPS chips at the time are not well-equipped for handling situations such as Eindhoven, as it is a big city.[3] The focus of this project lies on the present day, so this limits the choice.
As the non-autonomous cars cannot be interacted with via signaling or other means of digital communication, it being a humanly driven vehicle, the requirements the device should have, can be reduced to it just scanning the environment. This can be done via sensors that exist in the world of today, but also in other ways. This includes ways such as a ultrasonic sensor system, image sensor system or the far infrared sensor system. Each of these has its perks and downfalls, but the image sensor system, while being least efficient on power usage, has the ability to check for the velocities of vehicles and the length of a jam, aside from just the number of vehicles and the occupancy, along with being able to check multiple lanes at once.[4] One of the main subjects that is to be implemented and researched in this project, is the efficiency in terms of velocity, CO2 emission and more. As such, the most reliable way of scanning the environment in front of a traffic light, is the image sensor system.
The current system used in the Netherlands is by ways of a metallic sensor, that detects if a certain mass has been reached before allowing the detected object to be seen as a vehicle. This is not sufficient in terms of checking for velocity, or other important matters that need to be determined.
Information gathering of autonomous cars
Before implementing autonomous cars into the model and ultimately the real world, some background information is needed. So what are now a day cars capable to send and receive from the world ? To do so Tesla's autopilot was considered the best option since it is modern and gives a lot of open information. Unlike the WAYMO project of google. So what makes it possible that the Tesla model s , x and 3 all have semi-autonomous driving? The answer to that is sensors and a computer. All the Tesla’s are equipped with 8 different sensors: rear facing side cameras , front facing overview camera , main front facing camera , front facing distance camera , camera to drive backwards , ultrasonic system , front facing side cameras and radar. These sensors have the following properties:
- rear facing side cameras
- max range of 100 meters [5]
- keep track of the blind spots
- is used to safely switch lanes
- Front facing overview camera
- Main front facing camera
- max range is 150 meters [5]
- is mainly used to stay in lane and detect obstacles
- front facing distance camera
- max range is 250 meters
- this camera is handy when driving at high speed to spot a difference in environment ahead.
- camera to drive backwards
Algorithm
Contemporary traffic light algorithm
Currently a very standard model is being used for the structuring of traffic. 90% of the traffic lights (in big cities as well as small villages) work as follows: when a car approaches a traffic light, it is either green or red. When it turned red, the traffic light waits for the traffic lights in the area to either turn red or to accommodate to a situation in which both this traffic light as well as the others can work. Then it will turn green with an initial green time. When no more traffic is passing through, the light will turn to red in less time than the green time was supposed to last. If traffic is passing continuously, then the green light will turn red after the green time has passed.
Algorithm by previous group
PRE2016 1 group 2 [7] was a group of students who were already working on creating on a new traffic system at intersections. This group didn’t necessarily concentrate on a system where lights are turned green or red when a car is waiting in front of it. They instead made a system in which the greentime and the moments when a light is turned green, is dependent off of the amount of cars that are waiting in front of the traffic light.
Content of Algorithm
States
To turn this system into a practise, the previous group first defined all state (in there case 18) that are possible. With a state is meant the combination of red and green lights at the intersection at a certain time. These state are:
- All pedestrians green, all car lights red;
- 4 rotations of one right turn car lane green, 2 pedestrian routes green;
- 4 rotations of two right turn car lane green, 1 pedestrian route green;
- All right turn car lanes green, all pedestrians red;
- 4 rotations of one left and straight car lane green, one right turn lane green and one pedestrian route green;
- 4 rotations of one left and straight car lane green, two right turn lanes green and all pedestrian routes red.
Of course this are not all states available but these are the states where no other light can’t be added without causing an accident.
Cost function
For each of the state the cost will be calculate by the costfunction. This cost function was defined which determined whether a light has a priority on other lights to turn green. This function is defined as follows for the car lanes:
- Cost_Lane = Cost_traffic + Cost_waittime + Cost_waitlimit = N + B + C_1 * t + P * e_1(t) ;
And for the pedestrians:
- Cost_Pedestrianlane = Cost_waittime + Cost_waitlimit = C_2 * t + P * e_2(t);
Here are:
- N: The amount of autonomous vehicles. The traffic system get this amount through communication with the autonomous vehicle.;
- B: the number of normal cars in the turn lane as reported by the autonomous cars (R is smaller or equal to the total number of normal cars in the turn lane).;
- C_1: The constant to provide the severity of the waiting time in front of a traffic light;
- t: The waiting time;
- P: A large value (in the order of thousands);
- e_1(t): A function switching to 0 if t < T_maxcar and to 1 if t > T_maxcar;
- T_max: the maximum time a vehicle can be expected to wait at a intersection;
- e_2(t): A function switching to 0 if t < T_maxpedestrian and to 1 if t > T_maxpedestrian;
- T_maxpedestrian: the maximum time a pedestrian can be expected to wait at a intersection;
So the bottom line of this function is: a green light is provided to the biggest row of cars in combination with their waiting time. This function is implemented in each traffic light at the intersection.
Algorithm in simulation
Packet loss
Due to the fact that the algorithm counts the amount of cars by communicating with the autonomous vehicles on the road, there is a chance that error in the communication. There for a packet loss was implemented in the simulation. This needed to make the simulation more realistic.
Spawning of Cars
In simulation the algorithm was implemented no real traffic data was used. The spawn time of new vehicles was composed out of three components: a base time that defines the minimum time between vehicles, a slider dependent time that allows the user of the simulation to determine the number of vehicles that arrive at the intersection and a random number, because vehicles arrive at an intersection in an unpredictable manner, or at least one should not assume it is predictable. This random number is a Gaussian distributed random variable.
Green wave
A Green Wave effect with several intersection wasn’t implemented in the simulation. However, a Green Wave like effect can be used in another way by just the one intersection that the autonomous vehicle is approaching. The car will receive an estimation of what state the intersection will be in when it arrives at the intersection. This method was used in the simulation.
The new Algorithm
The amount of states in the system is improved upon by adding multiple more states to the system. The new system makes use of the proposed sensors in chapter 5.1 to detect all cars in front of the traffic lights, instead of only using autonomous cars to detect the cars around them, which also make communication errors. For the traffic light system a new algorithm was imagined where all traffic lights are connected to a “clock system” as described in chapter 6. This clock system is integrated into the cost function for the states where the people on the ring can drive. This makes the clock system not 100% effective in creating green waves but it will increase the cost of the states to try and keep a green wave in effect. The system should in theory improve the efficiency of the system by allowing the cars on the ring, which have further to travel, to have more chance to be driven on.
Content of Algorithm
In this chapter the contents of the algorithm will be explained in more detail.
States
In the new algorithm all possible states are still included. Due to the difference in simulation the amount of states also changes. This change comes due the fact that the previous group just one lane for going forward and left. Well the new simulation uses two different lanes. The new states are:
- All pedestrians green, all car lights red;
- 4 rotations of one right turn car lane green ,one right turn lane green and 2 pedestrian routes green;
- 4 rotations of two right turn car lanes green, one straight car lane green, 1 pedestrian routes green;
- All right turn car lanes green;
- 2 rotations of two right turn car lanes green and two straight car lanes green;
- 4 rotations of three right turn car lanes green and one straight car lanes green;
- 4 rotations of two right turn car lanes green, one left turn car lane and one straight car lane green;
- 4 rotations of three right turn car lanes green and one left turn car lane green;
- 4 rotations of one left and straight car lane green, one right turn lane green and one pedestrian route green;
- 4 rotations of two straight car lanes green, one right turn car lane green and one pedestrian route green;
- 2 rotations of two straight car lanes green and 2 pedestrian routes green;
Clock
The system that we are looking into, is mainly targeted to be used on rings of big cities. To describe this idea, an analogy with a clock is being proposed: a clock has a cursor which turns around its own axis. This pointer slides along the circumference of the clock. One can imagine the end of this cursor to be a car, which passes over a road with a constant speed. This is what we assume of a green wave: a state in which cars are allowed to pass sequent green traffic lights by traveling at a constant speed (within a degree of error in reality). This means that the traffic system can easily be corresponded with the speed of the car. The only thing for this system that we need to know, is what the speed limit should be of the road it’s traveling on. For instance when the speed limit is 60 km/h, and one has just past a green traffic light, and the next one is appearing in about 1 kilometer, then the next traffic light should turn green one minute after the previous one has turned green. This time is set that way because within this time, assuming a car will drive with a speed equal to the speed limit, then it will cover that one kilometer in one minute as well. This way, when the car is driving at a constant speed, it can always pass a green light. This is all because the moment the next light turns green, is slightly earlier (due to accelerating from 0 to the speed limit) then the moment where the car arrives at the traffic light. This way the car can drive further without pressing the brakes to slow down. This now introduced traffic system, will be crossed with the traffic system made by the previous groups. So on one hand, at the intersections the main focus is to give advantage to the longest row of vehicles. This whilst a green wave is being forced through the ring, so this green wave has a priority on the intersection system when it is about to pass through an intersection. This means that an alternate cost function needs to implement green waves as well.
New Cost Function
The new cost function looks a lot like the old cost function but works quite different. The new cost function for a car lane is update to implement the new “clock”. Well the function for calculating the cost for pedestrains stayed the same. The new function for a car lane is:
- Cost_Lane = Cost_traffic + Cost_waittime + Cost_waitlimit = A^T(t) + C_1 * t + P * e_1(t):
And for the pedestrians:
- Cost_Pedestrianlane = Cost_waittime + Cost_waitlimit = C_2 * t + P * e_2(t);
Here are:
- A: The total amount of cars in an intersection row;
- T(t): A function that shows whether a row is in a green wave, and where;
- C_1: The constant to provide the severity of the waiting time in front of a traffic light;
- t: The waiting time;
- P: A large value (in the order of thousands);
- e_1(t): A function switching to 0 if t < T_maxcar and to 1 if t > T_maxcar;
- T_maxcar: the maximum time a vehicle can be expected to wait at a intersection;
- e_2(t): A function switching to 0 if t < T_maxpedestrian and to 1 if t > T_maxpedestrian;
- T_maxpedestrian: the maximum time a pedestrian can be expected to wait at a intersection;
In this function it is implemented that a light is turned green earlier when a row at an intersection is in a green wave.
As stated and defined above, a new cost function is presented to create the traffic algorithm. As one can see, there are a few differences. First of all N + B is being replaced with just a regular capital A, which stands for the total amount of cars, with include autonomous cars if they are on the road. Secondly “A” is powered by “T”(‘’t’’). The rest of the constants that were already in the cost function made by group PRE2016 1 group 2 are still in the formula and have the same function. Depending on how big the value of C_1 is, the waiting time of the cars will also be weighed in the cost function. The same goes with ‘’C_2’’ for the pedestrians .When this value is made larger, priority is given to the row which has the cars that are waiting the longest. So the weight will proportionally grow with the implementation of waiting time. P is a large value (like 10000) which will only be put into the cost function, when the longest waiting car in the row had waited for T_maxcar seconds or longer (for pedestrains this is T_maxpedestrain). This is obviously implemented to prevent one car from waiting too long, when a large amount of cars are on the other roads.
The power T(t)
T(t) is obviously a function that provides a transformation for the power to which the amount of cars waiting in a row is raised. This function is built up from a so-called tent function or a triangular function. This means that most of the time, the function stays the same. But for a certain interval the function will take form of that of a triangle pointing up. So it rises linearly to a maximum, and from that maximum it decreases linearly with the same rate as the rising. We used this function as the basic for the function that we wanted to use as a power for A. Suppose you select a point where the green wave signal is about to begin, so at t=0 the green wave starts to pass by. We use C_end as the time at which the green wave signal stops. We use C_middle as the time at which T(t) has its maximum. C_middle is the average of C_end and the beginning of the green wave signal. We dub this as C_begin. So C_middle in this example will be C_end/2. Since the clockpower can be changed, we need to install the parameter λ, which denotes the chosen clock power. At last we also have to take care of the possibility to choose a different amount of clocks. When a new clock begins, the previous clock signal stops. Since the ‘’previous’’ clock is being described here we call this ending time C_next, which is the ending time of this clock, and the starting time for the new clock. So the function is stated as follows:
T(t) =
- 1 , if c is in [c_e , c_n]
- λ + ((c_m - t) * λ)/(2 * (c_m - c_b)) , if c is in [c_b, c_m]
- λ + ((c_e - t) * λ)/(2 * (c_e - c_m)) , if c is in [c_m, c_e]
Here λ is either 2, 2½, 3, 3½ or 4; c_e is C_end; c_m is C_middle; c_b is C_begin and c_n is the length of the beginning of a clock signal to the next one divided by the speed of the clock signal. Also note that the tent formed starts at the value of lambda, so it ‘’levitates’’ above 1.
So now, when a green wave passes by, it has to seem, to the traffic light, that there are a lot of cars waiting to cross the street. This will have the traffic system which throughputs the green wave, give a priority on crossing in relativation to the the rows which have a relatively fewer amount of cars waiting.
Simulation
Netlogo
To simulate the traffic situation a road plan which will symbolize the “ring of Eindhoven” with a reduced amount of intersections will be simulated. There will be 12 intersections in the simulation to test how the old system will work over several intersections, as well as how our new system compares to the old one. A simulation was made in netlogo [8] [9]to figure out the different systems compare to one another. Netlogo was chosen since it is a modeling environment which can be programmed in lots of different ways. The netlogo program also has the behaviorspace module which can be used to simulate a written program with different settings. This came in useful in testing for which settings our system is the biggest improvement to the old one.
A link to the simulation can be found here:File:Simulation files.zip
Program description
There are a few things that can be changed in the simulation. Before the simulation is set up, one can change the distribution of the directions from spawn by using the RealDistribution button. This RealDistribution button is based on the data that was gathered from the 'Berekuil' intersection in Eindhoven. [10] True means that the directions choosing is quiet similar to the real choosing in the 'Berekuil' and False means using a distribution that would make the green wave effect more visible. The amount and power of the clock hands can also be changed before setup. The speed of the clock and the amount of cars on the road can be manipulated during the simulation. The amount of ticks that will be run can be set in the runfor box. A car can also be spawned on the ring to investigate how a car driving a full circle on the ring is affected by the systems. It is also possible to run the simulation for one tick with the button GoOneTick. Setup sets up the simulation and its variables, after which go can be used to start and stop the simulation. The last button of interest is a button to export the data to a csv file. It will be output to a file named 1Clocks(clocamount)Power(clockpower).csv with (clockamount) being the amount of clocks set in the silder and (clockpower) being its power set in the slider. If the file name exists the number in front of the name will be incremented by one, up until 10, after which a message is printed to the command center warning that the data was not exported. The data that is of importance to the model is displayed in the box in the top left of the screen. The simulation can also be viewed, the first intersection is shown in screen on setup, and the other intersections can be seen when the simulation is scrolled of screen.
Outputs
As outputs on the simulation a few values are important:
- Cars that got to their destination
- Average speed of cars
- Average times stopped per car
- Average time stopped per stop
- Average time stopped per car
- Average finish time driven per car
Each of these values were also split between cars just crossing the ring, and thereby not actually driving on the ring itself, and cars that at least move a bit on the ring, since the cars that actually move on the ring should be more affected by the green waves. These outputs are also the ones which are in effect when the data is exported by the export data button.
Testplan
As seen in the ‘’dashboard’’ of the Netlogo program, some of the variables can be changed. The ones that matter the most in our program are focused on the use of the clock algorithm. Clocks are, in our program, expected to deliver positive changes in most of the parameters that can be measured, such as the total time stopped, the amount of cars stopped, the amount of cars on the road etc. In our clock system it is obvious that we needed to factor in two questions: how powerful should a clock be, and how many clocks should be on the ring? For this reason we implemented the following sliders in the program: Clock power and amount of clocks. For the test plan we needed to figure out how to run the program efficiently.
The clock power can be slid between 2 and 4, with a deviation of ½ . These numbers represent the power to which the amount of cars is raised at the start of the green wave. In the middle of the green wave this power will be 1½ times bigger. So the power will be raised from beginning to middle, and will be reduced from middle to end.
The amount of clock signals can be changed between 0 and 10 with a deviation of 1 clock. 0 meaning that there is no influence from green waves on the traffic on the ring, because there is no green wave signal. 10 meaning that 10 of these power function signals are sent through the intersection system, at the same speed as the cars in the program.
For the test plan of this program we decided to run the program as follows:
For 0 green wave signals we measure the parameters in one run. No green wave signal naturally means that there is no need for this amount to run in with different clock powers, because they won’t have effect when there is no green wave signal at all. This allows us to take a partial look into the results the previous group would have gotten, when the traffic lights with their cost function would be chained to more intersections. The rest of the results are obtained through running the program for 100.000 ticks for all remaining possible combinations of clock power with the amount of clocks. So every setting with a clock power between 2 and 4 and the amount can be changed between 1 and 10. This will give us 50 more results (5 power setting, 10 amount settings). The results of these runs are being put in an excel file which hands us the possibility to quickly see the best outcome per measured parameter. together, there are 51 different setting states that are worth exploring into. These are all ran twice. This is due to the random spawning of the cars on the road. By running them twice, we can take the average, so the deviations in spawn rate can be cancelled out a bit. The simulations are also ran with a focus on the parameters concentrating on ‘’cars at least a bit on the ring’’. This means that we exclude cars that just cross the ring from their spawn street to the opposite street.
The simulations with the lowest setting (0 green wave signals and any power) and the highest settings (10 wave signals and a clock power of 4) are being ran with test cars, which drive along the full ring once. These test cars are spawned every 1000 ticks. This is done because we want to obtain specific results for one car as well. We choose for these cars to be spawned after fixed times, so we can make an average, mainly because of the change of states at the intersections.
Results
During the simulation, the results were obtained through running the NetLogo program as described above. The simulation would run for every combination of the clock power and the amount of clocks. Plots and tables for the results were made for the following outputs:
- Average finishing time
- Cars traveling a full lap around the ring
- Cars traveling a part of the ring
- All cars
- Average time stopped per car
- Cars traveling a full lap around the ring
- Cars traveling a part of the ring
- All cars
- Average times stopped per car
- Cars traveling a full lap around the ring
- Cars traveling a part of the ring
- All cars
- Average time stopped per stop
- Cars traveling a full lap around the ring
- Cars traveling a part of the ring
- All cars
- Amount of finished cars
- Cars traveling a full lap around the ring
- Cars traveling a part of the ring
- All cars
Some hypotheses were made before looking into these results too much. These are the following:
- The average stopping time per car would be decreased with the implementation of clocks for all cars. The most cars are on the ring for a bit after all, and therefore should be able to travel more fluently with a working clock signal.
- The amount of finished cars would be higher. Since we predict a better throughput for more clocks/higher clock power, we expect more cars finishing for every specific time span.
- A higher clock power is beneficial for the cars traveling a full lap in terms of the finishing time. These cars are supposed to travel along with a green wave. So when the clock power will be higher, we expect these cars to have a priority on the rest of the cars. Which means that we expect these cars to have a shorter finishing time due to traveling longer (in terms of distance) with a green wave.
- Average time stopped per stop would not differ that much between the cars for different clock powers/amounts. This thought came up because of the supposed fact that a higher clock power/clock amount would result in a bit longer of a waiting time for cars of the side roads. This would result in an increase of the waiting time for cars waiting to get on the ring, which increases the overall average.
- The average times stopped per car will overall decrease. Most of the cars are supposed to, at least once, travel along the green wave signal, which already means certainly one stop less in comparison to a system without this signal. This would build up since cars will most likely be in a green wave for a longer distance than two intersections.
- The average times stopped per full lap car will be a bit larger than the average among all cars. This is mainly because of the proposition that these cars will catch more green wave signals and thus very likely will travel more with a green wave. This will result in not very many stops.
The output data, such as the finishing time, time stopped etc. were put automatically into an Excel file, after the simulation had stopped for a certain amount of ticks (in our case 100.000). From this file, a proper analysis of the trends that were occurring was done. From this Excel file, it was possible to make some graphs as well. This would be more meaningful for analysing the results because a visual of the results is easier and more comfortable to work with than a table with hundreds of numbers.
The whole table of the results is referenced in this link
The plots for these results are also put in a file.
As a leap towards the analysis: the plots show decreasing trends which is something that we predicted for some of the outputs. In the analysis, short versions of the tables, so tables with less but more significant and important results, are presented and discussed.
Analysis
Now that some results have been gathered, some analysis can be done to see whether the implementation of a new system has improved in some sort of way. For this, the several different aspects will be judged, as written in section 3:
- The throughput of the system: How many cars pass the system within a set amount of time
- How often a car has to stop during their trip
- How long a car has to stop on average for all cars
- How long a car has to stop when stopped
- The average time it takes for an individual to drive to its destination
The results can be split into several different categories before looking into the different evaluation aspects. These categories are: all cars, the cars making one full lap on the ring and the cars who travel along the ring at least one intersection. After this, there can also be made the difference between the clock powers ranging from 2 until 4. To begin with, the best clock power and amount will be determined, after which the most improved category will be determined, all of which are based on the five aspects.
Clock power and amount
First the optimal clock amount will be determined. For this, the difference in the aspects will be checked, generally speaking. Doing this, the following can be concluded:
- The average time it takes for an individual to drive to its destination seems to be less when adding more clocks, while the clock power does not seem to have a direct impact.
- The average time a car stopped also decreases as more clocks are added, and the clock power seems to help this decrease as well, but not as substantial of an impact as the addition of more clocks.
- The average time stopped per stop seems to be increased or decreased as more clocks are added, and even more with a higher clock power, depending on which category is being looked into.
- The average time a car had to stop, however, overall decreases as more clocks are added and does not seem to depend on the power of the clocks.
- The amount of cars that pass through the system seems to be slightly decreased as more clocks are added, while the power of the clock does not have an influence.
Thus the final conclusion is that more clocks is better, generally speaking, while more power does not influence it negatively (but not always positively either). As the power of the clock is not of a substantial influence on all aspects, aside from how much time a car spends stopped and the average time it stops per stop, it suffices to just look at the average of all clock powers with highest amount of clocks, as will give a more accurate depiction of how the results actually vary between systems.
Most improved category
In this section, the three categories will be looked into individually to see which one has been influenced the most by the new system. All of the data can be summarised in the next tables:
All cars | Cars a bit on the ring | Cars going a full lap | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
As can be seen in the tables, the average times stopped per car is decreased by at least 5.1% in all of the cases, and by 19.4% when looking only at cars that go one full lap. This seems to be the largest difference on average between the two clocks, while the smallest is the amount of cars that finished, being around a 0.4% to 0.6% decrease in the three cases. The most interesting of the criteria most certainly is the average time stopped per stop. For all cars, this is an increase of around 3.3%, for cars that travel along at least one intersection it is an increase of around 0.4%, while for cars going a full lap it is a decrease of 10.5%. This means that if you travel along the ring, you will experience less time stopping each time you have to stop. This is also noticeable via the average time stopped per car, as this is decreased by 27% if you travel one full lap, and by 4.6% if you only travel a little bit. The travel time decreases by around 4.4% for a full lap and decreasing to 1.4% if taking a part of the lap. These results can be compared to real life situations in the following way: there is a substantial decrease in the amount of time spent on the lap or distance in general, if you travel along the ring for long enough, while the cars that do not travel there, do not experience much hinderance. Besides this, there is also a decrease in stops that someone has to perform during the trip.
Conclusion
Influence on USE- aspects
As we saw in the results that the total travel of all the cars are not affected by the green waves. So the main user aspect (fast to destination) is not realised. However it can be seen that there are 5% less cars that come to a full stop. This results in a more convertible ride , as well as less energy consumption and CO2 emission . Since acceleration is more energy demanding than driving at a contrant speed. This brings us to a improvement of the Society since their main goals where the create a greener environment, with less pollution. As well as not spending too much money on it. This is also true since we do not use expensive ways to communicate with cars. At the end The enterprise is not affected by green wave technologie. Since traffic systems do not have the option to communicate with cars in the model that was created. Therefore car manufacturers have no need to build a communication system in the cars.
Improvements when compared to the old system
As seen in the analysis of the results, the new system makes an improvement in almost all of the different aspects that we looked into. The model that was utilized proved to be a real improvement on the old system when it comes to the waiting times. The only time that was slightly increased was the time per stop. But even this was only for the total amount of cars and the cars traveling a portion of the ring. Proven is that cars that travel the most around the ring, for instance a full round, pick up the biggest benefits with the most amount of clocks as well as the highest clock power. When it comes to solely the differences of using different clock powers, is was proven that the clock power had only marginal (but increasingly improving) benefits. This means that just giving some kind of priority on green waves is already enough. The severity of its priority, thus, is not that much of a case. So: for the traffic lights to know about the signal is already enough. This means that the huge improvements, are mainly because of the amount of clocks. Having more green wave signals traveling along the ring is resulting in an improvement on general waiting times, which even decrease more when a car travels a greater distance around the ring. This means that the general conclusion of the model, can be stated as follows:
- Cars experience more benefits from green wave signals when a greater portion of the ring is crossed.;
- A rise in the clock power does not significantly improve the total waiting time.;
- Having more green wave signals running through the ring system, allows the throughput to be better and suggests a decrease of overall waiting time.;
So this project has proven that the previous system made by the previous group (which already was an improvement when projected on one intersection), can be made into a ring system/chain of intersections around a city center, and that the implementation of green wave signals in this system will result in improvements on the overall waiting times generally speaking.
Discussion
As we saw in the conclusion green waves help to lower the pollution of cars in the city's. But how trustworthy was our model ? Are there things that can be added to the model to make it more realistic ? Are there models that may be more efficient using more advanced technologies ? What was changed in the model during the program and why did it change? These are the questions that will be discussed in this section.
To start with the last question: What was changed in the model during the program and why did it change?
At the start of the project we wanted to make a model that showed us the effect autonomous cars would have on the traffic system. But after a while we came to the conclusion that this was too complex. So we decided to narrow our reaches down to: what are the effects of platoons which are formed by autonomous cars, and what fraction of the autonomous cars is needed to make the platoon effective. A week later we came to the conclusion that platoons where too complex and that autonomous cars were also a little too complex. After this decision we decided to only focus on smart green waves on a city ring road.
Are there things that can be added to the model to make it more realistic ?
In order to simulate the model, assumptions were made to make the model programmable. However these assumptions also make the model a little less realistic. For instance the choice was made to not include emergency vehicles in our model. Looking back at the program it was possible to integrate this in the cost function, but on the other hand the chance that an emergency vehicle driving over a crossing point is less than 0.1%. this is the reason to not put so much effort in implementing the emergency vehicles in the model.
There is also an assumption that probably made the model less realistic. In the model every car has the same driving properties. They may have different destinations but there are no tailgaters , hogs or slow old grandmas in our model. Another point is that that there is no difference in car types , brands or models. A full electric car has no CO2 emission where most old timers do not even have a filter on there exhausts, so different cars have different pollution rates .
It may be possible to integrate by giving every car a different acceleration , reaction time , maxspeed , social drive level and pollution rate parameter. Those parameters are picked from some distribution (could be binomial , normal , exponential, chisquare etc.). However one downside is that this is a lot to program and it asks for a lot of the memory from the computer, which will result in a much longer running time when the simulation is turned on.
Are there models that may be more efficient using more advanced technologies ?
As discussed in the literary study new evolving technology can give the traffic system way more data through sensors as well as through communication with autonomous cars. If the traffic system has this data, the cost function can be more specifically defined. For instance if a car has a higher amount of CO2 emission when accelerating, It may be an idea to give these cars more value in the cost function. Also a model with autonomous cars could have been more efficient. The last group did literary research on autonomous cars, and concluded that they could keep track of their distance in relation to other cars. This means that platooning could have arised if we implemented this in our model. However, we chose not to implement this because of the difficulty of the implementation of this in the program code.
How trustworthy was our model?
Despite of all of the assumptions that were made in our model, the focus was still put mainly on the throughput of the traffic system, as well as the decreasing of the total waiting time. One thing that was understood is that rings need to keep up with an almost unpaused stream of loads of traffic. Since we accepted lots of traffic on the ring in our model, together with the assumptions of cars that are operated by humans (such as cars later in a row in front of a traffic light having more delay on driving further), it can be said that this model is trustable when it comes to the density of real life rings. Implementing the previous group's work together with the implementation of handing out priority to green waves, it can be seen that through the chaos created by the amount of cars, still an improvement could be made. These improvements were focusing on the reduction of waiting time, and most of these, except for one type of waiting time (the averga time stopped per stop), were indeed improved with significant results. Since traffic on rings is mostly driving in straight lines, and only a few exceptions of people who can't drive are on the road, it can be stated that the results that were obtained are (within a degree of error) very assumable. So overall, our newly created system is on these degrees trustworthy.
Future Research
As stated further above, and as mentioned in the discussion, there are factors that we had to drop out of our model due to time and workload related issues. One of these things is for instance the CO2 emission. This project started of with this feature but was later dropped because a focus was needed for the objectives that were proposed.
CO2 emission researched asked for factors such as the fuel power of cars as well as the content of CO2 in the fuel inceneration process. These things should be researched in order for it to be omplemented in the model that we used. So this is something that could be further looked into.
Also the phenomenon of platooning is something that we wanted to initially implement in our model and simulation. Platooning is something that happens more easily when autonomous cars would have also been introduced. Some small research in autonomous cars was done but creating a different driving and communication pattern for autonomous cars would have also costed a lot of work, which there was not time for whe the end of this project was in sight. This means that platooning was also not that easy to install in our program, since you needed more specific conditions for human controlled vehicles to form platoons (such as mutual knowledge on the distances between the cars on the road, and the speed at which cars drive away to name some conditions). These things would have made the model not much more complex but the implementation into the program would have costed more work. Cars had to be made rational thinking machines, which is not something that cars naturally are. So the adding of autonomous cars, and thus the possibility of creating platoons is something that can be looked into even further from this position.
Also some assumptions in our model that made it less realistic could have gotten rid off. For instance: the implementation of bad drivers was possible. This could have been done in a way in which these drivers could create delay for the drivers behind them for instance. This part could have made the program more realistic, but was not built into our model because of complexity of the running of the program and it would even pose problems for the creating of the code as well. So the installing of bad drivers, or at least disturbance in the system, is something that should definitely be looked into, in order for our model to be a more realistic represntation of real life city rings.
Also we did have formulas for the pedestrian traffic lights implemented. However we did not have time to focus on the results that would come out of these formulas. So we also did not have the capability to compare the benefits or worsenings of the new system to pedestrian throughput. This is also something that should be looked into further into the future.
References
- ↑ Sterbentz, J., “Valencia Signals Re-timed to Improve Traffic Flow and Safety”, Streetsblok SF, 2-3-2009. Available at: http://sf.streetsblog.org/2009/03/02/valencia-signals-re-timed-to-improve-traffic-flow-and-safety/
- ↑ Author unknown, “Drivers catch green lights 'wave'”, BBC News, 14-4-2009. Available at: http://news.bbc.co.uk/2/hi/uk_news/7998182.stm
- ↑ Jae-Hoon J., Min K. and Gi-Sig, B. “Position recognition for an autonomous vehicle based on vehicle-to-led infrastructure”, Lecture Notes in Electrical Engineering, Vol 415 LNEE, 2017, p.p. 913-921.
- ↑ Hayama, K. and Minakata, T. “A far infrared vehicle sensor for a traffic signal control”, 15th World Congress on Intelligent Transport Systems and ITS America Annual Meeting 2008, 2008, Vol 1, p.p. 99-104
- ↑ 5.0 5.1 5.2 Lambert, F., "A look at Tesla’s new Autopilot hardware suite: 8 cameras, 1 radar, ultrasonics & new supercomputer", 2016, Available at: https://electrek.co/2016/10/20/tesla-new-autopilot-hardware-suite-camera-nvidia-tesla-vision/
- ↑ Author unknown, "Hardware voor volledig zelfrijdende besturing in alle auto's", date unknown, Available at: https://www.tesla.com/nl_NL/autopilot?redirect=no
- ↑ PRE2016 1 group 2, Vehicle Intersection Control, Updating the Current Intersection System to be Compatible with Autonomous Vehicles, 2016, Available at:http://cstwiki.wtb.tue.nl/index.php?title=PRE2016_1_Groep2
- ↑ Netlogo, a multi-agent programmable modeling environment, Available at:https://ccl.northwestern.edu/netlogo/
- ↑ Netlogo Dictionary, user manual, Available at:https://ccl.northwestern.edu/netlogo/docs/dictionary.html
- ↑ H. Nijmeijer, A.A.J. Lefeber, B. van der Bijl, Anticipative flexible traffic light controller design and network stability, February 2017
Planning and project information
In the beginning of the project, we had a certain planning that said what everyone had to do in a specific week. This was abbreviated with letters for the different people. The planning can be seen in table 1.
week 3 | week 4 | week 5 | week 6 | week 7 | week 8 | |
---|---|---|---|---|---|---|
Understanding the current traffic system | All | All | ||||
The effects of autonomous vehicles on the traffic system | K M T | F T | ||||
What makes an autonomous vehicle better in traffic | S F L | S L | ||||
How are humans in the traffic affected | S F L | S L | S L | |||
What can be changed to optimise traffic with autonomous vehicles | K M T | M T | M T | |||
Model of the new traffic system | K F | K F | K F | K F | ||
Complete the article | All | All | ||||
Work on final presentation | ? | All |
After a couple of weeks, there were some complications, and certain deadlines were not met. Because of this, and the fact that our initial approach turned out to be wrong, we changed our entire planning so that we could still finish the project in time and have time remaining to give some finishing touches. This can be seen in table 2.
25-3 | 27-3 | 30-3 | 2-4 | 4-4 | 5-4 | 8-4 | 10-4 | 13-4 | |
---|---|---|---|---|---|---|---|---|---|
Programming in Netlogo | T K | T K | T K | T K | |||||
Rewriting focus, objectives, approach | F S | F S | T K | ||||||
Literature study green waves, platooning, sensors vs chips, autonomous cars | M L | M L | L F | ||||||
Results of program | L K T | L K T | L K T | L K T | |||||
Testplan | L K T | ||||||||
Final presentation | S | M L | M L | ||||||
Description old system | T | T | |||||||
Description new system | K | K | K | ||||||
Peer-review | All | All | All | All | All | ||||
How the program works | T | T | |||||||
Description clock system | S | ||||||||
Influence on the USE aspects | F | ||||||||
Analysis of results and conclusion | M | M | M | M | |||||
Writing discussion | F | F | F | ||||||
Rewriting introduction | S | ||||||||
Finalisation | All |
Because everyone writes their own parts, it still needs to be updated to the wiki. This has been delegated to Matthijs, while the final checker of for example grammar mistakes and of the wiki itself, has been delegated to Lars.
As part of the task division, there were not really special tasks that were given to certain people; everyone did their part of the project. There is however a small difference in the way people acted during meetings, or how they performed in the group itself.