1 / 43

SECTION 8 DRIVING MACHINE

SECTION 8 DRIVING MACHINE. Driving Machine. The Driving Machine drives your virtual vehicle according to your instructions much like a test driver would drive an actual vehicle. Driving Machine. What’s in this module: Standard Driver Interface (SDI) and Driving Machine Why Use SDI?

suchi
Download Presentation

SECTION 8 DRIVING MACHINE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SECTION 8 DRIVING MACHINE

  2. Driving Machine • The Driving Machine drives your virtual vehicle according to your instructions much like a test driver would drive an actual vehicle.

  3. Driving Machine • What’s in this module: • Standard Driver Interface (SDI) and Driving Machine • Why Use SDI? • Data Flow • Using the Driving Machine • Limitations • Creating Inputs for SDI • Driver Control Files • Example Event .xml File

  4. Driving Machine • Creating Event and .dcd Files • Structure of Event Files • Specifying End Conditions • Extensible End and Abort Conditions • Specifying Attributes • Driver Control Data Files • Driver Control Data File Architecture • Creating .dcd Files

  5. Standard Driver Interface (SDI) and Driving Machine • Standard Driver Interface (SDI) is an architecture used by Adams/Car to perform driving analyses using inputs to drive your virtual vehicle. The manifestation of this architecture is a feature in Adams/Car named Driving Machine. This interface controls five different channels: steering, throttle, clutch, gear, and brake. This enables you to easily recreate any physical test procedure or replay actual driving events from measured data. • Driving Machine provides a seamless interface to three vehicle controllers: • Open-loop control - The open-loop controller can use either constant values or function expressions to drive the vehicle. No feedback is passed back to the controller. • Machine control - The machine controller is a closed-loop controller that controls the vehicle by using the vehicle states. • Human control - The human controller is, like the machine controller, a closed-loop controller, but it also has learning capabilities.

  6. Standard Driver Interface (SDI) and Driving Machine (Cont.) • To help you calculate the control signals, the Driving Machine passes vehicle states such as position, velocity, and acceleration to your driver controller. It also provides a means for defining and passing sets of command signals, feedback signals, and parameters for each of the five control signals. • An XML file scripts full-vehicle simulations instead of a TeimOrbit format driver control file (DCF) used by the earlier IPG Driver lite code. • If you have DCF files from previous versions, Adams/Car reads the files and creates a corresponding XML Event file which is used by the driving Machine.

  7. Why use SDI? • What you can do with the Driving Machine • Using the Driving Machine, you can: • Input the vehicle path {x, y} and speed, and use closed-loop, machine control to steer a vehicle along a path or follow a desired velocity or both. • Input a variety of open-loop functions, such as swept-sine and impulse, to the steering, throttle, or brake. • Input recorded steering, throttle, brake, gear, and clutch signal to your model. • Stop a simulation, switch controllers, and change output step size based on reaching a target lateral acceleration, longitudinal velocity, or distance traveled.

  8. Why use SDI? (Cont.) • How you benefit from using the Driving Machine • When working with the Driving Machine, you have the following benefits: • You save the time you previously needed to set proper gains for closed-loop controllers. • You shorten simulation times by ending simulations based on targets for lateral acceleration, longitudinal velocity, and distance traveled. • You gain flexibility in how you input vehicle paths and desired velocity profiles, choosing from recorded data stored in external files or parametrically generated paths and profiles based on a few simple inputs.

  9. Data Flow • About data flow in the Driving Machine • When you submit a simulation using the Driving Machine, Adams/Car generates an Adams/Solver dataset file (.adm), an Adams/Solver command file (.acf), and an Event File (.XML). The .adm file references the event file, and the .acf file invokes a CONSUB included in the Adams/Car Solver that reads and processes the .xml file to perform the maneuver described in the file. Adams/Car Solver then provides the standard output files: .msg, .req, .res, .gra, and .out. • The event file describes the maneuver you want to perform as a list of mini-maneuvers. The event file can reference one or more driver control data files (.dcd). Driver control data files contain either vehicle path and speed for use by the machine (closed-loop) controller or steering, throttle, brake, gear, and/or clutch signals for use as open-loop inputs to the vehicle. • The illustration on the next slide summarizes the data flow specific to the Driving Machine.

  10. Adams/Car Solver Data Flow (Cont.) • The following illustration shows the Driving Machine data flow: Adams/Car Interface Adams dataset file (.adm) Adams command file (.acf) Driver control data file (.dcd) Event file (.xml) .msg .req .res Output files .gra .out

  11. Using the Driving Machine • Steps in using the Driving Machine • Using the Driving Machine involves the following steps: • Assemble a full-vehicle model with the .__MDI_SDI_TESTRIG test rig or open an existing full-vehicle assembly. • Do either of the following: • Use a predefined analysis. • Create your own .xml files to perform your specific set of simulations. • The next figure shows how the Driving Machine works in a virtual prototyping model.

  12. Using the Driving Machine (Cont.)

  13. Limitations • The Driving Machine has some limitations, as follows: • It can accurately steer a vehicle only when positive steer inputs steer the vehicle to the left. • It cannot control low velocities.

  14. Creating Inputs for SDI • Two file types are used as input for SDI-based events: Event files (.xml) and driver control data files (.dcd) files. • Event file (.xml) - Controls the event and contains a list of mini-maneuvers that allows you to script the simulation. • Driver control data file (.dcd) - Contains input data used in the driver control file. This file is necessary when it is referenced in the .xml file.

  15. Event Files • Event files (.xml) describe how you want the Driving Machine to drive your vehicle during an experiment or analysis. The event file instructs the Driving Machine how fast to drive the vehicle, where to drive the vehicle (for example, on a 80m radius skidpad), and when to stop an experiment (lateral acceleration = 8m/s2). Event files specify what kinds of controllers the Driving Machine should use for which input signals, such as steering, throttle, and so on. An event file can reference other files, primarily driver control data files (.dcd), to obtain necessary input data, such as speed versus time. For information on referencing .dcd files, see the Working with Driver Control Data Files section in the Adams/Car online help. • Event files organize complex experiments into a set of smaller, simpler steps called mini-maneuvers. An event file primarily contains a static-setup method and a list of mini-maneuvers. Each mini-maneuver details on how the Driving Machine is to control the steering, throttle, brake, gear, and clutch.

  16. Event Files (Cont.) • The Event file is an xml file which you can modify in the Event builder in the Adams/Car standard interface (Full Vehicle Analysis – Event Builder). You can specify the attributes for the event you want the Driving machine to carry out on your full vehicle assembly. It also allows you to reference external data in a .dcd file to drive the vehicle, such as steering wheel displacement, vehicle acceleration, or other inputs. The event file requires following information: • Experiment - Specifies some initial conditions for the simulation, static setup options, and a list of mini-maneuvers that makes up the complete experiment or event. • Mini-maneuver(s) - Specifies how the vehicle steering, throttle, brake, gear, and clutch are controlled for each maneuver, which are basically instructions for the vehicle.

  17. Example Event Files

  18. Example Event Files (Cont.)

  19. Creating Event Files • The easiest way to create an event is to run a standard event from the Full Vehicle Analysis menu in GUI and make the necessary changes to the resulting event file. The following describes changes to the blocks: • Units - The units should be those of the data in your .xml file, which can be different from you assembly units. Settings - Unit • Experiment block -

  20. Structure of Event Files • EXPERIMENT - Specifies the static setup, initial speed, initial gear, and a list of mini-maneuvers for the experiment. The Driving Machine executes each mini-maneuver in the order listed, until the list is complete or a mini-maneuver is terminated. In the EXPERIMENT section, you must supply parameters for INITIAL_SPEED, and optionally INITIAL_GEAR (default is 3) and INITIAL_CLUTCH (default is 0, engaged). Optionally, you can specify static-setup analyses that remove start-up transients, which can eliminate mini-maneuvers that you might normally use when setting up a vehicle for cornering maneuvers. You may choose any of the values below for STATIC_SETUP. If you omit the STATIC_SETUP parameter from your driver control file, Adams/Car uses a default value of NORMAL. • NORMAL • NONE • SETTLE • STRAIGHT • SKID_PAD For information see in the Adams/Car online help or press the F1 key

  21. Structure of Event Files (Cont.) The EXPERIMENT section is followed by a MINI_MANEUVER section. For each mini-maneuver, the MINI_MANEUVER section must specify a name for the mini-maneuver, the abort time, and the output step size. Optionally, you can define the condition for ending the mini-maneuver, and the maximum integration step size, HMAX (which must be smaller than the output step size). If the abort time is reached before the end condition is satisfied, the Driving Machine terminates the whole experiment, not just the mini-maneuver. You can also specify an end-condition subblock which will apply to all mini-maneuvers in the experiment. • The following shows an example:

  22. Structure of Event Files (Cont.) • Mini-maneuver section(s) – An event file can contain an unlimited number of mini-maneuver sections. Each mini-maneuver section contains sections titled (STEERING), (THROTTLE), (BRAKE), (GEAR) and (CLUTCH). Depending on the control methods you specify, you may have to choose a (MACHINE_CONTROL) or (HUMAN_CONTROL) block. A mini-maneuver may also include an (END_CONDITIONS) data, where a condition may be specified which will trigger the passing of control to the next mini-maneuver. In general, such a block is required for all but the final mini-maneuver, to ensure that all mini-maneuvers are executed before the abort time is reached. • The following shows an example mini-maneuver section, for a mini-maneuver named BRAKE_TURN:

  23. Structure of Event Files (Cont.)

  24. Specifying End Conditions • You can specify end conditions for each mini-maneuver in a sub-block. The END_CONDITIONS sub-block looks like this: where measure is the quantity that is monitored, such as: • VELOCITY - Vehicle longitudinal velocity • LAT_VELOCITY (VY) - Lateral velocity • VERT_VELOCITY (VZ) - Vertical velocity • LON_ACCEL - Vehicle longitudinal acceleration • LAT_ACCEL - Vehicle lateral acceleration • VERT_ACCEL (ACCZ) - Vertical acceleration

  25. Specifying End Conditions (Cont.) • DISTANCE - Total distance travelled by the vehicle during a mini-maneuver • TIME - Simulation time • YAW_ANGLE - Angular displacement about the vehicle’s vertical axis • YAW_RATE - Angular velocity about the vehicle’s vertical axis • YAW_ACCEL - Angular acceleration about the vehicle’s vertical axis • PITCH_ANGLE - Angular displacement about the vehicle’s lateral axis • ROLL_ANGLE - Angular displacement about the vehicle’s longitudinal axis • SIDE_SLIP_ANGLE - Angular offset between the projected vehicle’s longitudinal axis and the vehicle’s velocity vector • LON_DIS (DX) - Longitudinal displacement • LAT_DIS (DY) - Lateral displacement

  26. Specifying End Conditions (Cont.) • VERT_DIS (DZ) - Vertical displacement • ROLL_RATE (WX) - Roll rate • PITCH_RATE (WY) - Pitch rate • ENGINE_SPEED - Angular velocity of the engine crankshaft in number of revolutions per minute (rpm) • RACK_TRAVEL - Displacement in the steering rack joint • STEERING_ANG - Angular displacement in the steering wheel joint • The current choices for measure are: • test - Can be: • ‘==’ equal to (+/- 0.2%. For example, if the end condition for a mini-maneuver is VELOCITY and the value is 10 m/s, the Driving Machine terminates the mini-maneuver when the measured vehicle longitudinal velocity is greater than 9.98 m/s and less than 10.02 m/s.) • ‘>>’ greater than • ‘<<‘ less than

  27. Specifying End Conditions (Cont.) • value - The value against which the measure is tested to determine if the end condition is satisfied. Except for ENGINE_SPEED, you must specify the value in modeling units as defined in the UNITS block of the driver control file. • allowed_error - The allowed difference between the measure and value that still satisfies the test. allowed_error must be positive and be specified in modeling units as defined in the UNITS block of the driver control file (except ENGINE_SPEED). For example, LAT_ACCEL ‘==’ 5 0.1 0.0 0.0 Then the end condition is satisfied if: 5 - 0.1 < Lateral acceleration < 5 + 0.1 Or if the end condition is: LAT_ACCEL ‘>>’ 5 0.1 0.0 0.0 The end condition is satisfied when lateral acceleration > 5 - 0.1. Or if the end condition is: LAT_ACCEL ‘<<‘ 5 0.1 0.0 0.0 • The end condition is satisfied when lateral acceleration < 5 + 0.1.

  28. Specifying End Conditions (Cont.) • filter_time - The test must be satisfied continuously over the filter time to satisfy the end condition. filter_time must be positive. • delay_time - Once the end condition is satisfied, delay the end of the mini-maneuver by delay_time. • group - You specify a name to group end conditions together. All end conditions having the same group must be satisfied simultaneously to end a mini-maneuver. For example you might specify two end conditions: • Longitudinal velocity equal to 20 m/s • Lateral acceleration greater than 5 m/s/s Then you place the specified end conditions in the group ‘mygroup’. To end the mini-maneuver, the longitudinal velocity must be 20 m/s and the lateral acceleration must be greater than 5 m/s/s. For example: VELOCITY ‘==’ 20 0.1 0.0 0.0 ‘mygroup’ LAT_ACCEL ‘>>’ 0 0.1 0.0 0.0 ‘mygroup’

  29. Specifying End Conditions (Cont.) To define the different sub-blocks, you must specify their attributes. The following table lists the attributes you must specify for each sub-block: * Only required for the open-loop control method. • You specify attributes as described in Specifying Attributes, on slide 37.

  30. Extensible End and Abort Conditions • A condition sensor is a user-defined element that consists of a data element array and strings. It references an existing variable class element (data element variable or measure solver computed), which is then tied to the label and unit strings by the array. The array also encapsulates a request (for plotting convenience) and a units conversion factor. • In essence, a condition sensor represents a relationship between a measurable solver quantity (the variable class object) and a string label identifier that can be used in an event file (.dcf) to define an end condition for Adams/Car full-vehicle analyses. • Use of Condition Sensors in Adams/Car • Before each vehicle analysis, Adams/Car browses the assembly for condition sensor elements and updates the data element end_conditions_array with the derived list. At the beginning of the simulation, the Standard Driver Interface (SDI) uses the specified end condition measure string in the event to identify the associated variable class object in the dataset, which calculates the quantity the end condition sensor should compare to the target value.

  31. Specifying Attributes • Specifying an actuator type • When defining a STEERING sub-block, you must specify its actuator type. You use the actuator type to specify whether the Driving Machine steers the vehicle at the steering wheel or steering rack and whether the Driving Machine uses a force or motion, as described next. Actuators include rotation (wheel), translation (rack), force (rack), and torque (wheel). • Specifying a control method • When defining any sub-block, you must specify the control method that you want to use. You can choose from three control methods, as follows: • OPEN_CONTROL, on slide 33 • MACHINE_CONTROL, on slide 33-34 • HUMAN_CONTROL, on slide 35

  32. Specifying Attributes (Cont.) • OPEN_CONTROL • When you specify METHOD = 'OPEN' for steering or any other signal, the Driving Machine output for that signal is a function of time, and you must specify the function using the options in the CONTROL_TYPE argument. • Arguments: CONTROL_TYPE = ‘CONSTANT’ || ‘STEP’ || ‘RAMP’ || ‘IMPULSE’ || ‘SINE’ || ‘SWEPT_SINE’ || ‘DATA_DRIVEN’|| ‘FUNCTION’ • MACHINE_CONTROL • The MACHINE_CONTROL option in the event file specifies the vehicle path, speed profile, and other parameters used by machine control for the mini-maneuver block in which it resides.

  33. Specifying Attributes (Cont.) • We recommend that if you use machine control for throttle, you also use machine control for braking. Also, if you use machine control for gear, you should use machine control for clutch. When you select MACHINE_CONTROL for gear and clutch, you must also supply the maximum and minimum engine speed. Machine control will up-shift to keep the engine speed less than the maximum, and down-shift to keep the engine speed greater than the minimum. • If SPEED_CONTROL = LAT_ACCEL, then you must set STEERING_CONTROL to SKIDPAD. • Arguments: • STEERING_CONTROL = ‘FILE’ || ‘STRAIGHT’ || ‘SKIDPAD’ • SPEED_CONTROL = ‘FILE’ || ‘LAT_ACCEL’ || ‘MAINTAIN’ || ‘VEL_POLYNOMIAL’ ||‘LON_ACCEL’

  34. Specifying Attributes (Cont.) • HUMAN_CONTROL • The HUMAN_CONTROL sub-block in the .dcf file specifies the input files and parameters for Adams/SmartDriver. Adams/SmartDriver approximates the behavior of a human driver and is capable of learning and adapting to the characteristics of different vehicles. Before using Adams/SmartDriver, to gain an overview of how Adams/SmartDriver functions, we recommend that you read The Concept of Adams/SmartDriver in the Adams/SmartDriver online help. • You must have a separate Adams/SmartDriver license to run HUMAN_CONTROL.

  35. Specifying Attributes (Cont.) • Specifying a mode • When defining any sub-block and you are using METHOD='OPEN', you must define MODE to be relative or absolute. With all open-loop maneuvers, the value of the preceding mini-maneuver is used as the starting point for the next mini-maneuver. This is irrespective of whether you choose relative or absolute. For example, your vehicle is driving on a skid pad at 30 mph, with 20o of steering wheel, when the first mini-maneuver is finished. The steering wheel angle for the next mini-maneuver will be 20o. • The relative and absolute methods allow you to define what the steering wheel angle will be at the end of the next mini-maneuver.

  36. Driver Control Data Files • Driver control data files contain data for use by the Driving Machine. To instruct the Driving Machine to use the data from a .dcd file, you must reference the file in a event file (.xml). An excerpt from a .dcf file showing a reference to a .dcd file looks like the following:

  37. Driver Control Data Files (Cont.) • Driver control data files hold two types of data, as follows: • Open-loop data - Data that is played back as input to the vehicle without concern for how fast or where the vehicle goes. Such data includes: steering wheel angle, throttle, brake, gear, and clutch signals. Examples of open-loop data include steering wheel angle versus time, and throttle position versus time. • Closed-loop data - Data that specifies exactly where and how fast the vehicle should go. An example of closed-loop data is vehicle x and y position versus time. You may specify closed-loop data in several forms. For example, curvature and velocity versus distance travelled, or lateral acceleration and longitudinal acceleration versus time. You specify the type of data using the SPEED_CONTROL and STEERING_CONTROL attributes in the .dcd file.

  38. Driver Control Data File Architecture • Driver control data (.dcd) files use a TeimOrbit format similar to other Adams/Car property files. Driver control data (.dcd) files must contain these data blocks: • MDI_HEADER block - Identifies the file as a .dcd (not a .dcf) file and provides version information. • UNITS block - Identifies the units of the data contained in the .dcd file. • The driver control data (.dcd) file must also contain at least one of two data blocks: • OPEN-LOOP block - Specifies the steering, throttle, brake, gear, and clutch inputs to the vehicle. • CLOSED-LOOP block - Specifies the path or the speed of the vehicle, or both.

  39. Driver Control Data File Architecture (Cont.) • Driver control data files may contain both OPEN-LOOP and CLOSED-LOOP blocks. • The following table summarizes the closed-loop data that a .dcd file may contain. The columns represent speed-control options from the driver parameters array. The rows represent the steering control options from the driver parameters array. The intersections give the data contained in the .dcd file and, therefore, the data input to the funnel to produce {x, y, lon_vel} as needed by Driving Machine.

  40. Driver Control Data File Architecture (Cont.)

  41. Creating .dcd Files • You can use the sample .dcd files that MSC.Software provides or you can create your own .dcd files. • To create .dcd files: • Use one of three methods to create .dcd files: • Run a physical or virtual test and record the data that you obtain from the five actuator application areas. • In a text editor, modify the sample .dcd files that we provide for you. • Create a .dcd file using a text editor and following the specifications and format shown in the Analyze tab in the Adams/Car online help. • Save the file and reference it through a the event file (.xml).

More Related