Driver training in a simulator, part 2

This is the second post on how driver training in a driving simulator works, see the previous post here.

The first part of the simulator training curriculum consists of vehicle control lessons. This is followed by lessons in traffic participation. The final part consists of training in special circumstances.

Vehicle control forms the basis of learning to drive. Its not just about being able to use the clutch, gear shifter, brake, and steering wheel. Its much more than that. Vehicle control tasks are often procedures that have to be trained, where actions are performed in a specific order, and in which visual scanning  (checking the mirrors, and scanning to left or right or over a shoulder) and proper use of the indicator are an integral part. When the trainee has developed a sufficient level of skill in vehicle control tasks, the traffic participation tasks can be learned. This ensures that:

• elementary tasks are sufficiently well automated to enable the trainee to perform them without thinking, so all these tasks can be done simulaneously
• more attention demanding traffic tasks can be learned more efficiently because the trainee has sufficient free attention to monitor the immediate environment and to watch other traffic, road signs and make the proper decisions.

It is recommended that the trainee has already done the driver theory exam which is obligated in most countries. This ensures that the trainee already knows the rules of the road and all relevant traffic signs and the meaning of road markings and lines. At minimum, it is expected that the trainee knows the following:

• all speed limits
• the meaning of all road signs
• the priority rules
• where on the road the vehicle must be positioned (position on the road)
• rules about parking, overtaking, using the lights, etc.

After the meaning of the pedals and buttons has been explained, so the trainee knows the clutch, brake and accelerator pedals, the gear shifter, the indicator, handbrake and the buttons for the lights, wiper and for starting and stopping the engine, the student is ready for the first lesson.

Follow this to continue to part 3.

Advertisement

Driver training in a simulator, part 1

Driving simulators can be helpful as a didactic tool in drivers education. In other posts the benefits of a driving simulator have already been explained. Several driving schools already have one, but they generally use it in very diferent ways. In some driving schools the trainee is free to take lessons on a simulator, while in others the trainee has to take lessons in a simulator before they start their lessons on the road. The main reason a number of trainees wants to skip simulator training, is that a group of especially young male drivers is convinced that they are very good drivers and don’t need to be trained in a simulator. They think they only need a few lessons and want to get their licence with a minimum number of lessons.  Young male drivers often overestimate their skill level and underestimate the complexity of the driving task. That’s one of the reasons they are overrepresented in the accident statistics. So, if the instructor honors their demands to skip simulator training and start their lessons in a real car, that’s precisely against best safety practices.

It is recommended to follow a fixed trajectory for all students, in which everyone starts driver training in a simulator. When they have completed the simulator training phase, they start their on-road training with much more confidence. Also, because they have learned all basic skills and have automated these to some extent, they learning curve during the on-road training is steeper: they learn to drive safely in complex traffic situations faster. This is better for both the trainee, the instructor, the driving school and society in general: the pass rate for the driver tests will increase and accident statistics will improve. It has been found that during the first year after passing for the driver exam, accident risk is twice as high as the average accident risk.

Check the next post: part 2.

The advantages of using a driving simulator for driver training

Driving simulators are increasingly being used as a didactic tool in driver training and education. Because the hardware has become more affordable and the quality of the simulators has improved over the past years, more and more driving instructors have decided to add simulator training to their curriculum. Also, in a number of countries governments are contemplating to add simulator training as a mandatory component of driver training.

There are several advantages of using a car driving simulator for driver training.

