Final Presentation

(1) The main idea of the project and core aspects.

We wanted to create a realistic freeway and simulate the behaviour of cars and the creation of traffic jams as well as the changing of lanes.

To do this, we:

• Check neighbours forward and backwards using the x position (in two different loops) inspired from the code doing that in lab 2.
• Since we spawn our cars frequently,  we need to make sure that when they spawn they keep a safety distance at first (to avoid them spawning on top of each other), the car in the back will slow down its speed until it is within a safe radius.
• We are using two different radiuses. The biggest one is used for detecting neighbours within that radius (radius). The other one is minradius. If a car is within the minradius, they need to slow down untll they are in outside of minradius.

The radiuses are illustrated in the follwing image:

• When a car is detected within radius, it starts to slow down. This is done by interpolating the speed till it matches the neighbouring car if the neighbouring car is slower. We do this with the help of the Unity Lerp function.
• When a car starts to slow down it will try to change lane to the left. If that lane is free. This is done by checking if there is a car in the y position at the given coordinates of the neighbouring lane, the same way as checking neighbours front and back.
• Cars that are in the outermost left will try to change lane to the right if they are too slow. We do this by checking if the car behind (with the help of radius) has a higher starting velocity. If it does, the slower car will change lane to the right if the lane is free. The car that was behind, that had to slow down, will accelerate back to its starting velocity, with the help of the Lerp function.

Problems we encountered:

• We tried to get the cars to lerp sideways while changing lanes, instead of teleporting as they do now, but the values we need to lerp between are so small that the car doesn’t go all the way. It did work if we used Time.deltatime*1000, but it interpolated to fast and it still looks like it teleports. A solution to this would be to give the car a velocity in the y direction, but the way our code is built and how it checks neighbours, we wouldn’t be able to detect the cars that are in between lanes.
• We also discovered that since we use floats, there are a few bugs with the floating points (flyttalsfel) so we have put in place a few safety measures.   

(2) Your progress and where the project is now. A pre-recorded demonstration is the best way (if you have one), otherwise work in progress screenshots.

Here is a video of the freeway simulation:

(3) The approximate grade you are aiming for.

We are aiming for a pass.

Fixing Bugs and 3D

We fixed a few bugs with the interpolation.
Here are some videos of that progress:

We then made the simulation in 3D:

We tried making the cars change lane sideways with the help of Lerp, but we ran into problems when doing this. It doesn't quite work as well as we would like it to work for the code as it is now. If we want to make it work, we would need to change the structure of the code, which we probably do not have the time to do.

We will see what we do about it.

Decelerating and changing lanes

At this point we have cars driving in lanes and creating traffic jams, but they change velocity very abruptly instead of decelerating.

To do this we thought that we might need a deceleration formula, such as the ones found at http://byjus.com/deceleration-formula.

The most interesting version of the deceleration formula was the following one.

Where deceleration is  -a, starting velocity is u, final velocity is v and s is the distance covered.

To use this formula, v would be the velocity if the slower neighbour detected within a radius, and u would be the velocity of the current car. s would be the value we would need to calculate and use. So we would need to set a to an arbitrary value.

The problem with calculating this is that we need to do it in every frame, but we don’t actually want s to change once we’ve calculated s for one car. So updating s every frame is not an option.

