The invention pertains to the field of video driving simulators, and, more particularly, to the field of driving games having moving video displayed dashboards which simulate the perspective seen by the driver when cornering an actual vehicle.

One of the important visual cues to a driver of an actual vehicle is the relative movement between the dashboard and the outside scene when cornering the vehicle. This relative movement results from the fact that as the vehicle corners, the inertia of the driver's head causes the driver's head to move inside the vehicle from its pre-cornering position. This movement is caused by the tendency of the driver's head to continue motion in a straight line and by the centrifugal force of the turn. The resulting view before the driver's eyes is an apparent relative movement between the dashboard and the outside scene. This important visual feedback cue tends to verify for the driver that the car is in fact responding to the turning command.

Heretofore, as far as is known to the Applicants, no video or driving simulator has moved the dash of the simulated vehicle relative to the outside scene on the video display to provide the aforementioned visual cue. Therefore, a need has arisen for a driving simulator which provides this visual cue.

The US patent US-A-4 182 053 (Richard W. Allen et al), entitled "DISPLAY GENERATION FOR SIMULATING VEHICLE OPERATION" discloses a system for displaying the images in the outside scene to simulate movement through the scene. However, it does not disclose or even suggest the simulation of a relative movement between the dashboard and the outside scene.

Summary of the Invention

According to the teachings of the invention, there is disclosed an apparatus and method for scrolling a dashboard in accordance with simulated conditions affecting a simulated vehicle to simulate the perspective seen by a driver in response acceleration forces acting on the driver's head and neck.

An object of the invention is an apparatus for scrolling a video display of a control panel of a simulated vehicle operated by an operator to simulate a perspective change when a vehicle operator's head moves in a real vehicle relative to that vehicle under the influence of an acceleration vector acting on the operator's head, characterized in that it comprises :

• means for calculating data representing a simulated acceleration acting on the vehicle operator's head and data representing a resulting apparent perspective of the control panel to the operator of the vehicle which would result from the simulated acceleration; and
• a display for displaying the control panel (60) in a position on the display which simulates the apparent perspective.

An other object of the invention is a method of displaying a control panel of a simulated vehicle on a video display and shifting the displayed position of said control panel to simulate perspective change to the operator of said vehicle, characterized in that it comprises the steps of:

• reading control inputs from said operator indicating desired movements of said simulated vehicle and calculating therefrom data indicating the position at which to display said control panel taking into account the forces acting on the operator's head and the compliance of the operator's body resisting movement of the operator's head; and
• using said data to control the output of video data defining the appearance of said control panel (60) such that said control panel appears in the proper place on said display to simulate the perspective which would be seen by said operator.

Brief Description of the Drawings

Figure 1 is a block diagram of the hardware of a driving simulator.

Figure 2 is a view of a typical scene seen by an operator of the simulated vehicle in the simulator of Figure 1.

Figure 3 is a model of the head and neck model used for calculating the perceived perspective change.

Figure 4 is a mechanical model of the head and neck compliance model.

Figure 5 is a hardware block diagram of the circuitry that supports horizontal scrolling of the dashboard.

Figure 6 is a more detailed hardware block diagram of the circuitry that implements horizontal scrolling of the dashboard.

Figure 7 is a software flow chart showing the sequence of operations that occurs in implementing the horizontal scrolling of the dashboard.

Annex A is the high level C language description of the code computing the components of the acceleration vector.

Annex D is the C language communication structure for communication of data between the model processor and the 68000 master processor.

Annex B is the C language code which is run by the 68000 to process the acceleration vector input data from the model processor.

Annex C is the C language communication structure to pass data between the 68000 and the display processor.

Annex E is the C language code run by the display processor which calculates the position at which to paint the representations of the rear view mirror and the sidepost in the middle segments of the display.

Annex F is the C language code run by the display processor to calculate a variable curdashx which defines where the left edge of the dash is to appear.

Annex G is the C language code run by the display processor to call the norollhorizon routine to obtain the calculated value for the desired position of the dash and then performs the coarse and fine horizontal scrolling function by outputting the appropriate data to the DPYTAP register in the display processor and the preset nibble to the pixel scanning circuit.

Detailed Description of the Preferred Embodiment

Referring to Figure 1, there is shown an overall block diagram of the driving simulator hardware. Not all of the apparatus shown in Figure 1 is involved in implementing the teachings of the invention, but the overall system is shown for completeness. The driving simulator illustrated in Figure 1 uses a model processor 20 to calculate acceleration vectors acting on the simulated vehicle in accordance with driving conditions. User input is received regarding the desired movements of the vehicle from a steering wheel 22 a gas pedal 24, a brake 26 and a gear shift 28. The model processor receives these inputs and uses them as parameters in the solution of a set of simultaneous equations which implement a model of how a real vehicle would react to such user inputs in the real world. The solution of these equations represents an acceleration vector acting on the vehicle. This acceleration vector is output on bus 30 to a master processor 32.

The master processor serves as the system coordinator in coordinating communication between the various processors and other elements of the system. For example, the master processor 32 communicates with a math coprocessor 34 and a sound processor 36. The math coprocessor 34 computes a display list for polygons which comprise the visual scene which will be presented to the driver as a visual cue as to how the vehicle is moving through the universe stored in memory of the simulator. Note that the memory for the various processors in the system is not shown, but obviously all of the processors in the system need access to memory to store and retrieve data involved in their various operations. The sound processor 36 digitally generates sounds such as screeching tires, wind sound and motor sounds to provide the appropriate audible cues to the driver of the simulated vehicle based upon the current conditions affecting the vehicle. A sound processor 38 provides further sound processing and conversion to analog output for the loudspeaker 40.

The master processor 32 communicates the display list for the polygons in the outside scene to a display processor 42. The display processor performs the appropriate processing to cause a video display on a screen 44 of the position and actions of the simulated vehicle in the universe stored in the memory of the system of Figure 1. A typical scene which will be presented to the driver of the simulated vehicle on screen 44 is as shown in Figure 2.

Referring to Figure 2, the scene which is presented to the driver is comprised of basically three segments. The horizon segment 46 moves very little if at all because of its large distance from the driver and the vehicle as it moves through the universe. The middle segment of the screen indicated at 48 is where most of the apparent movement of the vehicle through the simulated universe is depicted. Finally, the dashboard segment of the screen, shown at 50, does move, but in the preferred embodiment is limited to horizontal scrolling back and forth along the axis represented by arrows 52 and 54 in response to cornering movements of the car. There is a simulated rear view mirror 56 and a simulated sidepost 58 which are connected to the car and which appear in the middle segment 48. These items 56 and 58 are moved simultaneously with the movement of the dash to provide visual cornering cues. In alternative embodiments, the simulated dashboard 60 on the video display and the cornerpost 58 and rear view mirror 56 could also move in the vertical direction represented by the arrow 62 to simulate the apparent movement of the dashboard in a car as the driver's head moves toward the front of the car or toward the rear of the car with acceleration and deceleration of the simulated vehicle.

Referring to Figure 3, there is shown a symbolic diagram of the relationship of the driver's head to the coordinating system used by the model processor to generate an acceleration vector. The driver's head is shown at 70 with a compliance model for the neck and body compliance of the driver's body shown symbolically at 72.

A coordinating system used by the model processor has the positive X axis toward the car front and extending into the page in the view shown in Figure 3. The positive Y axis is to the right, while the positive Z axis is downward in the view shown in Figure 3. Thus, the surface of the driver's head 70 seen in the view of Figure 3 is the back of the driver's head and the driver's face faces forward toward the front of the car or into the page.

Simulated dash movement by horizontal scrolling in the display shown in Figure 2 is used to simulate the perspective seen by the driver when the car corners or changes directions in the X-Y plane. For example, when the car turns to the right or to a more positive Y coordinate in the X-Y plane, the driver's head, because of inertia, tends to continue on the straight path the car was following before the turn was initiated. This causes the driver's head to move left or more negative in the Y direction relative to the framework of the car, which causes the apparent shifting of the dashboard, rear view mirror and sidepost in Figure 2 toward the right. Similar but reversed situation applies for turns to the left. In alternative embodiments, the program may be adapted to cause vertical scrolling of the dashboard 60, the sidepost 58 and the rear view mirror 56 in the view shown in Figure 2 to simulate acceleration and deceleration along the X axis in Figure 3. This would correspond to movement of the driver's head back and forth along the X axis in response to these accelerations.

Referring to Figure 4, there is shown a model of the mechanical system which represents the physical system shown in Figure 3. The compliance model 72 is represented by a spring constant in a spring 74 while a dash pot 76 represents the damping of the system. The driver's head 70 is represented by head mass 78. The system is anchored to a moving platform 80. A turn of the vehicle is represented by movement of the moving platform 80. This movement is transmitted to the headmass through the spring 74 and dash pot 76 and results in movement of the headmass 78 in accordance with the spring constant of spring 74 as damped by the dashpot 76.

Referring to Figure 5, there is shown a block diagram of the apparatus which performs the horizontal scrolling of the dashboard, the rear view mirror and the sidepost. A display processor 82 running a program stored in random access memory 84 generates the appropriate data to cause the horizontal scrolling. The display processor 82 is a Texas Instruments TMS 34010 model video processor. This processor receives a 4 mHz clock signal and has an instruction set which includes instructions to cause horizontal scrolling with a step size of 16 pixels. The display processor generates video signals on a bus 86 to control a video display in a digital to analog converter and display circuit 88.

The random access memory 84 contains the pixel data which defines the horizon section 46, polygon section 48 as well as the dash section 50 including the rear view mirror 56 and the sidepost 58 of the display shown in Figure 2. The display processor 82 manipulates this video data via a bus 90. The random access memory 84 is structured such that entire raster lines of video data may be simultaneously shifted into a bank of shift registers 92. These shift registers are sequentially enabled by control signals on a bus 94 which are generated by a pixel scanning circuit 96. The pixel scanning circuit is essentially a counter and decoder arrangement which receives a 16 mHz video clock signal and a blank signal on line 98 which establishes the start time for the scan of each horizontal raster line. As the video clock signal causes the counter in pixel scanning circuit 96 to count up, different selective signals on bus 94 are generated which cause the appropriate video data for the horizontal line being scanned to be output on the video data bus 100 to the display circuitry 88. There the video data is converted to analog signals in RGB format and display.

Horizontal scrolling with one pixel step sizes is implemented through the use of the preset signal on bus 102. This signal is comprised of a four bit nibble calculated by the display processor 82 in a manner which will be described further below.

Referring to Figure 6, there is shown a more detailed circuit diagram for the pixel scanning circuit 96 in Figure 5. A presetable counter 104 receives the preset nibble on bus 102. This preset nibble establishes the count from which the counter starts. The blank signal on line 98 is coupled to the lode input of the counter 104, and the 16 mHz video clock signal is coupled to the clock input of the counter 104.

When the blank signal is activated, the count established by the data on bus 102 is loaded into the counter and counting starts in synchronization with the pulses arriving at the clock input. The counter has a four bit output which is coupled to a bus 106 which in turn is coupled to the inputs of a decoder 108. This decoder has a lode input which is coupled to the blank signal on line 98. When the blank signal is activated, the counter output on bus 106 is decoded by the decoder 108 and causes activation of one of the multiple shift register select lines on output bus 110. Each of these shift register select lines is coupled to one of a plurality of inverted input norgates 112 through 119. The other input of each gate is coupled to a signal on line 120 called memory-to-shift-register-transfer. The outputs of these gates 112 through 119 are coupled to individual enabled inputs of individual shift registers in the bank of shift registers represented by block 92 in Figure 5. Thus, as the counter 104 counts, the decoder 108 sequentially selects different ones of the various shift registers in the bank of shift registers to cause the appropriate video data to be displayed for the raster scan line currently being scanned. Each shift register has its own count which corresponds to the activation to one of the lines on bus 110. The signal on the line 120 acts as a gating signal to pass the activated signal on bus 110 through to the enable input of the selected shift register. This signal on line 120 is activated at the time that a memory to shift register load event is supposed to occur to load a new line of video data into the bank of shift registers.

By changing the data on the preset bus 102, the first shift register that is enabled through the action of the decoder 108 can be altered which causes the left edge of the dashboard 60 in Figure 2 to appear at different positions along the axis represented by the arrows 52 and 54 in Figure 2. The arrangements of the shift registers in the bank of shift registers 92 in Figure 5 is such that changing the data on the preset line 102 causes horizontal scrolling of the dashboard with one pixel resolution. The preset data on bus 102 is essentially a "fine tuning" control while the display processor 82 provides the "coarse tuning" control. That is, horizontal scrolling of the dash is achieved with a 16 pixel resolution by loading a register called DPYTAP in the display processor 82 with a five bit number that defines the desired horizontal position of the dashboard within a 16 pixel resolution. This represents the coarse position of the dash. The fine position of the dash is established by setting the appropriate preset number on bus 102 in Figure 6. This number determines the fine position of the dash board as somewhere within the 16 pixel interval defined by the coarse tuning number in the DPYTAP register within the display processor.

Referring to Figure 7 there is shown in symbolic form a flowchart of the processing performed by the three processors to implement the horizontal scrolling of the dashboard, rear view mirror and sidepost according to the teachings of the invention. Block 130 represents the system of equations which models the response of the car to driver inputs. The particular model used for the car's response is not critical to the invention and will not be further described herein. Basically the model processor 20 in Figure 1 receives inputs from the steering wheel 22, gear shift 28, gas pedal 24 and brake pedal 26 and converts these driver-controlled inputs to parameters. These parameters are then substituted into the model equations to determine the response of the car to those driver inputs. This results in the calculation of an acceleration vector A (x,y,z) which represents the acceleration of the car in response to the driver inputs. This acceleration vector is a floating point number represented by x, y and z components in the coordinate system defined in Section A of Figure 7. This acceleration vector is then scaled and converted to an integer in an operation defined by block 132 in Section A of Figure 7. The purpose of the scaling is to implement the spring constant represented by spring 74 in Figure 4.

Referring to Annex A, there is shown the actual code in the high level language C which computes the acceleration vector x, y and z components. The acceleration vector is calculated by multiplying the force vector components in each of the x, y and z directions x the inverse of the mass representing the head of the driver. This is done because force = mass x acceleration and it is faster to multiply in a computer than to divide the force by the mass of the driver's head. Therefore the force multiplied by the inverse of the mass represents the acceleration of the driver's head. Note that in the preferred embodiment, the x and z components are commented out of the program listing so that only the y component is currently being used. In alternative embodiments, however, the x and z components may also be used with additional hardware to support the scrolling necessary to represent these changed perspectives.

Referring to Annex D there is shown the high level C language communication structure for communication of data between the model processor 20 in Figure 1 and the 68,000 master processor 32 in Figure 1. Communications between processors and the structure shown in Figure 1 is done by virtue of overlapped memory mapping. The code shown in Annex D essentially defines the structure of a portion of the memory in the sense of defining what a data record containing multiple fields. The definitions contained in the structure of Annex D define what the data in each field represents.

Referring to Annex B, there is shown the C language code which is run by the 68,000 to process the acceleration vector input data from the model processor. The purpose of the code in Figure 10 is to scale and low pass filter the acceleration vector input data and to generate an output variable called dash x. Although the C level code in Annex B also generates an output variable dash y, this dash y variable is not used in the preferred embodiment. In alternative embodiments however, it may be used to control vertical scrolling of the dashboard, rear view mirror and sidepost to simulate the changing perspective as the car accelerates and decelerates in a straightahead fashion.

The scaling and low pass filtering function of the code in Annex B is symbolized by blocks 134 and 136 in Section B of Figure 7. The model.H shared C language communication structure represented by the code of Figure 9 is symbolized by block 138 in Figure 7. The purpose of the scaling function represented by block 134 in Figure 7 is to implement the spring constant of the spring 74 in Figure 4. The purpose of the low pass filter operation represented by block 136 is to implement the action of the dashpot 76 in filtering out high frequency components. This avoids a jittery dash movement which would otherwise result by virtue of the updating of the acceleration vector every 30 miliseconds. Note that the coordinate system used by the 68,000 master processor and doing its function is changed from the coordinate system used by the model processor. In alternative embodiments, both coordinate systems can be the same. After the acceleration vector data from the model processor has been scaled and low pass filtered in the master processor, the value of the variable dash x is passed to the display processor 82 in Figure 5 via the communication structure 68 GSP.H symbolized by block 140 in Figure 7. Block 140 represents the shared code given in Annex C. This code is shared between the 68,000 master processor and the display processor to allow data to be passed between these two processors. The relevant field for the preferred embodiment of the invention is defined by the line pointed to by the arrow in Annex C. This field contains the data for the dash x variable represented by information transfer line 142 in Figure 7. This data represents the amount by which the dash is to be moved by virtue of the current acceleration vector.

Referring to Annex E, there is shown the code of the 68 GSP.H file run by the display processor which calculates the position at which to paint the representations of the rear view mirror and the sidepost in the middle segment of the display. This code pulls the parameter dash x out of the communication structure for use in calculating the locations of the mirror and sidepost so that their locations and movements may be synchronized with the location and movements of the dashboard. The calculations performed by the code of Annex E are done within a routine called "interiors" and are symbolized by block 144 in Figure 7.

Referring to Annex F, there is shown the code in a file called mountain.C which is run by the display processor to calculate a variable called curdashx which defines where the left edge of the dash portion of the screen display is to start. This calculation is made in a routine called norollhorizon. The key calculation is the line of code pointed to by the arrow in Annex F. The constant 114 is used as an offset so that the displayed dashboard will be centered when the dash x variable indicates no acceleration vector is acting on the driver's head. The code of Annex F is represented by the block 146 in Figure 7.

Referring to Annex G, there is shown the code in a file called DPOLY.ASM. This code is run by the display processor and serves to call the norollhorizon routine to obtain the calculated value for the desired position of the dash and then performs the coarse and fine horizontal scrolling function by sending the appropriate data bits to the DPYTAP register in the display processor and the preset nibble on bus 102 to the pixel scanning circuit 96 in Figure 5. The code which sets the coarse horizontal scrolling register contents is pointed to by arrow 150 and the code which writes the appropriate preset nibble on bus 102 is pointed to by arrow 152. The operation of this code is symbolized by block 154 in Figure 7.