• A high quality of training for all students. Since the quality of driver training is poor in a number of countries while traffic fatalities are high, training in a simulator guarantees a certain level of quality for all learner drivers.
• Because relevant driver skills can be consistenty practiced much better than in a real car on the road, the trainee gets much more driving experience in less time. This greatly enhances training efficiency.
• More efficient transfer of controlled to automatic processing, which results in safer driving. Separate driving tasks, such as lane changing, can be practiced and repeated again and again. without the trainee being distracted by other dangers on the road.
• Consistent and immediate feedback by a virtual instructor, which enhances speed of learning
• Complete and reliable evaluation after each lesson. The progress of the sudent is documented automatically and all aspects of the driving tasks are evaluated.
• All students receive the same training content, and all aspects of the driving task, ranging from gear shifting to filtering in on highways, are covered. So, completeness is guaranteed.
• Training in a safe environment without stress. Stress inhibits the efficient development of skills.
• A quaranteed supply of instructive traffic situations. During an hour of driving on the road in a real car the occurence of instructive traffic situations varies a lot. Sometimes nothing happens and sometimes there’s a lot of traffic, so the real world is verfy unpredictable. For efficient learning, you need predictable and carefully chosen learning situations.
• Fewer hours in a car on the road which amounts to less fuel consumption which is beneficial to the environment.
• The use of a driving simulator increases capacity of the driving school, while it reduces costs.
• Special circumstances, such as nightdriving, snow and rain, can be practiced anytime.

So, in conclusion, driver training in a simulator brings a lot of advantages. After the simulator training phase, the trainee can start driving in a learner car with much more self confidence, because the most important driving skills have already been learned.

Check the following post to see how driving simulator training actually works.

Task automation in car driver education

This post is sequal to a previous post on practice during driver training.

Because  individual tasks are practiced extensively, the required skills become automated in less time in a car driving simulator compared to driver training in a learner car on the road. The driving task-related skills are trained individually without the need to attend to other distracting matters. While driving on the road in a learner car, the instructor can not control the surroundings, which results in unpredictable and unexpected events. When skills change from controlled to automatic, they require less attention, and separate tasks can be performed simultaneously (multitasking). For example, when the gear shifting skill has become automatic instead of requiring controlled attention, and scanning behaviour while approaching an intersection has become more automatic as well, the complete procedure consisting of actions that need to be performed while approaching an intersection can be handled more efficiently and faster, with fewer errors. The automated skills that were trained in the driving simulator can be transferred to other similar situations as well. When scanning behaviour is learned well in a specific car, it can be applied well in an other car too. Or, when scanning behaviour is learned well in the driving simulator, it transfers to driving in a real car as well. The operations are similar in both situations.

If during driver training, extensive and systematic practice results in better task automation, workload and stress during on-road driving will be reduced. Research has shown that a higher workload results in a ‘cognitive tunneling’ effect, see Van Winsum et.al. (1999). This means that the driver narrows attention to a smaller part of the visual field or to a more limited set of objects. This increases the chance of a failure to detect important information, for example traffic signs or children crossing the road. Research has also shown that drivers with more driving experience, and consequently a higher level of task automation, look farther ahead. This results in a better anticipation to possible hazards. Also the driver has more time to adjust speed and adapt behaviour. This increases driver safety. A good driver is someone who adapts behaviour to changing circumstances and has a good representation of the surroundings of the vehicle (situational awareness). A lower workload results in the detection of more important information in time.

Practice is all in driver training

The main reason why young drivers fail for their driving exams and why they are overrepresented in the accident statistics is insufficient practice during driver training. Excellent driving schools where a large percentage of students pass the driving test let their students practice in a better way in various driving tasks. However, traditional driver training in a learner car may not be the most optimal way to learn to drive a car safely, in some respects. If a part of driver training is administered in a driver training simulator, especially the extensive practice of individual driving tasks, results can be improved drastically.

The learner car driver has to deal with a continuous high level of task load and stress during every driver training session. A lot of things have to be done simultaneously, for example:

• look far ahead to monitor the course of the road, which is required to steering; learner car drivers often don’t look far ahead but keep their gaze fixed to a point too close in front of the car
• look around the vehicle to detect hazards in the immediate surroundings, however, never take the eyes off the road for more than 3 seconds because otherwise the  risk of driving off the road is too high; learner drivers don’t scan around the vehicle sufficiently because the largest part of their attention is required for steering
• look in the rear view mirrors regularly, especially before approaching a junction or before decelerating
• always check the mirror and apply the indicator before a lane change
• check the road ahead to see if there are road signs
• check the speedometer to see if speed is lower than the local speed limit and remember the local speed limit
• look left and right before reaching a junction and evaluate if you have to give right of way to others; apply the priority rules you know
• monitor the rpm’s and decide if you have to gear up or down, choose the appropriate gear
• etc.

For a learner driver all this requires conscious attention because none of the separate driving tasks have been automated. Nobody can do multitasking. Multitasking is when more than one task has to be done simultaneously, that requires conscious attention.  A skilled driver can do a large number of these tasks simultaneously because the have had so much practice on these tasks that they are performed almost automatically without thinking. That means they have sufficient spare processing capacity left to anticipate to hazards in time and to react appropriately to unexpected situations that demand immediate attention.

Individual driving tasks, such as steering, driving off, gear changing, lane changing, scanning the mirrors, applying the indicator, etc. are practiced extensively in the driving simulator training program. These tasks are practiced in situations similar to real world situations in a real car. In a simulator, these tasks can be practiced without all the real world distraction the learner car driver has to deal with, while driving in a real car on real roads. For beginning drivers, the real world is simply too complex and unpredictable for learning to become skilled in the individual driving tasks.

See the next post to continue reading….

Create virtual worlds with RoadDesign, part 2

This article is a follow-up to part 1. RoadDesign is the tool to cretae virtual worlds that comes with the Carnetsoft research car driving simulator toolset.

Egg and ref files are stored when a database is saved and the Create 3D DB checkbox is ticked. The egg files must be converted into bam files by running the egg2bam utility from the command line (via a DOS window), for example:

egg2bam -ps rel Highway.egg Highway.bam

To see all the options of the egg2bam utility, type egg2bam –h

Egg files

Sometimes you may want to modify things in the egg file before you convert it into a bam file. In that case its good if you know the structure of the egg file

1. A list of all textures used. Textures for road signs, roadmarkings, TreePoly’s and Facepoly’s, are *.png (semi transparent). Textures for LandPoly’s are *.jpg. For example,

<Texture> 42 {

“textures/trees/S_Deciduous07.png”

<Scalar> wrap { repeat }

<Scalar> wrapu { clamp }

<Scalar> wrapv { clamp }

<Scalar> minfilter { linear_mipmap_linear }

<Scalar> magfilter { linear }

<Scalar> envtype { modulate }

}

This refers to a texture on a TreePoly (a rotating billboard, for trees and bushes). The folders referred to are in the \models folder where the *.bam file is located. So, the actual folder where S_Deciduous07.png is located is: c:\DriveSim3\Carnetsoft\models\textures\trees\

2. This is followed by a long list of vertices (vertex pool).

 

Vertices are 3D points (x, y, z). Each vertex has a unique id, referred to in polygons.

3. This is followed by a list of segments. These are the roadsegments with id’s as defined in the *.net file. So, suppose the egg file is Highway.egg, then there’s also a file named Highway.net, with segments that have id’s that refer to the segment id’s in the egg file.  Segments consist of subsegments, and may have road signs of roadmarkings connected to them.

4. This is followed by a list of intersections. These have the same id’s as the intersections in the *.net file.

5. After the intersections, there’s a list of LandPoly’s. A LandPoly is a ground texture, for example a grass field. A landpoly can have any number of vertices and must consist of a closed set of vertices (first and last point connect). If always MUST have a texture connected to it . If a texture has not been defined in RoadDesign, then <TRef> { -1 } will give an error when the egg file is converted into a bam file.

6. After the LandPoly’s there’s a list of TreePoly’s. A Treepoly is either a rotating billboard, that rotates in a way that is always is turned at the the viewer, giving it a 3D impression, or a simple 3D object with a set of transparant texture. TreePoly’s are trees, bushes and other vegetation, with a transparent texture on it. They are computationally cheap.

