|
|
| (20 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | =Introduction= | + | ==Introduction== |
| | | | |
| | The miniSim Socket Control (MSC) framework allows for communication between miniSim software, the host system, and any number of display or control surfaces. In it's current incarnation it can do any number of tasks: control miniSim state, monitor real-time miniSim output, manipulate system files, manage system power/tasks/state, and many others. | | The miniSim Socket Control (MSC) framework allows for communication between miniSim software, the host system, and any number of display or control surfaces. In it's current incarnation it can do any number of tasks: control miniSim state, monitor real-time miniSim output, manipulate system files, manage system power/tasks/state, and many others. |
| | | | |
| − | ==What Does It Do?== | + | ===How does it work?=== |
| | | | |
| − | MSC is a script built using Node.js. It establishes an Express web server, then uses Socket.IO to manage connections to different control and/or display surfaces. Because display and control surfaces are coded as web pages served up by the Express server, MSC creates a device-agnostic ecosystem, where any number of devices on any combination of platforms can participate (assuming they support a semi-modern browser). | + | MSC is a script built using [https://nodejs.org Node.js]. It establishes an Express web server, then uses [http://socket.io Socket.IO] to manage connections to different control and/or display surfaces. Because display and control surfaces are coded as web pages served up by the Express server, MSC creates a device-agnostic ecosystem, where any number of devices on any combination of platforms can participate (assuming they support a semi-modern browser). |
| | | | |
| | This means that you can potentially use | | This means that you can potentially use |
| | | | |
| − | In it's current incarnation, the main framework includes a mobile control surface for the miniSim. | + | In it's current incarnation, the main framework includes a mobile control surface for the miniSim, addressable through any common network interface of the miniSim host. |
| | | | |
| | + | ==Mobile Control Surface== |
| | | | |
| − | =MSC Mobile Control Surface=
| + | [[Image:Screenshot_2016-05-26-14-51-42.jpg|thumb|The MSC Mobile Control Surface - Main UI - Android client]] |
| | + | The Mobile Control Surface is the first application to take advantage of the Socket Control system. It's coded in standard HTML5 markup, using the jQuery Mobile framework. Through it's use, any device with a modern browser can control and monitor a miniSim system. |
| | | | |
| − | 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.
| + | <gallery mode="packed"> |
| | + | Image:Screenshot_2016-05-26-14-52-39.jpg|Running - Real-time driver gauge monitor |
| | + | </gallery> |
| | + | ===miniSim Operational Control=== |
| | + | The following miniSim functions are currently covered: |
| | + | * Launching the miniSim executable |
| | + | * Select scenario |
| | + | * Select vehicle |
| | + | * Play / control slides |
| | + | * Start / stop simulation |
| | + | * Closing miniSim executable |
| | | | |
| − | ==What it does==
| |
| | | | |
| − | 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.
| + | Additionally, the sim |
| | + | * Real-time driver gauge monitor |
| | + | * Video monitoring (currently in beta) |
| | | | |
| − | 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.
| + | ===System Control=== |
| − | | + | Outside of controlling the miniSim software, the host script can also accomplish system functions including: |
| − | 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.
| + | * Shutting down the system |
| − | | + | * (...) |
| − | ==Terminology== | + | |
| − | | + | |
| − | This section defines terms that are used frequently in this document.
| + | |
| − | | + | |
| − | <table cellspacing="0" cellpadding="0" style="margin:10px;">
| + | |
| − | <tr style="background:rgba(100,100,100,0.1);">
| + | |
| − | <td style="padding:8px; min-width:170px;"><i>Visual database</i></td>
| + | |
| − | <td style="padding:8px;">A set of data files representing the physical appearance of a virtual environment. The NADS computers use the OpenFlight format for visual databases.</td>
| + | |
| − | </tr>
| + | |
| − | <tr>
| + | |
| − | <td style="padding:8px;"><i>Synthetic environment</i></td>
| + | |
| − | <td style="padding:8px;">A set of correlated databases that fully defines a virtual environment for use in the NADS.</td>
| + | |
| − | </tr>
| + | |
| − | <tr style="background:rgba(100,100,100,0.1);">
| + | |
| − | <td style="padding:8px;"><i>Tiles</i></td>
| + | |
| − | <td style="padding:8px;">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.</td>
| + | |
| − | </tr>
| + | |
| − | <tr>
| + | |
| − | <td style="padding:8px;"><i>Simulator driver</i></td>
| + | |
| − | <td style="padding:8px;">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 <i>simulator driver</i> would be used to refer to the vehicle that shows the subject's actions.</td>
| + | |
| − | </tr>
| + | |
| − | <tr style="background:rgba(100,100,100,0.1);">
| + | |
| − | <td><i>Event</i></td>
| + | |
| − | <td>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.</td>
| + | |
| − | </tr>
| + | |
| − | <tr>
| + | |
| − | <td style="padding:8px;"><i>Scenario</i></td>
| + | |
| − | <td style="padding:8px;">A series of events that take place while a subject is driving the simulator.</td>
| + | |
| − | </tr>
| + | |
| − | <tr style="background:rgba(100,100,100,0.1);">
| + | |
| − | <td style="padding:8px;"><i>Scenario element</i></td>
| + | |
| − | <td style="padding:8px;">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.</td>
| + | |
| − | </tr>
| + | |
| − | <tr>
| + | |
| − | <td style="padding:8px;"><i>Research participant</i></td>
| + | |
| − | <td style="padding:8px;">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 <i>subject</i>.</td>
| + | |
| − | </tr>
| + | |
| − | <tr style="background:rgba(100,100,100,0.1);">
| + | |
| − | <td style="padding:8px;"><i>Subject</i></td>
| + | |
| − | <td style="padding:8px;">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 <i>research participant</i>.</td>
| + | |
| − | </tr>
| + | |
| − | <tr>
| + | |
| − | <td style="padding:8px;"><i>NADS</i></td>
| + | |
| − | <td style="padding:8px;">[http://www.nads-sc.uiowa.edu The National Advanced Driving Simulator].</td>
| + | |
| − | </tr>
| + | |
| − | <tr style="background:rgba(100,100,100,0.1);">
| + | |
| − | <td style="padding:8px;"><i>SDM</i></td>
| + | |
| − | <td style="padding:8px;">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.</td>
| + | |
| − | </tr>
| + | |
| − | <tr>
| + | |
| − | <td style="padding:8px;"><i>Coordinator</i></td>
| + | |
| − | <td style="padding:8px;">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.</td>
| + | |
| − | </tr>
| + | |
| − | <tr style="background:rgba(100,100,100,0.1);">
| + | |
| − | <td style="padding:8px;"><i>Buttons and dials</i></td>
| + | |
| − | <td style="padding:8px;">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.</td>
| + | |
| − | </tr>
| + | |
| − | <tr>
| + | |
| − | <td style="padding:8px;"><i>GUI</i></td>
| + | |
| − | <td style="padding:8px;">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.</td>
| + | |
| − | </tr>
| + | |
| − | </table>
| + | |
| − | | + | |
| − | ==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:
| + | |
| − | | + | |
| − | <ol>
| + | |
| − | <li>Your name and affiliation</li>
| + | |
| − | <li>The version of the ISAT that you are using (version information is available from the Help/About menu)</li>
| + | |
| − | <li>The scenario and LRI that causes the reported problem</li>
| + | |
| − | <li>A description of the problem</li>
| + | |
| − | <li>A series of steps that need to be performed to recreate the problem</li>
| + | |
| − | </ol>
| + | |
| − | | + | |
| − | All problems will be addressed in a timely manner in the form of a fix or a workaround.
| + | |
The miniSim Socket Control (MSC) framework allows for communication between miniSim software, the host system, and any number of display or control surfaces. In it's current incarnation it can do any number of tasks: control miniSim state, monitor real-time miniSim output, manipulate system files, manage system power/tasks/state, and many others.
In it's current incarnation, the main framework includes a mobile control surface for the miniSim, addressable through any common network interface of the miniSim host.
The Mobile Control Surface is the first application to take advantage of the Socket Control system. It's coded in standard HTML5 markup, using the jQuery Mobile framework. Through it's use, any device with a modern browser can control and monitor a miniSim system.
Outside of controlling the miniSim software, the host script can also accomplish system functions including:
