Topic: - Indian urban pattern of life representations ...

Indian urban pattern of life representations – the challenges and solutions; using AI.implant to simulate traffic behaviors in Indian urban areas Ankur Mour, IIT Bombay, [email protected]

Abstract: The paper explores the challenges and the possible solutions in the representation of the Indian urban traffic. The aim was to develop a realistic agent – centric road traffic behavioral simulation model for Indian Urban terrain. A COTS AI middleware produce PRESAGIS AI.implant Version 5.6 was used to this end. AI.implant is a multi-platform Artificial Intelligence (AI) authoring and runtime software solution for populating simulations and training applications with computer controlled characters. All the possible entities involved were listed along with the rules that govern the behavior of each entity. All the obstacles that could possibly hinder their movement were evaluated and several assumptions were made regarding the entity’s response to its environment as well as to external stimuli. Once the Road Traffic Simulation model was completed, validation was carried out in the form of Sensitivity Analysis Test. Two possible runs were selected – Time taken by the Bus to complete its run from the start to the last bus stop and Time Taken by a pedestrian to move from one corner of the NavMesh to the opposite diagonal corner. Different experiments were also carried out within the model.

Keywords: Urban Traffic, Indian Traffic, AI.implant, AI Middleware, Modeling and Simulation, traffic Behaviors, NavMesh

1

List of Figures Figure 1 – Types of Simulation in Transportation ………………….…………………….7 Figure 2 – AI.implant Explorer Window and AI.implant Visualization Window respectively………………………………………...………,,,..…12 Figure 3 – The Vehicle template Components and Decision Tree……………. ………..17 Figure 4 – Screenshot of the City Block Navigation Mesh……………………………...20 Figure 5 – EntranceStats.csv File. ………………………………………………………21 Figure 6 – ExitStats.csv File…………………...………………………………………...22 Figure 7 – Screenshot of the Traffic Simulation………………...……………………….24 Figure 8 – Number of Vehicles vs. Time Taken………………………………..……….26 Figure 9 – Rule-following Probability vs. Time Taken………..………………………...29 Figure 10 – Traffic lights Cycle vs. Time Taken…………….………………..…………31 Figure 11 – Threshold Frustration vs. Time Taken……………………………...………32 Figure 12 – Maximum Speed vs. Time Taken………………………………………...…34 Figure 13 – Time of the Day vs. Time Taken……………….………...…………………35 Figure 14 – Traffic Lights Cycle vs. Time Taken……………………………………….37 Figure 15 – Time of the Day vs. Time Taken (2)………………………………………..39 Figure 16 – Maximum Speed vs. Time Taken (2)…………….…………..……………..41 Figure 17 – Number of Pedestrians vs. Time Taken…………...………………………..43 Figure 18 – Number of Cycles vs. Time Taken (2)…… ………………...…...…………45 Figure 19 – Number of Vehicles vs. Time Taken (2)……… …………………...………47 Figure 20 – Stop Probability (others) vs. Time Taken ………………….………….……49 Figure 21 – Traffic lights Cycle (10 seconds base) vs. Time Taken…………………….51 Figure 22 – Traffic lights Cycle (15 seconds base) vs. Time Taken…………………….52

2

Figure 23 – Traffic lights Cycle (20 seconds base) vs. Time Taken…………………….52 Figure 24 – Breaking Point……………………….……………………………..……….54 Figure 25 – Chaotic Intersection Point…………………………………………………..55 Figure 26 – World without rules…………………………………………….…..……….56 Figure 27 – Response to Monster……...…………………………..……….……………59

3

List of Tables Table 1 – Number of Vehicles vs. Time Taken………………….………………………26 Table 2 – Confidence Intervals for Table 1……….……………………………………. 26 Table 3 – Rile-following Probability vs. Time Taken…...………………………………28 Table 4 – Confidence Intervals for Table 3……………………………..……………….28 Table 5 – Traffic lights Cycle vs. Time Taken…………………………..………………30 Table 6 – Confidence Intervals for Table 5………………….…………….…………….30 Table 7 – Threshold Frustration vs. Time Taken………………………….……………..32 Table 8 – Maximum Speed vs. Time Taken…………….……………………………….33 Table 9 – Confidence Intervals for Table 8……………………………………………...33 Table 10 – Time of the Day vs. Time Taken…………………………………………….35 Table 11 – Traffic Lights Cycle vs. Time Taken…………………………..…………….36 Table 12 – Confidence Intervals for Table 11……………………………...……………37 Table 13 – Time of the Day vs. Time Taken (2)……………………...……... …………38 Table 14 – Confidence Intervals for Table 13…………………………...………………38 Table 15 – Maximum Speed vs. Time Taken (2)……………………...…….. …………40 Table 16 – Confidence Intervals for Table 15……………………...……………………40 Table 17 – Number of Pedestrians vs. Time Taken…………….………………………..42 Table 18 – Confidence Intervals for Table 17………………...…………………………42 Table 19 – Number of Cycles vs. Time Taken (2)… …………………………………...44 Table 20 – Confidence Intervals for Table 19………...…………………………………44 Table 21 – Number of Vehicles vs. Time Taken (2)………………………. …………...46 Table 22 – Confidence Intervals for Table 21………..…………………….……………46

4

Table 23 – Stop Probability (others) vs. Time Taken …………….……………………..48 Table 24 – Confidence Intervals for Table 23…………………………………………...48 Table 25 – Traffic lights Cycle (10 seconds base) vs. Time Taken………..…………….50 Table 26 – Confidence Intervals for Table 25……………………………...……………50

5

1. Introduction Before we start with the challenges and descriptions involved with the representation of the road Traffic Simulation for Indian Urban areas, there are some critical questions that need to be answered. They include – 1. Why is there the need for Traffic Simulation in the first place? 2. What is the existing traffic simulation models used worldwide? 3. Which elements characterize Indian traffic scenario and how it deviates from its western counterparts? 4. Which is the best software tool for this purpose?

1.1. Why traffic Simulation? The first question that arises is – What is the need of simulating road traffic in the first place? To answer this, we must first digest the fact that within 30 years, assuming current trends continue, the number of motor vehicles in world will have doubled to a staggering 1.2 billion. Of course this figure is World wide, but the number of cars expected to be on the road in India is no exception to this rule. Traffic simulation can be used to study traffic theory and assess network infrastructure and control changes without costly infrastructure changes. Traffic simulation can be implemented using agent-based modeling (ABM), which enables dynamic objects such as vehicles to be modeled individually. This enables the analyst to have control over their behavior. The main objectives include gaining an understanding of traffic theory, learning the major features and issues of traffic simulation, and evaluating agent-based modeling as a means of simulating traffic. Simulation in transportation is important because it can study models too complicated for analytical or numerical treatment, can be used for experimental studies, can study detailed relations that might be lost in analytical or numerical treatment and can produce attractive demos of present and future scenarios. Another important application is to observe the traffic trends in case of emergency scenarios like terrorist attacks, explosions and mass evacuations. 1.2. Existing Models There are perhaps hundred of Road traffic Simulation models currently available. Although many of them are commercially available, most of them have been designed for use on specific research tasks. Some of the important models include 1 TransCAD, PCDYNEV, EVACNET4, Cube Avenue, Simulex, TRANSIMS, VISSIM, SimTraffic, Paramics, MITSIMLab, DYNASIM, AIMSUN II, and HUTSIM among many others. Traffic simulation models are classified according to discrete and continuous time, state, and space.

6

Figure 1 – Types of Simulation in Transportation2

