ISAT User's Guide

Introduction

What This Document Contains

This manual is the user's guide for the National Advanced Driving Simulator (NADS) Interactive Scenario Authoring Tool (ISAT), which allows graphical authoring of driving simulator scenarios as well as rehearsal and review of simulator runs. ISAT has been designed to use graphical menus, visual feedback, and guided input dialog boxes to increase usability. This guide describes how to use the ISAT and defines the authoring capabilities of the NADS Scenario Definition and Control (SDC) software.

Audience

This guide was written for an audience that‟s very familiar and comfortable with the use of a Windows based personal computer. It is expected, that readers of this document are familiar with general transportation concepts, high-fidelity driving simulation, immersive virtual environments, and the issues involved in designing scenarios.

Framework

The ISAT is one of a number of tools that can be used to prepare for conducting research studies at the NADS. Therefore, it is important to understand how the ISAT fits within the overall framework. Although it is difficult to pinpoint a process that is simple and easy to comprehend yet covers all potential models of NADS usage, we believe the example provided here covers a significant subset of NADS usage. This example should not be considered a limit on how the NADS can be used to investigate problems. Rather, it is an example that is useful in explaining the role of the ISAT (i.e., the process does not indicate the potential to instrument new cabs or integrate new in-vehicle devices to current NADS cabs, yet these activities are possible). At the same time, not all parts of this process are necessary for each NADS study, and some could be skipped under certain conditions. With those caveats in mind, Figure 1-1 illustrates this process.

The Tile Mosaic Tool (TMT) is a graphical tool that allows the creation of the road network that will be used in the simulator scenarios. The pool of tiles refers to a set of pre-fabricated components, each representing a small geographical area (e.g., a city block or a piece of road) that can be combined by the TMT into a larger virtual environment to be used in the NADS. The output of the TMT is referred to as a static virtual environment because it contains only the physical environment (i.e., the road network, buildings, terrain, and features) but no active elements (i.e., traffic, pedestrians, etc.). The static virtual environment comprises several distinct but correlated databases, each of which is used by the various NADS subsystems while the NADS is running. For example, the visual representation of the virtual environment is displayed by the NADS Image Generator and projectors, whereas the road network information is used by the various driver models populating the virtual environment. The ISAT depends on the existence of a static virtual environment on which to build scenarios. That file is called the LRI (Logical Road Information) file. LRI files typically use the .lri extension. The pool of scenario components represents existing libraries of scenarios that can be used for building new scenarios. The ISAT produces a scenario file, which, in combination with the static virtual environment, represents a dynamic virtual environment. This information is fed to the experiment builder, a tool that allows the specification of the number of participants in a study and the conditions that each participant will be exposed. For example, let us assume that the ISAT produces two scenarios, S1 and S2. If an upcoming study will use eight subjects, then each of the subjects can have any number of exposures using either S1 or S2. The experiment builder allows the specification of such associations. Upon completion of these associations, the cumulative set of files and databases is transferred to the NADS computer systems, where they can be used to execute the runs. After completion, the final output of the simulator is a number of raw data files, which may include video, binary, or other data. These data are then fed to various post-processing tools (this process is referred to as data reduction), and the resultant reduced data can be used by researchers for statistical analysis. Generally, the ultimate goal of this process is the generation of reports, articles, publications, or other publicity materials. This is facilitated through a Data Verification and Visualization Workstation (DVVW), which is a hardware-software custom-developed product that facilitates the integration, understanding, and dissemination of all available information.

Note that no matter how complex the data that is produced in the various phases of the process, the goal of the data-handling tools is to hide this complexity from the user.

Terminology

This section defines terms that are used frequently in this document.

Visual database	A set of data files representing the physical appearance of a virtual environment. The NADS computers use the OpenFlight format for visual databases.
Synthetic environment	A set of correlated databases that fully defines a virtual environment for use in the NADS.
Tiles	An instance of a synthetic environment that has been designed so that it can be combined with others, thus allowing the development of larger synthetic environments.
Simulator driver	The person driving the NADS. Depending on the context, the term may refer to the actual individual who is driving, or the vehicle representing the driver in the virtual environment. An example of the latter occurs when generating a top-down movie showing what happened during execution. The term simulator driver would be used to refer to the vehicle that shows the subject's actions.
Event	A pre-specified set of actions that may or may not involve the simulator driver and are an integral part of a scenario. It is often necessary to have repeatable events. An example of an event is having a car that is waiting at a red light run the light once the simulator driver is ready to enter the intersection.
Scenario	A series of events that take place while a subject is driving the simulator.
Scenario element	An object that usually is displayed in the ISAT main window, and corresponds to an entity that will exist in the virtual environment during execution of the scenario.
Research participant	An individual who drives the NADS during an experiment. Note that a single research participant may drive the NADS several times within the same experiment, and each time they may be exposed to a different scenario. Also called subject.
Subject	An individual who drives the NADS during an experiment. Note that a single subject may drive the NADS several times within the same experiment, and each time they may be exposed to a different scenario. Also called research participant.
NADS	The National Advanced Driving Simulator.
SDM	The Simulator Development Module, a second simulator in the NADS facility that allows testing and tuning of scenarios or other simulator modifications without occupying the NADS. A key feature of the SDM is that it uses hardware identical to or similar to that used in the NADS to ensure compatibility.
Coordinator	A coordinator is a scenario component that has no visual representation but can monitor the evolution of the virtual environment and create, delete, or control other entities to orchestrate scenarios.
Buttons and dials	In the ISAT, most objects have buttons and dials. When pressed or set, buttons and dials can modify the behavior of the object. Scenario events are often created by coordinators pressing the buttons and dials of objects at key points during the scenario.
GUI	A Graphical User Interface is term used to describe a user interface that relies on graphical symbols such buttons, text boxes, and drop down menus, and uses mouse or other pointer device (touch screen, trackball, and joystick). GUI elements refer to individual elements such as buttons.

In Case of Problems

At the time of this writing, most NADS tools have been tested to meet functional specifications and used extensively in research and studies conducted at the NAD. In the event that you experience any problems or would like to provide feedback, please contact Omar Ahmad at mailto:oahmad@nads-sc.uiowa.edu, or David Heitbrink at mailto:dheitbri@nads-sc.uiowa.edu. When reporting a problem, please provide the following information:

1. Your name and affiliation
2. The version of the ISAT that you are using (version information is available from the Help/About menu)
3. The scenario and LRI that causes the reported problem
4. A description of the problem
5. A series of steps that need to be performed to recreate the problem

All problems will be addressed in a timely manner in the form of a fix or a workaround.

Document Outline

The remainder of the document is organized into chapters, each covering a particular aspect of ISAT usage. Chapter 2 provides an overview of the issues involved in building scenarios for the NADS and a broad outline of the tools‟ capabilities. Chapter 3 provides an overview of the general graphical user interface features of the ISAT, including how to create new scenarios, save scenarios, navigate the synthetic environment, and so on. Chapters 4 through 9 focus on authoring components, and Chapter 10 is devoted to more advanced subjects.

Scenario Authoring Overview

Basics

Scenario authoring involves the specification of both the static and dynamic elements of a virtual environment so that certain events appear to anyone who drives the simulator under the specific scenario, regardless of small differences in driving style or timing. For example, consider the testing of a new in-vehicle warning device that provides various alarms to warn drivers of potential collisions. The researchers are interested in seeing how different warning signals perform as far as their ability to alert the driver and prevent a collision. To test such a device, one should be able to create potential collision situations. One way to do this is to have the subject drive along a road and through an intersection controlled by traffic lights while the light is green. As the driver nears the intersection, another car (car B), which is initially stopped by the red light on the other leg of the intersection, begins moving, thus blocking the subject‟s path. Let us consider the issues in building such a scenario.

The problem

By far the most critical aspect of such a scenario is timing the motion of car B so that it provides a consistent time-to-collision condition for all subjects, something that is necessary in evaluating the collision avoidance device. However, additional issues have to be considered. When was car B created? Is car B is the same make and model for all subjects, or does it change? How does one ensure that the traffic light is green when the subject approaches as opposed to yellow or red? What if different subjects travel at different speeds toward the intersection?

One approach to building such a scenario is to script everything explicitly that is dynamic about the virtual environment so that its timing is tied to the motion of the simulator driver. For example, time 0 is when the scenario starts, time 40 is when the driver reaches some fixed distance from the intersection, time 60 is when the driver's front bumper enters the intersection, and time 100 is when the driver reaches some point beyond the intersection. Scripting software can determine the value of time based on how fast or how slow the drivers moves and then trigger every change in the virtual environment based on the parametric time scale. For example, the light will turn green at time 20, and car B will begin moving at time 40 and reach the middle of the intersection at time 60. That way, everything is scripted, and no matter how fast or slow the driver moves, the event will happen consistently.

Such techniques are often used in simulators that use relatively short scenarios or involve few dynamic traffic elements. The technique is simple, easy to understand, and provides deterministic results. However, when considering such a technique for use in high-fidelity simulators, several problems arise. In high-fidelity simulators, scenarios are longer and generally involve multiple entities. Coordinating one or two elements through explicit scripting for a 5-minute scenario is reasonable, but coordinating 500 vehicles for a 45-minute scenario is daunting and virtually impossible. Note that the 500 vehicles may not be active at the same time; in fact, they may represent traffic in the opposing lane that is not an integral part of the scenario. Nevertheless, if scripting were the only tool available, it would have to be used for all vehicles. Another complication has to do with what happens after the event takes place. One may want to trigger different scenarios after the near-collision event, depending on the outcome of the first event. For example, if there was a near collision, a less severe event may need to take place at the next intersection, but if the subject veered away early enough, a more severe event may be necessary. Such decision-making cannot be programmed when scripting is the only tool.

