The Simulation of Driver Inputs Using a Vehicle Driver Model

Abstract

Traditional vehicle simulations use two methods of modeling driver inputs, such as steering and braking. These methods are broadly categorized as “Open Loop” and “Closed Loop”. Open loop methods are most common and use tables of driver inputs vs time. Closed loop methods employ a mathematical model of the driving task and some method of defining an attempted path for the vehicle to follow. Closed loop methods have a significant advantage over open loop methods in that they do not require a trial-and-error approach normally required by open loop methods to achieve the desired vehicle path. As a result, closed loop methods may result in significant time savings and associated user productivity. Historically, however, closed loop methods have had two drawbacks: First, they require user inputs that are non-intuitive and difficult to determine. Second, closed loop methods often have stability problems. This paper describes a newly developed driver model that appears to hold significant promise in addressing both of these areas. The paper describes the basic vehicle driver model and path generator. Next, the paper provides an intuitive basis for reasonable user inputs. Finally, the paper provides some interesting examples of the use of the vehicle driver model for real-world applications. MOTOR VEHICLE HANDLING simulation usually has as a goal the duplication of measured experimental data. Handling simulation is also used to assist in the reconstruction of real-world motor vehicle crashes using evidence (e.g., tire marks) gathered at the crash site. Quite often, the chief criterion is to duplicate the actual path followed by the vehicle during an event. To perform the simulation (once the required vehicle parameters have been assigned), the user assigns an initial position and velocity for the run. Next, a set of assumed driver controls (steering, braking, throttle and gear selection) is supplied. The run is then executed and the resulting simulated path is compared to the actual (measured) path. If an acceptable match is achieved, the user concludes the assumed driver controls are reasonable estimates of those used during the experiment. If the match is not acceptable, the user modifies the initial conditions or driver controls as required to improve the match.