7. This is followed by a list of FacePoly’s. A FacePoly is a vertical transparent series of polygons where a façade is displayed. This can be a wall, a forest of a hill, in fact anything that’s further away and is aimed to block the horizon

8. The FacePolys are followed by a list of 3D objects. They are referred to as externobject.

All 3D objects that are listed in the egg file must have the .egg extension, as in PowerPylon1.egg. However, it is advisable to put the larger (in the sense of containing more polygons) 3D models in the *.ref file. So, a number of 3D models will be referred to in the egg file, while the larger 3D models will be referred to in the ref file.

Ref files

A ref file contains the references to the larger 3D models. The first line of the ref file contains data referring to the switch distances of database tiles and flags, for example:

1 600 350 0 0 1 1

• The first number is the file version number
• followed by (600 in this case) the switch distance of all tiles with objects that are higher and must be visible from a larger distance
• followed by (350 in this case) the switch distance of all tiles with objects that are lower and don’t have to be visible from a larger distance
• followed by a flag that indicates whether this file is used in night driving
• followed by a flag that indicates if a background haze effects may be used in this file (can be overridden in script)
• followed by a flag that indicates if a shadows may be used in this file (can be overridden in script)
• followed by a flag that indicates if sunscattering effects may be used in this file (can be overridden in script)

After that all 3D objects (*.bam files) that are positioned in this datsbase are listed:

0 models/objects/Shed0/Shed0.bam 100 500 45.00 0 0 1 -88.00 -179.03 0.00
0 models/objects/Shed1/Shed1.bam 100 500 0.00 0 0 1 -76.00 -54.23 0.00
0 models/objects/Shed2/Shed2.bam 100 500 45.00 0 0 1 -84.00 172.55 0.00

 

This has the following structure:

• 0 or value > 0: if >1 then its the id of an object that can be manipulated from script (for example change the texture during an experiment).
• name of the model (must have the *.bam extention)
• switch distance1 (obsolete)
• switch distance2 (obsolete)
• heading, pitch, roll of the object in degrees
• unused (always 1)
• x, y, z coordinate where center of object is located

The *.ref files can be manually editted if you want to change the position or orientation of the object.

 

 

Create virtual worlds with RoadDesign, part 1

RoadDesign is a designer for creating virtual worlds for the Carnetsoft research driving simulator. With RoadDesign you design the roadnetwork geometry and this results in both a ‘logical’ database and a graphical database. The graphical databases are in a format that is required for the Panda3d rendering engine. Panda3d is a realtime game engine that was developed by Disney Studios and Carnegy Mellon University. For more information about Panda3d, see:  http://www.panda3d.org/

 RoadDesign lets you design a 3D database in a 2D working environment, where you see the 2D representation in a top-down way. It lets you design a network of roads and roadsigns, plus underlying fields, vegetation, facades, and positions of 3D objects. The 3D objects (for example, buildings) are read into the designer and have been created by other software such as 3D studio. The 3D objects have been converted into egg and bam files.

The relation between files and programs is shown in the following figure.

 

The source file of a database is always the (binary) *.rdb file. This contains all the descriptions of roads, intersections, objects, etc. So, RoadDesign reads and writes a *.rdb file when you select a database.

The graphical database consists of two ascii files:

• an *.egg file
• a *.ref file

The logical database consists of an ascii file:

• a *.net file

Egg files are the database files used by Panda3d. Egg files are compiled into *.bam files because a bam file loads faster and requires less memory. The *.ref files contain references to 3D objects (buildings etc.) that are loaded in the graphics system together with the *.bam file. The rendering modules that read the *,bam and *.ref files are:

• c:\DriveSim3\python\ppython_center.exe
• c:\DriveSim3\python\ppython_left.exe
• c:\DriveSim3\python\ppython_right.exe

 The *.net files contain definitions that are used by the traffic and scenario generation system:

• c:\DriveSim3\Carnetsoft\SimCarnet\traffic.exe
• in the script files a reference is made to a database and to paths and segments of the network of roads (as defined in the *.net file)

The research driving simulator toolset comes with a version of RoadDesign, and a large set of databases the user can work with. These can be modified, extended, or simply used in experiments. Selecting and/or making a database is the first step in defining an experiment.

This article is continued in part 2….

Scenario scripting language

The Scenario specification language of the Carnetsoft research car driving simulator is very much different from a regular programming language, such as C++, or from other script like languages like python.  The syntaxis however, resembles the Pascal and C programming language.

The script language is used in the research simulator toolset to create experiments by researchers. It does not require specific programming skills, although some people have more talent for this than others.

In a regular programming language and other script languages, there is a clearly define program flow. There usually is a main() function or something similar, that controls the flow of the program from start to end. This is very different in the scenario specification language.

Scenario specification language is a structured way to specify driving simulator scenarios. It consists of commands in an ASCII file (source file) that are read by the scenario- and traffic generation program. The scenario scanner first performs a syntactical analysis of the specification in the source file. The scenario parser makes a further analysis of the language elements. When no errors occur, internal scenarios are constructed as binary trees that are handled in runtime by the scenario interpreter. When there are syntactical errors, list of errors is printed on the screen, together with a linenumber in which the error occurred, and the simulator program is aborted. Internally, the scanner/parser mechanism constructs a temporary file that consists of a conjunction of the included scriptfiles and the top-level script file. This temporary file has the name ‘scentemp##001’. The line numbers in the errorlist refer then to the linenumbers in this file. Textpad 4 is used as a text editor with special syntactical help. The script files have the extention *.scn. They may use include file (extention *.sci) with functionality that’s reused. To read the script in the simulator, it has to be compiled into a binary scriptfile with the *.scb extention. In Textpad 4, the syntax is checked via a special tools. If there are syntactical errors you are referred to the file + linenumber where the error is located. If there are no errors, a *.scb file is created in the same folder as the *.scn file. Error checks can only be done from an *.scn file.

A scenario is a predefined list of situations with a start- and end condition. Scenarios are used for the complete simulation process. It may for instance be used for initialization and repositioning of all cars, for controlling traffic lights, for indicating when data must be stored, for communication with the driver via spoken messages and for sending messages to other devices. In our terminology, a scenario is a predefined script that specifies to the runtime system what to do.

Every scenario is unique in the sense that every scenario has a unique identification number. There is no upper limit to the number of scenarios that can be specified. Every scenario must have an unique number. This is an identification number that can be used by other scenarios to refer to. Scenarios are allowed to overlap, meaning that more than one scenario may be active at the same time. The number of scenarios that may be active at the same time is unlimited, with the restriction that if a particular scenario is active, it cannot be activated again until it is terminated. So if a certain scenario is active it cannot be activated again during the time it is active, but it may be activated again when it is finished. This means that all scenarios that are active at the same time are different and unique.

Local scenarios, that are assigned to traffic participants, are a bit different, however. Each participant (autonomous agent) may have the same scenario attached to it, but still all these instantiations are different because they have their own local variables. The same scenario may be activated more than once in the course of runtime.

So, there are two different types of scenarios, global scenarios and local scenarios. A global scenario is the normal type: it is defined as

Define Scen[number] {

Start {

When ( Condition1 = True );

}

End {

When ( Condition2 = True );

}

}

It starts when a certain condition evaluates to true and it stops when another condition evaluates to true. A local scenario is always attached to one or more traffic participants. It is defined as:

Define PartScen[number] {

Start {

When ( Condition1 = True );

}

End {

When ( Condition2 = True );

}

}

