Driver subsystem

Driver inputs (steering, throttle, and braking) are provided from a driver subsystem with available options in Chrono::Vehicle including interactive, data-driven, and closed-loop (e.g., path-following based on PID controllers).

The base class for a driver system, ChDriver, imposes minimal requirements from a driver system template, in particular the ability to return throttle input (normalized in the $$[0,1]$$ range), steering input (normalized in the $$[-1, +1]$$ range, with a negative value indicating steering to the left), and braking input (normalized in the $$[0,1]$$ range). In addition, a driver system can receive information from any other system (e.g., the vehicle state) through its Synchronize method and may have internal dynamics (implemented in its Advance method). Specific templates for a driver system may extend the set of vehicle inputs generated, for example including the current selected gear for a manual transmission, enabling/disabling the cross-drive capability on a tracked vehicle, etc.

Chrono::Vehicle includes several templates for driver systems. For interactive simulations, run in soft real-time, it provides a template for a driver system which produces the vehicle inputs based on user controls, either keyboard and mouse, or a game controller.

For design of experiment simulations, it provides a driver system template that is based on inputs provided through a text data file, with the vehicle inputs obtained through linear interpolation. Such data files can also be automatically generated by data collected during interactive runs.

Finally, Chrono::Vehicle includes several closed-looped driver system models, based on underlying support for PID controllers. These include speed controllers (which adjust the throttle and braking input simultaneously to maintain a constant vehicle speed) and path-follower controllers. The latter adjust the steering input so that the vehicle follows a user-defined path specified as a Bezier curve.

# Interactive driver

The interactive driver ChIrrGuiDriver can control (steer/accelerate/brake) a simulated vehicle through user input. Since it relies on Irrlicht to handle keyboard events, it is only available with Irrlicht based programs.

• key A increases left turn steering wheel angle
• key D increases right turn steering wheel angle
• key W accelerate
• key S decelerate

The throttle and braking controls are coupled, in the sense that acceleration first drives braking to zero before increasing throttle input (and vice-versa for deceleration).

Other features of this driver subsystem model include:

• experimental joystick support
• ability to lock/unlock driver inputs to their current values (controlled through key J)
• ability to record and playback user inputs (using an embedded data-based driver; see below)

# Data-based (open-loop) driver

Some important vehicle test maneuvers are based on time-dependent steering/throttling/brake signals. No feedback of any kind is considered. This driver model is implemented in ChDataDriver.

An ASCII data file with driver inputs contains four columns, for time (s), steering input (a non-dimensional quantity in $$[-1,1]$$, with $$-1$$ indicating full steering to the left), throttle input (a non-dimensional quantity between $$[0,1]$$, with $$1$$ indicating full throttle), and braking (a non-dimensional quantity between $$[0,1]$$, with $$1$$ indicating full braking force).

A sample driver data file is listed below

0.0 0.0 0.0 0.0
0.5 0.0 0.5 0.0
3.0 0.0 0.5 0.0
5.0 0.5 0.4 0.0
9.0 0.0 0.0 1.0

At any given time, the current driver inputs (steering, throttle, and braking) are obtained by piece-wise linear interpolation of the provided data. Beyond the last time entry, driver inputs are kept constant at their last values.

# Close-loop driver models

Close-loop driver models need a control strategy and consider feedback. Feedback can lead to instable behavior, so the controller parameters have to be chosen wisely. The example parameters have been working in a wide range of use. The user should start with one of the given example parameter sets and only modify it if necessary.

## Path-follower controller

To make the vehicle follow a given path it is necessary to measure the lateral path deviation and to generate a steering wheel angle that minimizes the deviation. A well known solution for this problem is the PID controller (P=proportional, I=Integral, D=Differential). Taking the pure P variant one only needs to set the P-gain. This will work in many cases but pure P controllers can never reduce the lateral deviation to zero. The residual deviation decreases with increasing P-gain. If the P-gain is too large, the vehicle begins to oscillate around the demanded vehicle path. A residual path deviation can be eliminated by setting the I-gain to a value of around 5% to 10% of the P-gain. By setting the D-gain it is possible to apply damping if a path oscillation occurs. If the I-gain is used, the simulated maneuver should not take longer than about 2 minutes. If it takes more time, the controller states should be reset every 2 minutes to avoid instabilities.

The next chart (Wikipedia) shows how Chrono implements the PID controllers:

• r(t) = demanded path signal
• e(t) = lateral path deviation
• y(t) = actual path signal
• u(t) = steering signal

This chart (Wikipedia) shows the influence of the gain factors:

A human driver does not only react on deviation changes, he is able to anticipate. In Chrono this ability is simulated by taking a reference point for measuring the deviation in front of the vehicle body. The distance of the reference point from the vehicle reference system is called look-ahead-distance and is an important controller input parameter.

The desired path is specified as a Bezier curve (see ChBezierCurve). The error is defined as the deviation between a "sentinel point" (a point located at the look-ahead distance in the vehicle forward direction) and a "target point" (the projection of the sentinel point onto the desired path).

## Constant-speed controller

To maintain a given vehicle speed the PID controller can be used. The difference to the path controller is that it uses a speed deviation instead of the lateral path deviation.

• r(t) = demanded speed signal
• e(t) = speed deviation
• y(t) = actual speed signal
• u(t) = throttle/brake signal

The class ChPathFollowerDriver implements the PID lateral controller in combination with a PID speed controller. It works well at extreme maneuvers like double lane change.

An interesting alternative for standard road driving maneuvers is ChPathFollowerDriverSR. It has a PID speed controller but takes lateral control strategy that considers human and vehicle properties. The anticipation uses look-ahead time instead of a look-ahead distance which means the effective look-ahead distance varies with the speed.

## Optimal-speed controller

The constant-speed controller is good for many standard driving maneuvers. For driving on a long and curved road it is interesting how fast the vehicle can negotiate the whole course. For cases like this the ChHumanDriver class has been developed. Both the lateral and the speed controllers use human behavior, vehicle properties, and anticipation as well as field of view of the driver. The lateral controller is identical to the one implemented in ChPathFollowerDriverSR.