Vehicle Traffic Simulation

Transcription

1 Vehicle Traffic Simulation CIS 400/401- Senior Project Final Report Norman Badler Univ. of Pennsylvania Philadelphia, PA Joseph Weinhoffer Fen Fei Yang Univ. of Pennsylvania Univ. of Pennsylvania Philadelphia, PA Philadelphia, PA ABSTRACT Abstract: Computer graphics has recently become steadily more applicable for use in technological devices and entertainment. Along with that development, virtual crowd simulations have become increasingly popular and necessary to successfully create realistic movies, video games, and training simulations. An important component of designing a realistic population simulator is to incorporate automobiles, traffic, road networks, and the associated rules which allow those vehicles to properly interact with pedestrians and other vehicles. Many traffic simulators currently exist independently of a crowd simulator with human agents. The goal of this project is to design a traffic simulation system that can be incorporated into an existing crowd simulation system, full scale 3D model city, and road network. Currently the crowd simulator does not include vehicles, and is therefore not entirely realistic. By including a traffic simulation the environment will gain another level of detail and realism. 1. INTRODUCTION Interaction with objects, places, and other people is a fundamental piece of human life. Every day is defined by the interactions that we make with the world around us. These interactions often go unnoticed, and many decisions or actions we take are autonomous and automatic. Many of the people that we pass each day, or locations that we move through, are hardly registered in our minds, but instead provide a fluid and dynamic background. While these events might not have a direct impact on our lives, they are a fundamental piece of our interaction with the world. If we try and picture a world where this extraneous background activity was absent, and nothing dynamic happened outside of what we directly interact with in our lives, the world would be a very monotonous place. Recent software has been used to simulate this interaction with human terrain, all of the action and life of people, vehicles, and objects that goes on unnoticed in the background of a location. These simulations provide feasible background environments for any virtual world space. These virtual crowds have become popular and necessary to create realistic movies, video games, and training simulations. An important piece of this human terrain is vehicle traffic and interaction with automobiles. People drive in vehicles to achieve locomotion goals, cross streets in towns and cities where they must be aware of traffic, and occasionally use vehicles for sports and events. In current crowd simulators that are built with a road network, any absence of vehicles is extremely noticeable. Many traffic simulators currently exist independently of a crowd simulator with human agents. The focus of this project is to design a traffic simulation system that can be incorporated into an already existing crowd simulation system, city, and road network. By building a traffic simulator, the simulation environments gain an additional level of detail and realism, and are more likely to be incorporated into future devices that require accurate and intelligent automated backgrounds. This paper first discusses past work related to vehicle simulation, then highlights the system model for the vehicle and traffic simulator. Next, the implementation of key components of the system is explored, along with justification of various design decisions. Finally, the paper concludes with a summary of the system s performance, a discussion of the ethicality of the project, and comments on potential future work. 2. RELATED WORK As interest in simulating individual people and crowds has grown, simulating traffic and vehicles to accompany those human interactions has become crucial. Traffic simulation has become an important development, helping city planners design roads that do not congest traffic or cause accidents. With current commercial software like VISSIM [9], simulations have been made easier. VISSIM can simulate complex dynamic systems such as traffic using a block diagram language that simplifies developing specific simulations. Cramer et al. [5] simulated the individualized behavior of autonomous cars. In the simulation, all of the cars correctly obey the laws of physics, such as acceleration and braking. Every car has some personality traits mimicking those of real drivers, such as how aggressive the car is, how attentive the car is to its surroundings, and how law-abiding the car is to traffic rules. Simulation of individualized agents is commonly referred to as a microscopic model of traffic (Fig. 1). On the opposite end of the spectrum is the macroscopic model of simulation. Sewall et al. [8] used a continuum based macroscopic model to simulate traffic. They focus on a large scale system where traffic can be simulated in real time. The model correctly handles lane changes, merges, and also changes in driving behavior due to changes in speed limit. This method demonstrates how a macroscopic model can be applied so that animating a great number of vehicles in a large-scale traffic network runs in an interactive rate. All of the cars in the simulation are described by a single