The simulation tools are generally classified according to their level of granularity: macroscopic, mesoscopic and microscopic (Williams, 1997). In this section, we will give a brief overview of these tools:1.2.1. Centralized approaches for traffic simulation The original models for traffic flow were mathematical, and utilized car-following laws, which are, in fact, differential equations that are obtained empirically through regression using data collected at currently operating road sections (Lieberman and Rathi, 1997). Even most current microscopic simulations, model in-line driving using the car-following law and intersections are managed using centralized scheduling techniques. A centralized scheduler makes decisions for each vehicle, similar to a policeman who lets the vehicles enter the intersection only when their trajectories are not in conflict. However, using car-following laws and scheduling techniques has several limitations. Mathematical approaches are not and cannot be generic. Let us elaborate on this. Since the designated car-following laws are obtained from measurements taken on existing roads, the resulting equations will be linked to the characteristics of the actual road section (length, number of lanes, road markings). Secondly schedulers are inappropriate for studying the phenomena inside the intersection and the simulated behaviors of individual drivers produced by schedulers are not always realistic. As a result, many

7

traffic phenomena like traffic backup between intersections, traffic signals violation and traffic congestion inside the intersection etc. cannot be simulated. One way to get around these limitations is to use behavioral approach to decentralize traffic simulation. 1.2.2. Behavioral approaches The behavioral approach, in contrast to the mathematical approach described above, considers traffic as an emerging phenomena resulting from actions and interactions of the various traffic system actors (e.g., car drivers, pedestrians, road operators). This behavioral approach aims to accurately model and reproduce the behaviors and interactions of the simulated entities in order to obtain realistic traffic phenomena. So the distribution of behaviors among the set of simulated entities will dictate the realism of the emergent traffic. 1.2.2.1.

Cellular automata approaches

More than a decade ago, models were being developed, based on the cellular automata programming paradigm from statistical physics. The main advantages of this approach include an efficient and fast performance, when used in computer simulations, due to their rather low accuracy on a microscopic scale. These so-called traffic cellular automata (TCA) are dynamical systems that are discrete in nature, in the sense that time advances with discrete steps and space is coarse-grained. This coarse-graininess is fundamentally different from the usual microscopic models, but this is aimed at obtaining a correct macroscopic behavior through their crude microscopic description. TCA models are flexible and powerful, in that they are able to capture the first- and second-order macroscopic effects that occur in traffic flows as shown by Chowdhury et al (2000). Nevertheless, using a grid to represent the environment is too limited to correctly render the dynamics of traffic situations at intersections. In fact, discretizing the driving area leads to discretizing vehicle speed, thus allowing only finite speeds like: 0, 25 and 50 km/hr. 1.2.2.2.

Robotics-inspired approaches

Modeling of traffic behavior has been also examined from a robotic point of view. Some computing-based models have been proposed by robotics specialists, with the objective of creating a robot capable of evolving with the road traffic, first in simulation and then in reality. For instance, Reece and Shafer (1993) proposed a case-based reasoning model. Although the resulting model behavior is appropriate for a robotic context, i.e. it is able to drive safely without causing any collisions, it is not really appropriate in the traffic simulation context since the model is not able to recreate all the individuality of real driver behavior. 1.2.2.3.

MAS approaches

8

In the traffic simulation literature, a couple of models, which provide a real alternative to classic traffic simulation models, are popular. Trannois et al. (1998) proposed an adaptation of the well-known blackboard system for planning the actions of agents evolving in an urban environment. The key differentiator of this approach was in the model of the environment and the distribution of the knowledge about the driving task. This knowledge was not integrated into each agent’s strategy but instead distributed among the entities on the road infrastructure. So a yield sign would bring the knowledge needed to cross the intersection to the attention of the different agents. Still, even in this method, the driver behavior is still connected to the road infrastructure. The second one was proposed by Paruchuri et al. (2002), introduced a model in which each simulated driver is autonomous, making its own decision using fine-tuning parameters (e.g., autonomous braking power, maximum braking power, autonomous acceleration, maximum acceleration, minimum inter-vehicle gap, overtake margin). These authors claim that their model allows realistic driver behavior to be simulated. However, the autonomy of the agents is limited since some traffic situations must be supervised and controlled by an external centralized process. Hence, the aim was to develop a multi-agent model which would allow more accurate and realistic drivers’ behaviors to be simulated in a dynamic environment. 1.3. Indian Scenario The Road traffic in India can be primarily classified as unorganized and heterogeneous. The same road space gets used by cars and buses, along with locally developed vehicles for public transport such as three-wheeled scooter taxis, scooters and motorcycles, bicycles, tricycle rickshaws, animal and human drawn carts. Hence infrastructure which is designed on the basis of homogeneous traffic models fails to fulfill the mobility and safety needs of this traffic. Organized traffic with drivers heeding to well-defined traffic rules is less dynamic and erratic, than modeling unorganized traffic, wherein the drivers either do not heed to the traffic rules, or there are no traffic rules in place. Needless to say, the traffic scenario in India tends more towards the unorganized side. There had been a number of attempts to model the flow of traffic of a fairly homogeneous nature and study the flow characteristics. These studies have been conducted under relatively homogeneous traffic environments, and hence the results are not directly applicable for heterogeneous traffic conditions. On most of the urban roads in India, the traffic consists of an unsegregated flow of different types of vehicles. A review of the literature shows that only limited studies have been done to develop an understanding of traffic flow under non-lane based heterogeneous traffic conditions. Marwah and Singh (2000) did simulation studies of traffic flow on urban roads in Kanpur City, India using a two-lane one-way traffic simulation model. Chandra (1997) developed empirical models to study urban heterogeneous traffic. Badrinath (1993) studied mixed traffic flow on one-

9

way urban roads, grouping two and three-wheelers together. Ramanayya (1988) developed simulation models to depict mixed traffic flow on single-lane one-way, twolane one-way, and two-lane two-way traffic roads. Khan and Maini (2000) studied the models of heterogeneous traffic flow, and Maini and Khan (2000) analyzed the discharge characteristics of heterogeneous traffic at signalized intersections. Faghri and Egyhaziova (1999) developed a microscopic simulation model (BICSIM) for mixed vehicle and bicycle traffic on urban roads. Nagaraj et al. (1990) investigated the linear and lateral placement of vehicles in mixed traffic environment to develop models of mixed traffic flow. These studies, though intended for simulating heterogeneous traffic flow, are either based on simplified assumptions or not validated over a wide range of traffic existing on urban highways. Because of these inadequacies, the models cannot be used for a comprehensive study of mixed traffic flow characteristics. Hence, this study aims at development of an appropriate traffic simulation model to replicate heterogeneous traffic flow conditions to comprehensively study the traffic characteristics. 1.4. Software It was a tough job to come up with the best tool for this purpose, as it is difficult to represent the spatial aspects of the Indian traffic flow that underlie many of the differences between traffic flow in an urban Indian city and that in a western city. However, after seeing the parallels that exist between the problem at hand and the Artificial Intelligence technology employed in the gaming industry, it was decided to proceed ahead with a COTS AI Middleware Product. AI middleware provides services for game engines for performing the AI function in computer games. It is mostly located outside the game engine and the process of producing the desired behavior of agents or non-player characters (NPC) or decisionmaking objects found in a computer game. AI Middleware offers several advantages• • •

The staff may not possess the AI expertise to develop the desired algorithms and processes. The project schedule may be tight with insufficient time to develop the desired level of AI for the game from scratch. It may contain the exact algorithms or processes that may achieve the desired level of AI.