An alternative approach is to use intelligent agents that populate the simulator‟s virtual environment and behave autonomously. For example, autonomous driver models can be used to control the various vehicles in the scene. In addition, an intelligent manager can control the traffic lights so their timing follows a specific pattern. Such an approach makes it easy to create scenarios involving multiple entities because the labor-intensive specification of the individual behavior of every entity is eliminated. In addition, the length of the scenario does not overly complicate the development of the scenario because autonomous entities can be created automatically throughout the scenario. However, various other complexities surface. For example, timing and coordination become harder to achieve. Consider the example described earlier. If a traffic light manager controls the state of the traffic lights based on a fixed pattern, there is no guarantee that the light will be green when the simulator driver approaches the intersection. Furthermore, if vehicles are autonomous, there is no guarantee that car B will be waiting at a red light because it may have decided to pick a different route earlier. Even if a car is waiting at the red light, subjects will travel at different speeds. Therefore, they will reach the intersection at different times, and the proper time for car B to block the intersection is not known a priori.

ISAT Toolset Approach

The approach used for scenario authoring in the NADS software and supported by the ISAT is a hybrid between the two techniques, with emphasis on using intelligent agents in conjunction with coordinators to ensure consistency. Specifically, the ISAT allows the user to create any number of entities that behave largely autonomously. In addition, the user can create coordinators; coordinators are "invisible" entities that exist in the virtual environment, but are not displayed. These coordinators orchestrate events by monitoring what happens and modifying the autonomous behavior of the remaining agents to achieve a pre-specified goal. Additional coordinators can be used to automate the generation of traffic, control the traffic lights, modify the environment conditions, and control numerous aspects of the simulator‟s operation. In addition, the ISAT allows the creation of purely scripted entities. The evolution of these entities is completely deterministic, and their timing can be either independent or dependent on the simulator driver's actions.

Deterministic objects, or Deterministic Dynamic Objects (DDOs), as they are referred to in the ISAT, are objects whose behavior is pre-scripted by the user. Specifically, the user can select a path and specify the velocity of the DDO at each point in the path. While the scenario is running, a DDO simply follows its path according to the user's specification. Dependent DDOs, or DDDOs, are similar in that they follow a specific path, but their velocity adjusts so they reach a specific point of their path at the same time another entity reaches another target point. DDDOs allow vehicles that follow a scripted path to behave consistently as far as their relative position to another object (including the simulator driver), independent of the variation in the other object's speed. Both DDOs and DDDOs lack collision-avoidance capabilities.

Autonomous Dynamic Objects (ADOs) use a sophisticated autonomous driver model that controls their motion. One can think of an ADO as a human driver that is driving around the virtual environment trying to reach its destination. An ADO will follow the rules of the road, including following the speed limit and respecting traffic lights, and will exhibit most behaviors exhibited by real drivers. A unique feature of the driver model used in the NADS SDC, however, is the ability to have its default behavior modified at runtime. For example, an ADO can be told to follow a specific speed independent of the external conditions, to change lanes, to take a particular turn, and so on. Such commands can be initiated by the researcher while the scenario is running, or can be issued by the various coordinators that can be authored a priori. The latter is by far the most common due to its repeatability. The key coordinators include the trigger, the traffic manager, the traffic source, and the traffic light manager.

The trigger is an entity that is given a series of conditions and a series of actions. It continuously evaluates its conditions and, when they are all true, performs the actions. Examples of conditions include another object reaching a specific point in the road network or a traffic light turning green. Various actions are available, including creating a new entity, deleting an existing entity, modifying the cycle of the traffic lights, terminating the simulation, causing system failures on the vehicle driven by the simulator driver, and issuing behavior modification commands to a set of autonomous entities. A detailed description of how the trigger operates and how the ISAT can be used to specify the trigger‟s events and actions is given later in this document.

The traffic manager is tasked with generating autonomous traffic to populate the area around the driver. Because of a finite limit on the computational resources of the simulator, it is not possible to simulate an arbitrary number of vehicles in real-time. Therefore, traffic is created only in the area around the driver. The traffic manager is given a specific traffic profile and a desired density, and it will create or delete objects as necessary to maintain that density.

A traffic source is another coordinator whose job is to create traffic. Unlike the traffic manager, however, it creates vehicles at a specific point in the database.

The traffic light manager is responsible for controlling the state of traffic lights in the scene. Through the ISAT, the user can program the traffic light manager to achieve just about any timing cycle. In addition, the traffic light manager, in conjunction with the triggers, allows the linking of traffic lights to achieve coordinated traffic light groups.

ISAT Overview

This chapter provides an overview of the capabilities of the ISAT as well as general issues regarding its use. The chapter covers the installing and starting the tool, the overall tool layout, along with the various operating modes supported by the tool. Finally, this chapter covers ISAT tasks that are general purpose in nature, apply to all authoring components, or apply to a scenario as a whole. Subsequent chapters focus on authoring tasks that are associated with specific components such as triggers, or ADOs.

The ISAT utilizes a Graphical User Interface (GUI) that follows the typical GUI conventions of Windows 2000® and later operating systems. ISAT uses a multiple-document interface, where each document represents a scenario. ISAT allows the editing of any number of scenarios at the same time.

Installing and Starting ISAT

The ISAT is distributed on a CD ROM or as a set of install files. In either case, a single Setup program needs to be executed in order to install ISAT. After installation, .bli and .scn files will be associated with the ISAT so double-clicking on such a file will commence the ISAT. In addition, the ISAT icon can be double-clicked to open the tool with nothing loaded. Finally, the ISAT can be started by typing its name on a DOS window, although this requires that the ISAT installation directory be part of the PATH environment variable.

Generally, the only reason to start ISAT from the command line is to run it in Batch mode or to modify some default parameters that cannot be changed once ISAT is loaded. Running the ISAT in batch mode allows the generation of movie animations automatically, without the need for user interaction.

Command Line Arguments

Table X summarizes the ISAT command line arguments. Generally, groups of parameters have to be specified together, whereas other parameters can be specified in isolation.

General Tool Layout

Figure 3-2 illustrates the tool as it appears immediately after invocation.

Figure 3-2 ISAT after invocation.

The ISAT uses toolbars to group similar function buttons close together. If no document is loaded, it displays only a subset of the available menu and toolbar options. The user can either create a new scenario (*.scn) by going to File->New, or open an existing by going to File->Open. When creating a new document the user will be asked for a BLI file, these files contain the “map” and should be located in the “Isat\data\” directory.

Below Figure 3-3 illustrates how the ISAT looks after a document is loaded.

Figure 3-3 ISAT after loading of a scenario.

The tool is conceptually divided into three areas: the top area that hosts the toolbar and menu area, the work area, and the status bar located at the bottom of the window.

Tools, Toolbars, and Menus

The menu bar and toolbars are located at the top of the window. The menu bar used in the ISAT is typical of most Windows programs, such as Microsoft Word. Various toolbars are available immediately below the menu. The ISAT toolbars can be “docked” at different places, including outside the main tool window. Toolbars are organized according to their functions and will be described throughout this document. Toolbars remember their position so if you move them to a specific place, they will be there next time the ISAT is started.

ISAT employs many advance user interface elements that are found in newer Microsoft products such as Visual Studio 2005. ISAT allows for the automatic docking of tools, and embedding tools into each other. Three controls control the docking position a tool, docking control, pin, and persistent bar. When a title bar of a tool is selected, the docking control will appear. If you drag the cursor over to one of the directional buttons, it will dock the bar in said direction. The pin control, located in the upper left hand corner of the control effects how the document is pinned to the interface. If the head of the pin is facing down, the bar will stay visible when not active. If the pin is facing sideways, the control will be added to the persistent bar. When the tool is no longer active it will slide away, and when the cursor is placed over the tool‟s title in the persistent bar, it will slide out again. The pin is toggled from facing sideways or downward by clicking on it.

Figure 3-4 Advanced User Interface

Figure 3-5 Docking Tool Step 1

Figure 3-6 Docking Tool Done

Work Area

The work area is located below the toolbars and contains a top-down view of the synthetic environment. This view focuses on the features necessary for driving. It displays roads, lanes, lane markings, traffic lights, signs, etc., but does not display forests, buildings, or other visual features that do not affect driving. In addition, certain features are displayed in iconic form rather than in a geometrically correct rendering. For example, an icon is shown in place of signs because an actual rendering of signs from the top would be illegible. Inside the work area, the green color represents areas outside the road network*. Roads are shown in a dark gray color with lane markings in either white or yellow consistent with roadway marking rules. Intersections are shown in a lighter gray color with corridors though them in the same dark gray color as roads. Clicking the mouse button in the work area has different effects, depending on the mode of the tool (see Section3.3).

Status bar

The status bar is at the bottom of the window, and composed of four rectangles that provide a number of changing messages. Figure 3-3 illustrates the various components of the status bar.

Figure 3-8 ISAT Status Bar