Each local instantiation of a PartScen has its own local variables. Local scenarios are used to control things for specific participants.

The difference between driving games and driving simulators

 

When most people think of a car driving simulator, the first thing that comes to their mind is a racing game or car driving game. Game manufacturers usually market their game as a simulator, so no wonder the term simulator can be confusing. However, the differences are very large.

Training simulators cover a long history. Already in the first world war, training simulators were used to train aircraft pilots. They were first used in the military training sector to teach aircraft-, ship-, tank- and landvehicle control. Simulators are also heavily used in space travel, and NASA has a complete simulation department for training astronauts. Driving simulators have been developed in the same tradition and can be found in universities and car industry laboratories, where they are used to study the effects of road infrastructure and in-vehicle-devices on driver behaviour, see for example the driving simulator of VTI in Sweden. Probably the most expensive research driving simulator in the world is located in Iowa.

Since the year 2000 driving simulators are increasingly being used by larger driving schools in a number of countries, especially because the price of hardware has been reduced while the capabilities of computers has been increased. However, the game industry has benefitted the most from the development in graphics boards.

Driving games are a much more recent development that has resulted in games with spectacular graphics. This has led people to expect the same level of graphics from driving simulators, especially since driving simulators are much more expensive. However, there are large differences between commercial driving games and driving simulators in the more traditional sense.

• The market for driving games is MUCH bigger than for driving simulators, so a good game title sells way more copies. This has a big effect on price. Games are often cheaper than €50 while the software of a commercial driving simulator is often more than €5000. That’s a simple matter of business economics: higher volumes means lower sales price.
• Game studios have larger development teams. The development of a game often takes more than a year, and a team consists of a number of programmers, designers, and other staff. The budget is typically a couple of millions of euros. Customers expect stunning graphics and this requires a lot of the developers. Only a few games become a commercial success, while the majority never becomes profitable. Development teams for driving simulators are usually much smaller and the budget for development is also a lot smaller. This results in less focus on innovation in computer graphics and more on training value.
• A computer game is usually played on just one monitor, and the forward horizontal field of view is around 60 degrees. That reduces the number of objects that can be seen and are sent to the graphics card (PGU). In a driving simulator, there are, at minimum, three monitors that cover 180 to 210 degrees horizontal field of view, plus three rearview mirrors. So, that’s 6 channels that cover approximately 360 degrees field of view. That’s 6 times as much objects sent to the GPU per frame. Modern GPU’s can process an enormous amount of polygons and vertices and have large amounts of texture memory, so this is hardly a limiting factor. However, the development of the bandwidth (number of Gb/s that can be sent to the GPU) has hardly seen any development, and this limitation makes 360 degrees surround rendering much more difficult. This is not a problem for games that render only over a small FOV, but it is a problem for driving simulators. And this is the most important reason that the graphics of driving simulators is not as spectacular as the game software, because the only way developers can deal with the bandwidth limitations is by reducing the number of objects, and by limiting advanced shader techniques for stunning effects.

Driving simulators and virtual reality

The typical components of a VR (Virtual Reality) system are a computer generated world through which the subject moves, that is displayed to the user by means of a helmet mounted display (HMD). A headtracker measures where you are looking at while the images are presented stereoscopically, to both eyes separately, from the viewpoint of the head in the direction the head is facing. The subject experiences depth which enhances the experience. Since the eyes are covered in most VR systems, the subject is unable to see the actual surroundings: only the virtual world is experienced and this greatly enhances immersion.

VR systems have been around since the seventies of the 20th century. The availability to the general public has been low because of the high cost and technical insufficiencies. The more expensive systems have been used in military training. However, the VR technology never became popular in games or simulators. The most important reason was the cybersickness that came with the use of a HMD.