After weighing the pros and cons of several COTS AI Middleware products currently available in the market, namely3 AI.implant, Direct IA, Render Ware AI 1.0 (RWAI), SimBionic, Autodesk HumanIK, Autodesk Kynapse, SpirOps, Navpower, Artificial Contender and PathEngine, the decision was made to go ahead with Presagis AI.implant version 5.6

10

2. Presagis AI.implant Version 5.6 AI.implant4 is a multi-platform Artificial Intelligence (AI) authoring and runtime software solution for populating simulations and training applications with computer controlled characters—including people and vehicles. AI.implant gives simulated characters the intelligence to make advanced context-specific decisions, and move in a realistic fashion within their environment (The next 5 pages are a modified extract from AI.implant Documentation) The tools in AI.implant include plug-ins for Autodesk 3ds Max and Maya, as well as the Artificial Intelligence Development Environment (AI.DE), a standalone application for authoring and debugging. Integration of AI.implant into other platforms is achieved using the AI.implant SDK, which contains runtime libraries for Windows and Linux. The two main components used for authoring in AI.implant are: • Decision making logic and locomotive characteristics of the characters themselves. • Creation of the AI world—a version of the environmental data used by the AI character(s) for perception and path planning within a dynamically changing environment. AI.implant performs several functions like Crowd Simulation, Intelligent Pathfinding, Dynamic Obstacle avoidance, Dynamic Path refinement, Hierarchical Pathfinding, Decision making and complex behavior templates. It finds its usage in both Military as well as Civilian field. Among the various AI.implant tools, perhaps the most important are AI.DE, AI.implant output compiler for Terra Vista and AI.implant SDK. 2.1. AI.DE The AI.implant Development Environment (AI.DE) is used to create and debug AI enhanced scenes. The AI.implant interface has two main elements: - Explorer and Visualization Windows. The AI.explorer displays objects in a tree view structure. Objects selected in the tree view are highlighted in the viewer. Items in the tree view can be expanded, to view detailed information about, or debug the selected object. The visualization has a schematic representation of autonomous characters and other AI elements but no artwork

11

Figure 2- AI.implant Explorer Window and AI.implant Visualization Window respectively. 4

2.2. Terra Vista AI.implant Output Compiler The Terra Vista AI.implant Output Compiler converts a Terra Vista database into an ACX file. It facilitates the use of Terra Vista data in: • Navmesh generation. • Obstacle creation. • Waypoint networks creation. • Building with interior creation. • ACX generation.

2.3. AI.implant Software Development Kit – The AI.implant Software Development Kit (SDK) includes tools for developing 3-D applications with the AI.implant Application Programming Interface (API). AI.implant is a dynamic, modular SDK; components are registered at runtime—rather than when compiling—so that AI.implant can be trimmed and extended to match the application’s requirements. It can also be used for remote debugging and even the visualization can be enabled within the engine. The other AI.implant tools include Maya and 3ds Max plug-in.  Creator plug-in.  STAGE.  Benchmark.

12

3. Overview Once the problem statement had been defined, a realistic and feasible goal was declared. The main aim of the project was to develop a realistic agent – centric road traffic behavioral simulation model for Indian Urban terrain. The initial focus of the work was on literature survey and research exercises. The principle that went behind designing the traffic simulations was investigated and a thorough understanding of the steering behaviors as outlined by Craig Reynolds was achieved. As this very same principle was employed to design Artificial Intelligence in the Gaming industry, a selected assortment of papers written by gaming software developers and critics was studied. Now that a sufficient background study had been done, the attention was shifted to the software in hand. After reviewing various COTS AI Middleware Products available, PRESAGIS AI.implant version 5.6 had been selected as the preferred tool to execute the project. Familiarization with the AI techniques used in AI.implant was then developed and the attached documentation was comprehensively reviewed. The next stage involved addressing the heart of the problem. All the possible entities involved were listed along with the rules that govern the behavior. Vehicles were differentiated on the basis of their type, their maximum velocities and their shapes and sizes. All the obstacles that could possibly hinder their movement were spelled out. It led to a very comprehensive list which included Speed-breakers, Junctions, Visibility, disruptive weather elements, Traffic lights and signs, Terrain modulation among a host of others. The rules that govern a vehicular entity’s interaction with its counterparts were investigated and it included the road dimensions, minimum Clearance maintained and the Selfish principle. The successive step was to specify which parameters govern the entity’s response to its environment as well as to external stimuli. Not surprisingly, the contents of these lists turned out to be quite numerous and myriad. It needed to be filtered to identify which of the governing rules and parameters could be modeled. Some of the factors like disruptive weather elements or accidents were identified as too complex to be modeled in the given duration. Apart from these several assumptions had to be made –    

The vehicles will necessarily take the best available route to their destinations. The vehicles will respect the traffic rules with a given probability. They will avoid collisions, obstacles etc. They do not park or stop unnecessarily on the way.

The features that distinguishes Indian traffic scenario from the western scenarios were also spelled out. Among the main differences were a highly heterogeneous traffic composition, unorganized traffic movement, difficult terrains with underdeveloped roads, and a general indifference to rules.

13

Now that the ground rules had been laid down and all the pragmatic goals had been identified, the subsequent step was to create the templates and the terrain. The main templates included Vehicle, Character (Pedestrian), Cycle, Truck, Bus and Ambulance template. Also a Traffic Controller, Populator and NavMesh were developed. An important aspect was to define additional steering behavior based on actual driving styles for the different classes of entities and assign appropriate intensity and priority for each of the chosen behaviors. 3.1. Traffic Controller The traffic controller controlled the traffic lights and the waiting time. The traffic lights were divided into two divisions – North-South traffic lights and East-West traffic lights. The total cycle time was allotted as 40 seconds. Considering that a clock is at 00:00 at the beginning – 00:00 – 15:00

The East-West traffic lights are added to the Active RED lights.

15:00 – 30:00 The Active RED lights group is cleared and the North-South lights are added to the Active RED lights group.

traffic

30:00 – 40:00 The East-West traffic lights are added to the Active RED lights so that all the lights are Red. At the end of 40 seconds the Red Lights group is again cleared and the cycle repeats itself. 3.2. Character Template The Character template outlines the pedestrian behavior. The characters are restricted to walk on the sidewalks only. A group of targets have been created and distributed around the NavMesh. The character picks up a random target from the group and navigates its way to the target by using intelligent Pathfinding, and avoiding the obstacles in its way. When a character comes near a STOP sign it stops for a period of 5 seconds before continuing in its way. The characters have been modeled in such a way that they only cross the roads using the designated Road-Crossing. Whenever a Character needs to crosses a road, it waits for the nearest traffic light to turn RED and only then does it make its way across the road. On its way it avoids the waiting cars, cycles, trucks, pedestrians and all other entities. Upon reaching its target, the character waits for a fixed period of time before selecting another random target and hence keeps wandering the NavMesh. 3.3. Bus Template Two Bus stops and a bus route have been created for the bus template. The Bus starts from a given waypoint in the NavMesh and makes its way to the Bus- Stop. After reaching the stop, the bus waits for a few moments, allowing some predefined characters

14

to board the bus. It then proceeds on its route, obeying the traffic rules and avoiding obstacles on its way. Once it reaches the destination stop, all the passengers disembark and then they proceed to their respective destinations by imitating the character template. The bus, meanwhile, continues on its route, till it exits the NavMesh. The Bus Template, can be modified by adding more Bus-Stops in its way and even allowing some passengers to exit the NavMesh with the Bus. 3.4. Ambulance Template The ambulance has been modeled as a special entity which does not obey any traffic rules. At periodic intervals an ambulance arrives in the navMesh and makes its way to the nearest exit, by avoidance all obstacles in its way. However the ambulance does not queue up behind any vehicles or give way to faster cars. The other vehicles have been scripted to stop and let the ambulance overtake it. Upon reaching the exit waypoint, the ambulance disappears from the navMesh. 3.5. Keyboard Handler Script In order to respond to the keyboard inputs an Event Handler Script called KeyDown has been defined.   