2 Figure 1: Example of Traffic Control From [5] computational cell that dictates each car s actions. Both of these systems simulate traffic, but do not include any human agents. Multiple systems have been developed that specifically focus on realistically visualizing crowds and human interactions, such as Heisenberg [3] or CAROSA [2]. Within these crowd simulations are virtual humans that each have specific sets of actions, goals, and responses to events. An interesting challenge faced when designing a traffic system for a crowd simulator is correctly implementing the necessary interactions between the human agents and the vehicles. Examples of this include behaviors such as a person getting on or off of a bus, or a driver parking a car and then getting out. As better traffic simulations are used to help plan cities, research on these simulations has taken on other purposes. One such example is the work done on creating believable traffic in entertainment such as video games. XaitTraffic [11] is one of the most sophisticated traffic simulations in computer games. It focuses less on the overall city traffic flow, but on the main cars in action on the computer screen. The cars in focus are completely simulated with actions such different driving maneuvers, drifts, and crashes. The simulation is extremely advanced, but is only limited to a small area of interest. Such a sophisticated simulation would generally not be used for large-scale crowd simulation projects. In some recent work, Jan Krassnigg [7] worked on a masters thesis about pedestrian and traffic simulation in a virtual city environment. He constructed a virtual model of Aachen in Germany, and created crowd and traffic simulation for the city. The traffic is done by creating roadmaps from the virtual city data and each car follows the same behavioral pattern with some randomness. The simulation is designed to handle large numbers of vehicles at once in a realistic manner without accounting for more intricate details. The cars all react to situations in the same way, with no differentiation between any two cars in the simulation. Possible expansion on such a simulation would be to add the implementation of different vehicles. Examples would be buses that follow a set route and pick up pedestrians, or private cars that drive through the city and eventually park. As the simulation of traffic becomes more complex, processing speed becomes an issue. Anthony Chronopoulos et al. [4] worked on a traffic simulation that used parallel processing. Chronopoulos used a macroscopic continuum traffic model which is based on traffic density, volume, and speed to simulate freeway traffic, which is very useful in applications such as highway safety and driver guidance in highly dense traffic. Because the system maps the simulation to a parallel computer architecture, it is capable of simulating highway traffic flow in real time. The use of parallel processing greatly increases the simulation speed such that a two hour traffic flow simulation that takes 2.35 min on a single processor only takes 5.25 seconds on the parallel traffic system. When combining crowd and vehicle simulations, processing speed is not as much of a concern, since the simulation occurs in the background and real time visualization is not necessary. Recent work done by Jur van den Berg et al. [10] of the University of Carolina attempts to simulate traffic through real world data and animate the events between time periods. The basic idea is for sensors in the real world, currently located in Chapel Hill, NC, to take sample data in time intervals. The simulation will take that data, analyze the position of the cars between samples and create a simulation of the car moving from one location to another using traffic simulation. It reconstructs the movements of the car while minimizing lane changes, keeping a safe distance from other cars, and smoothing the overall traffic. The whole simulation works in real time, allowing the user to see virtualized traffic of the real world. 3. SYSTEM MODEL This project involves designing a traffic simulation system, which includes vehicle dynamics, direct interaction with a road network, and incorporation of traffic rules. The overall benefit of designing this system will be to add a necessary component of detail and realism to an already well established, functional, and realistic human simulator. This combined simulation can then be used as a highly realistic backdrop for any type of virtual world. The primary function of the system is to take as input a road network, generate dynamic vehicles based on that network data, and display the simulation in an accurate way. The road networks are obtained from CityEngine, a 3D Modeling program used to generate procedural cities and road networks. An example of one such generated city can be seen in Fig. 2. Once the road network is received by the simulation, the system generates an internal data structure to store the road data. Simulated vehicles are then created specifically mapped to exact locations obtained from the road data structure. When the simulation begins, predetermined algorithms determine the actions taken by each vehicle along the roads they have been assigned to. Finally, the positions of each vehicle are smoothly animated in a designated display, which includes making turns, accelerating and decelerating to account for additional cars and avoid collisions, and stopping at traffic lights. The most important piece of the system is the simulation codebase. The simulation code has at its core a road network data structure, constructed from CityEngine data, which monitors every vehicle s current position on the streets. There is also a global list of all vehicles currently being simulated. Each vehicle stores its currents position, direction, and velocity. The simulation can be updated, a process which, when executed, moves all of the vehicles one step forward in time. After the simulation connects to a display, the display can easily access both the road network data structure and

