|
|
| (3 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| | + | [[ISAT_User%27s_Guide_Table_of_Contents|ISAT User's Guide Table of Contents]] |
| | + | |
| | + | [[Authoring_Expression_Triggers|◄PREVIOUS]] [[Introduction_II|NEXT►]] |
| | + | |
| | ==Visual Trigger Representation== | | ==Visual Trigger Representation== |
| | | | |
| Line 11: |
Line 15: |
| | [[File:979.png|600px|thumb|center|'''Figure 9-79 Icon areas.''']] | | [[File:979.png|600px|thumb|center|'''Figure 9-79 Icon areas.''']] |
| | | | |
| | + | [[#top|TOP]] |
| | The trigger type icon reflects the predicate used by the trigger. Figure 9-80 illustrates all trigger types side by side. Depicted from left to right are the global time trigger, road pad trigger, time to arrival trigger, traffic light trigger, and geometrical position trigger. | | The trigger type icon reflects the predicate used by the trigger. Figure 9-80 illustrates all trigger types side by side. Depicted from left to right are the global time trigger, road pad trigger, time to arrival trigger, traffic light trigger, and geometrical position trigger. |
| | | | |
| Line 20: |
Line 25: |
| | The Trigger Action icon pictorially represents the first action associated with the trigger. There is a distinct icon for each available trigger action; however, only the first action is depicted. If many actions are defined, the user has to use the dialog box to review the remaining actions. The Action Cardinality indicator can be useful in determining if actions other than the one depicted by the trigger action icon are defined. Figure 9-81 illustrates all iconic representations of the trigger actions. Depicted from left to right and top to bottom are the Create Element, Delete Element, Press Button, Set Dial, Select Traffic Manager Set, Play Audio, Vehicle Failure, Set Traffic Light, Log Data, Terminate Simulation, Pre-position Motion Base, Tune Motion Base, and Initiate Phone Call actions. | | The Trigger Action icon pictorially represents the first action associated with the trigger. There is a distinct icon for each available trigger action; however, only the first action is depicted. If many actions are defined, the user has to use the dialog box to review the remaining actions. The Action Cardinality indicator can be useful in determining if actions other than the one depicted by the trigger action icon are defined. Figure 9-81 illustrates all iconic representations of the trigger actions. Depicted from left to right and top to bottom are the Create Element, Delete Element, Press Button, Set Dial, Select Traffic Manager Set, Play Audio, Vehicle Failure, Set Traffic Light, Log Data, Terminate Simulation, Pre-position Motion Base, Tune Motion Base, and Initiate Phone Call actions. |
| | | | |
| | + | [[#top|TOP]] |
| | [[File: 981.png| 600px| thumb | center | '''Figure 9-81 Iconic representation of all trigger actions.''']] | | [[File: 981.png| 600px| thumb | center | '''Figure 9-81 Iconic representation of all trigger actions.''']] |
| | | | |
| | Finally, the target set area provides an iconic representation of how the trigger's target set is determined. The precise iconic representation is currently under development, and an initial method of using the first letter of the set is utilized (e.g., T for type, N for name, etc.). | | Finally, the target set area provides an iconic representation of how the trigger's target set is determined. The precise iconic representation is currently under development, and an initial method of using the first letter of the set is utilized (e.g., T for type, N for name, etc.). |
| | | | |
| | + | [[#top|TOP]] |
| | ==Using Triggers to build Scenario Events== | | ==Using Triggers to build Scenario Events== |
| | | | |
| Line 36: |
Line 43: |
| | The intended usage of certain trigger actions should be very clear. For example, the Terminate Simulation action can be used to deterministic stop the simulation either when the driver reaches a particular point or after a fixed amount of time. Therefore, a global time trigger whose action is to terminate the simulation provides a convenient way to ensure that all subjects in an experiment drive for exactly the same time. Other actions are much more flexible. For example, setting the dial of a traffic element is a powerful way to modify the behavior of traffic. When using such actions, it is critical to use the ISAT’s rehearsal mode to verify that the actual behavior is what was intended. | | The intended usage of certain trigger actions should be very clear. For example, the Terminate Simulation action can be used to deterministic stop the simulation either when the driver reaches a particular point or after a fixed amount of time. Therefore, a global time trigger whose action is to terminate the simulation provides a convenient way to ensure that all subjects in an experiment drive for exactly the same time. Other actions are much more flexible. For example, setting the dial of a traffic element is a powerful way to modify the behavior of traffic. When using such actions, it is critical to use the ISAT’s rehearsal mode to verify that the actual behavior is what was intended. |
| | | | |
| | + | [[#top|TOP]] |
| | When using actions that affect other scenario elements, the selection of the Target Set (i.e., the scenario elements that will be affected by the trigger) is critical. There are several ways to select the Target Set, each with its own advantages and disadvantages. In addition, multiple constraints can be used to define the Target Set. When multiple constraints are specified, they must all be satisfied for a scenario element to make it in the final Target Set. In other words, the constraints are combined with a Boolean AND operation. Further considerations for each constraint are given below: | | When using actions that affect other scenario elements, the selection of the Target Set (i.e., the scenario elements that will be affected by the trigger) is critical. There are several ways to select the Target Set, each with its own advantages and disadvantages. In addition, multiple constraints can be used to define the Target Set. When multiple constraints are specified, they must all be satisfied for a scenario element to make it in the final Target Set. In other words, the constraints are combined with a Boolean AND operation. Further considerations for each constraint are given below: |
| | | | |
| Line 48: |
Line 56: |
| | *The Instigator Set indicates that the trigger will affect the same objects that caused the trigger to fire. A simple example of using it is in defining a traffic sink (i.e., a place in the road network that deletes any scenario element that travels there). To implement this, select the action "Delete" with the Target Set specified as Instigator Set. Another issue to consider when using the Instigator Set is that various triggers provide additional flexibility in defining the Instigator Set. For example, a road pad trigger may fire because three vehicles stepped on the pad simultaneously. Alternatively, a trigger may have an activation delay so that by the time the trigger is activated, there are numerous vehicles on its pad. All such vehicles would belong to the Instigator Set unless the trigger parameters specified in the Specific tab in the Trigger dialog box further trim the Instigator Set. | | *The Instigator Set indicates that the trigger will affect the same objects that caused the trigger to fire. A simple example of using it is in defining a traffic sink (i.e., a place in the road network that deletes any scenario element that travels there). To implement this, select the action "Delete" with the Target Set specified as Instigator Set. Another issue to consider when using the Instigator Set is that various triggers provide additional flexibility in defining the Instigator Set. For example, a road pad trigger may fire because three vehicles stepped on the pad simultaneously. Alternatively, a trigger may have an activation delay so that by the time the trigger is activated, there are numerous vehicles on its pad. All such vehicles would belong to the Instigator Set unless the trigger parameters specified in the Specific tab in the Trigger dialog box further trim the Instigator Set. |
| | | | |
| | + | [[#top|TOP]] |
| | Finally, try to utilize the triggers’ ability to have multiple actions associated with them. A scenario will execute faster and be easier to understand if it uses fewer triggers that do more things, as opposed to numerous triggers that have the same predicate but do different things. | | Finally, try to utilize the triggers’ ability to have multiple actions associated with them. A scenario will execute faster and be easier to understand if it uses fewer triggers that do more things, as opposed to numerous triggers that have the same predicate but do different things. |
| | | | |
| | + | [[#top|TOP]] |
| | ==Verification Tool== | | ==Verification Tool== |
| | | | |
| Line 58: |
Line 68: |
| | [[File: VerificationTool.png| 600px| thumb| center|'''Figure 9-82 Verification Tool''']] | | [[File: VerificationTool.png| 600px| thumb| center|'''Figure 9-82 Verification Tool''']] |
| | | | |
| | + | [[#top|TOP]] |
| | ==Data Reduction Graph== | | ==Data Reduction Graph== |
| | | | |
| Line 70: |
Line 81: |
| | '''Reusing Scenario Components''' | | '''Reusing Scenario Components''' |
| | | | |
| − | ==Introduction==
| + | [[#top|TOP]] |
| − | | + | |
| − | Reuse is a desirable characteristic of any system that involves the development of detailed and laborious specifications. The ISAT allows the specification of numerous attributes associated with a virtual environment with the goal of providing deterministic and repeatable events to the simulator driver. Many of these specifications can take a lot of time to develop and tune, so it is desirable to have the ability to reuse them in other scenarios. The ISAT utilizes a component merge capability whose goal is to allow reuse of components that have been developed in other scenario files.
| + | |
| − | | + | |
| − | In general, when two scenarios use the same synthetic environment, any scenario elements can be used in either scenario. However, using scenario elements defined in the context of one synthetic environment in another scenario that uses a different synthetic environment is problematic. The key problem is the remapping of references to road network locations or objects that exist in one synthetic environment but may not exist in the other. Reusing a scenario event that utilizes a group of scenario elements in different parts of the same map poses similar problems. For example, a near-collision scenario caused by an ADO forced to run a red traffic light should be usable in any intersection, as long as it uses traffic lights. However, there are numerous issues involving the preservation of temporal relationships and event perception that cannot be easily addressed.
| + | |
| − | | + | |
| − | Because the solution of these problems is an active area of research, the ISAT utilizes two simpler methods to allow reuse. The first involves the use of Copy and Paste operations to reuse single scenario elements, and the second uses a Component Merge capability for reusing additional components.
| + | |
| − | | + | |
| − | ==Reuse through Copy and Paste==
| + | |
| − | | + | |
| − | The Copy and Paste capability of the ISAT, combined with its multi-document interface design, can be used to copy elements from one scenario to the other. Specifically, the Paste operation allows the user to specify a new location on the road network of the new scenario that overrides the old location of the element. This allows reuse of scenario elements even across scenarios that use different synthetic environments.
| + | |
| − | | + | |
| − | This approach becomes problematic, however, in cases when many individual scenario elements have to be copied (as in the case of having manually placed numerous static objects all over the map), or for high-level coordinators such as the TM or TLM that cannot be copied to the clipboard. For such cases, use of the Component Merge capability can provide a solution.
| + | |
| − | | + | |
| − | == Reuse through Component Merge==
| + | |
| − | | + | |
| − | Component merge is a special operation activated by selecting Merge Components from the File menu. The dialog box shown in Figure 10-84 appears.
| + | |
| − | | + | |
| − | [[File: 1084.png| 600px|thumb|center|'''Figure 10-84 Selecting a scenario from which to merge components.''']] | + | |
| − | | + | |
| − | Select any scenario file that uses the same LRI (the virtual environment), whose components are to be reused. The dialog box shown in Figure 10-85 appears when '''Open''' is clicked.
| + | |
| − | | + | |
| − | [[File: 1085.png| 600px |thumb|center|'''Figure 10-85 Component Merge dialog box.''']]
| + | |
| − | | + | |
| − | Four separate components (TM, TLM, static objects, and global environment conditions) can be merged into the current scenario by selecting the appropriate check boxes. Note that only components that are actually defined in the selected scenario file are enabled. In the example shown in Figure 10-85, only the TLM is available for import.
| + | |
| − | | + | |
| − | When the TM box is selected, all TMIS are imported in the current scenario and added to any existing TMIS in the current scenario. Any TMIS in the current scenario with the same name as merged TMIS are over-written.
| + | |
| − | | + | |
| − | When the '''Static Objects''' check box is selected, all static objects defined in the new file are imported to the current scenario. Existing static objects are left untouched.
| + | |
| − | | + | |
| − | When the''' Global Environment Conditions''' check box is selected, the default (global) environment conditions in the new file are used in the current scenario, overwriting any pre-existing conditions in the current scenario.
| + | |
| − | | + | |
| − | Finally, when the Traffic Light Manager check box is selected, the traffic light settings for CLGs in the new file are brought into the current TLM set, overwriting any current settings.
| + | |
| − | | + | |
| − | In addition to global components, the Component Merge dialog box gives a list of individual traffic elements in the new file. Selecting any of them will copy them to the current file using their exact same placement and properties.
| + | |
| − | | + | |
| − | ==Reuse through Groups==
| + | |
| − | Groups can be used to store groups of objects in a separate file. This allows these groups to be imported in other scenarios or linked to another scenario. When a group is imported, it adds a copy of the group to the scenario file. Any changes to the elements in these groups will not affect the original group file. When a group is linked or added as an external reference, this adds a reference to the file in the scenario file, and does not store the actual members of the group. This means that when a group files is added as external reference the group file must always be kept with the file. In addition, you cannot modify members of groups that are added as external references. This has the advantage of allowing a single section of a scenario to be saved as a group and used across multi scenarios. Groups are discussed in detail in section 3.18.
| + | |
| − | | + | |
| − | '''Appendix A: Authoring a Lead Vehicle Pull Out (LVPO) Event'''
| + | |
| − | | + | |
| − | This section is a tutorial designed to help a beginning scenario author to develop their first useful scenario. In this particular example, we are going to demonstrate Lead Vehicle Pull Out (LVPO) event. A LVPO event is when a car pulls out in front of the external driver (participant), in this particular example when a the external driver approaches a intersection we are going to have a vehicle pull out in front of them, effectively cutting them off.
| + | |
| − | | + | |
| − | [[File: 1086.png|600px |thumb|center|'''Figure 10-86 LVPO''']]
| + | |
| − | | + | |
| − | For this tutorial, you may select any LRI with a 3 or 4-way intersection with traffic lights. For this example, we chose WirelessUA.bli, and used the southern most intersection.
| + | |
| − | | + | |
| − | '''Step 1'''
| + | |
| − | | + | |
| − | Place the external driver. The external driver represents the participant vehicle in the simulation, for this example we need to place the driver significantly far away from the intersection that our event is to take place. The driver must take longer than 10 seconds to travel from there starting point to the intersection. To place the external driver, go to Insert->External Driver in the main menu. This will allow you to insert the external driver like any other scenario element. Once the external driver has been place, you can edit some of the external driver settings by going to Edit->Initial Condition. This will bring up the initial conditions dialog that which will let you change the cab type and make other general changes.
| + | |
| − | | + | |
| − | | + | |
| − | [[File: 1087.png | 600px| thumb| center | '''Figure 10-87 Initial Conditions''']]
| + | |
| − | | + | |
| − | '''Step 2'''
| + | |
| − | Place the Lead Vehicle. Now that we have placed the external driver, we need to place the lead vehicle that is to cut off our participant, hence creating our event. We need to select a ADO. To place an ADO go to Insert->ADO from the main menu, or by clicking on the ADO button on the toolbar. The Lead Vehicle needs to be placed such that it can make a right hand turn in front of our driver. In addition, the ADO needs to be close enough to the intersection that it is stopped at the intersection before the start of the event. Once we have place the Lead Vehicle we need to instruction it to make a right hand turn. This can be done by specifying the Lead Vehicle’s path. To do this, right click on the Lead Vehicle, and select the extend path option, and click on the lane the Lead Vehicle will be turning onto, past the intersection. This will place a blue path showing the path the Lead Vehicle will travel. Once the Lead Vehicle reaches the end of the path it will just continue as normal.
| + | |
| − |
| + | |
| − | [[File: 1088.png| 600px| thumb| center | '''Figure 10-88 ADO Path''']]
| + | |
| − | | + | |
| − | '''Step 3'''
| + | |
| − | Setting up the traffic lights. In order to make sure the lead vehicle waits at the intersection for the external driver to approach we need to make sure the light at the intersection is red. We do this through the traffic light manager. The traffic light manager can be accessed through Edit-
| + | |
| − | >Traffic Light Manager. Select the relevant traffic light from the applicable intersections list and press the button. This intersection will now be placed in the controlled intersections list. Now click on the intersection in the controlled intersections list. This will bring the state of the traffic light in the middle list box. When you click on the light name in the name in the list box it will highlight in the mini ISAT view the light the name is connected too. In order to change the state on the light, right click on the light value in the next column over from the light, it will list the lights state (R, G, Y). Once you right click on the light it will pop up a menu that you can select the state of the light from. For this example we will want the light the external driver is traveling on to be green, and the other lights to be red.
| + | |
| − | | + | |
| − | [[File: 1089.png|600px|thumb|center|'''Figure 10-89 Traffic Light Manager''']]
| + | |
| − | | + | |
| − | '''Step 4'''
| + | |
| − | Lead vehicle pull out. In this step, we want to cause the lead vehicle to make a right turn when the driver is within 7 seconds of the intersection. Remember triggers operate effectively as “if then” statements, if its predicate is satisfied then execute the action(s). We will place a road pad trigger and a time to arrival trigger to accomplish this. The first step is to place the time to arrival trigger. The road pad trigger can be inserted from Insert->Time to Arrival menu. Once placed, ISAT will bring up the road pad trigger settings dialog. On the predicate tab, place the time as 7, and hit the “Set Ext Driver” button, this will select the external driver as the predicate set (only the members of the predicate set may be evaluated by the predicate). Next click on the Actions tab. Hit the new button and select “Set Dial” in the “action type” combo box, and “ForcedVelocity” in the Dial combo. Next, hit the “Set Params” button. This will bring up the Set Forced Velocity dialog. Select Target Velocity and set MPH to 7 and Accel to 2.9. This will cause the target to accelerate to 7 Mph at a rate of 2.9. Hit “OK”. In the Action tab, select under “who to effect” the “Name” option and hit the “…” button to the right of the name option. This will pop up a dialog. Add the “Lead Vehicle” to the candidate set. This action will force the Lead Vehicle to start pulling out in front of
| + | |
| − | the external driver.
| + | |
| − | | + | |
| − | [[File: command.png| 600px|thumb |center]]
| + | |
| − | | + | |
| − | Next, we place the road pad. We do this by right clicking on the road pad trigger and selecting the “place road pad” option. The road pad needs to be placed such that its start point is far enough away from the intersection that we can catch a driver driving well above the speed limit. The end point needs to be placed such that if the driver is going well below the speed limit they will still be on the pad when they are 7 seconds from the intersection. The green dot is the start point, the red dot is the end point, and the orange dot is the target point. Place the target point just past the intersection around the point where the external driver and the lead vehicles paths would first intersect.
| + | |
| − | | + | |
| − | Now that we have placed the Time to Arrival trigger, we want to place a road pad trigger that will fire when the lead vehicle starts to turn right. This trigger will speed the lead vehicle up to the speed limit. By placing two trigger to cause the lead vehicle to speed up we can create a more natural looking turn. Road pad trigger can be inserted from the Insert->Coordinators->Road Pad Trigger menu. The road pad trigger will be set up in the same manner as the time to arrival trigger, except the lead vehicle will be the only member of the predicate set. On the actions tab we need to first add a “reset dial” action, with ForcedVelocity set as the Dial. Also, the sequential option needs to be selected, and Delay (bottom of the tab page) should be set to .1. In addition, we need to set the who to affect option to select the lead vehicle just like we did with the time to arrival trigger. The purpose of the reset dial action is to inform the lead vehicle that it is no longer supposed to follow the previous forced velocity dial, and it needs at least one frame to reset itself.
| + | |
| − | | + | |
| − | Next we want to add a set forced velocity action. This will be the same as the set forced velocity action from the time to arrival trigger except the speed now will be set to 35, the acceleration will be
| + | |
| − | 2.9 as well. Again, we need to set the Who to Affect options to the lead vehicle. This must be done for each action. The last thing we need to do is to place the road pad. So right click on the road pad trigger and select place road pad. The road pad should be place the same as the bellow figure.
| + | |
| − | | + | |
| − | [[File:1090.png|600px |thumb |center | '''Figure 10-90 Turn lane Accel''']]
| + | |
| − | | + | |
| − | '''Step 6 Testing'''
| + | |
| − | | + | |
| − | Now that we have, the basic elements of our event down, we can now use the rehearsal mode to insure that our event is working. The icon in the mode tool bar to enter the rehearsal mode. Here we can “run” the scenario. You can also start the rehearsal mode through the menu Mode → Rehearsal. The rehearsal mode will run two iterations of dynamics and one iteration of behaviors every frame. The behaviors and dynamics modules are also used in the NADS. Press the play button on the rehearsal dialog to start the simulation. The lead car should be pulling out just in front of the external driver in this scenario. If the lead vehicle is not pulling out in front of the external driver, we will have to check our setting on the individual scenario elements. Is the “SetForcedVel” action set right? Is the Time to arrival trigger firing?
| + | |
| − | | + | |
| − | '''Step 7 Data Reduction'''
| + | |
| − | | + | |
| − | Data reduction effectively adds markers into the data stream to help calculate certain data. Such as you can insert a “Reaction Time” data reduction event. This will provide data on the reaction time to an event quickly. In this particular event, we want to monitor the reaction time of the participant to the lead vehicle pulling out. Here we will be monitoring the time it takes the user to take their foot of the gas pedal, and the time it takes the user to apply the brakes. This first step in this process is to add a start data reduction at the start of the event. To do this we will make a time to arrival trigger that is identical to the time to arrival trigger that we inserted in step 2. The only difference is that we will not be inserting a set dial action. Instead, we will place a “start data reduction” action. We could use the same trigger as we do to advance the lead vehicle to the intersection to start our data reduction, but if we make some changes to that trigger, like adding additional sequential actions, our start data reduction action might not be fired at the correct time.
| + | |
| − | | + | |
| − | In this particular case, we are going to want to measure the reaction time of our participant to the event. We will measure this by measuring the time it takes the participant to take their foot of the gas pedal, and how long it takes the participant to apply the brakes. We will need two separate “start data reduction” actions for this event since we are measuring two separate reaction times. So first add a new action and select “Start Data Reduction” under action type. Then hit the parameters button. This will bring up the data reduction dialog. Set the group to one, and double click on “Reaction Time”. This will bring up the define parameters dialog. We will set the Column name to “LVPO1”, which which will identify the event, and Custom we will type in “BrakeT1”, this will identify this data reduction as measuring the brake pedal. Now hit “OK”, on the Define Parameters dialog and on the Data reduction Dialog. Now we can add our second data reduction. We will repeat the same process we used for inserting the first start data reduction action except we will set the group number to 2 in the “Data Reduction” dialog and set “Custom to “AccelT” in the Define parameters dialog. This will indicate that we are starting measure the gas pedal reaction time.
| + | |
| − | | + | |
| − | | + | |
| − | [[File: dataR1.png|600px|thumb|center]]
| + | |
| − | | + | |
| − | [[File: dataR2.png|600px|thumb|center]]
| + | |
| − | | + | |
| − | Now that we have our start data reductions set up, we need to add our stop data reductions. This will place a stop marker in our data stream, that will inform the data reduction that this event has stopped. In this case it will then measure the reaction time for the event as that is what we have specified as the data reduction type. We will use an expression trigger to fire our stop data reduction events. We will need two expression triggers, one for the brake pedal, and one for the accelerator pedal
| + | |
| − |
| + | |
| − | [[File: ExpressionT.png|600px|thumb|center]]
| + | |
| − | | + | |
| − | '''Appendix B: Data Verification using ISAT Playback'''
| + | |
| − | | + | |
| − | The simulators at the NADS collect a tremendous amount of raw data from various subsystems, including motion, dynamics, and scenario. A 20-minute drive on NADS-1 or NADS-2 may generate over 500 MB of raw data. Data reduction is the process of transforming raw data into meaningful performance measures that can be interpreted and used by the experimenter.
| + | |
| − | | + | |
| − | Data verification is the process of ensuring that collected data are reliable, valid, and complete, yet concise. Reliability in this case reflects the extent to which driving performance measures are consistent and measured with a minimum amount of error. Validity in this case has several interpretations, including the extent to which the results address the experimental hypotheses and pertain to real-world driving on actual roadways. Regarding completeness, missing data can be a problem when the participant does something unexpected, or when the inevitable computer errors occur. It is important to consider the impact of missing data and to work around the problem to the extent possible.
| + | |
| − | | + | |
| − | ISAT is one tool used for data verification; other tools include MATLAB, and digital video of simulator runs.
| + | |
| − | | + | |
| − | In a given study, some variables are more practical to verify than others. Examples of variables that are conducive to verification include between-subjects variables (e.g., participant number, age group, gender), reaction time measures, and collisions. To decide which variables to verify, start with the entire list of variables reduced for that particular study, and determine whether any tools could be used for verification of that variable. Keep in mind that verification can mean determining that the obtained values are exactly correct (e.g., number of collisions), or simply performing a sanity check on the values to ensure they are in a reasonable range (e.g., phase angle, a car following measure). Some variables that are appropriate for use with ISAT verification may be :
| + | |
| − | | + | |
| − | SCC_CollisionCount: number of collisions between the participant and the dynamic objects. SCC_Lane_Deviation: used to verify lane excursions.
| + | |
| − | CFS_Accelerator_Pedal_Position: used to verify reaction time.
| + | |
| − | | + | |
| − | '''Collision count'''
| + | |
| − | | + | |
| − | To examine/count collisions, perform the following steps:
| + | |
| − | | + | |
| − | #Choose the variable SCC_Collision_Count from the drop-down list of variables, and click Add Variable. | + | |
| − | | + | |
| − | #To graph the SCC_Collision_Count, select it in the Name: drop-down and hit Full Graph. This will bring up a graph of SCC_Collision_Count. Clicking on a location on the graph will advance the playback to that time.
| + | |
| − | | + | |
| − | #Watch each drive in Playback Mode and determine whether the participant collided with any vehicles or objects (“collided” means that any part of the two objects overlap). Static objects such as road signs and some parked vehicles will only appear in Playback Mode if the specific scenario file for that drive is loaded. Dynamic objects such as other moving vehicles will appear in Playback Mode regardless of whether the scenario file or the binary LRI file is used.
| + | |
| − | | + | |
| − | '''Lane excursions'''
| + | |
| − | | + | |
| − | To examine/count lane excursions, perform the following steps:
| + | |
| − | | + | |
| − | #A lane excursion is recorded when the participant vehicle’s tires exit the lane on either the left or right side. In ISAT, the tires cannot be seen, so the variable SCC_Lane_Deviation is used as a surrogate. When SCC_Lane_Deviation exceeds a certain value (the exact value will depend on the width of the modeled vehicle), the researcher will observe that the participant’s vehicle has exited its lane.
| + | |
| − | | + | |
| − | #To verify reported excursions, a report can be obtained of all excursions recorded in reduced data, with the following headings: right or left excursion, starting and ending frame numbers, and maximum extent out of lane. Each reported excursion is evaluated using the ISAT to ensure that the participant had in fact exited his or her lane at the point indicated.
| + | |
| − | | + | |
| − | #To use the search feature click on “Search Frames”. This will bring up the “Goto Frame” dialog. For SCC_Lane_Deviation we will want the second parameter value of this variable.
| + | |
| − | | + | |
| − | [[File: frame.png|600px|thumb|center]]
| + | |
| − | #SCC_Collision_Count
| + | |
| − | | + | |
| − | '''Reaction time to event'''
| + | |
| − | | + | |
| − | To examine reaction time to an emergency event, such as an incurring vehicle, perform the following steps:
| + | |
| − | | + | |
| − | #Determine a sensible start point from which to look for the reaction of interest. In the case of an incurring vehicle, the point at which the vehicle begins to move is a logical start point. This point can be identified in ISAT by watching the pertinent section of the drive, and looking for the incurring vehicle’s first appearance, then its first movement.
| + | |
| − | | + | |
| − | #One possible reaction time measure is the time difference between the moment the incurring vehicle starts moving (labeled as start frame) and the moment the participant reduces his or her accelerator pedal position by 10% (labeled as end frame). In this case, to find the end frame, accelerator pedal position is recorded at the start frame. When the participant reduces accelerator pedal position by 10%, that frame is recorded as the end frame. The difference between the two frames divided by 240 (number of simulation frames per second) is the reaction time.
| + | |
| − | | + | |
| − | '''Scenario Building Help'''
| + | |
| − | | + | |
| − | '''Appendix C: Scenario Authoring Help'''
| + | |
| − | | + | |
| − | This section is intended as a little quick help in getting started with the ISAT. The manual contains many more details on all aspects of scenario authoring.
| + | |
| − | | + | |
| − | '''External Driver'''
| + | |
| − | | + | |
| − | To determine to scenario’s starting location select Insert->External Driver this turns the cursor into the insertion cursor, and when you hit enter, will insert the External Driver into the scenario. The External Driver appears as a car (or truck) with all its lights on. When the simulation run begins, the driver will start in the location and orientation specified by the External Driver. It is best to position the External Driver on a road, since the simulation may become unstable if it is not. The External Driver is also sometimes referred to as the ExternalDriver, Own Vehicle, Ownership, or simply Driver.
| + | |
| − | | + | |
| − | '''ADO'''
| + | |
| − | | + | |
| − | These are Autonomous Dynamic Objects, semi-intelligent cars that you can insert into the scenario. They will follow the road network, adhering to the rules of the road, and responding to other cars. ADOs should only be placed on roads, because their behaviors only work there, and the simulation may become unstable if they are off road. When they are first inserted, they have settings in there default state. Most of these settings you won't want to change, but you will want to change the its model type by going to the SOL Model tab. don’t pick “Random within category” because some models may not
| + | |
| − | function correctly, and it is better to have known models so that all scenario models can be pre-created.The importance of pre-creation is described in the Performance section, 1.13.1.
| + | |
| − | | + | |
| − | You could change its initial velocity (velocity at creation), from the Velocity Control tab. From the same tab you can also give it a target velocity by moving the mph slider. This target velocity is the speed the ADO will attempt to maintain if road conditions allow.
| + | |
| − | | + | |
| − | To specify the ADO's path, right click on the model, and select Extend Path. Then right click on the road network to create its path. The path has to be a route that the ADO could follow.
| + | |
| − | | + | |
| − | '''DDO'''
| + | |
| − | | + | |
| − | '''D'''eterministic '''D'''ynamic '''O'''bjects only follow the path and speed they are given. They can be placed anywhere in the network. They blindly follow their path, at the given speed, without regard for any other objects. To set their path, right click on the model, and select '''Add Path Nodes'''. Right click again and again for each node. A left click will stop inserting nodes.
| + | |
| − | | + | |
| − | '''Static Objects'''
| + | |
| − | | + | |
| − | These are objects or vehicles placed in the scenario which will have a visual representation at runtime, but no other behavior.
| + | |
| − | | + | |
| − | '''Coordinators'''
| + | |
| − | | + | |
| − | These are scenario objects which coordinate actions between various scenario elements. Triggers are the main coordinators, but there are also Sources and the Traffic Light Manager.
| + | |
| − | | + | |
| − | '''Triggers'''
| + | |
| − | | + | |
| − | These elements fire (perform some action) when there predicate is true. They are named by predicate type, so a Roadpad Trigger is one that is fired when the appropriate object drives over its road pad. An Expression Trigger fires when its expression is true. Time Triggers fire at the specified time, Follow Triggers fire when their follow conditions are met, and Traffic Light triggers fire when the appropriate traffic light state occurs.
| + | |
| − | | + | |
| − | Details of the firing conditions are authored from the trigger’s Predicate page. In the case of a Roadpad Trigger, you select the object that will drive over the trigger's roadpad. You can select it by name, type, or road. If you want the External Driver to trigger the action, choose '''By Type Set -> ExternalDriver'''.
| + | |
| − | | + | |
| − | All trigger have the same set of actions which they can perform. They can do such things as create and object, delete an object, set a cell or variable, set a dial or button on an object, terminate the simulation, etc. The ISAT manual goes into details on all the actions, and how they are authored.
| + | |
| − | | + | |
| − | '''Source''''
| + | |
| − | | + | |
| − | A source creates ADOs at specific locations, at regular intervals.
| + | |
| − | | + | |
| − | '''Traffic Light Manager'''
| + | |
| − | | + | |
| − | The Traffic Light Manager is used to author each intersection’s traffic lights. Section
| + | |
| − | 1.14.1 gives an example of authoring with the Traffic Light Manager
| + | |
| − |
| + | |
| − | '''Scenario Testing'''
| + | |
| − | | + | |
| − | To test your scenario, run it in rehearsal mode. '''Select Mode->Rehearse''', and the scenario will perform, as if it is being run on the simulator. You will see the ADOs and DDOs following their paths, you can see triggers fire, and traffic lights changing. The External Driver will behave as if it is an ADO, following the rules of the road and responding to other objects.
| + | |
| − | | + | |
| − | The External Driver can be given a path, but it can’t be directed like an ADO. It can't be authored so that it changes lanes, or adjusts its speed. If you wish to test the scenario with behavior you expect of experimental subjects, you need to make a separate test scenario. Make a copy of your scenario, and replace the External Driver with a test ADO, giving is some unique name like “DriverTest.” Then author that test ADO so that it drives in the way you expect of the driver. You can use triggers to modify its speed, change lanes, stop, etc. Then modify the triggers that are to be fired by type, ExternalDriver, so that they are instead fired by Name, “DriverTest.”
| + | |
| − | | + | |
| − | '''DAQ Playback'''
| + | |
| − | | + | |
| − | After you have collected data from an actual simulation run, you can play that file back using Playback mode. Select '''Mode->Playback''', and a dialog like the one shown in Figure 1 will appear. Use the open file button to browse to the appropriate file. The bli file used in creating the DAQ file and the bli file open in the ISAT should match, or the Playback behavior won't match the road network.
| + | |
| − | | + | |
| − | [[File: DAQ.png|600px|thumb|center|'''Figure 1 - DAQ Playback Dialog''']]
| + | |
| − | | + | |
| − | Scenario Building Help
| + | |
| − | | + | |
| − | '''Segmentation'''
| + | |
| − | | + | |
| − | A big help in authoring, and debugging scenarios is to break them up into segments.
| + | |
| − | | + | |
| − | '''Independent Events'''
| + | |
| − | | + | |
| − | Try to ensure that each event is not dependent upon a previous event’s outcome. For instance, if you plan to have a lead vehicle breaking event, followed by a time of following the lead vehicle, and then another lead vehicle break. It would be best to have a different lead vehicle for each portion. The driver often does something completely unexpected, and if, instead of breaking for the first event, he passes the lead vehicle, the rest of your events have been ruined. It would be better to have a lead vehicle break, then another vehicle pull in and be the leader for the follow portion, then a different vehicle be the leader for the final break event.
| + | |
| − | | + | |
| − | '''Logstream Divisions'''
| + | |
| − | | + | |
| − | Breaking the route into sections physical sections is also useful. Set up roadpad triggers to increment one of the logstreams as the driver proceeds through the route. For example, at the start of the scenario, set logstream1 to 0, then every 2 miles increment that logstream by 1. This logstream value can either be displayed on the screen, or found in the DAQ replay. Having these logstream values helps pinpoint problem locations during debugging. It is also allows test drivers to better report the results of their drives.
| + | |
| − | | + | |
| − | '''Restart locations'''
| + | |
| − | | + | |
| − | Since scenarios can be very long, and drivers do unexpected things or simply don’t follow the drive instructions, restart scenarios are often part of the experimental plan. Restart scenarios may also be useful in authoring and debugging long, or complicated scenarios. Normally restart scenarios can be made by taking a copy of the original scenario, changing the start location, deleting the unnecessary objects and modifying the objects near the start of this new scenario. Having the different parts of the scenario independent of other parts, makes creating restart scenarios easier.
| + | |
| − | | + | |
| − | '''Scenario reuse'''
| + | |
| − | | + | |
| − | To simplify the authoring of scenarios, there are various forms of scenario reuse.
| + | |
| − | | + | |
| − | '''Object cut and paste'''
| + | |
| − |
| + | |
| − | Once you have an object’s settings the way you like, it is often easier to copy and paste that object then to create another one. This is especially helpful if you are creating a lot of oncoming traffic ADOs or deletion triggers. To copy an object, select it, then Edit->Copy. When you choose Edit->Paste, the cursor will become the insertion cursor and hitting enter will place the object in the new location. If you were placing a series or oncoming ADOs you would only need to rename it, and possibly change its model.
| + | |
| − | | + | |
| − | If you copy and paste a roadpad trigger, the trigger will be in the new location, but its roadpad may not. If it isn’t, simply delete the old roadpad and place a new one. You can also copy groups of objects, like DDOs by simply selecting all of them before choosing Copy.
| + | |
| − | | + | |
| − | Merge Component and External References
| + | |
| − | | + | |
| − | The ISAT manual has specifics on creating groups of objects and then either merging then from one scenario into a second scenario, or referencing those objects from a second scenario. Briefly, right clicking an object brings up a menu with Group as the top option. Either select an already created Group, or make a new one, to put that object into the group. An object can only be a part of one group. Once you have groups in one scenario, from your second scenario select File and then Merge Component or External Reference. With Merge Component the group of objects will be written into your second file, and editable within it. With External Reference, the group of objects will be written into the scenario at run-time, and only editable in the first file.
| + | |
| − | | + | |
| − | In the sample scenarios, ISAT-Samples-Avoid.scn, and ISAT-Samples-Left- Incursion.scn refer to traffic and parked cars created in ISAT-Samples-Right- Incursion.scn. The same group of oncoming traffic could be used in multiple scenarios with slightly different event criteria. A close look at ISAT-Samples-Right-Incursion.scn shows that static objects as well as database sign settings, can also be included in a group, and also therefore as part of an external reference.
| + | |
| − | | + | |
| − | Format
| + | |
| − | | + | |
| − | The following sections list some formatting techniques I’ve found helpful in authoring scenarios. Since scenarios can be quite complicated it helps to have a consistent format so that others (or yourself after a period of time) can make sense of the scenarios.
| + | |
| − | | + | |
| − | Unique object names
| + | |
| − | Give each object a unique name. Since objects in the goto bar, objects are listed
| + | |
| − | alphabetically, it won’t help you find a specific ADO if they are all named: “Traffic ADO.” Also, objects for a specific event could be given group names like: incursionAdo, incursionParked1, incursionDeletTrigger, etc.
| + | |
| − | For triggers, unless they are part of a specific group, I normally give them names that indicate their type, followed by their main action. A Road Pad Trigger would be “RPT Delete1” or “RPT Create oncoming Traffic.” Time Trigger names would be prefaced by a “TT,” Expression Triggers by “ET,” etc.
| + | |
| − | For traffic ADOs, I either give them just generic names like Ado1,Ado2, etc, or area specific names such as Down1, Down2, Oncoming1, Oncoming2, etc.
| + | |
| − | | + | |
| − | Initializations at start
| + | |
| − | | + | |
| − | Some logstreams, cells, and variables need to be initialized at scenario start. It is best to put the trigger(s) that sets these initialization values close to the scenario start location.
| + | |
| − | | + | |
| − | Created triggers
| + | |
| − | | + | |
| − | If one trigger creates another trigger, put them close to each other for easy reference and editing. It also helps to always put them in the same relationship to each other. For example always put the created trigger on top of the creating trigger.
| + | |
| − | | + | |
| − | Trigger point by road pad
| + | |
| − | | + | |
| − | I put roadpad triggers close to the start of their roadpad. This way, when you are looking at the big picture of the scenario, it’s easy to get a sense of where the triggers are happening.
| + | |
| − | | + | |
| − | '''Give all actions meaningful names'''
| + | |
| − | | + | |
| − | When a trigger is selected, it displays its name, as well as its actions. Since the default names are action1, action2, etc, it is better to give them a meaningful name so you can quickly find the trigger to edit.
| + | |
| − | | + | |
| − | | + | |
| − | '''Debugging'''
| + | |
| − | | + | |
| − | When you test the scenario by running it in Rehearsal Mode, the debug side bar comes up. Since some error messages give the object’s name and location, having unique object names helps track down the errors.
| + | |
| − | | + | |
| − | '''Scenario Robustness'''
| + | |
| − | | + | |
| − | There are a few different things you can do to ensure that scenarios perform, each time, as you expect.
| + | |
| − | | + | |
| − | '''Long Roadpads'''
| + | |
| − | Roadpad triggers are one of the most common scenario elements. If they are triggered by the driver, it is a good idea to give them a long roadpad, even up to a couple hundred feet, since it is not uncommon for the driver to swerve out of the lane, especially during events.
| + | |
| − |
| + | |
| − | '''Clean Deletions'''
| + | |
| − | | + | |
| − | Delete ADOs quickly after they have served their purpose. Otherwise they could end up driving around and firing triggers in unexpected manners.
| + | |
| − | | + | |
| − | '''One Shot and Debounce'''
| + | |
| − | If you only want a trigger to fire once, make sure the One Shop option is checked. If you want a trigger to fire multiple times, make sure to set the Debounce correctly. The
| + | |
| − | Debounce setting determines the time, while its predicate is true, between firings. For instance you may use an Expression Trigger to play a play a message every time the driver reaches a certain speed. In that case, give the Debounce a value slightly longer then the length of the message, or you may have that message play multiple times.
| + | |
| − | | + | |
| − | '''Performance'''
| + | |
| − | | + | |
| − | '''Pre-creation of all objects'''
| + | |
| − | The process of creating an object could cause a hiccup in the visuals. In order to minimize this, all models that will be needed during the simulation should be created at the beginning of the scenario. When an object is created, and then deleted, the Image Generator (IG) doesn’t delete the object it just moves it to a place out of sight. And then when the object is needed again, it is moved instead of being created. The process of moving the object to the correct location doesn’t cause a jitter, while the act of creating that object could.
| + | |
| − | | + | |
| − | This pre-creation needs to occur at the beginning of the scenario, and the models need to be pre-created within about 500 feet of the driver’s starting location. Figure 2 shows the starting location from ISAT-Samples-Right-Incursion.scn. Notice the group of models just below the driver. Each is a DDO, since ADOs being created off road generate errors. There is a model and color of each ADO used in the scenario. They each have a lifetime of one second. The one uppermost and to the left has an activation delay of 0, the one next to it, and activation delay of 0.1, the one next to it, an activation delay of 0.2 seconds, etc, and in the same manner for all 80 models. This way all models are created and exist for one second, which is enough for each model to be instantiated by the image generating software. Also notice that the models are created fairly close to the driver, but off to the side so that they don’t appear when they are created.
| + | |
| − | | + | |
| − | [[File:roadWithTruck.png|800px|thumb|center|'''Figure 2 – Pre-creation Example''']]
| + | |
| − | | + | |
| − | | + | |
| − | '''Minimization of active objects'''
| + | |
| − | Each object puts a load upon the image generating software, the behaviors, and the dynamics. Too many objects will put enough load on the system that you will start to see visual jitters, and eventually some scenario objects will become unstable and may do unexpected things.
| + | |
| − | | + | |
| − | '''Planned path'''
| + | |
| − | To help minimize the amount of active objects, create a different scenario for each experimental drive. That way each scenario will have a specific path and traffic and objects can be tailored to fit that drive, and only traffic that is actually seen by the driver needs to be created.
| + | |
| − | | + | |
| − | '''Cloud of traffic with driver'''
| + | |
| − | Creating a cloud of traffic, travelling in the same direction as the driver, gives a sense of being full, without putting too much load on the system. On a two lane road, it might be sufficient to put three vehicles in front of the driver, and one or two behind it. On a four lane road you might need to add a couple more in front and behind
| + | |
| − | | + | |
| − | '''Creation radius for triggers'''
| + | |
| − | Triggers put a load on the behaviors software, since they check, every frame, to see if their predicate is true. If the driver is going to hit a roadpad trigger, give the trigger a small creation radius, like three hundred feet. Doing this will cause the trigger to only be active when the driver is close. Other triggers could be deleted once they have fired, or will no longer be needed.
| + | |
| − | | + | |
| − | '''Creation radius and Curves for oncoming traffic'''
| + | |
| − | To minimize the time that oncoming traffic is active, give them a creation radius of 2000 or more feet. At about 2000 feet, you can see objects “pop in” as they are created, beyond that you normally don’t see that effect. If you give objects a creation radius greater then the pop-in distance, they will only be created, as needed, and will be deleted when out of sight. To further minimize the load, you could use curves and hills to shrink the creation radius further.
| + | |
| − | | + | |
| − | '''Clean deletions'''
| + | |
| − | Sometimes you will not be able to give vehicles or triggers a creation radius. If that is the case you could have the driver delete them with a road pad trigger, when they are no longer needed. If ADOs are not deleted, they may interact in unexpected ways, like driving back around and a loop, and hitting triggers at unexpected times. They also put unneeded load on the system
| + | |
| − |
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | =Other Things=
| + | |
| − | | + | |
| − | '''Traffic Light Authoring'''
| + | |
| − | | + | |
| − | The ISAT manual has details on authoring a scenario’s traffic lights. Figure 3 shows the settings for a typical type of intersection, with lights along one lane being red for thirty- three seconds then turning green for thirty and yellow for three. Along the other line of traffic, the pattern is reversed. Sometimes you may never want the lights to change, in which case you give them one desired state.
| + | |
| − | | + | |
| − | [[File:fig3.png|600px|thumb|center|'''Figure 3 – Traffic Light Authoring Dialog''']]
| + | |
| − | | + | |
| − | '''Triggers Creating Time Triggers'''
| + | |
| − | | + | |
| − | Time Triggers use global time, they are not timers. If you want to create a use a Global Time Trigger as a timer, you will need to modify its activation settings. For example, you may want to play a message, exactly forty-five seconds after the driver passes a certain portion of the road. You would then use a RoadPad Trigger to create a TimeTrigger. Set the TimeTrigger to fire at zero seconds with an activation delay of forty-five seconds.
| + | |
| − | | + | |
| − | '''Persistent Actions'''
| + | |
| − | | + | |
| − | Most actions are completed shortly after they are initiated. So if you are using a trigger, you could have that one trigger do a series or actions. You could create and object, then 5 seconds later, delete it, then 5 seconds later play an audio message, then 10 seconds later terminate the simulation.
| + | |
| − | | + | |
| − | Some actions are persistent, that is they are never completed, and could not be part of a series of actions. The persistent actions are those which set some of the ADO’s dials. Specifically, MaintainGap, ForcedVelocity, VisualState, and AudioState. These actions need to be reset, with the reset action, if they will be changed. For example, if you set an ADO’s visual state to display its brake lights, you could not immediately turn on its turn signals. You would have to reset its Visual State and then set it to display brake lights. The ISAT manual gives more specifics on ADO dials and whether they are persistent or not.
| + | |
| − | | + | |
| − | Figure 4 shows the settings for a trigger in '''ISAT-Samples-Avoid.scn'''. It is described here because it shows how to coordinate several actions at once. The trigger is named:''' Avoid RPT Move Second Follower'''. At this point in the scenario, there are two vehicles which have their MaintainGap dial set such that they are following the External Driver at a fixed distance. The first action of the trigger is to create three Time Triggers to do other actions. Then 0.1 seconds later it resets the MaintainGap dial on the vehicle named Second Follower, then 0.1 seconds after that it sets the MaintainGap dial of Second Follower to a different value. It could not do another action after this since MaintainGap is a persistent action and would never be completed.
| + | |
| − | | + | |
| − | So the right-most of the three created triggers is a Time Trigger, with a firing time of zero, meaning it will fire as soon as it is created. It resets the MaintainGap dial on the event van, and then gives that dial another setting, making the Event Van move closer to the External Driver.
| + | |
| − | | + | |
| − | The middle trigger is a Time Trigger with a firing time of zero, but an Activation Delay of five seconds. It will therefore fire five seconds after it is created. It affects the Second Follower by making it change lanes to the right. This action could not be done as part of the trigger shown below since its final action, setting the MaintainGap dial, will never be complete.
| + | |
| − | | + | |
| − | The left most, of the three triggers, is also a Time Trigger, with an Activation Delay of 10 seconds. It fires and resets the Second Follower’s MaintainGap, and then sets it ForcedVelocity dial to 83 mph so that it speeds out ahead of the Driver.
| + | |
| − |
| + | |
| − | [[File:fig4.png|600px|thumb|center|'''Figure 4 – Sequential Action Example''']]
| + | |
| − | | + | |
| − | =Sample Scenarios=
| + | |
| − | | + | |
| − | The data directory contains a few sample scenarios that illustrate some of the points in this document, as well as showing how to author simple events.
| + | |
| − | | + | |
| − | '''ISAT-Samples-Right-Incursion.scn'''
| + | |
| − | | + | |
| − | In this scenario there is an incursion from the right. Figure 5 shows a view of the main action. The selected trigger creates the incurring vehicle (the white car), when the driver is 1.85 seconds away from the driveway. The Roadpad Trigger next to is set to make the oncoming car slow down, to simulate another driver attempting to avoid the accident. The Roadpad Trigger also creates the TimeTrigger above which sets the ForcedLaneOffset of that oncoming vehicle, causing it to also pull off the road in an attempt to avoid the accident.
| + | |
| − | | + | |
| − | To get the oncoming car to always be in the correct location, it (and another vehicle behing it) are created 2,500 feet from the event, when the driver is 2,500 feet from the event. As soon as it is created, it hits a Roadpad Trigger which sets its ForcedVelocity Dial to match the velocity of the driver, and also sets the ForcedVelocity Dial of the car behind it. This setting is shown in Figure 6. Creating the car this way ensures that no matter the speed of the driver, it will always be at the appropriate distance from the event.
| + | |
| − |
| + | |
| − | [[File:fig5.png|600px|thumb|center|'''Figure 5 – Incursion From Right Scenario''']]
| + | |
| − | | + | |
| − | [[File:fig6.png|600px|thumb|center|'''Figure 6 – Oncoming Match Driver’s Velocity''']]
| + | |
| − | | + | |
| − | '''ISAT-Samples-Left-Incursion.scn'''
| + | |
| − | | + | |
| − | This scenario is similar to the right incursion, except the incursion occurs from the left. A car pulling out into the road, causes the car behind it to pull into the driver’s lane. The oncoming car is set to be at the correct distance from the event, in the same manner as the right incursion scenario. Figure 7 shows the event location with the TimeToArrival Trigger which creates the pulling out car when the driver is six seconds away. The other TimeToArrival Trigger causes the oncoming car to pull into the driver’s lane when the driver is 3 seconds from the event.
| + | |
| − | | + | |
| − | This scenario also uses traffic, parked vehicles, and signs, as an external reference from the right scenario.
| + | |
| − |
| + | |
| − | | + | |
| − | [[File:fig7.png|600px|thumb|center|'''Figure 7 - Incursion From Left''']]
| + | |
| − | | + | |
| − | '''ISAT-Samples-Avoid.scn'''
| + | |
| − | | + | |
| − | In this scenario, the driver is instructed to stay in the right lane. When the cars that are following the driver, get to the four lane portion of the road they start to pass the driver.
| + | |
| − | | + | |
| − | Eventually a construction van passes the driver and maintains its position in front of the driver. Within that van is a desk named AvoidDesk. Its settings are shown in Figure 8. Even though the desk is on the ground, somewhere in the scenario, when the scenario starts it is coupled to the van, sitting at 1.46 feet above the center of the van, as shown by its Relative Offset settings.
| + | |
| − | | + | |
| − | [[File:fig8.png|600px|thumb|center|'''Figure 8 - Desk Settings'']]
| + | |
| − | | + | |
| − | Figure 10 shows the three triggers that cause the event. The first trigger starts the van doors opening, and is shown in Figure 11. Opening of the doors is a visual state. Since the van has no other visual state set, the dial does not need to be reset, before it is set. The next trigger causes the desk to start sliding, relative to the van, and its settings are shown in Figure 12. It does this by changing its state from Coupled (state 2) to Relative (state 3). When it is moving in the Relative state, it is following its own path, but moving relative to the van in which is initially located. The actual path of the Desk is shown in Figure 9. The last trigger, shown in Figure 13, drops the desk, by changing its state to free (state 1). When its state changes, it receives the Initial Velocity shown in Figure 8, where the first three components are the x, y, and z components. While the last three are the roll, pitch, and yaw components.
| + | |
| − | | + | |
| − | [[File:fig9.png|600px|thumb|center|'''Figure 9 - Desk in Scenario''']]
| + | |
| − | | + | |
| − | | + | |
| − | [[File:fig10.png|600px|thumb|center|'''Figure 10 - Avoid Triggers''']]
| + | |
| − | | + | |
| − | [[File:fig11.png|600px|thumb|center|'''Figure 11 - Open Van Doors''']]
| + | |
| − | | + | |
| − | [[File:fig12.png|600px|thumb|center|'''Figure 12 - Slide Desk''']]
| + | |
| − | | + | |
| − | [[File:fig13.png|600px|thumb|center|'''Figure 13 - Drop Desk''']]
| + | |
| − | | + | |
| − | '''ISAT-Samples-TrafficLight.scn'''
| + | |
| − | | + | |
| − | This scenario has two traffic light intersections, and the Traffic Light Manager has been used to set the traffic light pattern.
| + | |
| − | | + | |
| − | = 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''' ===
| + | |
| − | | + | |
| − | <nowiki># prompt author for a sign to rotate</nowiki>
| + | |
| − | | + | |
| − | <nowiki>.Name SetSignRotation</nowiki>
| + | |
| − | | + | |
| − | <nowiki>.Icon SignRot.ico</nowiki>
| + | |
| − | | + | |
| − | <nowiki>Static sign</nowiki>
| + | |
| − | | + | |
| − | <nowiki>Select(sign,"Please Select a Sign")</nowiki>
| + | |
| − | | + | |
| − | <nowiki>sign.SetAngle(Anchor)</nowiki>
| + | |
| − | | + | |
| − | <nowiki>.End</nowiki>
| + | |
| − | | + | |
| − | == Reference ==
| + | |
| | | | |
| − | [[:File:ISC_Image2011_ISC.pdf]]Image ISC Paper | + | [[Authoring_Expression_Triggers|◄PREVIOUS]] [[Introduction_II|NEXT►]] |
The visual representation of triggers has been designed to convey as much information about the trigger as possible without forcing the user to bring up the Properties dialog box to review the trigger's functionality. Unfortunately, given the amount of information associated with triggers, it is not possible to visually display all of it. Therefore, the current design focuses on a certain subset of all available information.
Figure 9-78 illustrates a typical representation of a trigger. A small red circle identifies the actual location of the trigger. This is the location used for Creation Radius calculations. A separate box with rounded corners is used to depict key parameters associated with the trigger. Two lines help associate the pictorial representation of the trigger with its home location. The pictorial representation can be dragged with the mouse to any location without moving the home location. This allows the pictorial representation to be spread so it does not occlude other scenario elements or other triggers.
The pictorial trigger representation is divided into several areas, each containing smaller iconic indicators of the trigger's parameters. Figure 9-79 illustrates these areas and their meanings.
The Trigger Action icon pictorially represents the first action associated with the trigger. There is a distinct icon for each available trigger action; however, only the first action is depicted. If many actions are defined, the user has to use the dialog box to review the remaining actions. The Action Cardinality indicator can be useful in determining if actions other than the one depicted by the trigger action icon are defined. Figure 9-81 illustrates all iconic representations of the trigger actions. Depicted from left to right and top to bottom are the Create Element, Delete Element, Press Button, Set Dial, Select Traffic Manager Set, Play Audio, Vehicle Failure, Set Traffic Light, Log Data, Terminate Simulation, Pre-position Motion Base, Tune Motion Base, and Initiate Phone Call actions.
Finally, the target set area provides an iconic representation of how the trigger's target set is determined. The precise iconic representation is currently under development, and an initial method of using the first letter of the set is utilized (e.g., T for type, N for name, etc.).
Triggers are the building blocks of most scenario events. This section provides some guidelines and examples of how triggers can be used, with emphasis on the intended usage of each trigger. Keep in mind that the guidelines provided here should not be considered as a limitation. They are merely suggestions for how to use triggers. Finding new and innovative ways to use triggers is encouraged.
Triggers generally have low computational overhead, so they can be used freely within reason. However, when the number of triggers in a scenario exceeds one hundred or so, some care should be taken to control the computational load. The easiest way to do this is by using the Creation Radius parameter to activate a trigger only when a driver gets near.
The actual placement of the trigger is not important other than affecting when the trigger is activated when the Creation Radius is specified. Therefore, place the trigger near the region where it will be affecting things, but not on the road network where it can hide other scenario elements.
Carefully evaluate the need of either defining a trigger as a one-shot trigger or specifying a non- zero denounce value. Several triggers will fire continuously after their predicate is satisfied. For example, with a zero denounce value, the global time trigger will fire continuously once the specified time has been reached. This can be problematic if its action is to create an ADO. At the scenario control system’s default execution rate of 30 Hz, such a trigger will create 300 new objects in 10 seconds. This is guaranteed to overload not only the scenario control system, but also the Image Generator, the real-time communication channels, and a variety of other subsystems. The simulation will ultimately halt because of the overload.
The intended usage of certain trigger actions should be very clear. For example, the Terminate Simulation action can be used to deterministic stop the simulation either when the driver reaches a particular point or after a fixed amount of time. Therefore, a global time trigger whose action is to terminate the simulation provides a convenient way to ensure that all subjects in an experiment drive for exactly the same time. Other actions are much more flexible. For example, setting the dial of a traffic element is a powerful way to modify the behavior of traffic. When using such actions, it is critical to use the ISAT’s rehearsal mode to verify that the actual behavior is what was intended.
Misuse of triggers is one of the biggest causes of scenario authoring errors; these errors include creating stop or start data reduction without a stop, missing predicate information, missing action information and many other errors. The verification tool was introduced in order to help catch these errors. The verification tool is launched by clicking on (the Red check) icon on the view toolbar. This tool will not find all possible errors, it is meant to help catch simple authoring errors.
Click the verify button to refresh the error list. Click on the error description will set the focus on the scenario element in question. The verification tool is run when the .scn is saved, if an error is found the verification window is opened. This can be disabled by going to the Edit->Preferences->Verify and unchecking the check at start option.
The data reduction graph is a new tool that has been introduced in ISAT version 1.5, which is meant visualize data reductions. One problem with data reductions is that there is no way for ISAT to automatically tell if for a given event all the possible start and stops of the event have a stop or start data reduction action. For instance if we have an event where the car suddenly stops in front of the participant, and we are trying to comprehend their reaction time, we need to have a stop reduction for each possible case the driver could avoid the accident, such as either stopping, or swerving to avoid the accident.
The reduction graph has two views, “By Reduction”, and “By Action”. The “By Reduction” view organizes the chart by each reduction, that which is identified by actions that have the same group number, variable type and column name. Since each action can have multiple variables, a specific action may appear in multiple under multiple reductions. The “By Action” view organizes
the view by action. It draws a line from each stop reduction action to the start reduction action that it is stopping. When an action block is clicked on, ISAT will set the view to the trigger that contains
the given action