When the key ―T‖ is pressed, the Time of the Day is printed on the screen. When the key ―I‖ is pressed, the total number of characters that populate the scene gets printed. Upon pressing the ―Z‖ key, the InputMode is changed to the SpeedMode. This key press must be followed by pressing any number from 1 to 5. Consequently the speed of the simulation is increased that fold. For example, when the 1 is pressed, the simulation runs in Real-time mode and when 3 is pressed, the speed is three times faster than real-time. Presently this feature is not functioning properly. Upon pressing the ―C‖ key, the InputMode is changed to the TODMode. This key press must be followed by pressing a number from 1 to 3. It switches the Time Of the Day (TOD) to Morning (0900 hours) or Midday (1300 hours) or even Evening (1800 hours) correspondingly.

3.6. Vehicle template The vehicle template has been created as a master file which can be modified to imitate different vehicles like SUVs, MUVs, Sedans, and other motorized vehicles by tweaking the parameters. Broadly, the vehicle template has three subdivisions3.6.1. Officer These vehicles enter the NavMesh with a fixed destination in mind. It enters via any one of the entrances and makes its way to its target by using intelligent Pathfinding, obeying

15

the traffic rules and avoiding obstacles. The target waypoints represent Schools, Offices and Shopping Centers. Once the vehicle reaches the target, it waits for an interval of 5 seconds and then disappears from the NavMesh. The intent behind this is to show that the passenger has entered the building and the vehicle has been parked inside. 3.6.2. Commuter These vehicles enter the NavMesh with the sole intention of exiting it (hence the name). It enters via any of the entrances and makes its way to a random Exit by using intelligent Pathfinding, obeying the traffic rules and avoiding obstacles. 3.6.3. Wanderer As the name suggests these vehicles enter the Navmesh and roam around the terrain. It also enters via one of the entrances, picks up a random target in the terrain and makes its way to the target by using intelligent Pathfinding, obeying the traffic rules and avoiding obstacles. Once it reaches its selected destination, it again selects an arbitrary target and continues in this vein. The proportion of the three different classes has been programmed as a function of the time of the day. So the number of commuters and officers are more in the morning than in the afternoon. There are certain traits that are common among them, as described below. The vehicles follow the same set of traffic rules. They stop at Red lights, obey the speed limit, and stop for 5 seconds at a STOP sign. If the road has a NO-ENTRY sign ahead, the vehicle immediately stops, takes a U-turn and tries to find an alternative route to its target. All the vehicles have been scripted to give way to an ambulance. A guideline for overtaking has also been designed. In AI.implant, characters have a predefined attribute called Frustration which quantifies how much the character has been failing to achieve its motion goal due to dynamic obstacle avoidance. For each solve that the character is forced away from its specified motion, frustration is incremented proportionately to the motion deviation. When the character can travel in its specified direction, frustration falls off rapidly. Vehicles have been given a threshold of 6. If the frustration is below this value, the character queues behind the character in front. However as the frustration climbs and crosses this threshold, it tries to overtake the vehicle in front subject to the traffic conditions.

16

Figure 3 – The Vehicle template Components and Decision Tree. 5

17

3.7. Cycle Template On similar lines as the Vehicle and Character template, a Cycle template has been created. Just like the pedestrians, they are spawned at the start, at random points all over the NavMesh. They are comparatively smaller and slower than their vehicular counterparts. As far as the behavior is concerned, the cycles resemble the vehicle Wanderer template. It picks up a random target in the terrain and makes its way to the target by using intelligent Pathfinding, obeying the traffic rules and avoiding obstacles. Once it reaches its selected destination, it again selects an arbitrary target and continues in this vein. 3.8. Truck Template The truck template behaves exactly same as the vehicle Wanderer template. The only difference is they are larger and slower than their vehicular counterparts. 3.9. Populator The Populator is in charge of spawning pedestrians and cycles and populating the NavMesh with vehicles. We will first discuss the algorithm of spawning of the vehicles. A cap has been set on the maximum number of vehicles that can populate the scene. Tentatively, this number has been set to 150. First of all it checks if this cap has been exceeded yet. If the number of vehicles has not exceeded 150, the algorithm kicks into life. It gets hold of the names, positions, and ID of all the entrances and declares all the entry waypoints as Open. It then reads the entrance stats from an external csv file called EntranceStats.csv that has been linked with the user module. It obtains the number of entities that should enter the NavMesh at different times of the day and the proportion of commuters, officers and wanderers at a particular time. If the current time of the simulation exceeds the entrance time of the Populator, it begins to spawn the vehicular entities. It assigns a unique ID to each of the Character created and declares the character template as Commuter, Officer or Wanderer, based on the assigned proportion. Each entity is allocated a random position in the NavMesh, an arbitrary orientation and a Maximum speed that lies in a prescribed range. The entrance waypoint of each of the vehicles can also be tracked. Once the number of character exceeds 150, it declares the Entry waypoint as closed and ends the algorithm. If at any time in the simulation, a vehicular entity is destroyed or leaves the NavMesh the algorithm again compensates for this loss and keeps the total number of characters in check. In case of pedestrians, the logic is different. As the simulation starts, the algorithm checks the NavMesh for all the triangular navigable meshes that have been assigned as sidewalks. It obtains the centre point of these cells and spawns pedestrians at these points. As with the previous case, a cap has been set on the maximum number of character entities as 50. The generated entities are also assigned a unique ID and they are declared to be Character Templates. Each entity is allocated a random target in the NavMesh, an arbitrary orientation and a Maximum speed that lies in a prescribed range.

18

Once the prescribed number of entities has been created, the algorithm ends. Since the pedestrians remain inside the NavMesh all the time and are not destroyed, the Populator can remain idle for the rest of the simulation and this script is only called during a play or reset. In a similar vein like the Pedestrian Populator, a Cycle Populator has also been authored which populates the NavMesh with cycles at random points on the Waypoint Network. As with the prior cases, a cap has been set on the maximum number of character entities as 50. The generated entities are also assigned a unique ID and they are declared to be Cycle Templates. Each entity is allocated a random target in the NavMesh, an arbitrary orientation and a Maximum speed that lies in a prescribed range. Once the prescribed number of entities has been created, the algorithm ends 3.10.

NavMesh

The Navigation Mesh (NavMesh) is the Terrain that has been created for the road traffic simulation. The terrain is originally created in the Open Flight format and is then converted in the *.acx format with the help of the Creator plug-in. The .flt file is first imported in Presagis Creator version 4.0. This file shows a block of an urban city with designated buildings, road segments, sidewalks and road-crossings. The polygons that are used to construct the Sidewalks and the Road-crossings have a unique Feature ID (FID) value respectively. The FID is then configured to Blind Data for the use in AI.implant. Blind Data, sometimes referred to as Meta Data, is a value associated with a cell of the NavMesh. Characters use Pathfinding constraints to determine the cost of traversing a cell of one value to the next when finding paths. Blind Data is useful for describing what an area is made of for decision making purposes. The configuration is done in such a way that a Blind Data named SideWalk and RoadCrossing was created in the MeshBarriers and polygons that make up these Blind Data are assigned a value of 3 and 4 respectively. The default value 0 is used to all the unmapped FIDs viz. Road segments and buildings. The terrain is then selected and a NavMesh and a MeshBarrier are created according to the geometry of the selected terrain. The NavMesh so created, is then imported in the AI.DE. In order to create Roads, a series of Waypoints are generated and then are linked together in a Waypoint Network to provide a map of the environment. This waypoint Network is defined as the Roadway and is used by all the vehicles in the model for Pathfinding purposes. The waypoints are really multifunctional and diverse in its uses. Each waypoint can be assigned speed limits to control how the autonomous characters approach it. It is the waypoints that are designated as Traffic Lights, Targets, STOP signs, NO ENTRY signs, Entry points and Exit points. The NavMesh is also populated with Obstacles at various locations. Obstacles can be thought of as the AI specific physical representation of an object, to describe the physical world for Pathfinding Obstacles are used to make characters aware of the dynamic objects, obstructions, or other elements of the environment that affect movement.