3 ter the update, the display iterates over the list of vehicles and redraws them at their current positions. This process continues until the simulation is closed. The system is currently implemented in both 2D and 3D environments. The 2D implementation launches a very simple display created with OpenGL, primarily used for the development and testing of the simulation codebase. The 3D system is integrated with the Unity game engine, and will eventually be coupled with the Heisenberg crowd simulation, in order to place the traffic simulation inside a modifiable, full scale, 3D city environment. Both the 2D and 3D systems utilize the same basic simulation codebase and framework. However, the 2D system utilizes OpenGL as its display, depicted in Fig. 3, while the 3D system uses a full game engine, Unity, depicted in Fig. 4, in order to incorporate the 3D city model from CityEngine and any crowd simulator. The Heisenberg crowd simulation system cur- Figure 2: City Engine Example City the list of vehicles. From these lists, the current location coordinates in CityEngine world space can be retrieved for each street and vehicle, which can subsequently be used to draw the objects on the screen. When a display update occurs, a call is made to the simulation to update all of the vehicle positions. This update process takes into account for each vehicle whether it is turning, stopped at a traffic light, or moving among other vehicles, and then calculates the appropriate new location based on those factors. Once all of the vehicles have been updated by this process, the display can simply iterate over the vehicle list and redraw them in their new positions. Because the simulation update is called whenever the display updates, the system animates smoothly. Fig. 3 visualizes this model. Figure 3: 2D Simulation Workflow The diagram illustrates the initial step of road network data being retrieved from CityEngine and the corresponding data structure being constructed. This data structure is then provided to the simulation codebase, where vehicles are instantiated and generated. Because vehicles are generated directly on specific roads in the network data structure, vehicle positions are computed relative to the roads they are traveling on. The vehicle position data is then sent to the display, and the vehicles are drawn. Next, the system enters an animation loop where the display sends requests to the simulation to update the positions of all vehicles. Af- Figure 4: 3D Simulation Workflow rently runs using the Unity game engine, and also obtains its urban environment from CityEngine. Because of these similarities, it is simple to add the vehicle simulation system into this workflow as well. Once incorporated, the game engine simply queries the vehicle simulation system for updated vehicle positions to display, along with calls to the crowd simulation system for updated pedestrian positions. The game engine handles the display of both simulations simultaneously, and renders full 3D models for the city, pedestrians, and vehicles instead of simple OpenGL primitives. Fig. 5 depicts this combined workflow. The left half of the pipeline is the same vehicle simulation model as developed and used in the Unity 3D system (Fig. 4), with the difference being the addition of the crowd simulation codebase and human agents. Data from CityEngine is sent to the crowd and vehicle simulation systems concurrently, allowing the positions of all people and vehicles to be generated in reference to the city terrain and roads. All position data is then received by Unity, which updates the positions for each object and renders them to the 3D display. Unity then enters into a loop with both simulation codebases, requesting updates for both vehicle and pedestrian locations from their respective systems, and continually retrieving updated lists of positions. The display is then updated by iterating over these lists of vehicles and pedestrians and redrawing each entity. Interactions between vehicles and human agents are handled dynamically by the game engine, since it stores data on every object s location and controls the events broadcast to the world. 4. SYSTEM IMPLEMENTATION The traffic simulation system code is written in C++. The 2D system display is generated using OpenGL, while the

4 Figure 5: 3D Simulation Workflow Including Crowd Simulation System Figure 6: City Engine Road Network 3D system is run and rendered using the Unity game engine. The simulation system was implemented in two pieces, a simulation codebase and a display layer, and each piece has multiple components. Implementation history has been recorded on a blog for reference and development progress tracking [12]. 4.1 Simulation The key components of designing the simulation codebase can be divided into generating the road network data structure, creating the vehicles, controlling vehicle movement, implementing and controlling traffic lights, and preventing collisions Road Network The road network data is received from the CityEngine program. In any generated city, one can choose to view only the road network and then easily select all of the street edges, as seen in Fig. 6. Each street contains a vertex pair, and adjacent streets will contain the same vertex data. CityEngine has an option to export graph data into a Drawing Exchange Format (DXF) file. DXF files are human readable and are composed of pairs of codes with associated values. There are multiple tables and documents online that explain each code s meaning and its potential values, particularly published by Autodesk [6] and AutoCAD [1]. After exporting the file and correctly identifying the codes which define the street edges, the file is parsed. As the DXF file is parsed, streets are added to the network dynamically. The network also immediately updates its current streets to reflect any new additions. In this way, when parsing is completed the entire street network is formed and correctly connected. The network is also an identical copy of the original found in CityEngine, as seen by comparing the simulation display of the network in Fig. 7 to its representation within CityEngine in Fig. 6. Each pair of vertices that define a street is placed inside a Figure 7: Full Road Network as Displayed in Simulation System street object. Every street object contains references to all of the streets connected to each of its two vertices. Streets are also broken down further into two edge objects, which represent the directions that a vehicle could travel on that street, one for each lane. One edge will travel from V 0 to V 1 while the other edge will travel from V 1 to V 0. This implementation was used so that vehicles could be traveling specifically on one edge, instead of a street in general. This design allows for effective replication of two way streets with different lanes, prevents vehicles from overlapping one another in the simulation, simplifies checking for collisions, and reduces the amount of searching done to discover which vehicles are close in proximity. In its current state the simulation code does not account

5 for any highways or one way streets; every road in the simulation is a simple two-way street. The DXF file exported from CityEngine does not contain any parameters relating to lane width or number of lanes for the roads, so this information was not available for use in the simulation. Generating random highways throughout the road network would not be realistic, and would also have a high performance cost, so the design decision was made to make every road function identically at this time Vehicles After the street network is formed, vehicle objects are created and randomly assigned to edges, along with their respective streets. Because the road network is implemented as a list of streets, each containing two edges, the street can be chosen randomly by selecting an arbitrary list index. Every new vehicle is added to a global vehicle list. Each vehicle also contains a reference to the edge and street that it is currently driving on, and vice versa. In this way, there does not need to exist a global map of which streets contain which vehicles, which would require an immense amount of memory to store, and an infeasible amount of time to search through and update. After a vehicle is designated to a particular street, it is given a direction by random selection of one of the street s two edges. After the edge is chosen, a simple identification of any point between the two edge vertices gives the vehicle its starting position. A small offset in the direction perpendicular to the edge is used in order to separate vehicles on the same street and give the illusion of vehicles driving in distinct lanes. This also allows all vehicles to properly obey the rule of driving on one side of a road. Because these computations take place whenever a vehicle is instantiated on a given street, at its moment of its creation it immediately has a calculated position and direction. Base speed is provided for all vehicles by a global time step constant, retrieved from the user interface or game engine, which is then modified on a per vehicle basis to simulate acceleration and deceleration. Because the vehicle positions are computed directly from the road network data received from CityEngine, the world space coordinates for the positions in the simulation directly correspond to the coordinates in CityEngine world space. Therefore, the simulation system can easily function in the full 3D CityEngine environment without modifying or scaling any vehicle positions Movement Every vehicle has a current position, direction (given by the edge it is currently associated with), and speed. When an update call is made by the display function, the vehicle s updated position in the given direction is computed as a modifier of its speed and a time step constant. If the new position remains within the vertex boundaries of the current edge, the position is updated and returned. However, if the computed position is a location beyond the edge s end vertex, the vehicle must choose to move on to a new street. In this way, the vehicles positions are always interpolations between the two street vertices, and they never leave the confines of the street edges. To simplify this procedure, as soon as a vehicle is placed on a street it checks which possible streets it could move to after overstepping its current street and randomly selects one. Because of this, whenever a vehicle s new position is seen to extend beyond the current street, the remaining distance is calculated and that distance is simply transferred to the new edge and traveled in that new direction. Once the vehicle switches to a new edge, its direction is also automatically updated to reflect the orientation of the new edge s vertices Traffic Lights After the street data structure is created, traffic lights are generated for the road network. Due to the complexity of creating traffic lights for any intersections, it was determined that only four way intersections in the road network would have traffic lights. The light generation algorithm searches through the global list of street vertices, which are the endpoints used in creating the streets themselves. Every vertex keeps track of the streets it belongs to, so a four way intersection can be found by location all vertices that contain pointers to four street endpoints. At each of these vertices, a traffic light is created located at that vertex s location. The light is then appended to a global traffic light list. Each traffic light data structure contains its position, two light signals, and two edge lists corresponding to the lanes that must obey the light s signals. Each light signal is either red, indicating that vehicles should stop, or green, indicating that vehicles should proceed through the intersection. These two lights signals are programmed to always be opposites. Therefore, if one light signal is green then the other must be red. Each of a traffic light s two light signals corresponds to two edges on opposite sides of the light and the intersection. Therefore, when a light turns green, vehicles positioned on the same street on either side of the intersection are allowed to move and turn. However, not every four way intersection has two perfectly straight roads that are perpendicular to each other. To find the most suitable edges to match together for one of the traffic light s signals when street shapes and angles are irregular, the angle between the edges of the intersection are calculated and used to determine the best potential matches. For every possible pairing of two edges in the four way intersection, the angle between them is calculated using the dot product operation and compared to the same calculation for all of the other pairs. The best match for a given street is to have the angle between two edges be exactly 180 degrees, implying that the edges are parallel and the connected street is perfectly straight. However, in most cases this is not possible, so the edges that form an angle closest to 180 degrees are chosen as one of the pairs and joined to a light signal. Then, the two remaining edges are assigned to the other light signal. To ensure the angle returned from the dot product calculation is always within a range of zero to 180 degrees, and that the direction of travel from one edge to another is always the same, the angle calculation uses the vertex incident on both edges as the endpoint of the line segments. Each edge that ends in a four way intersection contains a reference to a traffic light. The vehicles traveling along an edge check to see if a traffic light exists at the end of the edge. When they reach the end of the edge, the light signal for the edge is checked. If the light signal is green, then the vehicle s motion path is unaffected and it continues as normal. However, if the light is red, the vehicle s path is blocked at the end of the edge by the light signal. Therefore, the vehicle reacts accordingly and decelerates as it approaches the intersection.

