All About the TwinParksCity Driving Scenario

One of the best things about STISIM Drive is that it comes with a lot of ready-to-run scenarios that you can use right out of the box. And while these scenarios are meant to make it easier for our clients to get up-and-running quickly, we realize that our documentation could use a little more detail.

In an effort to help our clients understand the scenarios available to them, we’re going to do a deeper dive into a specific driving scenario each month, so that you can better understand what they are and how you can use them.

This month’s featured driving scenario: TwinParksCity

The basic premise of the Scenario Definition Language (SDL), which is used to design scenarios, is that you build your roadway and it’s displayed on the fly. This helps to provide extreme flexibility designing drives and collecting data in situations that drivers must negotiate.

3D city model includes skyscrapers, houses, street signs, many other objects.

But the TwinParksCity scenario is a bit different. In it, the STISIM Drive simulator uses a fixed database approach to accomplish specific objectives (which we will explain in more detail a few paragraphs down).

This drive uses the Static Object Event to place a previously-created 3D model of a city into the scenario. Usually the objects that get placed into a scenario are something small, like a road sign or mailbox. But in this case, it’s an entire 5 block by 5 block city scene!

The scenario itself is fairly simple, using only five SDL events and several configuration overrides. It’s the city scene that adds complexity to the drive. It includes numerous skyscrapers, houses, street signs, vehicles, and various other objects. But because all these objects are part of the 3D city model, they do not need to be specifically called out in the scenario file.

Using a Fixed Database Driving Scenario

Drivers have to navigate from Point A to Point B through the cityscape.

Sure, having a pre-built 3D model of a driving situation is an awesome feature, it’s not all cotton candy and rainbows. There are a few drawbacks:

  1. This approach can only be used on a flat terrain. That means it can’t be used for things like overpasses, hills, etc.
  2. Unlike the SDL roadway, the driver can drive wherever they want – including on the grass, through buildings, etc.
  3. Standard data collection can’t be done easily because the software isn’t able to track where the driver is in their lane.

Why have a scenario like this? Well, this scenario was developed by our friend, Dr. Tom Marcotte, at the University of California, San Diego. Dr. Marcotte has used our simulator for over 25 years to do research on the cognitive issues that people face when transitioning from being HIV+ to having full-blown AIDS.

Using this map, drivers need to find their way through the city.

The TwinParksCity scenario was developed as a simple driving task to see how many turns it takes the driver to get from point A to point B. The participants are given a map before starting the drive, and are allowed to stop and consult the map whenever they need to. The researchers simply wanted to look at cognition, executive functioning, and decision-making behaviors.

TwinParksCity is a great example for how flexible the STISIM Drive simulator is for designing specific scenarios. The only practical way to design the driving task was to set up a true city scene, then have the driver follow the map. And SDL events alone couldn’t have done it!

The moral of this particular story is that the STISIM Drive simulator can do more than you might realize. The best way to approach it is to do a bit of reverse engineering. First think about where you want to end up, for example, what your goals are and what data you’re trying to collect. Then consider the best way to collect the data you need. Then, and only then, should you design a driving scenario.

Check out our previous post about how we recommend creating your drives!