19

We now have a realistic looking model of an urban city block. This block can be replicated many times or different blocks may be created and connected via a MetaConnection Network to depict an entire city. MetaConnection networks are higherlevel networks used for hierarchical Pathfinding that connect together several different lower-level NavMeshes or Waypoint networks.

Figure 4 – Screenshot of the City Block Navigation Mesh. 5

20

3.11.

Custom Functions

Several custom Lua functions have been defines in the project. A very brief overview is given below – 3.11.1. printTOD () This function displays the current Time of the Day of the simulation. The starting value has been assigned as 09:00:00. 3.11.2. resetSimulation () This function deletes all the characters in the scene and resets some generic attributes. It deletes all the pedestrians and vehicles, resets the total number of characters in the scene and resets the generic attributes of all the Entry and exit waypoints. 3.11.3. deleteSelf () This deletes the Character passing the function and decrements the Character counter. Apart from these, additional functions have also been defined to read and write simple csv files.

Figure 5 – EntranceStats.csv File. 5

21

3.11.4. Writing in files In the NavMesh, a total of four waypoints have been specified as Exit Waypoints. When a commuter template vehicle exits from any of these exits, the given waypoint keeps a record of the number of exits and the time of these exits. The writeSimStats function, then calculates the number of recorded exits in the period of last 60 minutes from each waypoint and stores this data in an external file called InstinctExitStats.csv

Figure 6 – ExitStats.csv File. 5

22

Once all the templates and the features had been created and the custom Lua functions defined, they were merged with the Navigation Mesh. A realistic looking, agent-centric traffic simulation model has been fabricated. The model was debugged repeatedly and the behavior of the system was visually evaluated in an attempt to validate the simulation. In order to make the simulation seem more realistic, the traffic lights at two intersection points have been disabled. These waypoints have been marked with a different color so they are easily identifiable. The vehicles approaching these two intersections points are governed by the First Come-first Go basis. So there are no governing rules and the entities inherently try to figure out which vehicle gets preference over the other. In order to accommodate the probability – based law abidance behavior exhibited by the Indian traffic scenario, an Intensity (weight) value has been assigned to the vehicles’ behavior template. The vehicles will now follow the rules with a prescribed probability only and in certain cases can even violate the traffic rules with impunity. Before the simulation is played the Time of the Day (TOD) has a predefined value 09:00:00 and the current time of the Solver is 00:00:00. The only entities present in the model are the Traffic Controller and the Populator. When the simulation is played, the pedestrians are immediately spawned from the centre of each cell of the Sidewalk. Cars begin to enter the NavMesh one by one from all the designated entrances. These cars are assigned one of the three templates – Wanderer, Commuter or Officer. The file EntranceStats.csv stores the data of the different proportion of vehicles at different time of the day. It also contains the data regarding the number of vehicles that will enter from each of the entrance waypoints. The current Solver time, TOD and the total number of characters are incremented with each passing second. At any time in the simulation the Ambulance and the Bus template can be activated. The Time of the Day and the Simulation speed can also be adjusted with a simple touch of the button. The simulation can be paused, stopped or reset as and when required.

23

Figure 7 – Screenshot of the Traffic Simulation. 5

24

4. Validation Once the Road Traffic Simulation model was completed, it was decided that the next ideal step would be to obtain some type of validation. Since the inputs that went into the model were not based on any actual concrete data, it was not possible to verify the results from the different runs. Hence a Sensitivity Analysis Test was carried out. Two possible runs were selected for this purpose 

Time taken by the Bus to complete its run from the start to the last bus stop. Time Taken by a pedestrian to move from one corner of the NavMesh to the opposite diagonal corner.

A set of parameters were identified, which could influence their run-time –         

Number of Vehicles in the Scene. Number of Cycles in the Scene. Number of Pedestrians in the Scene. Time of the day. Maximum Speed. Probability of Rule. Traffic Light cycle. Threshold Frustration level. Presence of Obstacles.

By holding all other parameters constant, each parameter was assigned a range of values and the corresponding run-time was calculated. Multiple runs were carried out for each set of parameter values and the average value was calculated. These values were plotted on different charts and the 95% confidence interval was calculated for each set of parameter values. In the end, certain deductions were made based on the obtained results and the parameters, which the Traffic Simulation model was most sensitive to, were highlighted.

25

5. Sensitivity Analysis 1 Calculating the Bus run-time by varying the parameter values, one at a time.

5.1. Number of Vehicles Table 1 – No. of Vehicles vs. Time taken.

Max. Speed

Threshold Frustration

Traffic Lights Cycle

Time Taken

900

1000

7

15-15-10

105.25

0.2

900

1000

7

15-15-10

112

0.8

0.2

900

1000

7

15-15-10

116.14

50

0.8

0.2

900

1000

7

15-15-10

121

50

0.8

0.2

900

1000

7

15-15-10

125.38

STOP GO TOD probability probability

Vehicles

Pedestrians

Cycles

10

100

50

0.8

0.2

50

100

50

0.8

100

100

50

150

100

200

100

5.1.1. Confidence Intervals The 95 percent two-sided confidence interval was calculated for the mean value of ―Time Taken‖ obtained for the different runs. Table 2 – Confidence Intervals for Table 1.

Vehicles

Mean Time

Lower Bound

Upper Bound

10

105.25

97.96562631

112.5343737

100

116.14

113.6852785

118.5897215

200

125.38

120.7793254

129.9706746

26

150

140

Time taken

130

120

110

100

90 0

50

100

150

200

No. of Vehicles

Figure 8 – No. of Vehicles vs. Time Taken. 6

The obtained results were pretty straightforward. As the number of vehicles in the scene increased, the Time Taken by the bus to transverse increased almost linearly.

27

250

5.2. Changing the STOP and Go probability Table 3 – Rule-following probability vs. Time taken.

100

100

50

1

0

900

1000

7

Traffic Lights Cycle 15-15-10

100

100

50

0.9

0.1

900

1000

7

15-15-10

156.03

100

100

50

0.8

0.2

900

1000

7

15-15-10

116.14

100

100

50

0.7

0.3

900

1000

7

15-15-10

106.76

100

100

50

0.6

0.4

900

1000

7

15-15-10

97.5

100

100

50

0.5

0.5

900

1000

7

15-15-10

101.2

100

100

50

0.4

0.6

900

1000

7

15-15-10

92.55

100

100

50

0.3

0.7

900

1000

7

15-15-10

95.9

100

100

50

0.2

0.8

900

1000

7

15-15-10

89.8

100

100

50

0.1

0.9

900

1000

7

15-15-10

87.32

Vehicles Pedestrians Cycles

STOP GO Max. TOD probability probability Speed



STOP probability 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1

Mean Time 156.0285714 116.1375 106.76 97.5 101.2 92.55 95.9 89.8 87.32