The two rectangles on the left side of the toolbar indicate the action that would be performed if the respective mouse buttons were pressed, and the rightmost rectangle contains the name of the object underneath the cursor.

The rectangle immediately to the right of the mouse action area displays information about the terrain underneath the cursor. This information is configurable by the user (see section 3.1.4 for details). When the cursor is over a road, it displays the parametric coordinates of that point in the road network coordinate system. For example, consider the following text appearing on above status bar area:

68.64, 37258.97, 0.00 (R:R3_-660_36960:4:623.01:7.03) Ferrari Dynamic Object

The first three numbers (68.64, 37258.97, 0.00) are the Cartesian coordinates of the point under the cursor. The (R:R3_-660_36960:4:623.01:7.03) indicates that this coordinate is on a road (the first R), that the name of the road is R3_-660_36960, that the specific lane is lane 4, and that the distance from the beginning of the road along the road centerline is 623.01 units. Lanes are numbered starting with 0 for the rightmost lane when looking along the direction of the road. The distance along the road is 0 at the beginning of the road and reaches the road length at the end of the road. When the cursor is over an intersection, the indicator changes from an R to an I with similar information provided about the intersection. When the cursor is not on a road or an intersection, the status bar will list “Offroad” after the Cartesian coordinates. When cursor is over an object, that object‟s name along with object type is displayed on status bar.

Customizing the ISAT display

Using the Edit>Preferences menu option brings up the Preferences dialog box shown in Figure XX.

Figure 3-9 Customizing ISAT display

The Color Manager tab allows the user to change the default display settings. The display objects are listed in a two-level hierarchical tree display. Change the color of an object by selecting it from the tree and then clicking the Change button. This brings up a color creation dialog box, which allows selecting of the appropriate color. Once the window is dismissed, the ISAT will re-draw all windows with the new color choices.

The Display Filter tab has two checkboxes. The first is labeled, Always show children. A few of the ISAT elements, such as triggers or sources, involve multiple elements in a parent-child relationship. For example, a source designed to create vehicles at two locations will have two children that act as placeholders, one per location. This setting controls if the children of an element appear always, or only when the parent is selected. Similarly, element labels can be shown all the time or only when an element is selected. The second check box labeled, Show Text Labels, controls this behavior.

The “Status Bar Settings” tag allows the user to specify the detailed format and information that the ISAT displays about the roads and objects under the cursor. This information is dynamically updated and displayed on the terrain information area of the status bar. The default configuration of the Status Bar Settings tab is shown in

Figure 3-10. Change these settings by entering the appropriate format in one of the three edit boxes

The dialog box displays all available codes that can be used when specified the text to print. Any text that does not use edit codes appears verbatim. For example, assuming that the cursor is at location (50, 50) then using the text “X = %x” in the position text box would cause the following to appear on the status bar: “X = 50”.

Like most ISAT settings all preferences are persistent, i.e., next time the tool is started, all settings will be remembered.

Tool conventions

Whenever possible, the ISAT uses a consistent user interface. Within each mode, the shape of the cursor indicates the type of activity that will take place when mouse buttons are clicked.

The default selection state is indicated by the standard Windows cursor. In that state, the left mouse button is used to select objects and the right mouse button brings up a context-sensitive menu. The left mouse button can be dragged to move elements or to form a rubber band rectangle that selects all objects within it. While authoring various objects that require the user to specify a series of locations, the tool uses the left mouse button to specify a location and the right mouse button to end the selection of locations.

New elements are generally created by first selecting the object category, and then clicking on the location where the object should be placed. A modal dialog box appears to allow specification of additional parameters for the newly created element.

Tool operating modes

The actions that the user can perform while using the ISAT change depending on the tool-operating mode. There are currently four operating modes, each focused on a different phase of the scenario development process. The four modes are authoring, rehearsal, monitoring and replay. The tool first starts in authoring mode. To switch modes, select the appropriate mode from the Mode menu or use the buttons in the mode toolbar:

Authoring mode (Edit Mode)

This is the tool‟s default mode, and is the leftmost button on the Mode toolbar. In this mode, the user can create new scenario elements and modify existing elements. In addition, various key-mouse combinations can be used for navigating around the map. Even though the specific details vary among different scenario elements, creating new and editing existing scenario elements follows a specific patter as described below.

Creating a new scenario element

To create a new scenario element, select the type of element either through the Insert menu or by clicking on the appropriate button in the toolbar. The cursor will change into a vertical arrow:

At that point, clicking on an appropriate location inside the work area will insert the element and pop up a dialog box that allows the user to specify object-specific attributes. Once the parameters have been set to the desired values, pressing OK will insert the element into the scenario. Since each scenario element has its own custom dialog box, the associated options and their meaning are described in the section that focuses on each element.

Editing an existing scenario element

Existing scenario elements can be edited by double-clicking on the element or by right clicking on the element and selecting „Settings‟ on the pop-up menu. Following either of these actions will pop up the object-specific dialog box that allows the user to modify the element‟s attributes. Certain elements that have no visual representation (such as Initial Conditions), these elements can be set from the menu.

Rehearsal mode

The Mode toolbar’s second button is rehearsal mode. It allows execution of the current scenario. A scenario is executed by running on the PC hosting the ISAT the same scenario control software used on the simulator. Even though the software is the same, the evolution of the virtual environment between the simulator and the ISAT will differ because whereas in the simulator there is a human driver that controls the vehicle, when running in the ISAT there is no way to interactively drive another vehicle that represents the driver.

To Rehearse a Scenario

To rehearse a scenario:

• Load the scenario on the ISAT
• Click the rehearsal button on the mode toolbar
• Once the “Scenario Rehearsal” dialog box appears, click on Start
  • Double-click on any object to auto-center the map on that object
  • Double-click on an empty spot of the map to release auto-center
• Click stop to terminate the simulation
• Click Dismiss to go back to editing mode

Rehearsal Mode Notes

Note that it is possible to use an autonomous driver model to simulate the simulator driver, however, the autonomous driver model “pretending” to be the human driver will operate autonomously, and can only be constrained on its actions by using available authoring tools. So for example, a human driver may drive all over the lane, the ADO simulating the human driver would more likely drive by properly tracking the center of the lane. At the same time, it is possible to force the driver to change lanes by using the lane change dial. In general, having a simulated human driver is better than not having one, but its availability does not eliminate the need for actual testing on the simulator.

To activate the “simulated” human driver, simply define a Start Position and optionally a path (See section 3.11.1) for the ownership. During rehearsal mode, an ADO will be added to the simulation with the same start position as the ownership and the same path as the one assigned to the driver. The simulated human driver will trigger the same triggers as the human driver, and in general will have the same effects as if a human driver is operating the NADS.

When the Rehearsal mode button is pushed, a command window will appear and after a short period, the dialog shown the figure 3-12 will appear. (NOTE: initially, the dialog box will not show options below the “Advanced” button; press the “Advanced” button to toggle display of the full dialog box).

The rehearsal mode operates by running “frames”. Each frame is produced by running the behaviors and dynamics for a given time period. The data is then stored as a “frame” in the “buffer”. The buffer is a collection of frames, and can be navigated through just like a movie.

The slider above the start button can be used to navigate through the buffer, or by entering the frame number in the “Frame Number” box and hitting Enter. The status bar under Buffer shows how full the buffer currently is. The “Pause” button by the buffer, pauses the operation filling the buffer, this may improve playback quality. The status bar under “Frames” shows how far the playback has progressed in the buffer. Once the “Frames” progress bar is at 100%, the playback may have to wait for more frames to be placed in the buffer.

The “Stop” buttons stops the simulation, and clears the buffer, the “Pause” button pauses the playback. If you want to go back to a frame that has already been deleted in the buffer (see advanced options), you will have to hit Stop, then Start again the rebuild that frame.

Advanced Options

Pressing the “Advanced Options” button exposes additional options that can be used to fine-tune the simulation and how it is rendered. There are two groups of controls; the first group, titled “HCSM Debug Options” modifies how much information is presented by the behaviors during the simulation. The second group titled “HCSM Execution Options” controls the simulation time-step and ISAT rendering rate. Figure 3-13 shows the controls within the “HCSM Debug Options” group.

Figure 3-14 Graphics Debugging Example.

In general, debugging messages vary between different behavioral models and evolve to meet the need of the developers, but a few items are consistently provided and may be of use to users. It is possible to enable messages for a single behavioral instance (i.e., a single ADO or DDO), or for all elements in the simulation. Debugging messages can be provided as text, graphics or both. Depending on its importance, each message is classified as Routine, Normal or Urgent. To enable messages, first select the appropriate display mode (pick one of the four radio buttons on the top row), then pick which class of messages to display (pick one of the three radio buttons on the second row). Once the modality (text/graphics) and message class is selected, click on “Apply to all” to apply these settings to all current elements, or press “Apply to selected” to apply these settings on the element that is currently selected on the map. One important thing to remember is that these setting are applied when a frame is “run” not displayed. So if the buffer is at frame 2000, and the display is at frame 120 when one of the HCSM options is selected, you will not see the debug information until frame 2000 is displayed. If you select “Run in Lock-Step” this will insure the buffer will be no more than 1 frame ahead of the display.

Note that if you pick display of text messages, a new window pops up. That window will list messages as they are generated by the behavioral models. Graphics messages generate additional graphics on the ISAT map during the simulation. For example, Figure 3-15 shows how an ADO appears when graphics debugging has been turned on for that object. A blue arrow provides information on the target point used by the steering controller, and 3 messages appear around the driver showing current speed (in mph, on the upper right), the object id (on the upper left) and the current state used to control the ADO (on the lower left).