The Oculus Rift is one of the most recent developments in VR that promises a larger field of view, high resolution, fast headtracking and less cybersickness for an affordable price. The developers of the new VR equipment are convinced that cybersickness is caused by technical imperfections, and that by making a technically more advanced system, cybersickness will be resolved. It is tempting to use a high quality low cost VR system like that in a car driving simulator for driver training. There are several advantages, such as a reduction in cost of the simulator hardware  because a complex and expensive projection system is not required. Also, it gives 3D vision with real depth perception. The experience of realism would be higher compare to regular driving simulators. Driver training in a VR simulator would be very attractive for young learner drivers because of the impressive immersion and the high wow factor.

A ‘traditional’ driving simulator is similar to a Virtual Reality system, except for the helmet mounted display (HMD) and head tracking. In both systems, a computer generated world is presented to the driver and the driver interacts with this world by moving through the virtual environment and responding to the infrastructure and other traffic though the steering wheel, shifter and pedals. A driving simulator is perfect for young inexperienced drivers. This group of drivers hardly ever experiences simulator sickness or cybersickness.

Simulator sickness is similar to the cybersickness experienced in VR systems, but it differs in some respects as well. Simulator sickness is very much related to the absense of motion which causes a mismatch between what you see and what you (expect to) feel. Since only experienced drivers have learned the experience of motions that occur during lateral and longitudinal accelerations, they experience a mismatch between what they see and the lack of feeling motions (in a fixed base simulator). This increases the prevalence of simulator sickness in older and more experienced drivers, while the chance of experiencing simulator sickness is very low in young and inexperienced drivers. Simulator sickness also increases with higher immersion and with projections over a larger horizontal field of view. For example, a three-display (120 degrees horizontal field of view) simulator results in a higher incidence of simulator sickness compared to a simple one-display system. Also, a system with 180 degrees of larger projection screens induces simulator sickness more frequently than a system with smaller 23 inch monitors. In a regular driving simulator, the rendering of the graphics is static: on the left, middle and right displays the images are always from the perspective of the position of the head facing forward. So, to see what is left of you, you look to the left display. If you want to see what is in front of the car, you look at the middle display and if you want to look to the right, you check the right display. In other words, your ego reference is fixed, just as in a real car. You sit in a virtual car and as the vehicle moves through the world, you move with it and your absolute position in the vehicle is fixed.

In a VR system this can be very confusing. There’s the motion of the vehicle which results in a different position and viewing direction in the virtual world, and there’s also the motion of the head which results in a different position and viewing direction in the virtual world. My point is that these two motions and directions are very difficult to unravel by the brain in a VR system.

I have done tests with VR systems connected to the driving simulator, most recently with the Vuzix Wrap 1200VR, and some consistent experiences I had were:

• driving in a VR system results in cybersickness very quickly, especially when you look around (left and right) while the car is driving. Especially the headaches can be quite pervasive and last for hours.
• driving in a VR system is very hard, especially steering is difficult. For example, when you look to the left while you are driving, there’s a strong tendency, which is almost impossible to suppress, to steer to the left as well. So, your steering follows the direction your head turns and this is a persistent effect that makes driving almost impossible. The only way to reduce the cybersickness is by keeping your head still, but in driver training visual scanning (mirrors and looking to left and right) is an essntial part of the task.

Maybe these effects will not occur in a sophisticated system like the Oculus Rift. However, I am not sure of that, because the effects are so pervasive.

From my experience, for driving, the HMD as used in VR is not suited, because of the risk of cybersickness that comes with the use of HMD’s and because of the difficulty of the brain to separate the effects of vehicle movement and head movements in a VR system:

• the vehicle moves through the world, controlled by the steering wheel and pedals of the driver.
• the driver looks around in the environment by turning the head (head tracking)

These two types of motions in combination give a high risk of cybersickness in a VR system and makes steering very difficult. It would be interesting to study these phenomena in more detail and to see if and how these problems can be solved. Maybe these effects are not so pervasive in a FPS game, where you ‘walk’ slowly and use other means to move forward (instead of a steering wheel and pedals).