6 4.1.5 Collision Prevention A key component of the vehicle simulation is the prevention of collisions. The simplest collisions are prevented between vehicles moving along the same street edge. Each vehicle has a certain amount of space in front of it reserved, generally computed to be proportional to the vehicle s current speed. When two vehicles are traveling along the same edge where the following vehicle is moving faster than the front vehicle, the former will smoothly decelerate until it reaches a location where the front vehicle does not enter its reserved space. In this way, a pre-determined constant following distance is always enforced between two vehicles through their reserved space. Fig. 8 depicts the use of this Figure 8: Reserved Space Algorithm Example algorithm. The single car has its set reserved space in front of it, but because there are no other vehicles that could obstruct its path it is able to accelerate and continue moving forwards. On the other hand, the two adjacent vehicles are traveling at the same speed. The vehicle in the back caught up to the vehicle in front, and when it could not proceed any further without having a conflict inside its designated reserved space area, it maintains a steady velocity. The reserved space ensures that a collision will not occur between these vehicles. When a vehicle approaches the end of an edge, it checks to see if any vehicles are already present on the street it will move on to after leaving the current street. This check is simple because every street contains a list of the vehicles currently on it. The vehicle seeking to move on to the street compares its position with that of the vehicle closest to it on the next street, if one exists. If the distance between them is greater than the reserved space amount, then it continues movement as normal. If, however, the distance is less than the amount of reserved space, the vehicle waits and does not move forwards until another update is called and the distance between them is increased. In this way, the constant amount of reserved space is still preserved between two vehicles during turns and collisions are avoided. Preventing collisions at intersections between vehicles traveling in different directions is a related but more complicated problem. Each vehicle has its designated amount of reserved space as described above. When a vehicle is moving along a road and reaches a point where its reserved space is greater than the remaining distance to be traveled on that edge, the edge that the vehicle will travel to next is flagged as occupied. This flag persists until the vehicle crosses onto that edge. With this flag implementation, whenever a vehicle approaches an intersection it checks the flag of the edge it will travel to next. If the edge is flagged, it is an indication that another vehicle is approaching and going to turn onto that street first. The vehicle stops before the crossing and waits for the flag to disappear, which indicates that no more vehicles are approaching, before continuing movement by checking reserved space as indicated earlier. In general, traffic lights also act to prevent collisions. Similar to real life, traffic lights control vehicles for each direction of a given street by restricting movement to only one side of the traffic light at any given time. In this way, collisions between vehicles located at a four way intersection are impossible when combined with the edge flagging system described above. One factor that was taken into account with the addition of traffic lights to the system along with the edge flags was the potential negative effect of creating a mini-deadlock. It was possible that one vehicle could obtain a flag for the next edge it wanted to move to, but would then be stopped at a red light. Since the flag was taken, although unused, other vehicles that had a green light but wanted to move to the same edge were unable to move because it remained flagged. This caused a temporary lock on some vehicles for one traffic light cycle until the vehicle with the edge flag received a green signal from the traffic light, continued travel, and ultimately released the edge flag. This problem was resolved by changing the edge flagging system so that vehicles would release their flags when stopped at red lights, which allowed other vehicles to continuing moving uninhibited. The edge flagging system and the traffic lights now work simultaneously and synergistically to prevent collisions at four way intersections. Even on intersections that are not four way, the edge flag implementation has proved effective for preventing collisions. Section 5 illustrates the overall progress made in decreasing collisions during the development of the system D Display For the 2D system, the display layer was implemented using OpenGL. Each street and vehicle object have specified OpenGL drawing parameters defined in a Draw() method. The display is included as one component of the overall UI, which is designed using FLTK. The UI contains options for controlling the camera location, number of cars, and global time step to modify the execution speed of the entire simulation. Additionally, the camera can be moved using keyboard input, allowing the user to pan around the scene as well as zoom in and out. The camera points in a fixed downwardfacing direction, and the orientation of the axes is exactly the same as CityEngine s coordinate system. An example screenshot of the simulation with animated vehicles, turning animations, and traffic lights can be seen in Fig Roads Roads are drawn as GL Quads. The four vertices for the quad are computed based on the two street vertices. These vertices are offset in the direction perpendicular to the line formed between the two vertices in order to create a rectangular road. The offset value is determined by a preset