Figure 3-16 Graphics Debugging Example.

Figure 3-17 shows the “Advanced Options” group. The HCSM Execution Options group allows tuning the ISAT rendering rate. In addition, you can set the buffer size; the buffer is where ISAT stores the data for rehearsal playback. You can set whether ISAT will stop running frames when the buffer is full, by selection “Stop Filling Buffer”, or delete frames that have already been displayed by selected “Delete Frames at Start”. The “Stop at Death of External Driver” flag when selected will stop running rehearsal frames when the external driver has been removed from the simulation. The “Run in Lock-Step” option when enabled will only add frames to the buffer as needed by the display. For example, the rehearsal mode will wait for frame 119 to be displayed before adding frame 120 to the buffer. The rendering rate slider controls the rate at which the playback is shown in frames per second, with 30 being the normal playback speed.

Figure 3-18 Graphics Debugging Example.

Making a Scenario Rehearsal Movie

To facilitate documentation of scenarios, the ISAT allows making movies of the top down view of a simulation performed in rehearsal mode. To make a movie, there needs to be at least one codec capable of encoding video installed on the computer running the ISAT. A codec is software that “compresses and encodes” video to a data stream. In other words, it stores video data to a hard disk. Microsoft Windows 2000 and XP operating systems come with a few codecs that are appropriate for that task.

There are two methods to make a movie of a session. Both involve some necessary setup, but one method is more automated than the other is.

Figure 3-19 Movie Options Dialog Box.

To make a movie using the automated method:

• After getting into rehearsal mode, press the “Start Movie” button on the Scenario rehearsal dialog box – The dialog box shown in Figure 3-14 will appear
• Select the appropriate options as described later.
• Make sure that the check-box titled “Start Immediately” is selected
• Press OK. The Movie Options dialog box will disappear but the simulation will begin. All rendered frames will be saved on the specified file as an AVI movie. Once the predefined number of simulation time steps have finished, movie making as well as the simulation will stop. The ISAT will remain in rehearsal mode.

To make a movie using the manual method:

• After getting into rehearsal mode, press the “Start Movie” button on the Scenario dialog box – The dialog box shown in Figure 3-14 will appear.
• Select the appropriate options as described later.
• Make sure that the check-box titled “Start Immediately” is not selected
• Press OK. The Movie Options dialog box will disappear but nothing happens automatically. From that point on and until the “Stop Movie” button is pressed, all rendering of the ISAT will be accumulated into the file as another frame of a movie. Note that the ISAT renders the top down view for many different reasons: the user zooms in or out, the user changes the panning center, or a simulation time step elapses.
• Press Stop Movie to close the file and complete the movie.

Movie Making Notes

Both the automatic and manual movie-making mode makes use of several common parameters. At the same time, some of the parameters make more sense in automatic mode rather than manual mode.

In automatic mode, it is useful to have the top-down view automatically center on the simulated driver, or on any other object in the simulation. Enable the “Follow Driver” checkmark to auto- center the view on the simulated driver, or enable the “Follow Other” checkmark to activate the adjacent text field into which you can type the name of any of the objects that will act as the auto- center target. In manual mode, this setting is not as important as you can pan manually or select which object to auto center by double-clicking on it.

The name of the AVI file under which a movie is saved can be specified by typing the filename in the text-field titled “Save as:” Press the “Browse” button to select a specific directory or pick an existing file to overwrite.

By default, the size of each video frame is equal to the size of the ISAT window. You can select a different window size by resizing the ISAT window before getting into movie making mode, or by picking a window size from the drop-down menu titled “Window Size”. Note that some codecs have limitations on the size of each video frame. If the ISAT or any of its components crashes consistently when making movies, especially when using codecs that did not come with the OS, experiment with some of the pre-defined window sizes (all of them use multiple-of-8 screen sizes).

You can select the codec to be used for encoding the video and configure it by Press “Edit Movie Settings” to select the codec. A window similar to the one shown in Figure 3-14 will appear. The “Compressor:” drop down menu will include all available codecs. The “Configure” and “About…” buttons provide codec specific functionality and information. Depending on its capabilities, there may be additional windows that allow for setting the quality, compression ratio and other similar settings. Such windows are codec specific and are not covered here. Typically, there may be additional quick settings available on the “Select codec” window. In the example shown in Figure X, the selected coded (Intel Indeo Video 4.5) allows a single compression quality setting, in addition to other settings selectable after pressing the “Configure…” button.

Figure 3-20 Codec Selection Box.

When in automatic mode, you must type the first and last simulation step that you would like included in the movie in the text fields titled “Start Frame” and “End Frame” respectively. Simulation steps (or frames) are measured starting with 0. For example, to make a movie of the first 20 seconds of a scenario and assuming you have not changed the default simulation time steps, you would type 0 and 600 for the start and end frame respectively.

Monitoring Mode

The monitoring mode is a special mode that can only be used when the computer running the ISAT is within the NADS network. In this mode, the ISAT connects to the simulator’s real-time system, obtains information about the position and state of all visible entities in the virtual environment, and displays them in real time in the ISAT window. In addition, the user can “take control” of a single autonomous entity and control it though issuing certain high-level commands.

Figure 3-16 illustrates the dialog box that allows control of top down monitoring mode. The “Simulation Location” area allows specification of which simulator’s real-time system the ISAT should connect with. When “Other” is clicked, the user can specify an IP number of host name (assuming DNS is available) for the computer running the real-time scenario software. Once the host has been specified, pressing the “Connect” button initiates the connection. After a short delay, the ISAT will connect or print an error message indicating that it cannot connect.

Once a connection has been achieved, the main map window will display a top down view of the simulator’s virtual environment. The refresh rate may vary depending on the complexity of the map and the number of vehicles in the traffic.

The sub-area titled “Selected Vehicle Controls” is functional when the user has selected one of the vehicles in the virtual environment. It contains a variety of controls that can affect the behavior of the selected traffic element. Note that for these controls to work, the selected element must be an ADO, not a DDO. At the current version, the ISAT cannot tell the user if the selected object is an ADO or a DDO, so the user must be familiar with the scenario before using these controls. Three of these behaviors can be controlled; these are: intersection turning behavior, lane change behavior, and speed selection. Clicking on the radio buttons titled “Left” or “Right” will override the next turn decision that that traffic element has to make. For this to work, the button has to be pressed before the traffic element has committed to the turn; in addition, the turn should be feasible, i.e., the car has to be on the right lane or have enough time to make a lane change. Sometimes, the commit time is surprisingly early making it appear as if the control is not working. The two lane-change buttons operate in a similar manner; they send a command to the element indicating it should make a lane change of the appropriate direction. Finally, there are two speeds that can be set. The max speed limits the naturally occurring maximum speed selected by the traffic element. The traffic element may not reach that speed due to road curvature, other vehicles ahead etc.; however, if possible it will travel as fast as specified in the “Max speed” setting. The forced speed commands to the traffic element to travel at the specified speed, no matter what. The traffic element will ignore curvature, traffic lights, other traffic, and simply go as fast as command. This can cause major problems if abused.

Figure 3-21 Monitor Mode

The Movie settings allow recording the evolution of the scenario to a file. See section 3.3.2.2.3 for details on how to specify movie settings.

Playback Mode

The last ISAT mode is the Playback mode. This mode is integrated to provide playback of a simulation that took place on a simulator, provided specific data streams have been collected in a file using the NADS Data acquisition format (NADS DAQ). The NADS and SDM data collection system can be easily configured to collect this data, making it very easy to re-play simulations on the ISAT.

Once the playback mode is selected, a dialog box pops up to allow finer control of mode specific parameters. Figure 3-22 illustrates this dialog box.