Lower Bound 154.5489805 113.6852785 104.6662439 91.63635608 93.18074916 87.93150631 91.3834863 84.24244082 82.42298011

28

Upper Bound 157.5081624 118.5897215 108.8537561 103.3636439 109.2192508 97.16849369 100.4165137 95.35755918 92.21701989

Time Taken 162

170 160 150

Time Taken

140 130 120 110 100 90 80 0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

STOP Probability

Figure 9 – Rule-following probability vs. Time taken. 6

5.2.2. Deductions The obtained results showed an almost linear variation initially and then a parabolic increase in the Time taken. A couple of local maxima were also obtained for STOP probability of 0.3 and 0.5, but the results are not very indicative of any significant departure from the overall trend.

29

1

5.3. Changing Number of Cycles Table 5 – No. of Cycles vs. Time taken.



Max. Speed



Time Taken

100

100

10

0.8

0.2

900

1000

7

15-15-10

109

100

100

50

0.8

0.2

900

1000

7

15-15-10

116.14

100

100

100

0.8

0.2

900

1000

7

15-15-10

130

100

100

200

0.8

0.2

900

1000

7

15-15-10

146.75

100

100

250

0.8

0.2

900

1000

7

15-15-10

158


Cycles

Mean Time

Lower Bound

Upper Bound

50

116.14

113.6852785

118.5897215

200

146.75

136.580708

156.919292

30

180

Time Taken

160

140

120

100 0

50

100

150

200

250

No. of Cycles

Figure 10 – No. of Cycles vs. Time taken. 6

5.3.2. Deductions The obtained results were pretty straightforward. As the number of cycles in the scene increased, the Time Taken by the bus to transverse increased almost linearly.

31

300

5.4. Changing Threshold Frustration Table 7 – Threshold Frustration vs. Time taken.



Max. Speed



Time Taken

100

100

50

0.8

0.2

900

1000

3

15-15-10

117.1

100

100

50

0.8

0.2

900

1000

6

15-15-10

118.1

100

100

50

0.8

0.2

900

1000

9

15-15-10

119.5

100

100

50

0.8

0.2

900

1000

12

15-15-10

118.7

100

100

50

0.8

0.2

900

1000

15

15-15-10

117.8

120

119.5

Time Taken

119

118.5 118

117.5

117

116.5 0

2

4

6

8

10

12

14


Figure 11 – Threshold Frustration vs. Time taken. 6

5.4.1. Deductions The obtained results showed that changing the Threshold Frustration level has negligible effect on the Time taken.

32

16

5.5. Changing Maximum Speed Table 8 – Maximum Speed vs. Time taken.



Max. Speed



Time Taken

100

100

50

0.8

0.2

900

300

7

15-15-10

221

100

100

50

0.8

0.2

900

500

7

15-15-10

176

100

100

50

0.8

0.2

900

750

7

15-15-10

159.92

100

100

50

0.8

0.2

900

1000

7

15-15-10

116.14

100

100

50

0.8

0.2

900

1250

7

15-15-10

112

100

100

50

0.8

0.2

900

1500

7

15-15-10

96.84

100

100

50

0.8

0.2

900

2000

7

15-15-10

89


Max. Speed

Mean Time

Lower Bound

Upper Bound

750

159.92

158.5678062

161.2655271

1000

116.14

113.6852785

118.5897215

1500

96.83333333

93.43223286

100.2344338

33

225

200

Time Taken

175

150

125

100

75 200

700

1200

1700

2200

Maxim um Speed

Figure 12 – Maximum Speed vs. Time taken. 6

5.5.2. Deductions The obtained results showed a parabolic relation between the maximum speed and the time taken. As the maximum speed increases, the time taken decreases in almost a parabolic fashion.

34

5.6. Changing TOD Table 10 – Time of the Day vs. Time taken.

STOP GO Vehicles Pedestrians Cycles TOD probability probability

Max. Speed



Time Taken

100

100

50

0.8

0.2

900

1000

7

15-15-10

116.14

100

100

50

0.8

0.2

1300

1000

7

15-15-10

113

100

100

50

0.8

0.2

1800

1000

7

15-15-10

125

126

124

Time Taken

122

120 118

116

114

112 700

900

1100

1300

1500

1700

1900

TOD

Figure 13 – Maximum Speed vs. Time taken. 6

5.6.1. Deductions When the time of the day is 1300 hours, the proportion of commuters and officers increases and hence the total no. of vehicles in the scene decreases. Correspondingly the run-time decreases. On the other hand, when the time of the day is 1800 hours, the proportion of commuters and officers decreases and hence the total no. of vehicles in the scene increases. Correspondingly the run-time increases.

35

5.7. Changing the Traffic Light Cycle Table 11 – Traffic lights cycle vs. Time Taken.

STOP GO Vehicles Pedestrians Cycles TOD probability probability

Max. Speed



Time Taken

100

100

50

0.8

0.2

900

1000

7

10:10:10

116

100

100

50

0.8

0.2

900

1000

7

10:10:05

114

100

100

50

0.8

0.2

900

1000

7

10:10:00

94

100

100

50

0.8

0.2

900

1000

7

15-15-15

124.42

100

100

50

0.8

0.2

900

1000

7

15-15-10

116.137

100

100

50

0.8

0.2

900

1000

7

15-15-5

111.03

100

100

50

0.8

0.2

900

1000

7

15-15-0

116.63

100

100

50

0.8

0.2

900

1000

7

20-20-20

131

100

100

50

0.8

0.2

900

1000

7

20-20-15

146.3

100

100

50

0.8

0.2

900

1000

7

20-20-10

105

100

100

50

0.8

0.2

900

1000

7

20-20-5

136

100

100

50

0.8

0.2

900

1000

7

20-20-0

93.5

5.7.1. Confidence Intervals The 95 percent two-sided confidence interval was calculated for the mean value of ―Time Taken‖ for the Traffic light cycles 15-15-15, 15-15-10, 15-16-5 and 15-15-00 obtained for the different runs. Table 12 – Confidence Intervals for Table 11. Traffic Lights Cycle 15-15-15 15-15-10 15-15-5 15-15-0

Mean Time

Lower Bound

Upper Bound

124.42 116.137 111.03

121.1824867 113.6852785 102.9052866

127.6397355 118.5897215 119.1447134

116.63

113.2942635

119.9501809

36

140

135

Time Taken

130

125

120

115

110

105

100 25

30

35

40

45

Cycle Tim e

Figure 14 – Traffic lights Cycle vs. Time Taken. 6

5.7.2. Deductions When the table for Traffic Lights Cycle vs. Time Taken is examined, certain trends become clear. When for a given base, the cycle time is decreased, the runtime also correspondingly decreases. This is because as the cycle time increases, a given stop light stays Red for a longer time and hence increases the run-time. For the same base, the minima are obtained near the shortest time cycle. For 10 seconds base, the shortest runtime occurred at 10-10-00 and f or 15 seconds base, the shortest runtime occurred at 15-15-05. As the base increases, the Time Taken also linearly increases.

37

50

6. Sensitivity Test 2 Calculating the Pedestrian run-time by varying the parameter values, one at a time. 6.1. Time of the Day Table 13 – Time of the Day vs. Time taken (2).


TOD

Max. Speed


STOP GO probability(others) probability(others)

Time Taken

100

100

50

900

200

15-15-10

0.9

0.1

333.125

100

100

50

1300

200

15-15-10

0.9

0.1

338.875

100

100

50

1800

200

15-15-10

0.9

0.1

387.75

6.1.1. Confidence Intervals The 95 percent two-sided confidence interval was calculated for the mean value of ―Time Taken‖ for the different runs. Table 14 – Confidence Intervals for Table 13.