7 compute and execute this turn properly, many steps must be taken. Fig. 10 illustrates the process. First, the intersec- Figure 10: Turning Animation Diagram Figure 9: 2D Simulation Display Example in OpenGL lane width constant. Because the street network is stable and does not change during animation, a display list is created for the street network during instantiation so that the streets do not need to be redrawn every iteration. Because the coordinate axes and up vector of the 2D display are exactly the same as those in CityEngine, the road networks are visually identical in each system See Fig. 6 and Fig. 7 above for an example of this similarity Vehicles Vehicles are drawn in the 2D display as simple cubes scaled to fit the road network dimensions. In the display, the vehicles are red boxes with green fronts. The small green piece was added to the front of each box so the vehicle s current direction could be easily identified. Whenever the display sends a call to the simulation to update the vehicle positions, it also makes a call to redraw the display. To update the positions of the vehicles each iteration, the display makes a call to retrieve the list of all vehicles from the simulation. The display then iterates over the entire list, calling the Draw() method on each vehicle. Because each vehicle contains the computations internally for where and how to draw itself, the process is extremely simplified and efficient. Vehicles also orient themselves at an angle specific to the street edge they are currently traveling on. This was accomplished by taking the dot product of the street edge vector and the X axis to compute an angle of rotation, which is then applied to every vehicle before it is drawn Turning Animations When any vehicle approaches an intersection with another street it enters into a special turning animation, separate from the normal functions that update location. The angle between the two streets is calculated, and from that angle a turning circle is defined. The vehicles then travel along the arc of the circle in order to turn smoothly. In order to tion between the vehicle s current and next edge, not street, is calculated. The distance from the start point of the turn and the end point of the turn to this intersection point is a fixed constant, labelled as x in Fig. 10. Once the intersection point is found, the turn start and end points can be easily computed by using this distance. The lines from the start and end points to the edge intersection point form vectors that are both tangent to the turning circle. Computing these vectors is simple, and once obtained it is trivial to find the parallel vector in the direction of the turning circle s center. At this point, the intersection point between these two vectors is found, which is exactly the center of the circle. By then calculating the distance from the start and end positions to the center, the circle s radius r is discovered. Now that the turning circle radius r is computed, the incremental position steps around the arc of the circle for the turn can be calculated. The total turn angle θ is found by taking the dot product of the street edges. The amount of the angle travelled per time increment is a function of the vehicle s current speed, the overall time step, and the radius of the circle. X = turncirclecenterx + r cos(currentangle) (1) Z = turncirclecenterz + r sin(currentangle) (2) Once all of these values are set, the new X position of any turn can easily be calculated from equation 1 and the new Z position from equation 2. The position of each turning vehicle will be updated in this manner until the current angle is greater than the total angle θ. At this point, the vehicle s current edge and street are set appropriately, all other values are reset, and movement along the next edge continues normally Traffic Lights Traffic lights are also displayed in a unique way in the simulation. For each traffic light at the four way intersections in the simulation, a group of four small GL Circles is drawn, representing the current light state on each of the four streets. The streets that are closest to being parallel with one another form the first pair of lights, while the remaining two streets form the second. The colors of each

8 pair of lights are linked together so they are always equal. When one pair of lights is green, the other will be red, and vice versa. The current light color is set by a simple boolean variable, which flips in the simulation after a certain number of update iterations have passed. Each traffic light is instantiated randomly so that the direction showing a red light is not the same throughout the road network. The lights also all start with a different number of counted updates, so that the lights do not all switch simultaneously User Interface The simulation display is incorporated inside of the FLTK user interface toolkit to allow for dynamic modification of the simulation. The UI currently includes functionality for controlling the camera, changing the number of cars being simulated, and increasing or decreasing the global time step of the simulation. Changing the time step directly affects both the speed of the vehicles and how quickly the traffic lights change colors. The UI is linked to the simulation codebase so any modifications to parameters in the UI are automatically and instantaneously reflected in the simulation D Display The Unity game engine is used to display the vehicle simulation in 3D. The simulation codebase was designed to function separately from the display. Therefore, the simulation codebase was compiled and compressed into a Dynamic Link Library (DLL) which can be imported into Unity. The DLL is defined with specific methods that give access to core functions of the simulation codebase. These functions are: Init, which takes in as parameters a CityEngine DXF file and the desired number of vehicles. Init then initializes the entire simulation by setting up the road network and creating all of the vehicles. GetStreets, which returns a list of street objects for every street in the road network. Every street object contains the positions of its four corner vertices, which are subsequently used to draw the road network in the 3D display. This is generally only used once during the initialization of the system. GetNumStreets, which returns the number of streets in the road network. This is also generally only used during the initialization of the system. Step, which causes the simulation to take one step into the future based on a provided time step. This step is calculated by updating all of the vehicle positions once. GetState, which returns a list of positions and directions for all of the vehicles in the simulation. Based on this DLL specification, Unity can easily set up and run the simulation by repeatedly calling the Step function and then retrieving the list of updated positions from GetState. Any 3D model can be specified as the vehicle, which is then replicated and rendered at all of the positions returned by simulation DLL. An example 3D display from Unity can be seen in Fig. 11. A crowd simulation system can be easily incorporated into this same scene in Unity by using a similar DLL design. Figure 11: 3D Simulation Display Example in Unity Including a crowd simulation DLL would enable Unity to make function calls for that system very similar to those used in the vehicle simulation. Unity could then simultaneously get updates and render objects at their new locations for both simulation systems. This would result in dynamic human agents also present in the same display as the vehicles. This simulation could ultimately also import and include the full 3D city model from CityEngine, resulting in the desired highly realistic and dynamic simulated environment. 5. SYSTEM PERFORMANCE Judging system performance for any simulation program is relatively difficult, because there are no simple ways of running quantitative tests to ensure correctness. Because the system is designed to function as a realistic replica of a road network and vehicle interactions, the optimal way to determine if the system is performing correctly is to visually compare the system to the real world. Currently, the system does not take into account all traffic laws when calculating vehicle positions, and is also lacking key components of real life travel such as highways and multiple lane roads. Because of these absences, the simulation is not yet identical to traffic. However, the development of the system has resulted in many features that do correspond very well to the real world. Vehicles travel smoothly on the road network without crossing over lanes or colliding. They also accelerate and decelerate at the appropriate times, such as speeding up when no other vehicles are present on the road and slowing down when approaching an intersection. Traffic lights switch on and off at realistic intervals, and vehicles react appropriately to the laws imposed by the lights at four way intersections. Finally, vehicles turn smoothly around corners and curves in the roads, moving faster for quicker hairpin turns and at a much slower pace for long drawn out curves. All of the visual tests that have been run for the currently implemented features have passed with successful degrees of realism, so up to this point system performance is as expected. Although overall realism of the system is difficult to determine by running empirical tests, the number of collisions that occur in the simulation can be monitored and recorded. By checking during each position update to see if any vehicle objects have moved too close to one another, a collision can easily be detected. As development of the system progressed, the number of collisions was tracked. To perform

