, | 3 min read

Anatomy of an Engineering-Class Automotive Driving Simulator

As noted in previous articles, automotive driving simulators can take on many forms, ranging from consumer-oriented entertainment devices to industry-oriented engineering tools. The question posed here is this:  If we are interested in the engineering tool end of the spectrum, is it possible to puzzle out some of the defining characteristics of a “good” automotive driving simulator?

anatomy-engineering-class-automotive-driving-simulatorA Driver-in-the-Loop (DIL) simulator is comprised of many sub-systems, just like a car -- mechanical, electrical, control systems and so on. All of these sub-systems must fit together to create a cohesive whole, similar to a complete image emerging from a collection of discrete puzzle pieces.  Although it is desirable for all the pieces to fit together neatly, it is also desirable to be able to remove pieces from time to time.  For example, you may wish to swap various hardware (dashboards, etc.) and software (vehicle modelling tools, etc.) for different DIL experiments, or it may be desirable to accommodate emerging technologies without disturbing the system as a whole (new projection technology, etc.). 

 

These aspects could be used to set the basic framework for any “good” driving simulator that is meant to serve as an engineering tool.  But alas, it’s just a framework; In order to identify characteristics, we must dive into performance.

 

Low Latency

Latency refers to the time domain delay between inputs and outputs.  In an engineering-class DIL simulator, inputs are vehicle states as calculated by a vehicle physics model and outputs are the inertial, visual, audio, and haptic cues that inform a driver about those vehicle states. In a simple sense, in order to assert that a DIL simulator’s latency is, say, 70 milliseconds, one could measure the occurrences of a few vehicle physics “demand” signals in time along with the corresponding changes in the simulator’s motion system, vision system, audio system and so on, and then equate the slowest responder to the overall simulator latency. But, in practice, there are a number of other subtleties to consider when referring to the term latency.

 

First, it is important to recognize that in some DIL simulator architectures, latency issues are, unfortunately, systemic and insurmountable.  For example, there are mechanical lag and friction issues associated with moving large payloads on hexapods that cannot be overcome with even the highest levels of applied engineering and/or cleverness. Another important aspect of latency is the notion of synchronicity between the various driver cues, i.e. Consideration of the time difference between the various cues, rather than independent assessments of each cue in isolation.  Getting this right in a DIL simulator means that a driver will be able to detect vehicle tuning changes that might affect, say, yaw-from-steer and g-from-steer responses during a virtual test drive session.

 

High-Performance Computing

High-speed computing is essential for creating virtual driving simulations for human drivers. Concurrent applications must be executed in real-time in order to avoid creating the above-mentioned system latencies and reduce expectation violations for the driver.  Enough communication bandwidth must be in place to share information to execute and monitor the DIL simulation, and there should be a reasonable amount of computational overhead to accommodate complex (simulated) situations.

 

It’s worth mentioning that human beings acting as the primary motion control system for a vehicle are unable to deliver voluntary movements beyond 5-7 Hz; i.e. this represents the maximum speed for hands and feet moving the steering wheel and foot pedals.  This is the usual state of affairs, except when ADAS or autonomous controls assume the role.

 

The implication is this:  Frequency content of driver cues in excess of 5-7 Hz will not result in voluntary vehicle control input changes.

 

This has important implications for computational resource allocations.  A practical example is that of image generation.  For displaying images of near-term forward and peripheral scenery moving past a DIL driver’s eyes at speeds up to 100 kph, an image refresh rate of 60 Hz might be adequate, but one might find it necessary to provide double that refresh rate at higher driving speeds. The driver’s vehicle control behavior is not being altered in this example if the vision system is changed, but the driver’s sense of immersion is most certainly changing.  In other computation areas, driver control behavior may be more strongly tied to execution strategy.

 

Driver Immersion

The ideal engineering-class DIL simulator creates an immersive driving environment that compels an experienced driver, upon emerging from the simulator cockpit, to speak about the simulated vehicle as if it was real.  An example of a salient driver comment is something like this: “I feel too much lateral compliance in the rear - this is especially noticeable on corner entry.” Although this may be considered a negative comment from the perspective of a ride and handling engineer, a DIL simulation engineer would be delighted because it implies that the driver is connecting with the driving experience rather than the simulator experience.

 

Creating this kind of immersive environment and inspiring this kind of driver response circles back to the need for balance among various sub-systems. Motion and vision systems are, of course, providing a key role in conveying the subjective experience of vehicle stability in this example, as is the vehicle physics and road surface model. The driver might also be picking up audio cues such as tire squeal and tactile and haptic cues through the seat and steering wheel related to lateral tire adhesion. Immediate cabin surroundings and A-pillars may be providing important visual references from which speed and directional changes are being assimilated.  And so on.  Overall, the symphony that is the DIL simulator must be “in tune” and playing a recognizable song for the driver in order to solicit subjective feedback about the (simulated) vehicle.

 

To learn more about next-generation engineering-class Automotive driving simulator and the advantages of high-performance, low-latency driving simulation, download our FREE white paper, Look Down the Road: Driving Simulator Technology and How Automotive Manufacturers Will Benefit”.

 

Look Down The Road: Driving Simulator Technology & How Automotive Manufacturers Benefit