TOD

Mean Time

Lower Bound

Upper Bound

900

333.125

310.973539

355.276461

1300

338.875

319.50937

358.24063

1800

387.75

342.7358633

432.7641367

38

600

Time Taken

500

400

300

200 700

900

1100

1300

1500

1700

Time of Day

Figure 15 – Time of the Day vs. Time taken (2). 6

6.1.2. Deductions When the time of the day is 1300 hours, the proportion of commuters and officers increases and hence the total no. of vehicles in the scene decreases. Correspondingly the run-time decreases. On the other hand, when the time of the day is 1800 hours, the proportion of commuters and officers decreases and hence the total no. of vehicles in the scene increases. Correspondingly the run-time increases.

39

1900

6.2. Maximum Speed Table 15 – Maximum Speed vs. Time taken (2).


TOD

Max. Speed



Time Taken

100

100

50

900

100

15-15-10

0.9

0.1

950

100

100

50

900

150

15-15-10

0.9

0.1

576.5

100

100

50

900

200

15-15-10

0.9

0.1

333

100

100

50

900

300

15-15-10

0.9

0.1

281.11

100

100

50

900

350

15-15-10

0.9

0.1

228


Max. Speed

Mean Time

Lower Bound

Upper Bound

200

333.125

310.973539

355.276461

300

281.1111111

249.3010155

312.9212067

40

1200

1000

Time Taken

800

600

400

200

0 0

50

100

150

200

250

300

350

Maximum Speed

Figure 16 – Maximum Speed vs. Time taken (2). 6

6.2.2. Deductions The obtained results showed a parabolic relation between the maximum speed and the time taken. As the maximum speed increases, the time taken decreases in almost a parabolic fashion.

41

400

6.3. Number of Pedestrians Table 17 – No. of Pedestrians vs. Time taken.


TOD

Max. Speed



Time Taken

100

10

50

900

200

15-15-10

0.9

0.1

312.25

100

50

50

900

200

15-15-10

0.9

0.1

318

100

100

50

900

200

15-15-10

0.9

0.1

333.125

100

150

50

900

200

15-15-10

0.9

0.1

399

100

200

50

900

200

15-15-10

0.9

0.1

462.9

. 6.3.1. Confidence Intervals The 95 percent two-sided confidence interval was calculated for the mean value of ―Time Taken‖ for the different runs. Table 18 – Confidence Intervals for Table 17.

Pedestrians

Mean Time

Lower Bound

Upper Bound

10

312.25

293.4549022

331.0450978

100

333.125

310.973539

355.276461

200

462.9

415.7145293

510.0854707

42

600

500

Time Taken

400

300

200

100

0 0

50

100

150

200

No. of Pedestrians

Figure 17 – No. of Pedestrians vs. Time. 6

6.3.2. Deductions The obtained results showed a linear relation between the number of pedestrians and the time taken. As the number of pedestrians increases from 10 to 100 the time taken also increases. However when the number of pedestrians exceeds 100, the linear graph shows a much steeper slope and the Time taken increases substantially.

43

250

6.4. Number of Cycles Table 19 – No. of Cycles vs. Time taken (2).


TOD

Max. Speed



Time Taken

100

100

10

900

200

15-15-10

0.9

0.1

334.5

100

100

50

900

200

15-15-10

0.9

0.1

333.13

100

100

100

900

200

15-15-10

0.9

0.1

342.125

100

100

200

900

200

15-15-10

0.9

0.1

353.375


Cycles

Mean Time

Lower Bound

Upper Bound

10

334.5

310.7429996

358.2570004

50

333.125

310.973539

355.276461

100

342.125

325.6661779

358.5838221

200

353.375

325.8303558

380.9196442

44

475 450 425

Time taken

400 375 350 325 300 275 250 225 0

50

100

150

200

No. of Cycles

Figure 18 – No. of Cycles vs. Time taken (2). 6

6.4.2. Deductions The obtained results showed that changing the Number of Cycles in the scene has little effect on the Time taken. However as the number of cycles increase, the run-time generally shows an increase as well.

45

250

6.5. Number of Vehicles Table 21 – No. of Cycles vs. Time Taken (2).


TOD

Max. Speed



Time Taken

10

100

50

900

200

15-15-10

0.9

0.1

311.66667

50

100

50

900

200

15-15-10

0.9

0.1

330.75

100

100

50

900

200

15-15-10

0.9

0.1

333.125

150

100

50

900

200

15-15-10

0.9

0.1

339

200

100

50

900

200

15-15-10

0.9

0.1

390.83333


Vehicles

Mean Time

Lower Bound

Upper Bound

10

311.6666667

303.402581

319.9307523

50

330.75

316.1401095

345.3598905

100

333.125

310.973539

355.276461

200

390.8333333

385.5155853

396.1510814

46

425

400

Time Taken

375

350

325

300

275

250 0

50

100

150

200

No. of Vehicles

Figure 19 – No. of Vehicles vs. Time taken (2). 6

6.5.2. Deductions The obtained results show that changing the number of Vehicles in the scene has slightly more effect than changing the number of Cycles. Extreme values of the vehicles (10 and 200) give extreme values of Run-time. But when the number of Vehicles is varied from 50 to 150, the Time taken is almost constant.

47

250

6.6. Rule-following probability of other Vehicles Table 23 – Stop probability (others) vs. Time taken.


TOD

Max. Speed



Time Taken

100

100

50

900

200

15-15-10

0.8

0.2

328

100

100

50

900

200

15-15-10

0.6

0.4

329

100

100

50

900

200

15-15-10

0.5

0.5

345.75

100

100

50

900

200

15-15-10

0.3

0.7

355

100

100

50

900

200

15-15-10

0.1

0.9

374.25


STOP probability(others)

Mean Time

Lower Bound

Upper Bound

0.8

328

318.772028

337.227972

0.6

329

320.4941118

337.5058882

0.5

345.75

340.3009297

351.1990703

0.3

355

348.1167062

361.8832938

0.1

374.25

365.9972207

382.5027793

.

48

390

Time Taken

370

350

330

310

290 0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

STOP Probability

Figure 20 – Stop probability (others) vs. Time taken. 6

6.6.2. Deductions The obtained results show that the Rule-following probability of other vehicles in the scene in the scene has linear relation with the Run-time. As the Stop probability decreases, the Time taken by the pedestrian to complete its journey increases.

49

0.9

6.7. Traffic-Lights Cycle Table 25 – Traffic lights cycle vs. Time taken (2).


TOD

Max. Speed



Time Taken

100

100

50

900

200

10:10:10

0.9

0.1

324.25

100

100

50

900

200

10:10:05

0.9

0.1

332.5

100

100

50

900

200

10:10:00

0.9

0.1

355.25

100

100

50

900

200

15-15-15

0.9

0.1

344. 67

100

100

50

900

200

15-15-7.5

0.9

0.1

386.125

100

100

50

900

200

15-15-0

0.9

0.1

370.375

100

100

50

900

200

20-20-20

0.9

0.1

376.67

100

100

50

900

200

20-20-10

0.9

0.1

356.67

100

100

50

900

200

20-20-0

0.9

0.1

416


Traffic Lights Cycle 10:10:10 10:10:05 10:10:00 15-15-15 15-15-7.5 15-15-0 20-20-20 20-20-10 20-20-0

Mean Time 324.25 332.5 355.25 344.67 386.125 370.375 376.67 356.67 416 50

Lower Bound 319.9876571 304.351643 322.4981029 319.9900323 339.762998 322.9791455 341.8188196 334.8019513 389.9730499