9 the collision test on each iteration of the design, the simulation was run on the same specific CityEngine road network map with 10 cars for a period of exactly 60 seconds. The results of these tests can be seen in Fig. 12. The graph, plotted Number of Collisions (Log Base 10) Vehicle Collision Over Time Project Version Figure 12: Vehicle Collisions Over Time on a log scale, clearly shows that collisions have drastically decreased over time as the simulation has continued development. During the first implementation of the system, cars were not placed on distinct edges, so the collision count is extremely high. Once cars moving in different directions are separated on their respective streets, the numbers drop considerably and vary from a few hundred collisions to a minimum at 90. Iterations four and five of the system were the first to include turning animations and traffic lights at intersections. Before all of the bugs were solved and these features were perfected, there was an increase in collisions as cars turned at the same time, took incorrect turning paths, or decided to disobey red lights and drive through intersections. However, it can be concluded from this graph that collisions in the most recent versions of the system are the lowest of the entire development process. Therefore, by this experimental test of system performance, the simulation has been consistently improving over time. 6. ETHICAL ISSUES One potential ethical issue that could occur during use of the traffic simulation system is if a user decides to import and run a simulation on proprietary street network data from CityEngine without consent of the creator. While this could be done in theory, as there are no privacy settings or checks on the imported DXF file, CityEngine is designed to procedurally generate cities so the possibility of copyright concerns being raised is minute. Additionally, even if this were to occur while using the simulation system, the use of proprietary data is not inherently connected to our system in any way. Therefore, this possibility is not an ethical concern for the simulation. Overall, the traffic system is more or less risk free for the user. The system does not ask for any personal information from a user, and does not record any data about the users simulation. It also does not require nor retrieve information from the users computer while the simulation is running. As there is no private data associated with the program, it is impossible to share or publish any information that could harm the user. Additionally, the using the simulation does not require any network connection and is completely selfcontained. The program is also incapable of manipulating or running other software and runs independently of other programs, excepting the programming and display libraries it utilizes. A final ethical discussion could be raised concerning the simulation traffic corresponding to drivers or traffic patterns in the real world. Recording and using the driving styles of real people without their consent definitely poses an ethical problem, because those people may not necessarily be comfortable with information about their driving habits being used in a simulation. However, in the traffic system the movements of the vehicles in the simulation are not based on any specific real world drivers or traffic movement. The vehicles in the simulation determine their movements randomly. Because the system does not utilize real world data, it does not invade anyones privacy. The ultimate goal of the traffic simulation is to create a more realistic environment and background for existing crowd and other simulations. These systems are primarily designed for research and use in academia, and do not attempt to interact with users on a personal level. Once all of these points are considered together, the simulation system can be seen as very ethical and safe to run. 7. FUTURE WORK The basic functionality of the system is in place, and all of the fundamental components of the simulation are working as intended. However, there are still many improvements and additions that can be made. The highest priority task for continuing the project will be to integrate the 3D display from Unity with the crowd simulation system and the full scale 3D city environment. The crowd simulation system the vehicle simulation will most likely interact with is called Heisenberg and is described by Badler et al. [3]. The system that Heisenberg was built on top of, called CAROSA, described in detail by Allbeck et al. [2], creates multiple smart human agents that have pre-defined actions that occur when events are broadcasted to the world. By combining the vehicle simulation system with the Heisenberg system, which incorporates this agent structure, the vehicles will also be agents. Proper integration will therefore require converting each vehicle to be an agent. Additionally, vehicle interaction with the pedestrian agents must be implemented to enable unique actions, such as getting in a car and utilizing it to complete locomotion objectives. The combined simulations need to handle clever traffic laws and integrate easily with large populations of people. Luckily, because both the Unity game engine and the crowd simulation system already have in place abilities to properly handle agent interaction and display, for example not drawing and using resources on any agents that are not currently being displayed, this should be simple to extend to the vehicles to provide increased performance and efficiency. Additional improvements will also be made to the simulation codebase and associated displays as necessary. In the current 3D environment, the vehicles are represented by simple cubes and cylinders with a basic texture map. An obvious next step to give heightened realism is to purchase or create multiple 3D models of vehicles to use instead. In this way, multiple styles of vehicles could be present in the simulation. This could also correspond with vehicles as agents, because then different classes of vehicles would have distinct 3D models. Also, in its current state the simulation code does not account for any highways or one way streets;

