Scenario Building Help II
ISAT User's Guide Table of Contents
Contents
- 1 Scenario Building Help
- 1.1 Segmentation
- 1.2 Independent Events
- 1.3 Logstream Divisions
- 1.4 Restart locations
- 1.5 Scenario reuse
- 1.6 Object cut and paste
- 1.7 Merge Component and External References
- 1.8 Format
- 1.9 Initializations at start
- 1.10 Created triggers
- 1.11 Trigger point by road pad
- 1.12 Give all actions meaningful names
- 1.13 Debugging
- 1.14 Scenario Robustness
- 1.15 Long Roadpads
- 1.16 Clean Deletions
- 1.17 One Shot and Debounce
- 1.18 Performance
- 1.19 Pre-creation of all objects
- 1.20 Minimization of active objects
- 1.21 Planned path
- 1.22 Cloud of traffic with driver
- 1.23 'Creation radius for triggers
- 1.24 Creation radius and Curves for oncoming traffic
- 1.25 Clean deletions
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.
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
