Refine Your Search

Search Results

Viewing 1 to 11 of 11
Technical Paper

Single Vehicle Wet Road Loss of Control; Effects of Tire Tread Depth and Placement

2002-03-04
2002-01-0553
When an automobile is driven on wet roads, its tires must remove water from between the tread and road surfaces. It is well known that the ability of a tire to remove water depends heavily on tread depth, water depth and speed, as well as other factors, such as tire load, air pressure and tread design. It is less well known that tire tread depth combined with placement can have an adverse effect on vehicle handling on wet roads. This paper investigates passenger car handling on wet roads. Flat bed tire testing, three-dimensional computer simulation and skid pad experimental testing are used to determine how handling is affected by tire tread depth and front/rear position of low-tread-depth tires on the vehicle. Some skid pad test results are given, along with corresponding simulations. A literature review also is presented. Significant changes in tire-road longitudinal and lateral friction are shown to occur as speed, tread depth and water depth vary, even before hydroplaning occurs.
Technical Paper

Validation of DyMESH for Vehicle vs Barrier Collisions

2000-03-06
2000-01-0844
A new three-dimensional collision simulation algorithm, called DyMESH (Dynamic MEchanical SHell) was recently introduced.[1]* This paper presents a validation of DyMESH for vehicle vs. barrier collisions. The derivation of the three-dimensional force vs. crush relationship was described previously.[1] Here the application of three-dimensional force vs. crush curves using the outlined methodology is shown to be effective. Nonlinear force versus crush relationships are introduced for use in DyMESH. Included are numerous DyMESH collision simulations of several types of vehicles (e.g., light and heavy passenger car and sport utility) compared directly with experimental collision test results from various types of barrier tests (e.g., full frontal, angled frontal, and offset frontal). The focus here is not on the vehicle’s change in velocity, but on the acceleration vs. time history.
Technical Paper

The DyMesh Method for Three-Dimensional Multi-Vehicle Collision Simulation

1999-03-01
1999-01-0104
Two-dimensional collision simulation has been used successfully for two decades. Two- and three-dimensional momentum methods are also well known. Three-dimensional collision simulation can be accomplished using finite element methods, but this is not practical for interactive collision simulation due to long mesh generation times and run times which may take several days. This paper presents an approach to collision simulation using a new algorithm to track interacting vehicle surface meshes. Three-dimensional forces due to vehicle crush are taken into account during the solution and the damage profile is visualized at run time. The new collision algorithm is portable in that it takes as input vehicle material properties and surface geometries and calculates from their interaction three-dimensional forces and moments at the vehicle center of gravity. Intervehicle mesh forces may be calculated from a user-defined force-deflection relationship. The derivation is discussed.
Technical Paper

An Overview of the EDSMAC4 Collision Simulation Model

1999-03-01
1999-01-0102
The EDSMAC simulation model has been in widespread use by vehicle safety researchers since its introduction in 1985. Several papers have been published that describe the model and provide validations of its use. In 1997, the collision and vehicle dynamics models were extended significantly. The main control logic was also extended and generalized. The resulting model was named EDSMAC4. This paper describes the EDSMAC4 model with particular attention to the extensions to the original algorithms. The paper also provides a validation of the new model by direct comparison to staged collision experiments and the results from the previous EDSMAC model.
Technical Paper

Further Validation of EDSMAC Using the RICSAC Staged Collisions

1990-02-01
900102
The accuracy of the SMAC computer program was evaluated in terms of its ability to predict the correct paths and damage profiles for vehicles involved in a crash. A comparison of the results from SMAC and EDSMAC were presented along with measured results from twelve staged collisions. Statistical analysis of those results revealed the average path error was 25 to 29 percent and the average damage profile error was 109 to 287 percent. A procedure was presented for improving the match between simulated and measured paths. After using this procedure, the average path error was reduced to -2 to 7 percent and the average damage profile error was 54 to 186 percent. CDC predictions were very good. Damage profile errors, which did not reduce the program's overall effectiveness, were the result of the way the program computes inter-vehicle forces, leading to a recommendation that the algorithm be reformulated to include an initial force coefficient.
Technical Paper

An Overview of the Way EDCRASH Computes Delta-V

1987-02-01
870045
The two procedures, DAMAGE and OBLIQUE IMPACT, which are used by EDCRASH for computing delta-V, are described in detail. Enhancements in EDCRASH Version 4 which improve the DAMAGE method of computing delta-V are also described. The advantages and disadvantages of each method are explored, and the numerical and graphical output and use of warning messages are reviewed. In general, it was found the two methods are complimentary: The DAMAGE procedure is best-suited for the conditions in which the OBLIQUE IMPACT procedure is least-suited, and vice-versa.
Technical Paper

An Overview of the Way EDSMAC Computes Delta-V

1988-02-01
880069
The EDSMAC personal computer program for use by accident investigators is described. The input data requirements are reviewed. The general calculation procedures are discussed and the specific procedures for computing delta-V are explained in detail. The method, based on equalizing the force between the vehicles at all times during the impact phase, is seen to be simple in concept but extremely complex in practice. The numerical and graphical output and warning messages are reviewed. Applications of the program are illustrated. The major benefit of EDSMAC is the ability, using graphics, to provide an analytical method illustrating how an accident may, or may not, have occurred.
Technical Paper

An Overview of the HVE Developer's Toolkit

1994-03-01
940923
A substantial programming effort is required to develop a human or vehicle dynamics simulator. More than half of this effort is spent designing and programming the user interface (the means by which the user supplies program input and views program output). This paper describes a pre-programmed, 3-dimensional (3-D), input/output window-type interface which may be used by developers of human and vehicle dynamics programs. By using this interface, the task of input/output programming is reduced by approximately 50 percent, while simultaneously providing a more robust interface. This paper provides a conceptual overview of the interface, as well as specific details for writing human and vehicle dynamics programs which are compatible with the interface. Structures are provided for the human, vehicle and environment models. Structures are also provided for events, interface variables, and the output data stream.
Technical Paper

An Overview of the HVE Human Model

1995-02-01
950659
Developers of human dynamics simulation software inherently use a mathematical/physical model to represent the human. This paper describes a pre-programmed, object-oriented human model for use in human dynamics simulations. This human model is included as part of an integrated simulation environment, called HVE (Human-Vehicle-Environment), described in previous research. The current paper first provides a general overview of the HVE user and development environments, and then provides detailed specifications for the HVE Human Model. These specifications include definitions for model parameters (supported human types and human properties, such as dimensions, inertias, joints and injury tolerances). The paper also provides detailed specifications for the HVE time-dependent human output group parameters (kinematics, joints, contacts, belts and airbags).
Technical Paper

An Overview of the HVE Vehicle Model

1995-02-01
950308
Developers of vehicle dynamics simulation software inherently use a mathematical/physical model to represent the vehicle. This paper describes a pre-programmed, object-oriented vehicle model for use in vehicle dynamics simulations. This vehicle model is included as part of an integrated simulation environment, called HVE (Human-Vehicle-Environment), described in previous research [1,2] *. The current paper first provides a general overview of the HVE user and development environments, and then provides detailed specifications for the HVE Vehicle Model. These specifications include definitions for model parameters (supported vehicle types; vehicle properties, such as dimensions, inertias, suspensions; tire properties, such as dimensions and inertias, mu vs slip, cornering and camber stiffnesses; driver control systems, such as engine, transmission/differential, brakes and steering; restraint systems, such as belts and airbags).
Technical Paper

The Simulation of Driver Inputs Using a Vehicle Driver Model

2000-03-06
2000-01-1313
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.
X