10 every road in the simulation is a simple two-way street because highway data could not be retrieved from CityEngine. Generating random highways throughout the road network would not be realistic, and would also have a high performance cost, so the design decision was made to make every road uniform. If a possible method of acquiring additional data specific to highways or other types of roads is discovered in the future, adjustments can be made to include them in the system. On a related note, all of the roads in the 2D and 3D environment have a uniform width as set by a constant lane width parameter. The simulation code generates vehicle positions based on the street vertices with a small offset to account for lane separation. However, in the 3D CityEngine environment almost all of the roads have differing widths. Therefore, it is possible that when the simulation codebase is used to generate vehicles and their positions in the 3D city, the vehicles could be located offset from the center of the designated lane on the roads (ex: on sidewalks, or too close to the road median line), causing visual discrepancies or collisions. If this problem occurs, work will need to be done to account for these varying street widths. 8. CONCLUSION Ultimately, the goal of designing a realistic traffic simulation system has been achieved in compliance with the original project proposal. The developed system is a fully functional traffic simulation that runs in both 2D and 3D environments. The program is able to receive as input a data file from CityEngine, extract street information, and generate a full road network for use in the simulation. The system constructs an internal data structure for both the street map and the vehicles which are directly connected to those streets. The coordinates used in the traffic simulation are exactly the same as those in the CityEngine world space. Therefore, the simulation can be easily adapted to any crowd simulation system that utilizes the same city model. The vehicles move along the streets in realistic ways and obey basic traffic laws. Every vehicles movement is determined by an algorithm based on the equations of motion which calculates speed, acceleration and deceleration. The vehicles turn smoothly from the edge of one street to another by traveling along the arc of a calculated turning circle for a specific angle amount. The implemented collision prevention algorithms keep vehicles from running into each other by utilizing methods such as reserved space, edge flagging, and traffic lights. One of the highly successful design decisions for the project was to keep the display layer and graphics components separated from the simulation codebase. This separation greatly facilitated importing the traffic simulation into different visual programs such as an OpenGL 2D display and a 3D display in the Unity game engine. The resulting system is a realistic traffic simulation that can be easily displayed and incorporated into any game engine or other simulation program. Control, volume 8 of Synthesis Lectures on Computer Graphics and Animation. Morgan and Claypool Publishers, [3] Norman I. Badler and Ben Sunshine-Hill. Perceptually realistic behavior through alibi generation. In Conference on Artificial Intelligence and Interactive Digital Entertainment (AIIDE), [4] A.T. Chronopoulos and C.M. Johnston. A real-time traffic simulation system. IEEE Transactions on Vehicular Technology, 47(1): , February [5] James Cremer, Joseph Kearney, and Peter Willemsen. A directable vehicle behavior model for virtual driving environments. In Conference on AI, Simulation and Planning in High Autonomy Systems, [6] Autodesk Inc. Ascii dxf files. acad2000/dxf/ascii_dxf_files_dxf_aa.htm, [7] Jan Krassnigg. Interactive pedestrian and traffic simulation in a virtual city enviornment. Master s thesis, University of Aachen, [8] Jason Sewall, David Wilkie, Paul Merrell, and Ming C. Lin. Continuum traffic simulation. EUROGRAPHICS, [9] Visual Solutions. Vissim [10] Jur van den Berg, Jason Sewall, Ming Lin, and Dinesh Manocha. Virtualized traffic: Reconstructing traffic flows from discrete spatio-temporal data. IEEE, [11] Xaitment. Xaittraffic. xaitment-generated-traffic-gets-the-thumbs-up-39. html, [12] Fen Fei Yang and Joe Weinhoffer. Vehicle traffic simulation REFERENCES [1] AutoCAD Dxf reference. http: //images.autodesk.com/adsk/files/acad_dxf0.pdf, [2] Jan M. Allbeck, Norman I. Badler, and Nuria Pelechano. Virtual Crowds: Methods, Simulation, and