Instead, by getting help at a project session, we found that we could use interpolation to get a linear change to make the car decelerate little by little instead of abruptly changing speed. Unity has one such function called Lerp (https://docs.unity3d.com/ScriptReference/Vector3.Lerp.html).

The second thing we implemented this time was changing lanes.

We started by implementing the conditions for which the cars would change lane. They were, when a car detects a car in front and changes its speed to that of the neighbouring car, it will change lane to the left. The actual changing of lane is done by changing the y position by an appropriate amount. We needed to add limitations on this, to make sure that the lane the furthest to the left is the last lane they can change to, so that they stay on the freeway.

When this was done the cars change lanes to the left when a car in front is too slow, but, they don’t check to see if the lane beside is actually free, and end up changing on top of each other.

To fix this we want to make the car aware of the cars in the neighbouring lanes as well as the cars in front, which it can do in the same way as it does when checking neighbours in front. The difference is that now it doesn’t only check on its x axis (which is in front). We needed to test a few times with different values, to make sure that the radius checked was big enough for the cars to stop changing into each other.

To make the simulation more realistic, we also want the car that changed lane to keep it’s old speed, so that it will pass the slower car, which we implemented.

Video of the lane changing:

The next step: use lerp for changing lane smoothly instead of teleporting (tip from project session)

+ Fixing bugs in lane changing, since it doesn’t always seem to work as smoothly as we would like it to.

Also, get a more interesting scene by adding texture and maybe converting to 3D (to be able to change camera angle and have a cooler view, also tip from project session).

When changing to 3D we need to change x and y in scripts because as it is, it looks like this: 

Which is more like space ships than cars, but apart from tha, the lane changing and freeway driving works.

Making Cars aware of each other

Up until now we have spawned cars the way we want to on our freeway. The problem is that none of the cars are aware of its neighbours, and so they drive through each other.

We need to make the cars aware of their neighbours, just like the fish in the second lab were aware of their neighbours. So, we will reuse the code doing that, changing it so that it is more appropriate to our case.

We will, just like for the fish, use a radius, to decide how far to look for neighbours. We set radius as a variable in our Cars class, corresponding to Boids in lab 2. We also only check for cars in the same lane (only using the x value).

We got stuck a while on the fact that our spawned cars were not children to the class called “School”, like for the school of fish in the second lab, until we found the two rows of code that fixed that. Before we fixed that, the cars couldn’t use the code we had written in the School class to use when updating, and instead they just stood still where they spawned.

With that fixed and working, we then needed to decide what to do when a car detects another car within that radius.

After some testing of different values and actions we found that we needed to have a maximum and a minimum radius.

The action that we decided made the most sense and looked the best was to check on every update of the simulation if the neighbour was in between minradius and maxradius, and if it was, to change the velocity of the car to the same as its neighbour. Then, if a car detects a neighbour inside its minradius, it will lower its velocity to be slower than the neighbour (so that they are not to close to each other). When the car has slowed down enough to find itself in between the minradius and maxradius instead, it will change its velocity to that of the neighbour.

The part with the minradius also solved a problem we had of cars spawning on top of each other and therefore forming a long box instead of separating since they matched their speeds to the car in front.

This is all illustrated in the following video:

The next step will be to make the deacceleration more natural, since now we just decide that the velocity changes instead of it changing gradually.

All the Cars!

The next few steps in the project were to spawn several cars in all lanes at random intervals and with random speeds. We did this by basing our code on the code of the fish and boids from the second lab and giving the code for our cars the same structure as the code in that lab.

We first randomly spawned one car in every lane. As seen in the following video.

(video 1)

We then want to spawn more than one car in every lane, at random intervals and randomly in every lane.

This is what we see in the following video.

(video 2)

We now have a highway with traffic! But the cars drive through each other if they one catches up to another. This will be the next thing to fix.

(excuse the quality of the videos, a recording of the computer screen…)

First steps in the project

The first steps in the project is to draw the freeway and make "cars" (boxes) spawn and move from one side to the other. This is the progress on this made last week by Conrad. 

The texture for the highway is the following:

It is asfalt found at https://thumbs.dreamstime.com/t/asphalt-highway-road-markings-background-41377159.jpg

Here is what we did:

Create a new sprite

Drag the road texture into the sprite inspector

Put 2.2 spacing in x and 1.5 in y

Add a sprite for a car

Add a new component under Car and use Rigidbody 2D.

Set gravity to 0.

Create script and drag the script onto the car element in the left list.

Now the car moves straight in the lane.

Project Specification

Title: Freeway Simulation

By Group Radish

GROUP MEMBERS:

Conrad Hildebrand (conradhi@kth.se) and Emmeli Hansson (emmelih@kth.se)

GRADE:

We are aiming for the grade E (pass) because we want to be sure to pass the project, but if we have the time, we would like to implement more of the things we thought of doing at first.

SPECIFICATION DETAILS

BACKGROUND

The idea to this project came from a game called cities skyline. In the game you build a city from the ground up with roads you draw yourself, in residential, commercial and industrial areas. All and all a very complex simulation game. A frustrating moment in the game is to create good roads so that the traffic runs smoothly and optimizing traffic to avoid traffic jams. Traffic simulations are also interesting in the real world, because it traffic jams are just as much a problem and complex here as in the virtual reality of the game. At the beginning, we wanted the project to be about city traffic simulation with cars having random destinations and finding the fastest way to get there. However, we felt that path finding algorithms for car routes wasn’t what we wanted to focus on and, furthermore together with creating intersection behaviour, it seemed to be to hard of a task with the time given and the level we have chosen for our project. Instead we decided to focus on a single straight road or a freeway. Now we can focus on using group behaviour from lab 2 and spring functions from lab 3 to simulate cars’ behaviour on a freeway.

IMPLEMENTATION SPECIFICS

    We would like to simulate a semi-realistic behaviour of cars on a highway, how they avoid each other when changing lanes, how they change lanes and consequently how the traffic is affected and resulting traffic jams. The one big constraint we will have is that we will have a perfect world where cars do not collide because all cars behave exactly as they should.

    We will use Unity for this project.

   

Here is a list of the implementations we want to do, in the order we think we need to do them:

• Draw a 4 lane freeway
• Make cars spawn on every lane (the cars being boxes)
• Get the cars moving from from one end to the other and despawn
• Give cars random spawn intervals
• Assert random speeds to cars within a limit
• Make sure cars don’t collide by deaccelerating when getting to close (by using part 2 in lab 3)
• Get cars to change lane
• Get surrounding cars to avoid the car that changes lane (by using separation force as for the fish in lab 2)
• Get car to accelerate back to their starting speed.
• Fluent lane swapping, so that the cars change lane little by little and don’t just teleport there
• Set conditions to when cars change lane. The condition being if the car in front is slower, change to the left.

The following points, without implementation order, will be implemented based on time:

• Give each lane a recommended speed interval.
• Second condition, if a car is moving too slow for the lane, change lane to the right.
• Implement a 24 hour cycle, where fewer cars are spawned during the night, and more during certain hours of the day.
• Make cars breakdown and stop on the freeway
• Make our cars look like cars and not just boxes.

SPECIFICS OF WHAT THE FINAL SYSTEM WILL LOOK LIKE AND DO

Simulation of stop&go traffic (https://www.youtube.com/watch?v=W_kYXpAEnd8) - We want our simulation to look something like this video looks at about the 0:25 timestamp and onwards.

Cities: Skyline Review (https://www.youtube.com/watch?v=9xj4ciP0Riw) - This is the game that sparked the idea of this simulation.

Paramics Road / City Traffic Simulation (https://www.youtube.com/watch?v=Bl3C8aS0sgs) - Here is a more advanced version of what we want to do. Not the graphically most appealing but having traffic lights and loads of intersections makes it a lot harder to implement properly.  

POTENTIAL RISKS/CHALLENGES

Potential risks and challenges we might run into are:

• If we want to model the cars, and start putting in too much effort into that, which takes time, instead of focusing on the behaviour and physics aspect.

Solution: Have this step as an extra implementation that we decide we will only do if we have time.

• That one of our steps takes more time to do then we thought at first, and consequently we might not be able to do all the implementations.

Solution: Have a few steps that we decide we will only do if we have time.

• If we run into difficulties with Unity, that we are too inexperienced to solve.

Solution: Ask for help at the project sessions.

DEGREE OF SIMULATION

We will try to base our simulation on labs 2 and 3 as much as we can for the physics of our project, because we believe that some parts of the physics in those labs correspond to the physics we will need to implement.

So, we will not be implementing anything from the ground up. Instead we will use Unity and the labs to help us.

LINK TO BLOG

http://radishfreeway.blogspot.se/

REFERENCES

Simulation of stop&go traffic (2007) [video]. traffic-simulation.de. https://www.youtube.com/watch?v=W_kYXpAEnd8 [2017-02-17]

Cities: Skyline Review (2015) [video]. IGN. https://www.youtube.com/watch?v=9xj4ciP0Riw [2017-02-17]

Paramics Road / City Traffic Simulation (2012) [video]. https://www.youtube.com/watch?v=Bl3C8aS0sgs [2017-02-17]