The first thing that must be done is selecting the DAQ file to play back. Use the file selection button to bring up a file-selection dialog box. The NADS DAQ files contain data in a binary format that is very efficient for storage but not very efficient for random access. ISAT creates a TOC file for efficiently accessing this data. It may take several minutes to create this TOC file. The TOC file is stored in the same location as the DAQ file, and once created it is used to re-open the DAQ file efficiently. ISAT automatically looks for the TOC file in the same directory as the DAQ file. When copying a DAQ files from a location try to copy over the .toc file, as this will prevent ISAT from having to re-create the DAQ file. If a TOC file does not exist for a given file, and the permission for the directory the file is stored is read-only (such as on a The TOC file replaces the cache system that was used before.

It is important to note that if frames are dropped in the DAQ file some data output may not be 100% correct. Specifically the graph and frame search features may be off slightly due to dropped frames. In addition, any data that should have been collected in the dropped frame would be lost and not available. These errors are not common and in most cases only have minor effects on the accuracy of the data.

Figure 3-22 Playback Mode Dialog Box.

Once a file is loaded, the horizontal slide titled “Frame” will show the number of frames available in the DAQ file. The row of buttons immediately below the slider allows VCR-type control of the replay. Seven buttons are provided implementing the following functionality respectively: Play fast backwards, seek back one frame, pause, play, stop, seek forward one frame, and fast forward. In addition to these buttons, the slider itself can be moved around to seek to a specific place in the file. Moving the slider around will cause the main window to display, as fast as it can, the respective frames.

During replay, the Movie buttons can be used to record a movie. Please see section 3.3.2.2.3 on details on recording movies.

During replay, several controls allow fine-tuning the amount of information that is provided to the user. The “Show Text” and “Hide Text” buttons control display of extra labels associated with a selected traffic element. Figure 3-18 shows an example of one traffic element for which text display has been turned on.

Figure 3-23 Text Display Example.

In addition to text display, the Playback Mode dialog box displays the current frame as well as the number of traffic elements in the scene. It can also show an ongoing textual display of the values of any other variable that is present in the DAQ file. The value shown for each variable corresponds to the same frame as the animation. To display the value of any of the variables in the DAQ file during the playback do the following:

• Click the drop down menu titled “Names:”. Pick any of the variables you would like to see
• Press the button “Add Variable”
• Next time a new simulation frame is rendered, the value of the variable during that frame will appear in the window at the bottom of the dialog box.

Once a variable is displayed, you can remove it by selecting it in the list box and clicking the “Delete Variable” button.

Search Playback

As of version 1.1.31, a new Search feature has been added to the playback. This search feature has been added to allow the searching through the playback for instances for when a given statement is true. Such as Brake Pedal Force > .1, will return all the periods when the brake pedal force what greater than 0.1. This search feature can be accessed by clicking on the “Search Frames” button in Figure 3-22.

Let’s say we want to find where CFS_Accelerator_Pedal_Position is greater than .1 and the CFS_Steering_Whell_Torque is greater than .1. First, open the "Go to Frame" window by clicking on “Search Frames” as seen in Figure 3-24. From this window, we can build our expressions. Each expression needs 3 things, a Variable, an Operator, and a Value. By Clicking on the cell in the Variable column, it brings up a drop-down where we can select the available variables from the DAQ file. Likewise clicking on the “Opr” column will bring up a drop down where we can select the operator (+, <, >). The value is typed in. The “Param” column takes in the Column number of the variable to use. For instance if we have the variable SCC_LogStream and we want to compare the 3rd value of the variable we would put 3 in the column. If no value is placed in the param column, it is assumed that it is the first value. We can enter multiple expressions, should we run out of available spaces to enter expressions, we can click on the “Insert New” button, and it will insert a new row. The “LogOp” or logical operator column selects the logical operation to be performed between the current row and the next row, if no operation is selected then the AND operation is used. If the row is the last row in the expression then this column is ignore.

Once we have our expressions built, we hit the “Build List” Button. It then finds all there periods where our expressions are true. This can take several minutes depending on the length of the DAQ file. Once the list is built, you can click on the Frame number and it will advance the DAQ playback to that frame number.

We can also produce expressions that are more complex by clicking on the “Advanced” button. This will allow the creation of a text based expressions. The “(“ and “)” are used nesting the expression, each sub expression, such as CFS_Accelerator_Pedal_Position > 0.1 must be enclosed in “(“ and “)”. The following logical operations are allowed between sub-expressions AND, OR, | (or), & (AND). Also the expressions are case sensitive, so the variable CFS_Accelerator_Pedal_Position, must be typed in exactly, for example CFS_Accelerator_Pedal_Position, would not work as it does not match exactly.

Figure 3-24 Goto Frame

Playback Graph

Another new feature that has been introduced in the 1.1.31 release is the Graph feature. This feature allows the graphing of a variable for either the next minute from the current position in the playback or for the entire playback.

To select the variable that you wish to graph, first select it in the “Name” dropdown in the playback dialog (Figure 3-22). Then to graph the variable hit either the Minute Graph, to graph the variable for the next minute, or Full Graph, to graph the variable for the whole DAQ file. It may take a few minutes to generate the graph. The Minute Graph should take a lot less time to create than the Full Graph. Once done the GL Graph window will come up (Figure 3-25). The green line in the graph is the current position in the DAQ file. The mouse wheel stretches or shrinks the graph along the X- axis (width). Z and X shrinks and expands the graph along the Y-axis (height). The arrow key moves the graphs position, and the “Home” key resets the view back to original view. The value of the variable at the current position in the DAQ file is displayed in the lower left hand corner.

Figure 3-25 Playback Graph

Open Movie

When the Open Movie button is clicked, it brings up an open dialog button to open a movie file related to the current daq file. When the movie file is selected, it will be displayed in a pop-up window. As the daq file is played, it will synchronize the movie with the daq file. The “+/-“ button allows for setting an offset between the current video frame and the daq frame. Since the daq file and the video file will not always start at the same frame, it may become necessary to adjust the start position of the video. In order for this feature to work, your computer must have an mpeg-2 decoder capable of efficiently seeking.

Creating New Scenarios

This section describes how to build a new scenario. It is important to understand that a given scenario is always associated with a specific road network. As a result, the first step in creating a new scenario is selecting the road network on which this scenario will take place. Road networks are stored in files with the extension .bli.

To create a new scenario select the File->New menu option. The dialog box shown in Figure 3-26 appears.

Figure 3-26 Selecting the road map for a new scenario.

Select the appropriate road network and click on the Open button. After a brief delay (the delay will vary depending on the speed of the computer and the complexity of the selected road map), the road network will appear on the main window of the tool. It is now possible to author scenarios on that map.

Model and Object Pre-creation

During run-time operation, the simulator is very sensitive to processor or memory-intensive operations, including loading objects from the hard drive into memory. The effects of these operations typically exhibit as a momentary pause or 'hang', during which the display no longer updates. The duration of the hang can range from a few frames up to several seconds.

Fortunately it is possible to avoid these types of run-time hangs through "pre-creation". Objects are created by the scenario author at the beginning of each scenario they are required for. Their lifetime can be as short as 1 second; offsetting the creation time by .1-.2 seconds allows the simulator to process the pre-create object list efficiently. The pre-creation process will take a noticeable period of time, so it is necessary to inform the participant not to start driving until told do. On the MiniSim a message text can be displayed for this purpose, and then changed to “Begin driving..” after a pre-determined period of time.

Once an object has been created and then deleted, it is available in memory and the use of the object will not cause a creation hang later in the scenario. For multiple objects that share the same model type, only one pre-creation is needed on the MiniSim. The model will be loaded into memory after one pre-creation and multiple instances of it are created by duplication in memory instead of reading from the hard drive, so there will be no hangs.

Opening Existing Scenarios

To open an existing scenario, use the industry default File->Open menu option or use the Ctrl-O shortcut key. The dialog box illustrated in

Figure 3-27 appears.

This dialog box is the typical file-selection dialog, with one exception. It provides a text area to the right of the directory listing. Once a scenario file is selected from the file list, the text area on the right shows the comments associated with the scenario.

Clicking on the Open button opens the specified scenario file.

Figure 3-27 File open dialog box.

Navigating the Map

You can zoom in closer to see more details or zoom further out to see a better overview of the map. In addition, the center of the screen can be changed (panned). There are several ways to navigate around the map.

Navigating using toolbars

A few navigation shortcuts are available on the navigation toolbar:

Figure 3-28 View Toolbar

The leftmost button ensures that the left mouse button can be used to select elements as opposed to navigation. The second button places the tool in zoom mode. Zoom mode is indicated by the cursor shaped like a magnifying glass:

While in this mode, clicking the left mouse button (or rolling the mouse wheel backwards) on a location of the map makes that location the center of the screen and zooms closer to the scene. Repeatedly clicking on a point of interest can quickly zoom the view to that point. Clicking the right mouse button (or rolling the mouse wheel forward) anywhere in the map display zooms out but does not change the center of the screen.

The third toolbar button zooms and centers the map display so that it covers all scenario elements. This button is useful for quickly focusing on the area of the map where the current scenario is being developed.

The fourth toolbar button zooms and centers the map display so that it covers the entire road network.

The Follow Vehicle is the fifth button on the toolbar. It is only activated during rehearsal or monitoring mode. While in these modes, if the user selects one of the scenario elements in the virtual environment and then clicks on that button, the tool will maintain the same zoom but will pan the view port so that the selected element is always at the center of the screen. This functionality can be achieved also by double mouse click on the scenario element. This mode is useful for tracking a specific traffic element without having to adjust the map display continuously so the element is visible. If more than one element is selected before clicking the button, the view port will keep all of the selected objects in its view, panning or zooming out as necessary.

The sixth button, maintains the same zoom level, but pans the view so that the scenario start position is in the center of the display.

The button with the yellow question mark is used to bring up the find object window (Figure 3-29). Select the object from the list, click OK, and the view will pan putting that object in the center of the view field. The check marks at the bottom of the window filter the list. The refresh buttons refreshes the list and filter the list.

The check mark button brings up the verification tool. This tool checks the triggers for potential errors.

Figure 3-29 Find Object

Navigationg using keys

In any of the tool modes, the + and - keys located at the numeric row immediately above the main set of keys can be used to zoom in or out, respectively. Holding the Shift key while pressing + or - increases the amount of zooming performed at each button click.

The four arrow keys can be used to pan around the map. Again, holding the Shift key while pressing any of the arrow keys increases the amount of panning. Note that when clicking a particular arrow key, the map is re-centered as if the viewer has moved in the direction of the arrow key. For example, if the left arrow key is pressed, the map will be redrawn slightly to the left of its original position.

Navigating using Saved Locations

During scenario authoring, it is often useful to go back and forth between specific areas in the database. The ISAT provides the ability to save up to ten different viewpoints in the database and go between them by the click of a single button. To activate this functionality make sure the Saved Locations window is activated. To do so, selected, View->Saved Locations. The window shown in Figure X will appear. It contains two rows of numbered buttons. Buttons on the row titled “Save:” allow making a snapshot of the current view port. Buttons on the row titled “Restore:” allow returning to the respective viewpoint.

Figure 3-30 Saved Locations Window.

Note that initially all buttons on the Restore: row are grayed out, which indicates no viewpoint has been saved for the specific number. Once viewports are saved, the corresponding buttons on the Restore row become active. For example, in Figure 3-25 locations 1, 3 and 4 have memorized viewports.

To save the current viewpoint:

• Ensure the Saved Locations window is visible (click View->Saved Locations) if not.
• Click on any button on the Save: row (note that if the corresponding Restore: button is not grayed out, the previously saved viewport will be overwritten)

To return to a saved viewport:

• Ensure the Saved Locations window is visible (click View->Saved Locations) if not.
• Click on the button on the Restore: row that has the required viewport memorized

Navigating using the Navigation Window

A smaller overview window that shows the whole map can be continuously displayed as a way to provide a top view of the whole database. Select menu View->Navigation Window to activate or de-activate display of the navigation window. When the navigation window is visible, a red rectangle within it shows the current boundaries shown in the main ISAT window. Dragging the rectangle in the navigation window dynamically adjusts the viewpoint of the main window allowing quick panning to specific areas in the database.

Navigating using the cursor

While not in zoom mode, the right mouse button can be used to draw a rubber band rectangle that the tool will automatically use as an area to zoom into. The tool computes a center point and zoom factor so that every part of the rectangle is visible.

For example, consider Figure 3-31. The left side illustrates the rectangle formed by clicking and then dragging the right mouse button, and the right side illustrates how the tool draws the map after the right mouse button is released.

Figure 3-31 Rubber Banding to a specific area

Figure 3-32 Zooming to a specific area.

Selecting and Editing Scenario Elements

Selecting elements

In edit mode, scenario elements can be selected either in isolation or in groups. Selection can only take place in the pointer sub-mode (as opposed to zoom mode). To select a scenario element, simply click on it. The selected scenario element will be drawn in a different way to indicate its selection status. In general, a thick red rectangle is drawn around its bounding box. To select more than one element at a time, click on the first element, and then click on additional elements while holding down the Shift key.

Editing elements

To edit a scenario element, double-click on that element, or by right-click on the element and selecting the Settings entry from the pop-up menu. Note that the actual menu will depend on the type of scenario element, but there will always be a Settings entry. After either double-clicking or selecting the Settings option, a modal dialog box reflecting the current settings of the scenario element will appear.

Moving Scenario Elements

Moving a single scenario element

The technique and detailed outcome of moving a scenario element vary somewhat between elements. In general, to move a single scenario element, click on that element and then drag the mouse pointer across the screen. The element will move to follow the pointer. Once the mouse button is released, the element will be placed in the new location.

Note that there is quite a bit of customized behavior associated with different elements. For example, when moving a DDO, only the start position moves, not the whole trajectory. Similarly, when moving an ADO that has a path, the path is modified but not moved. If the ADO is moved to a different road altogether, or if it moved away from the road network, the path is lost. Moving a trigger or traffic source does not move the child elements, just the coordinator. Also, note that individual DDO path nodes can be moved using this technique.

Moving multiple scenario elements

To move multiple elements at the same time, select all of them (see section 3.7.1) and then hold down the Shift key while dragging the mouse pointer. All elements will be moved at the same time. The rules described in Section 3.8.1 still apply. For example, selecting two of the control points on the trajectory of a DDO and then applying a Shift-drag operation will move both control points at the same time.

Deleting Scenario Elements

Scenario elements can be deleted in several ways. You can select the element and hit the Delete key, or by right clicking on the element and selecting the delete option. Finally, you can select the element and then select the Edit->Cut menu option or use the associated shortcut key (usually Ctrl- X).

Undo

The ISAT supports multi-level undo functionality. After performing any action, select the Edit->Undo menu option to undo the most recent operation. Often, the actual label under the Edit menu will indicate the action that would be undone. For example, after issuing a Cut command that deletes a scenario element, the first option in the Edit menu would read Edit->Undo Cut. The Undo command can also be activated though the shortcut Ctrl-Z. Also, the and icons can be used for undo and redo.

Defining Simulator Initial Conditions

One of the first things that must be done when authoring scenarios is defining certain initial conditions that affect both the environment and the simulator driver’s vehicle when the scenario first starts execution. Note that ISAT allows the user to place the start position anywhere, although several limitations exist that ISAT does not enforce. For example, if the initial position is placed away from the road network, the vehicle dynamics will not be able to determine the elevation of the terrain, and the scenario will be interrupted. In addition, it is the ISAT user’s responsibility to place the initial position so that the simulator driver (subject) will not be surprised when the scenario begins (for example, because of an awkward orientation or high-speed heavy traffic nearby).

Specifying where to start

The ISAT allows specification of the simulator driver’s position when the scenario begins. To specify the initial position of the simulator driver, select the Insert->Initial System Conditions->Own Vehicle menu option. After selecting that option, the cursor turns into an insertion pointer:

Clicking the left mouse button inserts a vehicle at the position of the cursor. This vehicle represents the position and orientation of the simulator driver at the beginning of the scenario. Figure 3-33 illustrates the appearance of the vehicle representing the initial position. In addition to specifying the initial position of the simulator driver, the vehicle can act as the human simulator driver while in the rehearsal mode of the ISAT. This is achieved by using an ADO whose start point is the initial position of that vehicle. For all practical purposes (trigger firings, traffic manager, traffic light manager), this ADO acts as the human simulator driver.

Figure 3-33 Initial position vehicle

Specify a path

A path can be associated with the simulator driver. This path has a dual purpose. First, it can act as a mnemonic for the scenario author of the intended path of the simulator driver though the network. Second, when in rehearsal mode, the path is followed by the ADO simulating the driver. Naturally, when on the actual simulator, nothing can be done to ensure that the actual path taken by the simulator driver is the same as the path specified here.

To specify the path, right-click on the vehicle and select “Extend Path”. The cursor will change into this shape:

Click on points on the road network to extend the path. To extend the path, click on road locations that an actual vehicle could drive toward from the prior point (or the start of the path) without crossing more than one intersection. Each time a point is clicked, if the location can be connected to from the prior point, a set of blue boxes will outline the route. If there is no access to the new point from the prior point, the path will not be extended. To terminate the path selection, click anywhere with the right mouse button.

Changing the initial orientation

To change the orientation of the initial position right-click on the vehicle representing the start position, and then select the option “Rotate” in the context menu that will appear. After selecting that option, the start vehicle will rotate to follow the cursor. Click any of the mouse buttons when reaching the desired orientation. Note that the actual position does not change, only the orientation does.

Moving the initial position

To change the initial position, click and drag the left mouse button on top of the vehicle representing the start position. The initial position will change to follow the mouse cursor. When the left mouse button is released, the new position of the start vehicle will be set to the current position of the cursor. Note that when moving the initial position, the orientation does not change, but if a path has been specified, it is removed.

Specifying other initial conditions

In addition to the placement of the vehicle at the beginning of a scenario, the user can select conditions that affect various aspects of the simulator. All such conditions are collected in a single dialog box. To show this dialog box, select the Insert->Initial Scenario Conditions->Other menu option. The dialog box illustrated in Figure 3-34 appears. The dialog box contains various areas that allow specification of the following types of initial conditions.

Figure 3-34 Initial conditions dialog box.

Cab type

This selects the cab that the simulation is expected to use. Clearly, selecting this cab in the ISAT does not automatically force the specific cab to appear in the simulator. In fact, switching the physical cab can take as long as eight hours. Instead of a definition, this setting should be considered as a request, either when the scenario is developed by researchers who plan to submit their scenarios to NADS staff, or as a means to document the actual cab used for a particular study.

Motion drive and Settings file

These buttons and associated text-fields allow selection of the file that configures the motion system. This very specialized subject is not applicable unless scenario files are specifically targeted to the NADS, so no additional information is provided here.

BLI Path

If necessary, an alternative path where BLI files are stored can be provided here. By default, BLI files are stored in a directory contained in the NADSSDC_LRI environment variable.

Other Terrian

The NADS software can be configured to utilize a high-resolution low-latency terrain interrogation technique that is overlaid on top of the information contained in the BLI file. When that software is in use, the terrain file is specified here.

Motion subsystem scenario

The neutral position of the motion base is in the center of the NADS X-Y track, providing equal amount of travel space for braking or acceleration maneuvers and for left or right lane changes. When the actual maneuver is known a priori, the neutral position can be changed to favor the maneuver. Whereas this setting can be changed dynamically using triggers, it is also possible to define the neutral position at the time that the scenario starts. Pressing the “Select” button adjacent to the “Motion Subsystem Scenario Position” label pops up a dialog box shown in Figure 3-35. The dialog box allows selection of the default neutral position for the motion system. A top down graphic of the simulator dynamically changes to reflect the values typed in the text fields.

Figure 3-35 Motion Scenario Position

Collision Simulation

This setting allows the user to determine what happens when there is a collision between the simulator vehicle and a scenario element or a static object. There are two options. The first option stops the simulator, and the second option simply logs the collision and continues the run. Note that selecting “Log and Continue” does not necessarily include collision information in the DAQ file. The data collection specification must include the collision flag as part of the collected data.

Tire Conditions

The NADS can simulate various tire failure conditions. Specifically, any tire can be made to act as if it has worn tread or as if it were over or under-inflated. This setting specifies the initial conditions for all tires. The tire can be picked by using the drop down menu and the failure condition for that tire is picked by selecting any one of the buttons listed within the “Tire Condition” box.

Brake Conditions

The NADS can simulate various brake failure conditions. Specifically, either overall brake system failures or failures of brake modules on specific wheels can be simulated. This setting specifies the initial conditions of the failure state of the various brake systems and subsystems.

Other Vehicle Failures

This setting controls the initial conditions of various other failure conditions associated with the vehicle driven by the simulator driver.

Working with Components

Components are a mechanism by which scenario elements can be grouped together for re-use.

Emailing Scenarios

To e-mail the current scenario, select the File->Email Scenario menu option. The default e-mail program will appear with an attachment that contains the current scenario.

Printing the Map

To print the map, select the File->Print menu option. In addition, all standard Windows print dialog boxes work as expected, including Print Preview and Print Setup. Note that only the area of the map displayed on the tool’s work area is printed. As a result, be sure to adjust the view port as necessary before invoking the Print menu. If in doubt, use Print Preview to ensure that what will be printed is what is intended.

Adding Scenario Comments

To associate a textual comment with a scenario, select the Edit->Scenario Comment menu option. It is recommended that long descriptive descriptions be added for each scenario to make it easier to remember the goals of a scenario that was built by others. Keep in mind that the scenario comment appears in the preview window when opening an existing scenario file (see Section 3.5 for more details).

Comment Objects

When authoring a scenario it often becomes necessary to create complex events made up of multiple triggers and actions. Because of this, it may not be easy to understand the purpose of a specific group of triggers and other scenario elements when looking at them. It may then be necessary to insert a comment object to describe the goal of a group of scenario elements. This is particularly true if the scenario is likely to be reused in the future. The comment object is denoted by a piece of paper, and is inserted just like any other scenario object. If you double click on the comment object, it brings up a text box. The contents of the text box are stored in the scenario. Scenario objects are only used by ISAT in editing mode, and will not affect anything else.

Figure 3-36 Comment

Defining Common Scenario Element Parameters

For consistency and ease of use, most scenario elements use a similar definition method with a tabbed dialog box where the user can specify the various parameters. These dialog boxes are scenario element-specific; however, they all contain a set of common parameters that have similar functionality, independent of the scenario element. These parameters are defined below.

Name

The name of a scenario element is used to identify that element in the scenario. The ISAT does not force scenario elements to be unique, so it is up to the user to ensure that when a scenario element will be referenced somehow in the simulation, then that name should be unique.

Creation Radius

The creation radius is a threshold in the distance between the scenario element and the position of the simulator driver. At runtime, the element will not be created until the actual distance between the position of the simulator driver and the scenario element is less than or equal to that threshold. For example, consider a scenario element placed at position (0, 0), a creation radius of 300, and an initial position for the simulator driver at location (500, 0). When the scenario begins, the actual distance will be 500, which is larger than 300. Therefore, the scenario element will not be created. What this means in the simulator is that there will be no visible entity at location (0, 0). Furthermore, the computational load on the scenario caused by this element is minimal. Now consider the situation where the simulator driver is driving toward the location (0, 0). The range between the scenario element and the driver is continuously monitored, and when that range gets below 300, the scenario element will be created. In the above example, this will take place when the driver reaches the location (300, 0). The actual effect of the creation varies depending on the nature of the scenario element. For example, if the scenario element has a visual representation (it could be, for example, a stopped vehicle), then this is the time when that vehicle will appear in the simulator’s virtual environment.

The creation radius only affects when a scenario element is created; it does not affect the deletion of a scenario element. In other words, if after creation the range between the driver and a scenario element exceeds the creation radius, the scenario element will not be deleted automatically.

Note that the range between the scenario element and the driver is measured along a straight line, not along the road network. It is the user’s responsibility to ensure that the creation radius is large enough or that the initial position of the scenario element is occluded so that the simulator driver does not observe the creation of the scenario element.

The rationale for having a creation radius is twofold. First, it helps manage the computational load of the system by not creating scenario elements until near the time they will be used. Second, it can be used as a simple authoring mechanism where the rough timing of events is controlled by the motion of the simulator driver.

In the ISAT, a creation radius is shown as a red circle around the element. The default value for the creation radius is 0, which indicates that no such constraint is in effect and the scenario element will be created at the beginning of the scenario.

Activation Delay

The activation delay is the number of seconds between the time a scenario element is created and the time its behavior is engaged. The default value for this parameter is 0, indicating that an element will begin acting as its behavior dictates immediately upon its creation. Note that, upon creation, the visual representation of that element, if any, will appear in the simulator’s virtual environment, even if an activation delay is in effect.

The activation delay is often useful in conjunction with a creation radius. Using a larger than needed creation radius can help minimize the chance that the simulator driver will observe an object popping out of nowhere, and the activation delay can ensure that the object does not begin its activity until the driver is closer. For example, consider a DDO vehicle that is programmed to begin traveling at 50 mph, has a creation radius of 500, and has an activation delay of 3. Once the driver gets within 500 feet of the DDO, the DDO will be created and the vehicle will appear in the virtual environment. However, another 3 seconds have to go by before the DDO will begin moving.

Lifetime

The lifetime is the maximum number of seconds that a scenario element will exist. The time of existence begins when the scenario element is created. Once the lifetime is reached, the element is automatically deleted. Like the other parameters, the lifetime is useful in controlling the computational load of a scenario. Having a finite lifetime ensures that a scenario element does not consume computational resources long after it has performed its task within the scenario.

The default value for the lifetime is 0, which indicates that the maximum lifetime will extend until the end of the scenario (unless, of course, the element is explicitly deleted through other means).

It is the user’s responsibility to ensure that the lifetime, if specified, is large enough to ensure the scenario element is not close enough for the driver to observe its disappearance.

SOL Model

Most scenario elements have a visual representation associated with them. It is important to realize that, in general, the visual representation is decoupled from the behavior of a particular object. Behavior refers to whether the object is a DDO, ADO or static. Visual representation refers to what the object looks like. The visual representation is selected among existing objects contained in the Scenario Object Library (SOL), a library containing numerous objects, their visual representations, and additional properties such as their audio signatures or terrain effects. Objects in the SOL are grouped in categories. Objects in the same category have similar properties and are conceptually similar. For example, all objects of category Truck have a parameter “weight”; however, each object can have its own value for that parameter. At this point, the actual parameters and their values are not visible to the user but are maintained by the SOL internally. See Appendix A for a detailed description of the SOL categories and objects.

The SOL model to be used for all behaviors is selected through a consistent tab in the scenario element’s dialog box. Figure 3-37 illustrates this dialog box tab, as shown within the DDO definition dialog box. There are two components to the dialog box. On the left, a list box contains the SOL categories in a two-level hierarchical tree display. The top level is the category name and the lower level is a listing of the available object types in that category. For example, as shown in Figure 3-37, the category EmergVeh contains two object types named Ambulance and PoliceCar. Clicking on an object highlights the entry and at the same time displays a visual representation of the object on the right side of the dialog box. The selected entry is the one that will be used for the behavior of the object being authored by the dialog box.

Figure 3-37 The SOL selection dialog tab.

Keep in mind that the actual SOL categories appearing on the left side of the dialog box will vary depending on the actual behavior of the enclosing dialog box. Specific SOL categories will be omitted when it makes no sense to associate an object of that category with a behavior. For example, there is an SOL category named "Signs" whose objects are various regulatory signs. This category does not appear in the SOL selection list shown in Figure 3-37, which is used for defining DDOs. Associating a sign object with a DDO would result in a sign that moves about the virtual environment.-

Occasionally, there will be objects that have no convenient visual representation. For example, there is a category named POI which stands for Points of Interest. It includes objects such as audio generators that cause sound effects in the virtual environment but have no visual representation. The picture displayed for such objects is a red X.

The SOL has been designed so it can be extended with additional objects or even additional categories. Adding new objects involves creating entries for the various NADS-correlated databases, such as the visual and audio databases, and rebuilding the NADS software. Although this process is not complicated, it requires access to all the NADS software and intimate knowledge of the software’s structure. Therefore, it is not possible at this time for ISAT users to extend the SOL.

Buttons and Dials

All scenario elements that can be authored by ISAT exhibit some form of behavior when activated in the virtual environment. The complexity of this behavior varies. By far the simplest behavior is associated with the Static Objects. Specifically, they appear and stay put in a fixed location in the database. The ADOs exhibit the most complex behavior through their driver model. To allow orchestration of events within scenarios, the default behavior of the various scenario elements can be changed at runtime. The mechanism used to implement behavior changes is access to buttons and dials. Buttons and dials are conceptual models for inputs associated with each behavior type and operate much like physical push buttons and analog dials everyone is familiar with. Specifically, a button is an input mechanism that when pressed, provides a one-time binary signal to the behavior. Similarly, a dial is an input mechanism that, when set, provides a perpetual analog signal to the behavior. The actual effect of the delivered signal depends on the behavior itself, the state of the scenario element when the signal is received, and the button or dials itself.

For example, consider an imaginary dial associated with the DDO behavior. The name of the dial is Speed. Setting the dial has the effect of changing the speed of the DDO for the remainder of its lifetime. As another example, consider an imaginary button associated with the ADO behavior. The name of the button is TurnLeft. When pressed, this button signals the ADO that it should take the next turn to the left rather than whichever direction it was going to take.

Note that buttons and dials provide a "suggestive" means of control, not an explicit one. This implies that a given behavior may decide to ignore a signal delivered though a button or dial if it cannot gracefully fulfill the request. For example, if the TurnLeft button press came at a time when it was not possible to make a left turn, that request would not be fulfilled. At the same time, if a particular behavior defines that a given button or dial has a direct effect, then the responsibility of reasonable behavior is passed to the user. Again, consider another example of a dial associated with an ADO named ForceVelocity. If this dial is set, the ADO will travel at that velocity, no matter what. However, setting the speed to a fixed value could cause collisions or make the car run off the road.

For each type of behavior that can be authored by the ISAT, this document will provide a listing of all buttons and dials and a description of how they will affect the behavior at runtime. At runtime, the actual pressing of buttons and setting of dials is done though coordinators such as the trigger or, to some limited extent, interactively by the user though the ISAT. The rehearsal mode of the ISAT can then be used to execute the scenario and verify that the runtime behavior is what was expected.

Group Bar

The group bar has many useful features, mostly dealing with groups. A “group” is a group of scenario elements. The go to button cycles through the group members whereas the select button selects all the members of the group.

Groups can be saved to a file, or loaded to a file. To save a group select the group name in the group combo box, and hit the “Save Group” button. This saves the group to a .grp file. This file can be loaded into other scenarios. To load a group from a file hit the “Load Group” button. The Add Ref. button will bring up the external references window. From here, you can add and remove external references. The left hand side of the colon in Figure 3-39 is the scenario name the reference is from, and right hand side is the group name.

The difference between adding a reference, and loading a group from a file, is that the when adding a reference, the group is stored in the original scenario, and cannot be changed in the current scenario. The group members can be changed by making the changes in the original scenario. Loading a group from a file, adds the group to the .SCN file. The elements from the group are just like any other element, and can be changed in the current scenario. Changes to the original group (*.grp) file will not have an effect on the scenario elements that have already been loaded.

Scenario elements can be added to a group by right clicking of them and selecting the group menu, from the context menu. A check will appear next to the group name the element belongs to. The “New Group….” option will allow you create a new group, and add the currently selected element or elements to the new group. Note: you cannot change group membership through use of the group drop-down on the group bar; this is new as of version 1.5.0.

The right most three edit-boxes in Figure 3-38 can be used to set the current screen resolution and zoom level. This is useful for recording movies as it allows the setting of the exact resolution and zoom level. Hit the set button to set the resolution and zoom level to the values specified in the edit-boxes. To change the zoom and not the resolution, leave the two resolution boxes empty (the two boxes on either side of the X) and hit set. Conversely to change the resolution and not the zoom leave the Zoom box empty and hi the set button.

Figure 3-38 Group Bar

Figure 3-39 External References

Preferences

ISAT preferences can be set by opening the preferences windows through Edit- >Preferences menu. The preferences window has 5 tabs controlling Colors, Displays, Status Bar, General Settings, and Verify preferences.

The Color manger tab, as it the name suggests is where you can set the display colors for the map. You can set the road color, color of the background and other settings.

The display tab allows you to set some general display options. Currently the only two options in this tab are, Show Exact Roads and Show Control Points. The control points will show up as small X’s on the screen as seen in Figure 3-41. Show exact roads forces ISAT to use an exact representation of the roads instead of a slightly simplified model that it usually uses. This feature as of version 1.1.36 does not work. This may be fixed in future versions.

The status bar settings tab allows you to set the information that is displayed on the bottom of the screen. Information such as x,y coordinates and Speed Limit can be set here.

The General Preferences tab includes two options, Automatically Check ISAT for Updates, and Auto-Save. The Automatically Check for ISAT Updates option when enabled ISAT checks on the local network if a new version of ISAT is available when ISAT is first opened. If a new version is available then ISAT will prompt the user if they want to update to the new version. The Auto-Save options saves a back up copy of the current scenario being edited every 5 minutes. If no changes to the document have been made or the document is not in edit mode then no back up files will be saved. ISAT saves the files as Your-Scenario- Name.SCN.BAK. In order to restore a back up, rename it to your-scenario.scn and open it up in ISAT as usual.

The Verify Preferences tab sets the Verification tool preferences. The Verify at Save option is set, ISAT launches the verification tool at save, if any errors are found the verification window is then displayed.

Figure 3-40 Preferences

Figure 3-41 Control Points

Authoring Deterministic Dynamic Objects

Behavior

Deterministic Dynamic Objects (DDOs) are objects with no autonomous behavior. These objects follow a pre-scripted path in the virtual environment. There are two types of DDOs: regular and dependent. Regular the user specifies the velocity, whereas dependent DDOs the velocity is controlled relative to the closure rate of another object toward a target point.

The trajectory of a DDO is described by a series of user-specified control points. During scenario execution, the DDO follows a path that visits all control points in order. The exact path is set using a geometric spline to smooth the motion of the DDO between control points. The DDO always starts at the beginning of the trajectory, which must be placed at a point of the virtual environment that contains underlying terrain. All intersections, roads, and the road shoulder including various SOL objects provide terrain information. Control points other than the first one can be placed on points in the virtual environment where there is no terrain. When the DDO crosses from a point with terrain to a point with no terrain, it uses the most recent value from terrain elevation. If the path crosses into an area that provides elevation again, then the DDO will then use the new elevation.

The execution of DDOs is also controlled by the three standard parameters: creation radius, activation delay, and lifetime. These were described in detail in Section 3.17.

The velocity of regular DDOs is explicitly specified by the user at each control point. When traveling along the path, the DDOs velocity will be at the specified value for the control point it is crossing; when it is between two control points, the velocity will be linearly interpolated.

Figure 4-42 illustrates two DDOs as they appear on the ISAT's top down map.

The DDO scenario element is rendered using the actual top down representation of the object in the SOL, and the path of the DDO is shown as a series of points connected by a line. The line uses the same spline interpolation technique that is used by the DDO at runtime, resulting in the display of the same path the DDO will traverse at runtime. When selected, a DDO will be drawn with a red outline. In addition, a circle will be drawn to indicate the activation radius, as in the top DDO shown in.

Figure 4-42. If no such circle appears, the DDO has no defined activation radius.

File:Tdmap3.png

Figure 4-42 Appearance of DDO’s.

Dependent DDO Velocity Control

As described earlier, the key difference between a DDO and a DDDO is the method by which their velocity is determined at runtime. The DDO's velocity is explicitly specified at every control point. On a DDDO, however, the speed is controlled by the relative motion of another object in the simulation. To achieve this, a DDDO has three more parameters associated with it. These are the target control point, the controlling object, and the controlling object target location. The target control point is one of the control points on the DDDO trajectory. The DDDO will continuously adapt its velocity so that it arrives on the target control point at the same time that the controlling object arrives at the target location. For example, consider the illustration in Figure 4-2.

Figure 4-43 Dependent DDO illustration.

The DDDO is shown traveling south on the road controlled by the STOP sign. The highlighted control point is acting as the target control point. The controlling object is traveling from right to left, and its target location is shown with a red striped circle. In this example, the DDDO will adjust its speed so that no matter how fast or how slow the westbound vehicle is traveling, the DDDO will arrive at the target control point at the same time that the vehicle arrives at the target location.

Once the DDDO reaches the target control point, it will continue on its trajectory using the velocity specified at the control points.

Note that the DDDO will never go backwards, including the case where the target location is defined such that the controlling object is traveling away from it. In such a case, the DDO will stop (i.e., the minimum attained velocity will be zero).

ISAT Scripting

ISAT uses a custom language (ISC) to automate placement and manipulation of scenario objects. Combined with simple direction commands and the capability to navigate a road network, ISC scripts can ask the scenario author for input and prompt for selecting objects.

Scripts are an efficient way to automate repetitive and/or complex tasks.

ISAT installs with some ISC script files. If your version of ISAT contains a data\isc folder, then your version of ISAT is capable of running scripts. You can create additional scripts as needed. All scripts located in the data\isc folder will load in ISAT when ISAT is launched.

New scripts created during an existing ISAT session will not appear until ISAT is re-launched.

Scripts that have been edited will not update until ISAT is re-launched.

You can use these scripts for reference in creating your own custom scripts.

Unless otherwise indicated, scripts are case-sensitive.

NOTE: Please do not edit the existing scripts!

Make a copy of any existing script before you make changes. In the event your modified script does not work, you can look at the original file for reference.

Icon Files

Script icon files are 8-bit windows icon files (file.ico). GIMP is capable of exporting valid ico files. To create an ico file, scale it to 32x32 pixels. Export the file as .ico to the isat\data\isc folder.

In order for a script to use an icon file, both files must exist in the isat\data\isc folder.

Examples

This section contains example scripts.

Rotate sign

# prompt author for a sign to rotate

.Name SetSignRotation

.Icon SignRot.ico

Static sign

Select(sign,"Please Select a Sign")

sign.SetAngle(Anchor)

.End

Reference

File:ISC_Image2011_ISC.pdfImage ISC Paper