Driver Controls
Open-Loop Controls (3)
Configurable Functions (3)
Summary of Open-Loop Control Keywords (6)
Reference Paths (7)
Reference Path Geometry: Station S and Lateral coordinate L (7)
Applications of Reference Paths in VS Models (8)
Control: Target Path for Driver and Traffic (9)
Initial Vehicle Conditions (12)
Changing Paths Using Events (14)
Closed-Loop Speed Control (15)
Predefined Speed vs. Time or Station (15)
Speed Control Using Path Preview (18)
Interactions with Open-Loop Brake and Throttle Commands (24)
Steering by the Closed-loop Driver Model (25)
The Closed-loop Driver Model Steering Controller (25)
User Settings (26)
Using the Closed-loop Driver Model with External Steering Models (28)
Closed-Loop Shifting (29)
Control: Clutch Shifting Parameters (Closed Loop) (30)
Control: Clutch Shifting Timelines (Closed Loop) (31)
CarSim and TruckSim include all of the controls normally provided by a driver: steering, braking, throttle, gear shifting, and clutch control. Each control has options for either open-loop or closed-loop operation.
In general, VehicleSim (VS) models are intended to provide realistic simulation of the physical vehicle as it responds to driver controls. The models are not intended to provide a full representation of a human driver with psychology, strategy, route planning, etc. However, the closed-loop controllers are routinely used to mimic typical driver behaviors within the context of following a given path at either a given speed or a speed determined with basic rules, with appropriate steering, throttle, braking, shifting, and possibly clutch control.
The choices of control methods are made at runtime. Usually this is done in the VS browser by linking to the appropriate library screen when setting up a test procedure. Table 1 lists the library screens used for controls. These are all listed in the Control submenu of the Libraries menu. Control modes that are associated with the choice of linked dataset are also listed in the table under Related Control Mode(s).
For example, linking to a dataset from the Control: Steering (Open Loop) library automatically sets up the VS solver to operate with open-loop steering control (OPT_DRIVER_MOD EL = 0) with steering wheel angle rather than torque (OPT_STEER = 0). On the other hand, linking to a dataset from the Control: Steering by the Closed-loop Driver Model sets up the solver to operate with
a closed-loop controller that will follow a path with global X-Y coordinates (OPT_DRIVER_MODE L =
3).
Table 1. Summary of control libraries and modes. Linked Library Screen Related Control Mode(s) Notes
Control: Braking (Open Loop) Control: Braking Pedal Force (Open Loop)* Open-loop control of brake pressure or pedal force; may interact with other controls.
Control: Clutch (Open Loop) OPT_CLUTC H_MODE = 0 Explicit open-loop clutch.
Control: Clutch Shifting Parameters
(Closed Loop) Control: Clutch Shifting Timelines
(Closed Loop) OPT_CLUTC H_MODE = 1 Automatic clutch control
when a gearshift occurs.
Control: Shifting (Open Loop) MODE_TRAN S_CONS TANT = 1 Explicit open-loop shifting. Control: Shifting (Closed Loop) Defines shifting mode.
Control: Speed (Closed Loop) Using Path Preview OPT_SC = 4Speed control vs. path
location using preview.
Control: Speed (Closed Loop) vs.
Station OPT_SC = 3Speed control vs. path
location (station).
Control: Speed (Closed Loop) vs. Time OPT_SC = 2Speed control vs. time.
Control: Steering by the Closed-loop Driver Model OPT_DRIVE R_MODE L = 1 or 2Closed-loop path follower.
Can generate image of
target path for animation.
Control: Steering Preview Time for the Driver Model Preview time for driver model as function of speed.
Control: Steering (Open Loop) OPT_DRIVE R_MODE L = 0
OPT_STEER = 0 Open-loop steer using steering wheel angle.
Control: Steering Torque (Open Loop)* OPT_DRIVE R_MODE L = 0
OPT_STEER = 1 Open-loop steer using steering wheel torque.
Control: Target Path for Driver and
Traffic OPT_DRIVE R_MODE L = 3Specify target path that is
independent of road data.
Control: Throttle (Open Loop) Open-loop throttle; may
interact with other controls.
* Option not supported in TruckSim
Note that parsfiles for open-loop braking and throttle controls do not set control modes; the open-loop throttle and braking are allowed to interact with closed-loop controls as needed to simulate some intervention systems.
The datasets in some of the libraries listed in Table 1 also set other control modes based on user controls that are described in following sections.
In addition to the controls listed in Table 1, several powertrain control variables are available. These include twin-clutch controls and shifting conditions for closed-loop transmission (upshift and downshift schedules). Although the shifting control logic can be used to represent driver behavior, it is also used to represent shifting in a closed-loop transmission, and is described in the documentation for the powertrain. The library screens for simulating closed-loop transmission shifting are in the Powertrain submenu of the Libraries menu.
When a run begins, the vehicle position variables (X, Y, and yaw) may be set based on information about a reference path. (See the section Initial Vehicle Conditions on page 12.) Open-Loop Controls
Each open-loop control screen specifies a driver control as a function of time.
Controls that are defined in VS software as “open-loop” are not influenced by any controllers built into the VS solvers. However, these control variables can be replaced with values from closed-loop controllers from external software such as Simulink, or with VS commands that are processed at runtime (see page 7 for details).
The open-loop throttle and braking controls remain active when the built-in speed controller is used, in support of simulation of advanced safety systems that intervene with driver controls. Therefore, if you create a procedure that switches from open-loop to closed-loop mode during the run (using VS commands), you might need to set the open-loop controls to zero to prevent unwanted interactions.
Configurable Functions
Each open-loop control is represented in the VS solvers with a function that can be configured at runtime to use one of many calculation methods. For example, Figure 1 shows the library screen for open-loop steering wheel this case, the function type is set to Linear
is based on a table of values of steering wheel
the screen.
Documentation for Configurable Functions
There are many options for configuring these functions. Three reference manuals cover different aspects:
1.VehicleSim Browser Reference Manual describes the user interface for configuring the
functions with screens such as the one shown in Figure 1;
2.VehicleSim Solvers Manual lists all of the built-in calculation methods and the associated
keywords; and
3.VS Commands Manual goes into more detail about extending the model with the
_EQUATION option (to provide an equation for the function at runtime) and other methods for extending the model to use alternate equations.
The keywords for the options and parameters associated with a specific configurable function can be found in the echo files generated for each simulation run. The text in the lower part of the
keywords based on the root name
Figure 1. Open-loop steering control screen.
Listing 1 shows excerpts from an echo file written at the end of a simulation run in which the STEER_SW waveform from Figure 1 was used and rescaled during the run. The comment lines at the top of the listing describe the options that are supported for this specific configurable function (constant, linear coefficient, nonlinear function of time, custom equation, etc.). The options are not the same for all configurable functions, so the echo file always lists those that can be used for each specific function.
After the documentation, the lists the data associated with the function. The type of
function selected on the screen
(Figure 1) is defined in the parsfile with keywords Array
STEER_SW_TABLE and LINEAR_FLAT (Listing 1), followed by a table of numbers that match
After the keyword END_TABLE, four parameters (two scale factors and two offsets) are listed
that can transform the shape of the function as described below.
Listing 1. Excerpts from an echo file with data for open-loop steering vs. time.
! STEER_S W: Ste ering wheel angle as a f unctio n of time. St eering wheel angle can
! be a co nstant, a li near c oeffic ient m ultipl ied by time, or com puted as a
! nonline ar fun ction of tim e. Alt ernati vely, a cu stom equa tion c an be define d at
! runtime. Stee ring w heel a ngle f rom th e calc ulat ion can b e adju sted w ith a gain
! and off set. T ime us ed in the ca lculat ion ca n be adjusted with a gain and
! offset.
! 1D tabl e: col 1 = t ime (s), col 2 = s teerin g wh eel angle (deg)
STEER_SW_TABLE LINEAR_FLAT ! line ar int erpola tion, flat-li ne ext rapola tion
0, 0
0.01428571429, 0.06279051953
0.028********, 0.1253332336
…
( Edited for L ength )
…
1.914285714, -0.06279051953
1.928571429, 0
ENDTABLE
STEER_SW_GAIN 122.401125 ! Gain (-): mu ltipli ed w ith calcu lated value to get
! stee ring w heel a ngle
STEER_SW_OFFSET 0 ! Off set (d eg): a dded t o ca lculated value (after gain) to
! g et ste ering wheel angl e
TSTART_ST EER 48.496 ! Off set (s): sub tracte d fr om time b efore calcul ation
TSCALE_ST EER 1 ! Ref erence scale (-): divi ded into (time - TSTA RT_STE ER)
! b efore calcul ation
Scaling Reference Waveforms
A built-in (native) open-loop control is calculated with a configurable function:
native_control = f(X)? gain + offset
native_control = f([t – tstart]/tscale) ? gain + offset(1) where
1.f is a function (e.g., STEER_SW) that uses a method you define on the screen (e.g., linear
interpolation is specified in Figure 1 and Listing 1);
2.X is the independent variable shown on the screen and used to calculate f; X is in turn
defined as a function of time and two parameters: X = [t – tstart]/tscale, where t is the simulation time, tstart is a parameter to offset the timeline of the control (e.g., TSTART_STEER), and tscale is a parameter to scale the timeline of the control (e.g., TSCALE_STEER);
3.gain is a dimensionless multiplier applied to the function (e.g., STEER_SW_GAIN); and
4.offset is an offset applied to the function (e.g., STEER_SW_OFFSET).
Notice that the table of numbers in the data screen shows the waveform starting at a time of zero, with a range of steering wheel angle limited to ±1°. The amplitude of the waveform shown in the figure is increased using the keyword STEER_SW_GAIN. Thus, the amplitude of the sine with dwell applied at the time the echo file was written was not 1° as shown in the figure, but 122.4°
(Listing 1). The waveform is delayed, to start at T=48.496 sec using the keyword TSTART_STEER. Thus, the waveform did not start at T=0 as shown in the figure, but at 48.496.
The other two parameters (TSCALE_STEER and STEER_SW_OFFSET) were not set in this run, and keep the default values of 1 (TSCALE_STEER) and 0 (STEER_SW_OFFSET).
When a reference waveform is rescaled, the values of parameters are usually set on a different screen than the one that has the waveform. Typically, the scaling parameters are from the Procedures screen, the Events screen, or for quick changes, the Run screen. As always, if the same parameter is specified in different datasets, the last value read by the VS solver overwrites the previous value.
Replacing Open-Loop Variables with Outputs from Custom Controllers
Controls that are defined in this document as “open-loop” are not influenced by any controllers built into the VS solvers. However, the controls can be set with closed-loop controllers defined with external software such as Simulink, or with VS commands that are processed at runtime. The VS Commands Manual describes several methods for extending configurable functions that apply to the open-loop controls used in the math models:
1.Events can be defined in which some of the parameters are redefined when a condition is
reached in the simulation.
2.Equations can be defined to calculate existing parameters or variables every time step.
3. A configurable function can be set to use an equation that defines f in terms of any of the
thousands of variables that exist in the vehicle model that have associated keywords.
In addition to the built-in options, external software such as Simulink and LabVIEW can be used to define variables that are imported into the VS solver where they are applied in the math model. Imported variables can be combined with values computed internally using four potential methods:
1.The imported variable can replace the internal value.
2.The imported variable can be added to the internal value.
3.The imported variable can be multiplied with the internal value.
4.The imported variable can be ignored.
See the VehicleSim Solvers Manual and VS Commands Manual for more information about import variables.
Summary of Open-Loop Control Keywords
All of the library screens for open-loop control are similar in layout to the one shown in Figure 1 (page 4). Table 2 summarizes the distinguishing features, as defined by the keywords used to specify the controls. The root keyword in the table is used for the table function (f in the above equations) and the import variable identifies import. Each function also has four parameters for transforming the calculated value (e.g., STEER_SW) or time, as described earlier.
Table 2. Summary of open-loop control keywords. Control Library Screen Name
Root Keyword Import Variable Control: Braking (Open Loop)
PBK_CON IMP_PBK_C ON Control: Braking Pedal Force (Open Loop)* F_BRAKE_P EDAL IMP_FBK_P DL Control: Clutch (Open Loop) CLUTCH_CO NTROL IMP_CLUTC H Control: Shifting (Open Loop)
GEAR_TRAN S IMP_GEAR_TRANS Control: Steering (Open Loop)
STEER_SW IMP_STEER _SW Control: Steering Torque (Open Loop)*
M_STR_IN IMP_STEER _T_IN Control: Throttle (Open Loop)
THROTTLE_ENGINE IMP_THROT TLE_EN GINE
*Screen is not in TruckSim Reference Paths
Road designs typically rely on station number (longitudinal distance along the design centerline) as the primary variable for locating features along the road. For the case of a curving road with elevation change, the curved path is projected onto a flat and level plane (that is, Z coordinates are ignored), and station is the length along that projected path.
VS vehicle models apply this convention to define reference paths for defining road features and for defining a target path for closed-loop controllers in the simulated vehicle. A reference path can also be used to define motions of other objects in the simulation, such as traffic vehicles. Reference Path Geometry: Station S and Lateral coordinate L
A reference path is defined in the VS solver with a table of X-Y coordinates. The classic definition of station is the distance along the curved path that goes through the points (Figure 2).
Figure 2. Horizontal geometry of a curved reference line.
In VS models, station S is calculated using straight-line segments; the length of each line segment is added to the previous value of S when going from point to point in a direction of increasing station:
S i = S i–1 + 2i X -i -1X ()+2i Y -i -1Y () { i > 1 } (2)
This definition of station is deliberately simple — straight lines connect points as viewed from a satellite in space. Effects of elevation change and curvature are not included, meaning that S from this definition is slightly less than the distance alone the curved path (the curved black line in the figure). This simplified definition of S is used to provide a connection between multiple properties of the road surface (elevation, banking, friction, etc.). Station is also used to control inputs such as target speed and lateral position.
The station for the first point is provided as a parameter; SPATH is the starting station for the road reference line and SPATH_DRIVER is the starting station for an alternate reference path.
Although the calculation of station is based on straight-line segments, the reference path between the points is indeed curved, as indicated by the black line in Figure 2. At station values between the original data points, there can be an offset between the straight connecting line and the curved path. Internally, the VS solver programs generate tables of X vs. S and Y vs. S and use spline interpolation to calculate X and Y as continuous functions of S for points on the curved reference line. The spline functions also provide ?X/?S and ?Y/?S as functions of S.
The second path coordinate is L, the lateral distance from a point perpendicular to the road reference line (see the red circle in Figure 2). As is the case with station, L is defined in a horizontal plane, as if viewed from space by a satellite.
Applications of Reference Paths in VS Models
The S and L coordinates of a reference path are used in VS vehicle models for several purposes:
1. A road reference line can be used to define 3D ground geometry where elevation Z and
friction μ are defined in terms of S and L coordinates. The road reference line is used whenever a link is made to a dataset from the Road: 3D Surface library.
Note The documentation for the road model (VehicleSim 3D Ground and Roads) provides a thorough description of how the reference line is
combined with other properties of the road surface.
2.The initial vehicle location (X and Y coordinates) and heading (yaw angle) can be
specified using S and L coordinates relative to a reference path.
3. A reference path can be used with closed-loop driver controllers to specify target speed
and target location of the vehicle as functions of S.
4.VS commands can be used to position and control moving objects (e.g., traffic vehicles)
using S and L coordinates based on a reference path.
Screens For Defining Reference Paths
The reference path used for items 2-4 above can be either the road reference line or a separate driver reference path. Using a dataset from one of these libraries enables the road reference line: ·Road: 3D Surface
·Road: Segment Builder
·Road: X-Y Coordinates of Centerline
·Road: X-Y-Z Coordinates of Centerline
·Road: X-Y-Z Coordinates of Edges.
These libraries can be found from the Libraries menu of the VS browser in the category 3D Ground and Roads. The road reference line dataset would normally be linked to a dataset from the Road: 3D Surface screen. These screens are described in the document VehicleSim 3D Ground and Roads (listed in the Help menu as 3D Ground and Roads).
Linking to a dataset from the Control: Target Path for Driver and Traffic library (described in the next subsection) enables an alternate driver reference path.
Standard Station Variables for Reference Paths
The VS solvers have standard variables related to reference paths:
·The current position of the vehicle sprung-mass coordinate system origin on the reference path used by the closed-loop controllers is available as an output variable
Station and as a state variable SV_STATION.
·The current station in the road reference line is available as the output variable Sta_Road and state variable SV_STA_ROAD. The two station variables will have
the same value when the controllers use the road reference line, but will differ if the
controller uses the alternate reference path.
The variables Station and Sta_Road are available for plotting; the state variables SV_STATION and SV_STA_ROAD are written into the echo file made at the end of a run (along with all other state variables). Both can be used in VS commands; in general, the state variables are recommended because they are updated sooner each time step.
Control: Target Path for Driver and Traffic
The Control: Target Path for Driver and Traffic screen (Figure 4 on page 11) defines a driver reference path that is an alternative to the road reference line defined on screens such as the Road: X-Y Coordinates of Centerline screen.
Sequence of Links
If a simulation scenario involves the vehicle travelling over a 3D road surface with the driver controllers using an alternate path, then it is important to link to a dataset from this library after linking to a dataset from the Control: Steering by the Closed-loop Driver Model library.
The sequence in which datasets are referenced is important due to the associated control modes shown earlier in Table 1 (page 2). The Control: Steering by the Closed-loop Driver Model datasets assign a value of 1 or 2 to the control variable OPT_DRIVER_MODEL; the Control: Target Path for Driver and Traffic datasets assign a value of 3 to OPT_DRIVER_MODEL. The last setting read by the VS solver is the one used. Therefore, the link to the Control: Target Path for Driver and Traffic dataset must come after the link to the Control: Steering by the Closed-loop Driver Model dataset.
These links are typically made on the Procedures screen, where a link to the target path is naturally made after the link to the steering controller (Figure 3).
Figure 3. Linking to a Target Path dataset after the link to a Driver Path Follower dataset.
If this type of dataset is used, then the variables Station and SV_STATION apply to this path. Otherwise, those variables apply to the road reference line.
About the Path Table
that is unusual with respect to nearly all other tables shown in the GUI of a VS browser.
First, the table does not require rows to have an ascending order in X. The VS math models do not actually use X as an independent variable to determine Y. Instead, the X-Y coordinate pairs are preprocessed to generate two other tables internally as functions of station S: X vs. S and Y vs. S. In these tables, S is the independent variable and is defined such that all rows have S in ascending value.
Second, a third column is added automatically to show the values of S that are associated with the X and Y coordinates. This is done to provide a reference listing of station, because it is such a critical variable when using the closed-loop driver controls.
If the path is not looped, then it is a good idea to consider the direction of the path when extrapolated outside the range of the table. The extrapolation is not Y vs. X as with most VS tables; instead, it is X vs. S and Y vs. S. In general, it’s best to make a path that covers the full range that is to be considered in simulations.
Looped Paths
case of a looped path. The initial station (SPATH_DRIVER) is the final
station (SPATH_DRIVER_MAX) to show the length of the loop on this screen
simulation, the state variable SV_STATION is always within the limits of the initial and maximum station of a looped path.
Whenever the VS solver initializes, it calculates the maximum station and assigns it to the parameter SPATH_DRIVER_MAX for the benefit of advanced users who may use the parameter in VS command equations. (A similar convention is used for a looped road reference line; in that case, the maximum station is assigned to the parameter SPATH_MAX.)
The VS solver counts the number of times that the state variable SV_STATION crosses the start of the loop. This count is assigned to a state variable SV_N_START_CROSS that has a default initial value of zero. When station is increasing and reaches the value SPATH_DRIVER_MAX, the solver subtracts the loop length (SPATH_DRIVER_MAX– SPATH_DRIVER) from SV_STATION and increments SV_N_START_CROSS by one. Going the other way, when the station is decreasing and reaches the starting value, the solver adds the loop length and increments
SV_N_START_CROSS.
If no link is made to this screen and the simulation includes a looped 3D road, then the road reference line is used to increment SV_N_START_CROSS.
User Controls
Checkbox to treat path as a loop (keyword = ). When checked, the
path is looped and the total length is shown In this case, the final pair of X-Y coordinates in the table must be the same as the first pair.
Length of looped path. This is shown only when the box is checked to treat the path as a
loop
Station at start of table (keyword = SPATH_DRIVER). This is the station set for the first pair of X-Y coordinates in the table. All other station values are calculated automatically using equation 2 (page 7).
Table of X-Y-S values. As noted above, the X and Y coordinates are the data provided as
(The VS solvers also calculate values of S automatically for internal use and for printing in echo files.)
Initial Vehicle Conditions
All VS vehicle models have options for setting the start and stop conditions for a simulation run. They are described in the reference manual System Parameters in VS Solver Programs. Table 3 lists some that are used to set the initial conditions of the vehicle with respect to the driver reference path.
Note The parameter OPT_DIRECTION was added in April 2011 (CarSim
8.1). In prior versions, the direction was defined using the parameters
SSTART and SSTOP. If OPT_DIRECTION is given a non-zero value,
then SSTOP is not used to define direction. For purposes of backward
compatibility, OPT_DIRECTION has a default value of 0, such that old
datasets that set direction using the SSTOP parameter will still work.
Default Initialization
The Procedures library screen has a checkbox for specifying initialization details. If checked,
three more boxes are shown that are linked to the parameters OPT_INIT_CONFIG, OPT_INIT_ROAD, and OPT_INIT_SPEED. When hidden, these parameters all keep their default values of 1.
Table 3. System options used to set initial vehicle conditions and simulation stop conditions. Keyword Description
OPT_DIRECTION Set to +1 to have the vehicle travel in the direction of increasing station;
set to –1 to go in the direction of decreasing station; specify 0 to set the
direction automatically to ±1 using the relationship between SSTOP and
SSTART when the VS solver initializes. This parameter is automatically
updated to ±1 during the initialization.
OPT_INIT_CONFIG If not zero, set vehicle Z coordinate, springs, and tire deflections to
approximate equilibrium on the 3D ground surface.
OPT_INIT_ROAD If not zero, set vehicle X-Y position and yaw angle to match path at
station SSTART with direction OPT_DIRECTION.
OPT_INIT_SPEED If not zero, set vehicle wheel spin rates to match initial forward speed. OPT_SSTOP Select option for stopping the run. If OPT_SSTOP is zero it will stop
when TSTOP is reached; if OPT_SSTOP > 0, then the run will stop
when station SSTOP or time TSTOP is reached; if OPT_SSTOP < 0
then neither SSTOP nor TSTOP are monitored to stop the run. SSTART Station value used to define the initial location of the vehicle on the
reference path if OPT_INIT_ROAD is not zero.
SSTOP If OPT_SSTOP > 0, then the run stops when station SSTOP is reached. Note:All references to station are based on the driver reference path as selected with model options OPT_DRIVER and OPT_ROAD.
When OPT_INIT_ROAD has the default value of 1, the VS solver locates the vehicle at the specified starting station with a yaw angle parallel to the reference path. If the stop station is greater than the start station or if Road forward is selected as the direction of travel in the start and stop conditions of the GUI, then the vehicle is pointed in the direction of increasing station. If the stop station is less then the start station or if Road reverse is selected as the direction of travel in the start and stop conditions, then the vehicle is pointed in the direction of decreasing station. If closed-loop steering control is specified and OPT_INIT_ROAD is not zero, then the vehicle is offset laterally from the driver reference path using the configurable function LTARG (see Figure 11 on page 26). With open-loop steering, there is no lateral offset.
The Events library screen also has a checkbox for specifying initialization details. If checked, three more boxes are shown that are linked to the parameters OPT_INIT_CONFIG, OPT_INIT_ROAD, and OPT_INIT_SPEED. If the dataset from the Events screen is loaded after a run starts, these parameters all have default values of 0. In this case, the individual settings would be made to force initializations in the middle of a run, such as done sometimes to simulate a sequence of tests in a single run.
Arbitrary Starting Position
You can set the vehicle initial position and orientation explicitly using the vehicle state variables. On the Procedures screen, check the box for specifying initialization details. Uncheck the other boxes to turn off the automatic initializations associated with OPT_INIT_CONFIG, OPT_INIT_ROAD, and OPT_INIT_SPEED. Use one of the miscellaneous yellow fields to set initial conditions using keywords for state variables in the math model. These keywords appear in
two machine-generated files that can be viewed using the View button in the lower-right corner of the Run Control screen. One is the Echo File with Final Conditions; the other is the Multibody model description file. Keywords for state variables begin with the prefix "SV_". For example, the initial X and Y coordinates of the vehicle sprung mass origin are SV_XO and SC_YO; the vehicle yaw angle is SV_YAW; the initial forward speed is SV_VXS.
Suppose you want to specify the initial X and Y coordinates and yaw angle on the Procedures screen. Check the box to Specify initialization details.Uncheck the box to set the vehicle X, Y and Yaw automatically, but leave the other two boxes checked (wheel speeds and vehicle springs).
In a miscellaneous yellow field, type SV_XO followed by the desired X coordinate in meters, SV_YO followed by the desired Y coordinate in meters, and SV_YAW followed by the desired yaw angle in degrees.
Advanced users can use this same general technique for resetting positions in the middle of a run, using the Events screen to specify the values of some state variables.
Changing Paths Using Events
Events can be set up to change paths during a run. When an event condition is triggered and a new parsfile is read, the VS solver goes through the initialization options described in the previous section. Often, the intent is for the vehicle state to remain “as is” with no change in position or speed of any moving part. In these cases, the solver must determine where the vehicle would be located along the new path by converting the global X and Y coordinate values of the vehicle to S and L path coordinates.
Converting from X-Y to S-L coordinates can be complicated for the math model. A major potential difficulty is that there might be many solutions of S-L coordinates that would be valid for a given vehicle location. For example, Figure 5 shows a path for a racecourse (blue) and a point of interest on the vehicle (red circle). Any of the points labeled A, B, etc. on the reference path are connected to the point with a line perpendicular to the path and are therefore valid locations for determining S and L. (In this case, point A is probably the correct location.) Internally, the math model keeps track of the most recent value of station for each point of interest. The station variable used by the closed-loop controllers for speed and steering use the state variable SV_STATION.
If you set up an event to change paths during a run, it is a good idea to also set the station state variable to a value that is close to where the vehicle will be located on the path when it is activated. For example, suppose the path shown in Figure 5 is activated during a run and the vehicle will enter near point A. The path station at point A is 2012 m, the path station at point C is 1243 m, and the current value of the state variable SV_STATION is 956 m. It is likely that the solver will either determine that the location on the path is point A (S = 1243), or that it will fail to find a value and stop the run. To provide a clean transition, the parsfile loaded when the event is triggered should not only load the new path dataset, it should also set SV_STATION to a value near 2000 to enable the solver to properly locate the vehicle position in the path.
Figure 5. Multiple locations on a path might provide valid S-L coordinates for the vehicle. Closed-Loop Speed Control
VS vehicle math models use a built-in closed-loop speed controller to follow a target speed. The target speed can be specified several ways:
1. a constant,
2. a predefined function of time (use the Control: Speed (Closed Loop) vs. Time screen),
3. a predefined function of station along the driver reference path (use the Control: Speed
(Closed Loop) vs. Station screen), or
4. calculated automatically as a function of station by previewing the target path and taking
into account the curvature and possibly the 3D properties of the ground surface along the path (use the Control: Speed (Closed Loop) Using Path Preview screen).
Predefined Speed vs. Time or Station
Figure 6 shows the screen used to specify the target speed as a function of station. For example, it can be used to specify lower speeds for turns in the road. A nearly identical screen (not shown) is used to specify the target speed as a function of time.
Discussion
As shown on the screen, the controller calculates target acceleration with the equation:
A xTarget = K p V err + K i I err + K p3 V err 3 (3) where
V err = V target – V x I err = ∫ V err dt (4) Speeds are expressed in m/s and the coefficients K p , K i , and K p3 are defined such that A xTarget is dimensionless (g’s).
Figure 6. Closed-loop speed control.
If the vehicle has a full powertrain, then acceleration is obtained by modulating the throttle. If a
is checked, then deceleration is obtained using the brake system. Otherwise, the
control box Array
same control used for acceleration is also used for deceleration (throttle or direct application of
control box
unchecked, the speed control is turned off when the brakes are applied, Array
mimicking the typical behavior of a cruise control.
All of the terms shown in equations 3 and 4 are accessible for use in VS commands that might be created to extend the controller. V x , V target , V err , and I err are output variables (the full names are Vx,VxTarget,Vx_Err, and Vx_IErr, respectively). V x and I err are also state variables (keywords = SV_VXS and SV_IVERR, respectively).
The integral error I err is automatically set to zero if the vehicle stops or reverses directions. It can also be set to zero using VS commands. (Be sure to set the value of the state variable SV_IVERR, rather than the output variable that is copied from the state variable.)
User Controls
Target speed for control. As with most configurable functions, this can be a constant, a coefficient, a nonlinear table specified with a set of numbers and a choice of interpolation
and extrapolation methods, or a symbolic equation as described in the VehicleSim Browser
Reference Manual and VehicleSim Solvers Manual. The example in the figure defines the speed with a table of speed vs. station values that are interpolated as shown in the plot.
Proportional gain coefficient K p(keyword = SPEED_KP). Typical values are about 0.5. Setting the value higher causes the drive torque to be modulated more rapidly. Although this
Integral gain coefficient K i (keyword = SPEED_KI). Integral control forces the speed error to zero when the target speed has a constant or slowly changing value. In these cases, a value of about 0.5 m-1is typical. However, integral control also adds dynamics to the closed-loop system that can cause overshoot and instabilities if the target speed goes through large changes. When rapid changes in target speed are specified, it is often best to turn off integral control by setting this value to zero.
Cubic gain coefficient K p3 (keyword = SPEED_KP3). Nonlinear cubic control generates an aggressive response when there are large differences between the target speed and vehicle speed. When the vehicle speed approaches the target speed, the cubic effect becomes negligible. This coefficient can be given a value of zero for constant or slowly changing speeds. For more dynamic speed changes, values of about 1.0 are typical.
Option to account for engine braking in the speed control (keyword = OPT_SC_ENGINE_BRAKING). When the simulated vehicle includes a full powertrain, the throttle is estimated using engine properties at the current engine speed (RPM). In older versions (prior to April 2011, CarSim 8.1), the throttle was calculated using the torque from the engine table at the current engine speed and full throttle together with an assumed zero torque at zero throttle. When this box is checked, the engine table is also checked for the current speed and zero throttle, in order to provide better transitions between low throttle and braking.
Option to include braking in the speed control (keyword = OPT_BK_SC). When this box is checked, the speed controller is allowed to use the brakes to slow the vehicle. When it is not checked, the speed controller uses the same control for deceleration as is used for acceleration (throttle or direct application of torque to the drive wheels, depending on whether the vehicle has a full or “minimal” powertrain).
When this box is not checked, applying the brakes turns off the speed control, mimicking the typical behavior of a cruise control.
Brake system performance (keyword = BK_PERF_SC), used in the closed-loop controller. This value relates deceleration to brake pressure. The feedback method used by the controller compensates for errors in this parameter, so an approximate estimate is usually
is checked.
Brake pedal force to master cylinder pressure gain (keyword = FPD_PERF_SC) for the
detailed brake model. This value needs only to be a reasonable estimate, and can be is checked. If the basic brake model is used, this parameter is ignored.
only when box
This is a CarSim option that does not exist in TruckSim.
Stop speed (keyword = OPT_VMIN). A simulation continues until one of several conditions
The minimum speed must be given a value that is smaller than the initial vehicle speed or the target speed. To prevent the simulation from stopping due to low speed, set the threshold to a negative number (e.g., –1).
Speed Control Using Path Preview
The speed controller can calculate target speed as a function of curvature in the reference target path, combined with driver aggressiveness, skill parameters, and possibly 3D surface properties. This is done with the Control: Speed (Closed Loop) Using Path Preview screen (Figure 7).
Figure 7. Speed Control Using Path Preview.
Discussion
When you use a dataset from this library, the speed controller is set to run in path preview mode (OPT_SC = 4). In this case, the controller calculates target speed by previewing the target path ahead of the vehicle.
The controller looks at the target path, starting a distance SPEED_PREVIEW_START in front
covering a distance SPEED_PREVIEW It looks at the path curvature at intervals of
SPEED_PREVIEW_STEP
over segments of length SPEED_CURV_LENGTH
using the Control: Speed (Closed Loop) vs. Station screen (Figure 6 on page
16).
2.The target speed is possibly reduced in turns in order to keep lateral acceleration A y
3.The target speed is possibly reduced when approaching lowered speeds to account for
realistic braking, to keep combined longitudinal and lateral acceleration (A x and A y,
4.
When the path preview mode is active, the same closed-loop speed control is used to modulate throttle and brake controls as used for the other closed-loop modes. Hence, the user controls on
Brake control is fundamental path preview mode and cannot be disabled; hence, the
Acceleration Limits: Skill Level
The acceleration limits used to determine target speed are based on a skill level and aggressiveness limits.
Drop-down list of three skill levels available for combining lateral and longitudinal acceleration in order to compare them to specified acceleration limits. These are designated as skill levels 0, 1, and 2:
0 Ax and Ay are not combined. The target speed is adjusted to allow acceleration either
longitudinally or laterally, but never both at once.
1 Ax and Ay are combined using straight lines, allowing some combination of lateral
and longitudinal acceleration. However, the combined acceleration does not make
use of as much available friction as is used in pure longitudinal or pure lateral
acceleration.
2 Ax and Ay are combined using a friction ellipse, providing a consistent use of
available friction regardless of the direction of the total acceleration vector.
Note The methods used to combine lateral and longitudinal acceleration while previewing the path do not take into account the detailed dynamics of the
vehicle that will occur; they only take into account the geometry of the
path and the speed to be followed along the path.
Due to dynamic effects, the actual accelerations of the vehicle can
exceed the specified limits, especially when aggressive limits are set, and
wide ranges in speed are simulated (as in a race course). In some cases,
better performance can be obtained using the straight-line combined
acceleration (skill = 1) than with the friction ellipse (skill = 2).
Checkbox to account for road surface 3D geometry. This box is available when lateral and
Here are some example effects of geometry:
·The lateral acceleration limit is adjusted based on banking angle. Banking into the turn allows higher speed, but banking out of the turn requires lower speed.
·The longitudinal acceleration limit is adjusted based on grade angle. More throttle acceleration is allowed going downhill, while more braking acceleration
is allowed going uphill.
·Acceleration limits are adjusted based on curvature normal to the surface. More lateral and longitudinal acceleration is allowed when compression increases
forces normal to the surface, while lower lateral and longitudinal acceleration
limits must be used when forces normal to the surface are reduced.
Acceleration Limits: Aggressiveness
Aggressiveness of the speed controller is defined with four limits in acceptable acceleration limits (front, rear, left, right). Each of the four limits can be specified as either a constant or as a nonlinear configurable function. A drop-down list is provided to choose between these options (Figure 8).
Figure 8. Choose a constant or a link to a configurable function screen.
If the constant is chosen, a yellow field appears (e.g.,
appears (e.g., Generic Table
When a configurable function is used, it is necessary to specify the keyword associated with the specified acceleration limit (SPEED_AX_THROTTLE, SPEED_AX_BRAKE, SPEED_AY_LEFT, or SPEED_AY_RIGHT). Right click on the drop-down control to see the keyword associated