Upper Bound 328.5123429 360.648357 388.0018971 369.343301 432.487002 417.7708545 411.5145137 378.531382 442.0269501

450

Time taken

400

350

300

250 15

20

25

30

Cycle Time

Figure 21 – Traffic Light cycle (10 seconds base) vs. Time taken. 6

51

35

550

Time Taken

500

450

400

350

300 22.5

30

37.5

45

52.5

Cycle Time


460 440

Time Taken

420 400 380 360 340 320 300 30

40

50 Cycle Time

52

60

70


6.7.2. Deductions When the table for Traffic Lights Cycle vs. Time Taken is examined, certain trends become clear. For a given base, the shortest runtime occurs near to the longest cycle time. This is logical as a longer cycle time, indicates that the stop light remains Red for a longer period and hence leads to a shorter runtime. As the base increases, the Time taken also increases linearly.

53

7. Experimentation

7.1. Breaking Point An attempt was made in order to ascertain the maximum number of entities that the Road Traffic Simulation Model could handle comfortably. It was found that the model could accommodate about 1000 entities, without breaking down. This number included an even distribution between the number of vehicles, pedestrians and cycles. However the simulation showed a decrease in the Frames per Second (fps) and was a little sluggish in responding. When the total number of entities crossed the 1200 mark, the model became really chaotic and snaillike with the fps showing a significant decrease.

Figure 24 – Breaking Point. 5

54

The intersections got completely clogged, leading to chaos and a breakdown in rulefollowing behavior.

Figure 25 – Chaotic Intersection Point. 5

7.2. A world without rules In another experiment, the model was modified and all the traffic lights were disabled. The aim was to find out if a world without rules lead to a bedlam or did it prove to be more efficient than the Rule-following model. Qualitatively speaking, the result showed a very smooth flow of traffic with absolutely no bottlenecks or queues. In order to gauge the effectiveness of the model, it was decided to run the bus template in the standard conditions of Sensitivity Analysis 1 and calculate the mean run-time.

55

The results of this exercise for average run-time verified the qualitative conclusion. Whereas the Time Taken in Sensitivity Analysis 1 under standard conditions was 116.5 seconds, the same conditions resulted in a mean Time Taken of 82.5 seconds. This was less than any run-time encountered in the Sensitivity Analysis, proving that a world without rules was indeed more effective. However, with more than 800 entities, this model was no less disordered than the previous model.

Figure 26 – World without rules. 5

56

8. Future Applications As it has already been pointed out there is a tangible need for realistic traffic simulation models. Traffic simulation can be used to study traffic theory and assess network infrastructure and control changes without costly infrastructure changes. Even the optimal time-cycle period of traffic lights can be assessed with the traffic simulation model. Presently we have assigned this period as 40 seconds. But after adjusting the inflow of vehicles, to match the realistic data we can derive an optimized period. There is no dearth to number of add-ons that can be incorporated in the model to make it more realistic. Some of them include1. Presently all road segments have a predefined Blind Data value as 0. In India the roads are classified as National Highways, State Highways, District Roads and Village roads. They have different speed limits, layouts and terrains. This can be reflected in the model by assigning a unique BlindData value to the different road classes. So all the additional information about navigating various types of roads can be incorporated in the BlindData.

2. The buildings in the MeshBarrier are modeled as Obstacles and hence are opaque and collidable. In truth some building like Shopping Malls are navigable and is used by Pedestrians for the purposes of navigation. Bridges, Foot-over bridges, Railway crossings are other possible additions.

3. Vehicles only originate from the entrance waypoints. When the vehicles cloned as Officer Templates reach their destinations, they are deleted from the NavMesh in order to show that the passenger has entered the building and the vehicle has been parked inside. If parking spaces are designated in the model, the vehicles can be parked there and once the passenger leaves the building, the vehicles can originate from such parking spaces.

4. Although the vehicles have been assigned a range of sizes, maximum speeds and turning ability, it does not aptly represent the chaotic diversity that characterizes Indian Traffic. Entities like Bicycles, Rickshaws, Scooters, 3-wheeled Autorickshaws and even Animals populate the typical Indian Roads. In this respect, the model has not fully captured the essence of bedlam.

57

5. In the model only two main Traffic Signs have been shown – STOP and NO ENTRY. In India traffic signs are classified as Mandatory, Cautionary and Informatory. Some common signs include Overtaking prohibited  Right/Left/U- Turn prohibited  Give way  Steep Ascent/Descent.  Roundabout Based on the need an assortment of Road traffic signs can be included in the model.

6. A number of assumptions have been made in order to develop the traffic simulation model. A number of parameter values that are variable and dynamic, have been assumed as constants, e.g. –  The probability of law-abidance is dependent on Time of the day.  Driving experience, driver’s aggressiveness, knowledge of the city routes etc do not appear in the picture.

One of the main intentions that went behind making a traffic simulation model for urban Indian cities was to observe the traffic trends in case of emergency scenarios like terrorist attacks, explosions and mass evacuations. As a demonstration of the possible application of the model a Monster Entity has been created. This entity is intended to represent a hostile terrorist entity and it is assumed that any other entity in the model will recognize the hostile character when they see it. Every character in the simulation has an EscapeFromMonster behavior. This behavior kicks in when the given character is within a 3000 units radius from the Monster. As soon as the behavior gets activated, all other active behaviors like SeekTo target, obey traffic rules, follow the Road etc gets deactivated. The sole intention of the affected character is to get as far as possible from this Monster Entity. Once it reaches a distance of 5000 units from the Monster, the EscapeFromMonster behavior is disabled and all the prior behaviors get activated. The character tries to get back to the nearest navigable path and seek to its target. Although it might seem quite rudimentary, this is one of the most primary and inherent forms of response to an emergency situation.

58

Figure 27 – Response to Monster. 5

Another important feature that needs to be included is the encountered and prevalent response to different contingencies. This might be something as trivial as the response to a passing fleet of Army or Police vehicles, an incoming fire-engine or VIP traffic to something as sinister as a Bomb explosion.

59

9. Possible Look-Ahead and Conclusion The best part of this project is that it can be easily extended into the future. With an appropriate interval of time, the simulation model can be made more detailed and sophisticated. A future model will have entities that include two-wheelers, three-wheelers and trucks, navigating on multi-lane roads, with underlying BlindData differentiating the different types of road segments and presence of special entities like Police and Army vehicles, Ambulance, Fire engines etc., responding realistically to traffic rules and special contingencies and external stimuli as well.

60

References 1. http://www.its.dot.gov/its_publicsafety/emo/emo.pdf (last accessed on 1st July 2010). 2. http://en.wikipedia.org/wiki/File:Simulation_Table.JPG (last accessed - 1st July 2010). 3. http://en.wikipedia.org/wiki/List_of_Game_AI_Middleware (last accessed - 1st July 2010). 4. AI.implant Technical Overview Documentation. 5. The figures were self taken. 6. The figures were generated using Microsoft Office Excel 2003.

61

Acknowledgement This paper is a culmination of the work done as a part of the Cranfield University Boeing Summer Internship Program 2010. It was originally submitted in the fulfillment of the Summer Internship Boeing Technical Emphasis Program (BTEP) on Analysis, Modeling, Simulation & Experimentation in India 2010. I want to acknowledge the invaluable inputs and guidance provided by the people at the Simulation & Synthetic Environment Laboratory, DCMT, Shrivenham and those at Boeing Strategic Development and Experimentation in Bangalore. The paper would not have been possible without the supervision and support of Mr. Jonathan M. Read, Senior Manager of India Boeing SD&E and Mr. Vijaya Kumara, Technical Lead of India Boeing SD&E.

62