Driver model drive-cycle task with feedback

The Matlab fmincon function is used in an optimisation algorithm to fit the driver model frameworks to the recorded data from the simulator. The driver cost function weightings on speed error are varied to identify the combination resulting in the minimum fitting cost function value. The fitting function is as defined in ( 3.46 ). Constraints are initiated to ensure that the weightings are positive. In the one-sided cooperative case, the driver dominance, 𝜌1 is also included in the

optimisation.

Figure 4-18 demonstrates the effect of varying the driver dominance, 𝜌1, on the fitting

function for Driver 6 over a range of values of 𝑞1𝑠. It is noted that the global minimum is located

4.5 Driver model identification 151 This is also the case for the other eight drivers, although the minima are located at slightly different values of 𝑞1𝑠. Hence, for this task, one-sided cooperative control is no longer considered. It is also

noting that the contour for 𝜌1= 0 is a horizontal line. This is because, for 𝜌1= 0, the driver’s own

target is no longer taken into account, and there is no cost associated with the driver’s pedal force. The result is that the driver exerts the forces necessary to reach the sustainable target.

Figure 4-18 – Fitting function sensitivity for the one sided cooperative for a variety of values of driver dominance, 𝜌1, and decentralised (𝜌1= 1) cases

Figure 4-19 illustrates the optimal cost function weightings for each of the nine drivers. From an initial comparison, it is noted that the weightings on speed error between the unassisted driver case (from 3.2) and the decentralised controller model are of similar magnitude, supporting the idea that drivers might interact with the feedback controller in a decentralised manner.

In terms of ‘goodness of fit’, Figure 4-20, shows that the fitting function for the decentralised case is less than that for the unassisted case for six of the nine drivers. This means that, in most cases the driver model is better able to predict the behaviour of a decentralised driver with feedback, than the driver unassisted. The framework is well suited to modelling the human driver-active pedal interaction.

152 Pedal Feedback

Figure 4-19 – Fitted cost function weightings for the Drive Cycle task

4.5 Driver model identification 153 The behaviour of the assisted driver model is now demonstrated over the next set of figures. Driver 9 is selected for demonstration as the driver models best fitted with this driver over both cases of unassisted and assisted. Figure 4-21 illustrates the recorded and modelled vehicle speed for the drive cycle following scenario. The real driver, does not have perfect knowledge of the behaviours of the vehicle and therefore is unable to control the vehicle to the same high standard as the very capable driver model. Another possible explanation for the discrepancy is that there is noise in the human sensorimotor system and an inaccurate simulation model (as intermittency is not included for example). With this is mind, the driver model does quite closely resemble the shape of the driver speed profile.

Significant differences between the human driver and the driver model occur in the driver pedal forces -Figure 4-22. The decentralised driver model underestimates the forces from the driver. As the driver pedal forces are inaccurate, the pedal feedback forces will also be inaccurate -Figure 4-23. In the model situation, the pedal feedback is having to exert much higher forces to reach its objective, as the driver model is exerting lower forces than the human driver did. The resultant of these uneven pedal forces between the driver and feedback controller even out to produce a pedal position that closely resembles the measured pedal position - Figure 4-24.

154 Pedal Feedback

Figure 4-22 – Measured human driver and modelled pedal force for Driver 9

4.5 Driver model identification 155

Figure 4-24 – Measured human driver and modelled pedal displacement for Driver 9 Further analysis of the driver model with feedback is completed through a parameter study examining how, by varying the cost function weightings, differences in driver model behaviour can be seen. Figure 4-25 demonstrates the trade-off between different costs for different driving styles (determined by different driver cost function weightings on speed error). The driver model and feedback controller are given a drive-cycle following task using the modified Millbrook cycle in both the decentralised and one sided cooperative framework (note that the one-sided cooperative case is introduced for comparison again, and the value of 𝜌1 is fixed to 0.75.

Looking at the RMS speed error and RMS pedal force plots (Figure 4-25), several key features of the shapes are noted. Firstly, it is noted that the one-sided cooperative control framework produces lower (or near equal) speed errors over all driver cost function weightings than the decentralised controller. This is because the driver is modelled to have understanding of the feedback controller’s objective, and will hence make some accommodation to this. It is also noted that in the decentralised case, that by increasing the driver’s weighting on speed errors, 𝑞_1𝑠, it is possible to increase the resultant speed errors, before a continued increase in speed error weighting results in reduced speed errors. This is due to the transition between the driver being overpowered by the feedback controller’s strategy at low weighting of speed error and the driver being very dominant over the feedback controller at high weightings on speed error. In the region in between the two, the controllers behave similarly to each other, which results in non-optimal performance.

156 Pedal Feedback It is also noted that the experimental data points for each human driver are significantly higher than the modelled values, suggesting the human drivers behave in a non-optimal way with the pedal feedback – this could be an effect of the presences of sensorimotor noise not included in the simulation.

Figure 4-25 –Trade off graph for the drive cycle with feedback scenario