Integrated Vehicle Stability and Power Management Controls for

Integrated Vehicle Stability and Power Management Controls for
Integrated Vehicle Stability and
Power Management Controls for
Electric Vehicles
by
Andy Wong
A thesis
presented to the University of Waterloo
in fulfilment of the
thesis requirement for the degree of
Master of Applied Science
in
Mechanical Engineering
Waterloo, Ontario, Canada, 2014
c Andy Wong 2014
Author’s Declaration
I hereby declare that I am the sole author of this thesis. This is a true copy of the thesis,
including any required final revisions, as accepted by my examiners.
I understand that my thesis may be made electronically available to the public.
ii
Abstract
An integrated vehicle controller is presented for electric vehicles using independently
driven wheel motors. This topology takes an optimal control approach to enhancing a
vehicle’s performance, stability, and energy consumption metrics simultaneously in a unified software structure. The logical output of this algorithm is a set of re-distributed wheel
torques, to create torque vectoring for stability-focused yaw rate tracking, and longitudinal
biasing to modify motor load for energy savings. A real-time numerical approach to solving
the optimization problem is also presented, and shown to o↵er benefits over a closed form
analytic approach. In this, solution constraints are used to link considerations such as
nonlinear motor limits, tire friction envelopes, and lower-level traction control loops. To
test the efficacy of this control structure, two vehicle test platforms were constructed as
retrofits of production gas SUVs for electric drive. For this, the component layout is given,
followed by an explanation of the software code structure as performed in a Simulink/Carsim/dSpace environment. Results from these platforms are given, with experimental and
simulation data for traction control, yaw performance tracking and drive cycle power consumption. Proven performance over a variety of maneuvers and surface conditions further
demonstrate the controller’s stability and suitability for mass production.
iii
Acknowledgments
I’d like to thank General Motors for providing the initial concept of the control approach, their technical support, and guidance through the years with their bi-weekly meetings. I’d also like to thank the Ontario Research Fund (ORF) and Automotive Partnership
Canada (APC), who provided the large amount of funding needed to make such a project
possible. Finally, my gratitude goes to Professor Amir Khajepour, who built our work
environment and guided so much of our research.
iv
Dedication
This is dedicated to my parents, who have always taught me to value education above
all else.
v
Table of Contents
List of Tables
vii
List of Figures
viii
1 Introduction
1
1.1
Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2
Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2 Integrated Vehicle Stability and Energy Management Control
2.1
9
Background Information . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.1.1
Vehicle Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.1.2
Vehicle Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2
Driver Command Interpreter . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3
HCC Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.3.1
Weight Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
Numerical Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.4.1
Tire Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.4.2
Motor Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.4.3
Drivetrain Reconfiguration and Fault Tolerance . . . . . . . . . . .
26
2.4.4
Traction Control . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
Energy Management Formulation . . . . . . . . . . . . . . . . . . . . . . .
28
2.4
2.5
vi
2.5.1
Energy Management Algorithm . . . . . . . . . . . . . . . . . . . .
29
2.5.2
Friction considerations . . . . . . . . . . . . . . . . . . . . . . . . .
33
3 Platform Design
35
3.1
System Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.2
Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.2.1
44
Physical Integration . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Software Design
4.1
4.2
4.3
48
Simulink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.1.1
Controls - Logic Level . . . . . . . . . . . . . . . . . . . . . . . . .
50
Carsim Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.2.1
Driver Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.2.2
Simulated Sensor Input . . . . . . . . . . . . . . . . . . . . . . . . .
67
dSpace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
5 Results
78
5.1
Energy Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.2
Energy Management Under Dynamic Maneuvers . . . . . . . . . . . . . . .
83
5.3
Straight Line Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
5.3.1
Experimental Results, Split-Mu, Wet Asphalt . . . . . . . . . . . .
92
Double Lane Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.4
5.4.1
Experimental Results, Sine Wave in Snow . . . . . . . . . . . . . . 101
5.4.2
Experimental Results, Double Lane Change on Asphalt . . . . . . . 103
6 Conclusion
105
References
106
vii
List of Tables
2.1
Vehicle Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
4.1
MABX Inputs from GM-HSCAN . . . . . . . . . . . . . . . . . . . . . . .
73
4.2
MABX Input Signals for Andybus . . . . . . . . . . . . . . . . . . . . . . .
74
5.1
Average Motor Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.2
Power Consumption
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.3
Driver Model Tracking Error Rates . . . . . . . . . . . . . . . . . . . . . .
81
viii
List of Figures
1.1
Electric Equinox Platform . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1
Control Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2
Simple Tire Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3
Longitudinal Tire Force Curve . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4
Lateral Slip Definitions in a Bicycle Vehicle Model . . . . . . . . . . . . . .
13
2.5
Lateral Tire Force Curve . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.6
Yaw Gain Response Comparison . . . . . . . . . . . . . . . . . . . . . . . .
16
2.7
DCI Deadband Function . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.8
Force Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.9
Proposed Weighting Function for wf
. . . . . . . . . . . . . . . . . . . . .
22
2.10 Electric Motor Curve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.11 Engine Efficiency Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
2.12 Sinusoidal Throttle Input and Resulting Efficiencies . . . . . . . . . . . . .
32
2.13 Comparison of Allowable Search Indices for Two Di↵ering Surface Frictions
34
3.1
RWD Equinox Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.2
4WD Equinox Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.3
Detailed Component Layout (4WD) . . . . . . . . . . . . . . . . . . . . . .
37
3.4
Systems Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
ix
3.5
dSpace Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.6
Rewired ECU Dongles . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.7
Drivetrain Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.8
High Voltage Power Systems . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.9
Battery Charging and Management Systems . . . . . . . . . . . . . . . . .
43
3.10 Validation Equipment
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.11 Front Motor Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.12 Rear Motor Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.13 Front Vehicle Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.14 Vehicle Midsection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
3.15 Vehicle Rear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
3.16 Rear Accessory Pan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.17 Vehicle Interior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.1
Code Logic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.2
AWDC Logic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.3
AWDC Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.4
BRFC Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.5
Brake Torques of Equinox Model . . . . . . . . . . . . . . . . . . . . . . .
53
4.6
DCI block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.7
HCC Simulink Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.8
Multiple HCC Moding . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.9
HCC Safety Cuto↵s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.10 TBC block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.11 Function Scheduler block . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.12 Carsim Vehicle Model
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.13 Carsim Tire Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.14 Simulated Driver Manoeuvring . . . . . . . . . . . . . . . . . . . . . . . . .
65
x
4.15 Double Lane Change Simulator Input . . . . . . . . . . . . . . . . . . . . .
66
4.16 Carsim Interface
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.17 MABX Input Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
4.18 BCM Signal Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
4.19 Simulated Signal Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
4.20 CAN Channel Functionality . . . . . . . . . . . . . . . . . . . . . . . . . .
70
4.21 Sample CAN Message Layout . . . . . . . . . . . . . . . . . . . . . . . . .
72
4.22 Simulink CAN interface . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
4.23 Main Demonstration Screen . . . . . . . . . . . . . . . . . . . . . . . . . .
76
4.24 Tuning Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.1
Vehicle Testing at UW Fire Research Facility
. . . . . . . . . . . . . . . .
79
5.2
EPA Drive Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.3
Vehicle Tracking Results . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
5.4
Driver Inputs for Simulated Run . . . . . . . . . . . . . . . . . . . . . . . .
83
5.5
Comparison of Torques With and Without EMS . . . . . . . . . . . . . . .
83
5.6
Comparison of Torques With and Without EMS . . . . . . . . . . . . . . .
84
5.7
Path and Yaw Rate Tracking Comparison With and Without EMS . . . .
85
5.8
Pedal Input for Straight-Line Acceleration Test . . . . . . . . . . . . . . .
86
5.9
Slip Ratios, Traction Control On . . . . . . . . . . . . . . . . . . . . . . .
87
5.10 Slip Ratios, Traction Control On . . . . . . . . . . . . . . . . . . . . . . .
88
5.11 Permissible Tire Force Bounds, µ = 0.6 . . . . . . . . . . . . . . . . . . . .
89
5.12 Slip Ratios, Traction Control On, µ = 0.3 . . . . . . . . . . . . . . . . . . .
90
5.13 Slip Ratios, Traction Control On, µ = 0.3 . . . . . . . . . . . . . . . . . . .
91
5.14 Pedal Inputs, Split-Mu Acceleration . . . . . . . . . . . . . . . . . . . . . .
92
5.15 Comparison of Yaw Rate Responses on a Split-Mu Surface . . . . . . . . .
92
5.16 HCC Correction Torques For Driven Wheels . . . . . . . . . . . . . . . . .
93
5.17 Comparison of Slip At Driven Wheels . . . . . . . . . . . . . . . . . . . . .
93
xi
5.18 Steering Input for Double Lane Change . . . . . . . . . . . . . . . . . . . .
94
5.19 Comparison of Yaw Rate Responses at µ = 1.0 . . . . . . . . . . . . . . . .
95
5.20 Path Following Abilities of HCC Across Various Friction Surfaces . . . . .
96
5.21 Comparison of Yaw Rate Responses on Di↵ering Surfaces . . . . . . . . . .
97
5.22 Permissible Tire Bounds for the Rear-Right Tire Over Various Friction Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
5.23 Comparison of HCC Augmentation Torques on Di↵ering Surfaces . . . . .
99
5.24 Slip Ratios at Each Corner, µ = 0.1 . . . . . . . . . . . . . . . . . . . . . . 100
5.25 Yaw Rate Response Comparison, Snowy Conditions . . . . . . . . . . . . . 101
5.26 Vehicle Speeds During Maneuver . . . . . . . . . . . . . . . . . . . . . . . 101
5.27 HCC Torques, Snowy Conditions . . . . . . . . . . . . . . . . . . . . . . . 102
5.28 Performance Comparison, Double Lane Change on Asphalt . . . . . . . . . 103
5.29 Vehicle Speeds During Maneuver . . . . . . . . . . . . . . . . . . . . . . . 103
5.30 HCC Vectoring Torques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
xii
Chapter 1
Introduction
Recently, increasing attention has been placed on hybrid and electric vehicles as a coste↵ective way of reducing reliance on oil. Historically, full-electric vehicles have not been
widespread due to technological and cost restraints, but trends are improving for the long
term future. Vehicles such as the Nissan Leaf, Chevrolet Volt, and Tesla S have shown
that it is feasible to release a commercially viable electric car for the masses. Over time,
full electric drives look to replace internal combustion engines as technology matures. This
transition allows for distributed wheel motors at each corner, since electric motors could
be produced smaller and implemented with fewer parts than their gasoline equivalents.
Given independent wheel actuation and faster response times over traditional clutch and
di↵erential 4WD systems, a new generation of algorithms are enabled to exert greater
control.
This thesis outlines the design process of such an electric vehicle, produced with the
intention of researching new control algorithms. A major goal of the project was to create production-like qualities in packaging, weight distribution, and performance. Given
the project’s association with the General Motors Corporation, a pair of 2010 Chevrolet
Equinoxes were chosen as the base platform, one to serve in RWD and one in 4WD modes.
These vehicles are kept with stock suspension and tires, and independently driven for each
active wheel. It is meant to be indicative of an outwardly production-like electric SUV, as
shown in Figure 1.1.
By retrofitting a vehicle, e↵ort was saved by not attempting major mechanical design.
This allowed more resources for supporting the research group’s primary focus in vehicle
controls. The control system described in this thesis is comprehensive, and encompasses
performance, stability, and energy management considerations. At the core of this system
1
Figure 1.1: Electric Equinox Platform
is the Holistic Corner Controller (HCC), a flexible algorithm which dynamically redistributes tire forces between driven wheels to create torque vectoring for vehicle control. To
accomplish this, the algorithm uses state feedback from the vehicle, largely from sensors,
state and parameter estimation algorithms. Together, these provide information for feedback such as body acceleration and tire forces, which the HCC uses to calculate control
actions.
The HCC is set up as an optimization problem, where a cost function is used to determine the best actuator output given a desired yaw moment, under the constraints of
tire friction limits, number of available actuators, and motor dynamics. Weights within
the cost function may be tuned according to the vehicle’s design objective - emphasis may
2
be placed on stability, handling, or comfort. Most importantly, the main benefit of this
approach is a unification of the control structure, since the HCC can optimize against
multiple control objectives in one single step.
The dynamic aspects of the HCC respond most when tire limits are reached, and tire
slips result in an error between the desired and actual response. A large portion of driving
is not performed at these limits of handling however, and consists instead of start-stop
accelerations with mild turns. This led to the development of an energy management
component, which generates the baseline torque at each wheel while minimizing energy
usage during periods of low performance requirements. This algorithm reduces energy
usage by finding a torque distribution between the front and rear axles at any given speed,
such that the weighted average of the two efficiencies is at a maximum.
Chapter 2 outlines the theoretical basis of the controller, while Chapter 3 outlines
the platform’s hardware design. Software implementation of the structure is described in
Chapter 4. Finally, results are given in Chapter 5 for a variety of drive cycles and test
maneuvers.
3
1.1
Literature Review
The HCC is a formulation which maintains vehicle stability by generating an additional
force and yaw moment on the vehicle via lateral di↵erentials in tire force. The maximum
deliverable forces at each tire are constrained however, and varies with the dynamic state
of the vehicle. In order to achieve a desired state, the tires are controlled by supplementary traction or braking torques. E↵ective systems already exist in the market place, by
companies such as Bosch who supply various forms of Anti-Lock Braking Systems (ABS)
[2] and Electronic Stability Control (ESC) [25] for large Original Equipment Manufacturers (OEMs). In traditional gas-engine vehicles, brakes and active clutches are used to
distribute torque and create yaw moments, and generally act as a control layer separated
from the rest of the vehicle [4]. In a term coined as ”peaceful coexistence”, OEMs have had
little control over the inner workings of these stability programs, and higher-level controls
have had to be tuned around a number of unknowns.
In literature, examples of research have been published which solve specific aspects of
yaw moment control, such as: active steering[24] [34], torque vectoring [33] [30] [36], or
traction control [39] [35]. However, there are few that consider all factors at the same time.
This gives motivation for the development of a unified structure, which can perform
all major aspects of vehicle control at once, such that maximum performance can be extracted without margins for ”peaceful coexistence”. Furthermore, the projected availability
of distributed-motor vehicles place high-bandwidth actuators within the OEMs’ reach, allowing higher fidelity control as compared to traditional mechanical systems.
A unified control structure similar to the HCC was first proposed by Y. Hattori [21], in
a closed form objective function that was solved using nonlinear optimization techniques
for di↵erential torque and braking signals. Later developments saw the addition of active
steering capabilities [23], but one major setback for both solutions is the use of slip ratios
inside the cost function, which needs a subsequent tire model to attain patch forces at
each corner. Because of this requirement, more parameters are required to arrive at a
solution. In Hattori’s implementation for example, a brush tire model is utilized, which
requires cornering sti↵ness and vertical coefficients of sti↵ness, among other things. These
parameters change as a function of road conditions and tire model, which may limit its
practical deployment. The HCC improves upon this, by directly solving for desired forces
at each wheel patch instead. As a result, tire models and associated slip ratios do not
need to be considered in the analytic solution. Ultimately, lower control loops using force
estimation or motor torque feedback may be used to carry out desired forces. The evolution
of this work was first proposed by a GM patent in [17], and elaborated upon in [15] and
[1].
4
The main objective function used in the HCC may be solved analytically, or numerically with bounded constraints on the solution. Several options exist for solving constrained
optimization problems, including interior point methods [20], active-set methods [18], augmented Lagrangian methods [9], trust-region reflective methods [28], and other gradient
methods [29]. In this thesis’s implementation an active set method was found to perform
best, given the speed and availability of third-party solvers.
In addition to vehicle dynamics, a practical vehicle controller may also need to integrate
other considerations, such as actuator fault tolerance, or energy use optimization. This is
the point at which no unified controllers in literature have been found to provide all of the
aforementioned features.
For example, [16] specifies a target function to optimize energy consumption for longitudinal and lateral motion. However, performance under low friction coefficient conditions,
and interaction with traction control algorithms are undefined. Similarly, [31] deploys a
piece-wise, condition based algorithm to decompose a non-convex motor efficiency map
into sub-regions for optimization. Due to its rule-based structure, the system is unable
to adapt for changing road friction limits, and stability problems may arise when ideal
assumptions are not met.
In the proposed HCC solution, a smooth numerical search is proposed instead, for a
range of possible front/rear distribution ratios at each instance in time. In this, motor
models predict the efficiency for each ratio. Dynamic weighting functions are described,
which shifts bias away from energy management and towards traction control as a function
of road friction coefficients.
As a result, the HCC described in the rest of this thesis constitutes a novel approach
to comprehensive vehicle controls, encapsulating a large number of control topics within a
single architecture and easily applied across a range of di↵erent scenarios.
5
1.2
Contributions
Within this thesis, focus has been given to my specific contributions, and the work applied
to each module to transform the HCC from a simulated theoretical work into a working
controller for a full sized vehicle. The work laid out is a snapshot of the vehicles and
their software structure, as presented to General Motors at their Milford testing facility
in October of 2013. Due to the large scope of this large project however, success would
not have been possible without contributions by my fellow lab mates. A summary of our
team’s logical division at this time is given below in Figure 1.2.
Andy Wong
-
Vehicle Build RWD
CANbus Interfacing
Controls Integration
Vehicle Simulation
Driver Feel Tuning
Track Test Validation
Traction Control
Fault Tolerance
DCI
Energy Management
HMI
Ayyoub Rezaeeian & Reza Zarringhalam
- Vehicle force and velocity estimation
Alireza Kasaiezadeh & Dhanaraja Kasinathan
- HCC formulation
- Numerical Solver Adaptations
Ehsan Hashemi & Jonathan Spike
- Tire Modeling & Road Classification
Kevin Cochran, Jeff Graansma, Adrian Neill
- Vehicle Builds
- General Maintenance
- Track Testing
Figure 1.2: Contributions
Numerous people have worked on specific aspects of the system before myself. Prior
to the Equinox, team members Alireza Kasaiezadeh, Abtin Athari, Ayyoub Rezaeeian
and Jonathan Spike applied initial versions of the HCC, DCI, vehicle estimation, and
tire estimation algorithms respectively on an older Opel hatchback platform using a GM
supplied code base, with the aid of Kevin Cochran. The first part of my work was to build
a new physical platform to alleviate the physical limitations of the Opel. The second part
was to design a new software structure that brought the Waterloo-developed modules into
a cohesive system for the first time. The final part involved developing solutions for things
that did not function as expected.
For the first (RWD) vehicle build, technicians Kevin Cochran and Adrian Neill gave me
help as we wired up retrofit components, and laid out the trunk space for interfacing to the
6
dSpace computer. Two base vehicle chassis which included the electric power trains were
purchased from AMP motors. Later, Je↵ Graansma designed a front motor mount for the
second platform and worked with Kevin to replicate the layout for our 4WD platform. For
physical testing, I got much help from our technicians Kevin Cochran and Je↵ Graansma
for booking the facilities, towing cars, and gathering data. For these tests, I designed the
dSpace control-desk HMIs used to debug and configure our vehicles with in real time.
In the context of full vehicle integration, I was responsible for the high-level integrated
vehicle control code, with help from Kevin Cochran for setting up signal flows, such as
the interfacing of test modules initially carried over from the Opel platform. CAN-Bus
network interfacing, Global-A security bypasses, and subsequent code layout changes were
performed by myself. Other contributions involve development of the Simulink code’s
CarSim simulation branch, which utilizes a model built by GM measurements to provide
virtual sensor feedback. Using this, I performed many full-vehicle simulations using GMspecified maneuvers to tune responses, and track/debug problems with lower-level function
blocks such as the estimators. I regularly updated this environment, and pushed it to lab
mates for the the purposes of virtual code validation before track days.
At the logical level, my contributions were motivated by requirements to showcase a
working car in real life, and the additional challenges that ensue. For example, initial
DCI modules exhibited instabilities, including oscillations due to filtering phase delays,
poor tracking of vehicle states, and path deviations due to sensor noise and integration
error. My contribution to the DCI involved the change to a stable reference model, the
implementation of an atemporal dead-band filter to avoid phase o↵sets and oscillation, and
shifting the architecture from yaw-moment control to that of a yaw-rate control in order to
solve rate-derivative noise sensitivity and steady state errors. Related to the DCI was driver
feel tuning which also fell under my responsibility. In this, I utilized track days to tune
vehicle model parameters and pedal mappings to achieve desirable vehicle responsiveness.
Along these lines, I also simulated the feel of an automatic transmission inside the car
using mapped electric creep torques to achieve user expectations of a ”normal” feel.
The HCC approach was initially provided by GM, and modified by Saber Fallah and
Alireza Kasaiezadeh. As such, parts of the initial mathematical formulation, and literature references contained in this thesis are shared with these authors due to the common
background. In its original format, tire force estimations from Ayyoub Rezaeeian and Reza
Zarringhalam were combined with road friction values from Ehsan Hashemi and Jonathan
Spike to draw tire limit ellipses. Stacked estimation errors led to inaccurate calculations
however, and slip control was unsuccessful. My contribution in this regard was the implementation of a traction control system using a constrained numerical HCC formulation,
solved by an open-source solver configured by Dhanaraja Kasinathan. This di↵ered from
7
a simplified approach initially created by Alireza Kasaiezadeh, which removed the tire
ellipse completely and replaced it with independent PID loops at each wheel outside of
the HCC, operating o↵ wheel acceleration feedback. Rate-derivative noise from the wheel
encoders led to erratic performance in that case, and the uncoordinated wheel actions gave
undesirable net yaw moments as a consequence of overriding optimized HCC outputs. In
my contribution, the tire ellipse is maintained for operation within a tire’s grip margin,
so as to not interfere with regular control. Once limits are surpassed, a slip-based formulation a↵ecting the bounds within the HCC objective function corrects the o↵ending
wheels and redistributes torque to compensate for the control action. This was significant
in maintaining optimized, neutral yaw control even under dynamic maneuvers.
Additional contributions to the HCC involve the consideration of actuator torque limits,
which is a dynamic function of speed in electric motors. The original analytic formulation
had no provisions for this, and instead applied a constant penalty weight in the optimization
process to discourage actuation. Under harsh maneuvers, it is possible for the HCC to
request forces past deliverable limits, and saturation resulted in squarewave-like control
outputs that gave non-ideal behaviour. Under the new paradigm, motor data are used to
dynamically constrain desired corner forces, which resulted in smoother control requests
that follow the optimization process.
Motor limits also have a direct impact on fault tolerant control. An initial solution was
provided by Alireza Kasaiezadeh which shrank the dimensionality of an actuator contribution matrix within the objective function, followed by a doubling of torque request on
the failed side to maintain longitudinal force. This however, resulted in unwanted net yaw
moments due to errors between commanded and achievable motor forces. For example,
anything over a 50% throttle request would result in actuator saturation on the compromised side and led to yawing. Drivetrain asymmetry under fault exaggerates errors, and
resulted in oscillations about neutral yaw requests. My contribution in this area was to
utilize the constrained solver to specify faults as a reduced tire force bound, while governing
the remaining wheels with dynamic motor limits. This way, the formulation dimensionality
did not need to be changed, and all control outputs were achievable. As a consequence,
straight-line and dynamic performance under failed states were significantly improved.
Finally, the initial idea for the energy management feature arose from a study I performed while specifying possible motors for the platform. In this, it was determined that
longitudinal torque distribution was e↵ective in shifting peak motor efficiency points for
energy savings. Alireza Kasaiezadeh carried this procedure forward by creating a parallel
search algorithm to determine optimal distribution ratios at each instance of time. Integration into the HCC framework, vehicle simulations, and drive cycle simulations were
performed by myself.
8
Chapter 2
Integrated Vehicle Stability and
Energy Management Control
In the literature, individual aspects of vehicle dynamics have been widely studied, but there
have been a limited number of works which o↵er a practical, integrated control strategy that
considers all aspects of vehicle dynamics simultaneously. The integrated vehicle controller
outlined in this chapter proposes to alleviate this problem, with the control structure shown
in Figure 2.1.
A mathematical formulation for the control topology will be given, which optimizes
vehicle dynamics performance and energy consumption simultaneously. Broadly speaking,
two main components work together to provide a comprehensive, integrated vehicle control.
First, target vehicle states are output by the Driver Command Interpreter (DCI), which
uses a vehicle model to generate desired behavior. This model is compared against feedback
signals from the actual vehicle response. Error between the desired and feedback signals
are used to generate corrective signals, sent to the Holistic Corner Controller (HCC) for
actuation. The general HCC formulation accepts a target vehicle state (CG forces and yaw
moments) as input, and generates an output involving tire and suspension forces, or active
steering angles. At the time of this writing, the formulation has been physically tested on a
platform supplying 4 wheel independent drive with manual front steering. Without active
steering, the HCC is restricted from directly a↵ecting lateral forces, and thus performs
primarily in a torque vectoring mode to track desired yaw moments. An analytic general
solution for the optimization process, followed by a numerical solver approach to constrain
solution values is shown to provide a means of integrating traction control and actuator
limits within the objective cost function.
9
Driver Input
Throttle Position
Steering Angle
IMU
CG accelerations
Yaw Rate
State
Estimation
Vehicle Velocities
Driver Command Interpreter
(DCI)
Target Yaw Moment
Holistic Cornering Control (HCC)
State
Estimation
Tire Forces
Motor
Status
Actuator Faults
Wheel
Sensors
Tire Capacity
Wheel Constraints
Motor Limits
Wheel Speeds
Traction Control
Slip
Force Optimization
Motor
Model
Torque Request
ΔForces
Energy Optimization
Motor Efficiency
Redistributed
Torque
+
+
ΔTorques
Tire Radius
Combined Torque
Requests
Motors
Figure 2.1: Control Structure
10
2.1
2.1.1
Background Information
Vehicle Parameters
Information about parameters specific to the Equinox platform, and the definition of variables used in subsequent sections are provided below in Table 2.1.
Table 2.1: Vehicle Parameters
Vehicle Width
Vehicle Height
Vehicle Wheelbase
Front CG Distance
Rear CG Distance
Ground Clearance
Vehicle Mass(2WD)
Vehicle Mass(4WD)
Tire Radius
Rolling Resistance
Road Friction Coefficient
Drag Coefficient
Air Density
2.1.2
1.842m
1.684m
2.858m
1.42m
1.44m
0.198m
2047kg
2306kg
0.365m
0.02
0-1
0.36
kg
1.1839 m
3
w
h
L
a
b
c
m
m
ref f
µR
µ
Cd
⇢air
Vehicle Dynamics
The main motivation behind a vehicle stability controller is the minimization of slip, in
order to maintain the best possible tracking of any given driver input. A vehicle’s ability
to control the motion of its mass depends ultimately on its tires, and the amount of friction
force they can apply to the ground. To generate force, a tire requires slip, which can occur
in both longitudinal and lateral directions. A visualization in the longitudinal direction is
given below in Figure 2.2.
Here, slip is calculated as the proportion di↵erence between the hub and patch velocities,
and defined as:
S=
Vx,patch Vx,hub
max(Vx,patch , Vx,hub )
11
(2.1)
ω
𝑽𝒙,𝒉𝒖𝒃
𝑹𝒆𝒇𝒇
𝑭𝒛
𝑽𝒙,𝒑𝒂𝒕𝒄𝒉
𝑭𝒙
Figure 2.2: Simple Tire Mechanics
where Vx,hub would generally require direct measurement or estimation, and Vx,patch is a
simple rotational relationship, defined as Vx,patch = !Ref f . ! is the rotational velocity of
the wheel, and Ref f represents the e↵ective tire radius, which can marginally change due
to rubber compliance.
Meanwhile, longitudinal tire force FX is a function of both normal forces FZ , and the
road’s coefficient of friction µ, the maximum of which is defined as FX,max = µFZ . Three
longitudinal tire friction curves for di↵ering normal forces are given below in Figure 2.3 for
µ = 1, for the platform’s Michelin Latitude tires to show their general relationships.
12000
10000N
5000N
1000N
10000
Fx (N)
8000
6000
4000
2000
0
0
0.2
0.4
0.6
Slip Ratio
0.8
Figure 2.3: Longitudinal Tire Force Curve
12
1
It is seen that this tire’s response curve is linear for small slip ratios, but plateaus
and diminishes with increasing slip. If a tire slips beyond its peak grip threshold, a loss of
control is likely since diminishing tire forces lead to yet more slip. Therefore, a goal of ABS,
ESC, and other traction control systems is to keep tire slip within the linear region, such
that these run-away conditions do not exist and maximum usable tire forces are attained.
In lateral directions, slip is referred to in terms of slip angles, of which there are two. A
diagram showing a visualization of this slip occurring in conjunction with a steered angle
is shown below in Figure 2.4 for a simplified two-wheel bicycle model.
α
δ
𝑉
β
𝑉
𝑉
Figure 2.4: Lateral Slip Definitions in a Bicycle Vehicle Model
The first angle is , which applies to the body and defines the di↵erence between a
vehicle’s local orientation versus the actual heading of its center mass. Mathematically, it
is defined as:
✓ ◆
Vy
1
= tan
(2.2)
Vx
13
where Vx and Vy represent longitudinal and lateral components of vector Vheading , respectively.
The second angle, ↵, applies at the wheel level, instead of the body. Assuming the
wheel is steerable, it represents the total angle between this steered angle and the vehicle’s
velocity vector. Mathematically, it is defined as:
↵=
.
(2.3)
For cases where a wheel is non-steerable (such as in the rear), becomes 0, and ↵ = .
Ultimately, the lateral slip angle ↵ is used to generate lateral force. Figure 2.5 below
shows resultant lateral force curves for the tires used in this thesis, for three di↵ering
normal forces.
12000
10000N
5000N
1000N
10000
Fy (N)
8000
6000
4000
2000
0
0
5
10
15
20
Slip Angle (deg)
25
30
Figure 2.5: Lateral Tire Force Curve
In a relationship similar to the longitudinal case, forces are linear for small slip angles, and eventually plateau and diminish for greater slip. Of note is the X-axis, which
substitutes the longitudinal slip ratio with a lateral slip angle.
14
2.2
Driver Command Interpreter
A vehicle model in the form of a DCI is used to produce a target state for the HCC to
follow. The inputs to the DCI are steering wheel angles, driver torque/brake requests, and
current vehicle states. In general, the DCI translates these inputs into desired forces, yaw
rates and moments about the center of gravity (CG).
A 2 degree of freedom bicycle model as initially shown in Figure 2.4 was chosen for the
current HCC implementation, and coupled with a linear tire model to generate an ideal
yaw rate. In a linear tire model, forces are assumed to scale linearly with increased slip
angles ↵. This results in the lateral force FY , defined as:
FY = C↵ ↵
(2.4)
where C↵ represents the linear coefficient, also known as cornering sti↵ness.
Actual tire response, as seen in Figure 2.5, is nonlinear in high-slip conditions, and
leads to an error between the simple model and actual feedback. This discrepancy works
well as a target for the HCC, as it is assumed that the error would be corrected via the
HCC to realize an ideal vehicle response.
Vehicle performance is greatly a↵ected by tuning the cornering sti↵ness, due to its
impact on feed-forward control. A single term known as the understeer coefficient encapsulates the impact of cornering sti↵ness on a bicycle model, and is defined as:
Kus =
mb
LC↵f
ma
[19]
LC↵r
(2.5)
where a represents the distance from CG to the front axle, b the distance from CG to the
rear axle, and L the total wheel base. m represents the vehicle mass, and independent
values for the front and rear cornering sti↵ness are defined via C↵f and C↵r respectively.
This coefficient plays a major role in the model’s desired steady state yaw rate, defined as:
rd =
Vx
L + Kus Vx2
(2.6)
where in this case refers to the front steered angle. By relating driver feel to Kus ,
vehicle stability and response may be easily tuned. In general, a negative Kus results in
an oversteering vehicle, while a positive value results in understeer. As speeds increase,
an oversteering vehicle will tend to yaw more in response to a steering input, increasing
the likelihood of a spin-out. An understeering vehicle on the other hand, will become less
15
sensitive, resulting in a safer but less responsive trajectory. Yaw gain is a useful term in
explaining the di↵erence between these two situations, and represents the yaw rate output
per degree of steered input. Mathematically, this is defined as:
rd
=
Vx
.
L + Kus Vx2
(2.7)
A visualization of this term’s influence is shown below in Figure 2.6, which plots the
vehicle yaw gain for two Kus values over a range of speeds. Here, a sample value of 0.001
is used to represent the positive Kus case, while a value of 0.001 represents the negative
Kus case.
35
Kus < 0
Kus > 0
Yaw Gain (r / δ)
30
25
20
15
10
5
0
0
50
Speed (km/h)
100
150
Figure 2.6: Yaw Gain Response Comparison
It is seen that the Kus < 0 line becomes divergent and unstable as velocities rise. The
Kus < 0 line on the other hand, displays an increasingly dulled response, indicating a safe,
understeering car suitable for mass consumption. In the Equinox, the DCI was tuned to
match vehicle performance on dry roads as closely as possible, and resulted in a positive
Kus value as per from the factory.
At this point, it should be noted that yaw rates are output from the model, while the
HCC requires yaw moment as the input. As such, the tracking of an ideal yaw rate requires
an intermediary controller. There are two major motivations for doing this.
Firstly, the stock commercial IMU only provides yaw rate signals for feedback. Earlier
versions of the DCI attempted to use the time derivative of this for moment feedback,
16
but high-frequency sensor noise causes particularly large spikes in the resulting values.
Smoothing filters may be applied, but they incur time delays which lead to laggy response
and controller oscillation.
Secondly, a pure moment-based controller is subject to steady-state errors which are
only correctable by tracking its integral over time, which is once again the rate. These
reasons combined, led to the selection of a rate-based feedback system coupled with a
reliable proportional controller to command the HCC. Added to the proportional controller
is an adjustable dead-band function centered around zero to further attenuate unwanted
actuation due to road noise or small disturbances. The yaw moment output of this filter,
Gz , is defined as:
|edci |
, where
kd + |edci |
rf b .
Gz = kg edci
(2.8)
edci = rd
(2.9)
Here, edci is the controller error, while rd and rf b are the desired and measured feedback
yaw rates respectively. kg is the yaw moment controller gain, and kd is a constant controlling
the amount of dead-band.
After physical tuning, a dead-band coefficient kd = 0.1 was applied to Equation (2.8),
resulting in the response curve shown below in Figure 2.7. To enhance performance under
faulted actuator conditions however, this dead-band is disabled in order to enhance the
correction of small yaw deviations, ensuring that the vehicle remains in a straight line.
1
Deadband Gain
0.8
0.6
0.4
0.2
0
−10
−5
0
Yaw Error (rad/s)
5
Figure 2.7: DCI Deadband Function
17
10
2.3
HCC Formulation
Generally, a ground vehicle has four corners, each of which have longitudinal, lateral and
normal forces. Longitudinal forces can be controlled via drive motors and brakes, while
lateral forces can be influenced by steering angles or force di↵erentials about the center
line (ie. torque vectoring). First, a general vector defining all tire forces may be defined
as:
f = [Fx1 , Fy1 , Fz1 , Fx2 , Fy2 , Fz2 , . . . , Fx4 , Fy4 , Fz4 ]
(2.10)
where Fxi , Fyi , Fzi are the longitudinal, lateral and normal tire forces respectively, at each
corner i = {1, 2, 3, 4}, defined by the corner numbering shown below in Figure 2.8.
𝑭𝑿𝟏 + ∆𝑭𝑿𝟏
Fy
Fx
1
𝑭𝒀𝟏 + ∆𝑭𝒀𝟏
𝑭𝑿𝟐 + ∆𝑭𝑿𝟐
𝑭𝒀𝟐 + ∆𝑭𝒀𝟐
Gz
𝑭𝑿𝟑 + ∆𝑭𝑿𝟑
𝑭𝒀𝟑 + ∆𝑭𝒀𝟑
2
3
𝑭𝑿𝟒 + ∆𝑭𝑿𝟒
𝑭𝒀𝟒 + ∆𝑭𝒀𝟒
4
Figure 2.8: Force Conventions
It is implied that longitudinal augmenting forces FX are provided by motor torque,
while lateral forces FY are provided via steering angles. Let there be a vector f which
represents these overlay forces in the same format as vector f , namely:
f = [ Fx1 , Fy1 , Fz1 , Fx2 , Fy2 , Fz2 , . . . , Fx4 , Fy4 , Fz4 ] .
18
(2.11)
Meanwhile at the body level, the main purpose of the HCC is to minimize error between
target and actual vehicle forces. To determine this error, let there be a feedback state vector
F , and target vector F ⇤ of the same format for forces at the body level. These take the
form:
⇤
⇥
F ⇤ = Fx⇤ , Fy⇤ , Fz⇤ , G⇤x , G⇤y , G⇤z
(2.12)
F = [Fx , Fy , Fz , Gx , Gy , Gz ]
(2.13)
where Fx , Fx⇤ are the longitudinal forces, Fy , Fy⇤ are the lateral forces, Gx , G⇤x are roll
moments, Gy , G⇤y are pitch moments, and Gz , G⇤z are yaw moments, all about the CG.
In the current case where the vehicle does not have an active suspension to control pitch
and yaw, these vectors may be shortened by removing the elements that these actuators
a↵ect, resulting in the forms:
⇤
⇥
F ⇤ = Fx⇤ , Fy⇤ , G⇤z
(2.14)
F = [Fx , Fy , Gz ]
(2.15)
which has the net e↵ect of reducing the formulation’s dimensionality, but not the overall
format of the optimization procedure.
For feedback, let the error between desired and actual forces be defined as E, where:
E = F⇤
F.
(2.16)
Adding the impact of an overlay torque dictated by f produces a projected error term
Ep , defined as:
Ep = F ⇤ F (f + f )
(2.17)
and approximated via a first order taylor series as:

dF
⇤
F+
Ep ⇡ F
df
dF
⇡E
f.
df
f
(2.18)
(2.19)
Assuming that a control action vector f exists which drives E towards 0, optimal
values for each element of f may be solved using a cost function P , defined as



1
1
1 T
T
f Wm f +
(f + f )T Wf (f + f ) .
(2.20)
P = Ep WE E p +
2
2
2
19
Here, three terms are given, each with a di↵erent weight. The first term considers the
vehicle force tracking error, weighted by WE . The second term is used to weigh the energy
consumption needed to apply f , and is weighted by Wm . The third term considers actuator limits, and is weighted by Wf . More detailed information on the weighting structure
is given subsequently in Section 2.3.1.
In determining the error term Ep , dFdf(f ) is a Jacobian matrix since the body-level force
F and the tire-level force f are both vector fields. For simplification, this matrix will be
called AF henceforth. In the general case, it is defined as:
3
2 dFx
dFx
. . . dF
dFx1
z4
6
.. 7
...
AF = 4 ...
(2.21)
. 5
dGz
dFx1
...
dGz
dFz4
where each element can be derived using equations of vehicle motion. These link the
relationship between CG and tire forces, and follows the dimension of feedback vectors
F and F ⇤ . In the current case where the car is controlled in 2 dimensions, the motion
equations are:
Fx =
Fy =
4
X
i=1
4
X
[Fxi cos( i )
Fyi sin( i )] ,
(2.22)
[Fxi sin( i )
Fyi cos( i )] ,
(2.23)
i=1
Gz = a
X
i=1,2
+
[Fxi sin( i ) + Fyi cos( i )]
w X
[Fxi cos( i )
2 i=2,4
b
X
i=3,4
Fyi sin( i )]
[Fxi sin( i ) + Fyi cos( i )]
w X
[Fxi cos( i )
2 i=1,3
Fyi sin( i )] .
(2.24)
By substituting Equations (2.19) and (2.21) into Equaton (2.20), the objective function
becomes



1
1
1
T
T
P = (E AF f ) WE (E AF f ) +
f Wm f + (f + f )T Wf (f + f ) .
2
2
2
(2.25)
Using this cost function, the optimal f is a vector such that the cost function P is
minimized. Assuming the weight matrices WE , Wm , and Wf are selected such that the
20
objective function P remains positive definite, then P is minimized when:
dP
= 0.
d( f )
Isolating for
forces, namely:
(2.26)
f results in the final analytic solution for solving the required overlay
f = [Wf + Wm + ATF WE AF ] 1 [ATF WE E
Wf f ].
(2.27)
For actuation, these forces may be multiplied against an e↵ective tire radius to determine
motor torque requests. The e↵ective tire radius is currently assumed to be a constant value,
although minor deflection may be seen under harsh scenarios. In these cases, tire model
estimation may be used to determine the dynamic value, and remains as an opportunity
for future work.
2.3.1
Weight Selection
The primary HCC formulation denoted in Equation (2.27) contains matrices that are multiplied against the weights WE , Wm , and Wf . Respectively, these will be referred to as
weights for the first, second and third terms.
First Term
The first term, controlled by WE , applies to the vehicle CG’s force tracking error, and
is applied against the error signal. In the two dimensional case, this becomes a diagonal
matrix,
WE = diag [WFX , WFY , WGZ ]
(2.28)
where each element WFX , WFY , WGZ weighs the corresponding axis present in the error
vector E.
Second Term
The second term in the HCC equation deals with actuator e↵ort, and is governed by Wm .
This term attempts to save energy, by preventing excessive use of actuators. The format of
this weight is a diagonal matrix, and is dependent upon the dimensionality of force vector
f . In the 2 dimensional case, this becomes:
Wm = diag [Wx1 , Wx2 , Wx3 , Wx4 ]
where each element corresponds to one of the corner actuators.
21
(2.29)
Third Term
The third and final term is Wf . In a general sense it prevents control actions past physical
limits; in the planar 2D case, it limits tire forces to be within traction limits. Unlike the
other weights, Wf is a dynamic function, and in the planar case considers friction capacity.
Here, each component of the diagonal matrix Wf is magnified dramatically when requested
forces approach limits, such that it functions as a penalty term. Wf follows the size of the
tire force vector f , and in the 2D case is a diagonal matrix of the form:
Wf = diag[wf (⇢21 ), wf (⇢22 ), wf (⇢23 )wf (⇢24 )]
(2.30)
where ⇢i is a normalized indicator of tire utilization, with i = {1, 2, 3, 4} acting as an index
for each wheel. ⇢i is equal to 1 when fully saturated, and 0 when completely unloaded.
The values of ⇢i may be calculated via a friction ellipse concept as:
◆2 ✓
◆2
✓
Fxi
Fyi
2
+
(2.31)
⇢i =
Fxi,max
Fyi,max
where µx and µy are the road friction coefficients in the X and Y directions respectively,
Fxi,max = µx Fzi , and Fyi,max = µy Fzi .
Figure 2.9 shows a sample function for wf (⇢2i ), which shows a desirable steep incline as
tire utilization reaches its upper limit. At low utilization, the weighting function should
remain small so as to not interfere with other terms in the objective function.
50
Wf(ρ2i )
40
30
20
10
0
0
0.2
0.4
ρ2i
0.6
0.8
1
Figure 2.9: Proposed Weighting Function for wf
22
2.4
Numerical Extensions
The HCC formulation up until this point is solvable from a purely analytic point of view,
and provides an excellent baseline for an integrated torque vectoring application. Recall
from Section 2.3.1 that the closed form solution required a dynamic weighting function
to penalize actuation as a function of tire utilization. While this works for its intended
purpose, one compromise is that an aggressive profile may result in control chatter, while a
weak function may not penalize the objective function enough to prevent exceeding traction
limits.
A numerical approach to solving the generalized equation on the other hand, o↵ers the
advantage of explicitly constraining the solution to stay within allowable friction limits at
each wheel, without any interference if the operating point is within bounds. Dynamically
setting constraints below the traction limit may also be used for other purposes, such as
limiting motor output for energy savings, or dealing with partial actuator failures.
To utilize a numerical solver, the HCC formulation must first be converted into a
standard quadratic programming problem [3], of the form:
1
min xt Hx + g t x,
x 2
where x denotes the unknown tire force control vector,
of the HCC formulation then results in the matrices:
(2.32)
f . A full generalized conversion
H = Wf + Wm + (ATF WE )AF
⇥
⇤
g = 2 ATF (WE Ep ) Wf f
(2.33)
(2.34)
where H is the Hessian matrix, and g is a vector containing the remaining linear terms.
As described in Section 2.3.1, weight matrices Wf and Wm correspond to tire friction
and actuator e↵ort considerations. In the extended numerical solution, both may be implemented via solution bounds instead, and the terms removed to result in the simplified
matrices:
H = (ATF WE )AF
⇥
⇤
g = 2 ATF (WE Ep )
(2.35)
(2.36)
where hessian matrix H is positive definite (H > 0). This is a convex minimization problem
[3], and guarantees the existence of a unique solution. This, in turn can be solved using
an iterative procedure [29].
23
The controller design objective in HCC leads to a quadratic programming problem
which has a closed-form solution. Mathematically, a linear constraint is a convex function.
Since both the quadratic programming problem and the linear constraints are convex in
nature, the quadratic programming problem subject to linear constraints is also a convex
problem [3]. Theoretically, such a linearly-constrained quadratic programming (LCQP)
problem has a solution and is unique. On the HCC, this becomes:
1
min xt Hx + g t x
x 2
s.t. BL  x  BU
(2.37)
(2.38)
where BL and BU are (n⇥1) matrices denoting the lower and upper bound on wheel torque
limits respectively, where n is the number of actuated wheels.
The experiments in this thesis used an active-set solver, with constraints on the output
of each wheel set as an upper and lower bound torque. By constricting or expanding
this bound, secondary factors are able to a↵ect the HCC solution within the loop. These
include dynamic tire limits, motor output limits, faulted actuator limits, and traction
control loops. To use the limits derived from each of the aforementioned modules, the
lowest value is selected and pre-existing tire forces are subtracted to determine remaining
margins. The bounds become:
⌘
⇣
f ault
slip ub
mot
tire
BU,i = min Fxi
Fxi
, Fxi
, Fxi
, Fxi
(2.39)
⇣
⌘
f ault
slip lb
mot
tire
BL,i = max
Fxi
, Fxi
, Fxi
, Fxi
(2.40)
Fxi
f ault
slip
mot
tire
and are now completely defined for Equation (2.37), with Fxi
, Fxi
, Fxi
, and Fxi
representing the limits determined by actuator faults, slip ratios, motor limits, and tire
utilization respectively. The derivations of each limit are given in the sections below.
2.4.1
Tire Capacity
The primary consideration for each wheel’s torque limit comes from tire capacity, and the
need for each wheel to stay within its friction ellipse. At each wheel, the tire’s operating
limits are:
max
Fxi
= µx Fzi
max
Fyi = µy Fzi
24
(2.41)
(2.42)
max
where Fxi
and Fyimax represent the limits along the major X and Y axes respectively. µx
and µy represent the coefficients of friction with the road along each respective axis, and
Fzi is the vertical tire force at the contact patch. The allowable bounds using an ellipse
model then become:
s
Fyi 2
tire
max
Fxi
= Fxi
1
.
(2.43)
Fyimax
2.4.2
Motor Limits
An explicit constraint on requested wheel torque allows for the consideration of electric motor limits, which can vary as a function of speed. In the HCC’s analytic form, motor limits
are handled by the Wm weight, which penalizes actuation. However, torque availability is
not linear in electric motors, as shown below in Figure 2.10.
250
Torque (Nm)
200
150
100
50
0
0
2000
4000
6000
8000
Speed (RPM)
10000
12000
Figure 2.10: Electric Motor Curve
As a consequence, a static weight may result in unattainable requests as speeds rise.
Given the numerical formulation however, this limit may simply be expressed as a dynamically changing function of RPM. This is defined as:
mot
Fxi
=
Tmax (rpm)
Ref f
(2.44)
where Tmax represents the peak available motor torque as a function of RPM. In a practical
application, this may be attained via a lookup table, or generated via a piece-wise analytic
function to account for the nonlinear transition point. Meanwhile, Ref f is the e↵ective tire
radius.
25
2.4.3
Drivetrain Reconfiguration and Fault Tolerance
Related to motor torque availability is drivetrain reconfiguration and fault-tolerant torque
vectoring, where power delivery may be compromised due to failed or missing actuators. In
the analytic HCC solution, actuators are removed as rows and columns from the Jacobian
matrix shown in Equation (2.21), which leads to an on/o↵ condition at that corner. Solving
the HCC formulation with constraints however, provides a solution for partial actuator
failure cases, where diminished torque delivery is still possible.
The detection of failed actuators and their remaining capacity is assumed to be known,
and the bound may simply be set to the limit,
f ault
Fxi
=
Ti,f ailed
Ref f
(2.45)
where Ti,f ailed is the remaining capacity on the motor. For total failures, this element would
be 0. Ref f , meanwhile is the e↵ective tire radius.
To reconfigure the control formulation for FWD cars for example, the rear actuators
could simply be given a bound of 0, facilitating easy transport of the controller between
chassis configurations.
2.4.4
Traction Control
Anti-lock Brake Systems (ABS), Traction Control Systems (TCS) and Electronic Stability
Control (ESC) are examples of less complex control systems that are widely used on cars
to prevent wheel slip [25]. In such systems, a simple structure measures signals such as
wheel speeds and wheel acceleration to detect slip. Once detected, various forms of power
reduction or active braking takes place.
The HCC formulation lowers torque away from saturated wheels to remain within the
tire ellipse, which is similar to the function of conventional traction control and stability
systems. However, in practice, there may be delays or errors in the estimation of tire forces,
which then requires a robust means of correction if limits are surpassed. To accomplish
this, feedback from a lower wheel control loop is brought back into the objective function
to maintain overall yaw tracking and prevent controller conflicts. The interface for this is
through the bound vectors, BL and BU from Equation (2.38).
In ABS, brake actuation is pulsed when slip is detected, and uses a bang-bang type
approach to utilizing the tire at its limits. This bang-bang approach to control is not
26
ideal, as the tire is allowed to pass limits before correction is applied. At the same time,
the driver feels an unpleasant pulsation. In the HCC, a continuous controller is proposed
instead, providing for smoother vehicle response.
Firstly, a velocity di↵erential between the hub and patch speed is defined as a threshold
before actuation, defined as:
Si,limit = |Ks max(Vxi,hub , Vxi,patch )|
(2.46)
where Ks is a tunable constant representing the permissible percentage of slip. Typically,
values between 0.1 to 0.2 are used as this represents the linear tire region, and is where
peak tire force lies. Wheels i exceed the slip threshold when
|Vxi,patch
Vxi,hub | > Si,limit ,
(2.47)
Vxi,patch Vxi,hub
.
max(Vxi,patch , Vxi,hub )
(2.48)
in which case, slip may be calculated as:
Si =
The maximum and minimum allowable tire force in each direction may then be modified,
by implementing a proportional controller to constrict the bounds. The limits then take
the form:
max2
max
Fxi
= Fxi
min2
Fxi
=
max
Fxi
Si P
Si P
(2.49)
(2.50)
max
is the state estimated limit from Equation
where P is a tunable proportional gain and Fxi
(2.41) needing adjustment. In theory, a similar approach could be used to constrict tire
limits in the lateral direction as well, given a lateral slip angle. However from a practical
sense, lateral velocity estimators would be required to derive the slip angle. In deployment,
these estimators often incur processing delays or absolute inaccuracies, which can cause
unwanted control actions. A purely wheel speed based longitudinal approach, while not
optimal, has the benefit of direct measurement feedback via wheel encoders.
Acknowledging this, an ellipse model may be used to determine maximum longitudinal
tire forces, defined as:
s
Fyi 2
max2
✏pos = Fxi
1
(2.51)
Fyimax
s
Fyi 2
min2
✏neg = Fxi
1
(2.52)
Fyimax
27
where ✏pos and ✏neg define the positive and negative limits respectively.
Depending on the amount of slip, the modified limits may exceed deliverable forces by
the motor. To alleviate this e↵ect, a saturation is implemented to cap each bound within
motor limits. These bounds are defined as:
⇤
⇥
mot
mot
✏adj
(2.53)
pos = max min(✏pos , Fxi ), Fxi
⇥
⇤
mot
mot
✏adj
(2.54)
neg = min max(✏neg , Fxi ), Fxi
adj
where ✏adj
pos and ✏neg represent the positive and negative saturated values, respectively.
Finally, a check is applied to ensure that the bounds do not surpass each other in the
wrong direction, and the entire range is o↵set by the feed-forward driver requested force
to determine remaining margin. Mathematically, these bounds are defined as:
slip
Fxi
slip ub
slip
where Fxi
and Fxi
control, respectively.
2.5
lb
ub
adj
= max ✏adj
pos , ✏neg
Fi,driver
(2.55)
slip lb
Fxi
adj
✏adj
pos , ✏neg
Fi,driver
(2.56)
= min
are the final upper and lower bounds determined from traction
Energy Management Formulation
A vehicle traveling on the ground is generally subject to several major forces which the
motors have to overcome. These are defined as:
⇢air Cd w(h c)Vx2
2
Fr = µR mg
Fd = max
Ft = F a + F r + F d
Fa =
(2.57)
(2.58)
(2.59)
(2.60)
where Fa is air resistance, Fr is tire rolling resistance, and Fd is the requested acceleration
from the driver. At any moment in time, the total force output is Ft , which is the sum of
all resistances and accelerations. This total force may be converted to a required torque,
defined as:
Ft
Tt =
(2.61)
ref f
28
where (ref f ) is the e↵ective tire radius. Let this total torque be split in a 4WD system,
such that:
T t = T f + Tr
(2.62)
where Tf and Tr represents hypothetical front and rear axle torques respectively. Let the
distribution between the front and rear axles be defined as:
⌫=
Tr
T f + Tr
(2.63)
where ⌫ is a set of values which encompass a range of possible front and rear values. Each
element in this set is ⌫n 2 {0, s, 2s, . . . , 1}, with s representing an incremental step size
between 0 and 1. Meanwhile, n represents the index of a particular element. The front
and rear torques for each index may then be calculated as:
⌫n Ft
, and
ref f
(1 ⌫n )Ft
=
.
ref f
Tf,n =
(2.64)
Tr,n
(2.65)
Assuming for symmetry, the per-motor torques are simply half that of each axle. Permotor efficiency has been demonstrated to vary with requested torque, and may be defined
as ⌘f,n and ⌘r,n for the front and rear motors respectively. The total efficiency, ⌘t,n is then
defined as:
◆ 1
✓
Tf,n Tr,n
⌘t,n = (Tf,n + Tr,n )
+
(2.66)
⌘f,n
⌘r,n
⌘f,n ⌘r,n
.
(2.67)
=
(1 ⌫n )⌘r,n + ⌫n ⌘f,n
2.5.1
Energy Management Algorithm
In electric motors, the surface representing motor efficiency is a nonlinear function of torque
and rotational velocity, with no guarantee that the objective function would be convex.
This is a problem for optimization, as it prevents the use of an analytic solution.
To overcome this, a lookup table is used to accurately represent the surface instead,
a common approach in applied engine controls for other areas such as fuel mix ratios or
transmission shifting. Multiple efficiencies may be predicted at the motors’ instantaneous
29
operating speed, using a set of possible distribution ratios (⌫). Since the number of data
points representing motor torque, speed and efficiency are bounded, search times are also
bounded and practical for real time control purposes. A profile for the motors used in the
Equinox is provided in Figure 2.11.
100
225
Torque (Nm)
175
80
125
75
60
25
−25
40
−75
−125
20
−175
−225
2000
4000
6000
8000
10000
12000
0
Motor Speed (RPM)
Figure 2.11: Engine Efficiency Map
This efficiency chart is indicative of a typical electric induction motor; the maximum
deliverable torque fades at higher speeds, and the efficiency varies over its range of operation. The deviation in this case involves a peak efficiency of 95.5% near the surface
centroid, and below 50% at the outer limits of the performance envelope.
In this project’s implementation, ⌫n is incremented from 0 to 1 in a step size s of 0.05.
In theory, any reasonable step size may be used, but this value was chosen after testing
showed that smaller step sizes resulted in diminishing returns since increasingly smaller
amounts of torque is distributed.
For each ⌫n , ⌘f,n and ⌘r,n are attained using the table shown in Figure 2.11. Equation
(2.67) is used to determine the net projected efficiency ⌘t,n for each ratio ⌫n . The optimal
ratio is defined as:
⌫ opt = ⌫n |max(⌘t,n ).
(2.68)
If identical motors are assumed for all corners of the vehicle, there may be cases where
a tie occurs between a front or rear-biased ratio, due to a symmetry around ⌫ = 0.5. In
such cases, the tie may be broken by placing more torque on the wheel with highest tire
30
capacity, thereby reducing the amount of slip and thus wasted energy. Parameters useful
in determining this include vehicle pitch, longitudinal acceleration, roll angle, or vertical
tire forces. In the current implementation, an IMU is used to give a rear-biased preference
for acceleration cases, and forward-bias for braking.
An example is hereby given for a straight-line acceleration, starting with a vehicle speed
of 60 kph. The pedal input is sinusoidal to provide a range of requested torques, as shown
in Figure 2.12a. As speeds increase, the operating efficiency of the motors vary. On the
Equinox, a step size of 0.05 is used to search through the [0-1] range of possible distribution
ratios, resulting in 21 indices. For demonstration purposes, the full set of efficiency curves
is shown below in Figure 2.12b. Selecting for the most efficient scenario, the optimized
ratios are shown in Figure 2.12c. Of note is the fully rear-biased efficiency’s drop to 0,
which represents the inability of two motors to fully deliver the load requested of a 4WD
system. Thus, the solver is forced into a ratio of 0.5 to share the work. When loads are
lower, it is seen that the ratio of 1.0 enjoys a higher efficiency at the 5-6s, and 8-9s marks.
The system then selects for the rear-biased acceleration. Points between these events may
be assumed to lie within the spectrum, leading to a gradual blend between these two ratios.
31
Gas Pedal Input (%)
100
80
60
40
20
0
1
2
3
4
5
6
Time (s)
7
8
9
10
7
8
9
10
(a) Pedal Input
Overall Efficiency (%)
120
100
80
60
40
20
0
1
2
3
4
5
6
Time (s)
(b) Set of Overall Efficiencies for Compared Ratios
2
Ratio
1.5
1
0.5
0
1
2
3
4
5
6
Time (s)
7
8
9
10
(c) Optimal Ratio
Figure 2.12: Sinusoidal Throttle Input and Resulting Efficiencies
32
2.5.2
Friction considerations
The primary mode of actuation in this algorithm is the redistribution torque to more
heavily load one axle, such that the motors operate in higher efficiency region. However,
traction limits may at times prevent this torque from being delivered, and instead result
in tire slip.
To combat this, the search space may be constricted as a function of tire capacity,
which fluctuates. This may be done by checking against current road friction and normal
tire force estimators. Knowing this information, the upper bounds on transmissible torque
per axle can be determined as:
Tfbound = µ(FzF L + FzF R )ref f
(2.69)
Trbound = µ(FzRL + FzRR )ref f
(2.70)
(2.71)
where Tfbound and Trbound are the front and rear axle motor limits, respectively. FzF L , FzF R ,
FzRL , and FzRR are the front-left, front-right, rear-left, and rear-right normal tire forces
respectively. A limiting axle is present, defined as:
bound
Tmin
= min(Tfbound , Trbound ).
(2.72)
This limiting axle is used to calculate the proportion of transmissible torque versus
total requests, and defined as:
2T bound
W = min .
(2.73)
Tt
This weight is then used to constrict the search space, resulting in the term:
⌫ adj = (2W
1)⌫ + (1
W ).
(2.74)
⌫ adj may then be used in the place of ⌫ to find the optimal value as defined in Equation
(2.68). It should be noted that even a constriction to 50% distribution may result in
individual tire capacities being surpassed, given sufficiently low friction and high driver
requests. One assumption made with this algorithm is that lower-level traction control
loops exist to prevent tire slip, and therefore returning the torque distribution to a neutral
front/rear bias best prepares the car for peaceful coexistence with such systems.
This friction-based constriction is shown in a following example, whereby a pulsed driver
input is applied on to both a slippery and grippy surface. Figure 2.13a shows the requested
33
torque at one wheel, while Figures 2.13b and 2.13c show the allowable search spaces for
the two cases of µ = 0.3 and µ = 1.0 respectively. It is seen that a slippery road surface of
µ = 0.3 is too low to carry the requested torque, causing the algorithm to converge upon
the neutral state of ⌘ = 0.5 in preparation for a secondary traction control algorithm.
Motor Torque (Nm)
800
600
400
200
0
0
5
Time (s)
10
15
(a) Requested Motor Torque
Distribution Ratio(η)
1.5
1
0.5
0
−0.5
0
5
Time (s)
10
15
(b) At µ = 0.3, Range of ⌘ Contracts
Distribution Ratio(η)
1.5
1
0.5
0
−0.5
0
5
Time (s)
10
15
(c) At µ = 1, No constrictions
Figure 2.13: Comparison of Allowable Search Indices for Two Di↵ering Surface Frictions
34
Chapter 3
Platform Design
At the GM collaboration’s onset, a specific list of objectives were set for the vehicle test
platform. These were:
1. Investigate the specific advantages of independently driven electric 4WD in the SUV
class
2. Prepare an electrified platform for various control strategies
3. Benefit from an SUV’s larger storage space, and more apparent roll dynamics
4. Keep vehicle as close to production-state as possible
Given these requirements, the Chevrolet Equinox was chosen as an ideal candidate. As
a brief background, the Equinox features a unibody construction, MacPherson front struts,
multi-link rear suspension, an electric steering rack, and a hydraulic braking system.
The conversion of a production Equinox into an electric research test-bed can then
be separated into three main considerations - Mechanical (ie. packaging), Electrical (ie.
batteries and power electronics), and software (ie. signaling and controls). Overall, this
entails replacing the gasoline engine and tank with electric motors and batteries, and
designing a new control system which can interface driver inputs with the new actuators.
35
ries
3.1
System Layout
Ultimately, two sister SUVs were built, one as RWD and one as 4WD. The primary di↵erences in layout between these are shown below in Figures 3.1 and 3.2 below.
In the RWD Equinox, the batteries are separated into two compartments, one within
the front hood and the second in the gas tank cavity. The 4WD Equinox meanwhile,
has three battery compartments, due to the installation of motors and inverters in the
front hood space. As a result, the front battery was downsized, with the displaced cells
relocated to the trunk. A more detailed view of the supporting components is shown below
in Figure 3.3 for the 4WD model, while a logical layout of the interconnections between
these components is given below in Figure 3.4. Multiple electrical and hydraulic loops exist
in the platform. To cool the motors, Automatic Transmission Fluid (ATF) is constantly
circulated through each motor, while a separate glycol loop keeps the power electronics
dSpace
Batteries
Batteries
M
Electronics
Figure 3.1: RWD Equinox Layout
dSpace
Invert.
Batteries
Batteries
M
Electronics
Figure 3.2: 4WD Equinox Layout
36
M
Batteries
(AC inverters, DC-DC converter) within operating limits. Electrically, a high-voltage bus
powers the drive motors, while a 12v high-current bus powers regular vehicle electronics,
fans, and pumps.
Inverter
M
Inverter
M
Battery
DC-DC
BMS
Relays & Fuses
Inverter
Inverter
Battery
M
dSpace
M
Charger
Figure 3.3: Detailed Component Layout (4WD)
37
CHARGER
HLIM
ANDYBUS
BMS
ATF
300v
CUR_SEN
CELL BOARDS
RH
1
M
Front Pack Ign
RH
2
GLYCOL
300V
BATT
12V
BAT
M2
Glycol
Pump
PEDALS
GEAR
GM-CAN
BCM
Ign Relay
ADC
MASTER
dSpace
SENSOR BUS
ENABLE
STEERING
BOOST
I/O
GPS
ANDYBUS
DC-DC
(12v)
FRONT
FAN
M
M1
Ground Fault Relay
ATF
Pump
RELAY
DRIVERS
12v
GLYCOL
M3
M
M4
RH
3
RH
4
ATF
300v
Figure 3.4: Systems Layout
38
M
ATF
Pump
REAR
FAN
It is seen that a central component to the vehicle’s logical layout is the dSpace embedded
computer, which performs all processing for the custom code. The specific model used on
the platform is the dSpace Micro-Autobox II, which runs a real-time OS with code crosscompiled from a Matlab/Simulink environment. Relevant details of this machine involve
a 900 Mhz PowerPC CPU, 4 hardware-driven CAN interfaces, 80 input/output channels,
and 16-bit ADCs [10].
The dSpace takes in data from many sources for its computation, and it was decided
to centralize all CAN signaling and I/O in the trunk, as shown in Figure 3.5a. Here, the
dSpace can be seen in the upper right as a small aluminum box, while surrounding it are
industrial automation DIN rails which house connection blocks for I/O.
One feature of the dSpace system is its Control Desk software, which enables an
Ethernet-connected laptop to interface with the Micro-Autobox to acquire signals, and
adjust parameters for tuning. In the Equinox, a laptop is mounted to the passenger seat,
as shown in Figure 3.5b.
(a) Trunk I/O layout
(b) Vehicle Computer Setup
Figure 3.5: dSpace Hardware
At the software level, the Engine Control Module (ECM) was used as the primary
injection point for the dSpace to communicate with existing vehicle computers for sensors
and outputs. To accomplish this, three sockets were removed from the ECM, and redirected
to breakouts for the dSpace. Each of these connectors provide 73 signals normally meant for
ECM processing, and provides a convenient means of accessing physical sensors in addition
to the software buses. The original unit shown in Figure 3.6a was removed, and replaced
with breakout boards that routed relevant signals to the dSpace as shown in Figure 3.6b.
39
(a) Removed ECU
(b) Vehicle-Side ECU Dongles
Figure 3.6: Rewired ECU Dongles
The most important hardware signals from the ECM sockets are the pedal position
sensors, which are analog potentiometers. The voltages are passed through ADCs, and
translated into percentage values for torque actuation. A system bus wakeup pin is also
essential, as this provides dSpace synchronization during vehicle start. Transmission gear
positions on the other hand, are directly measured via a retrofit linear potentiometer, since
the transmission controller was also removed. A detailed layout of the software using these
signals will be provided in Chapter 4.
40
3.2
Components
The motors used in the Equinox are the HVH-250 models produced by Remy Corporation
[22], and were purchased from a company called Amp Motors, which provides custom
retrofit vehicles for the consumer market. The purchased modules placed two motors
back-to-back in a single cooling jacket, as shown below in Figure 3.7a. Figure 3.7b shows
in detail each motor’s low-profile planetary gear transmission, which provides a single-stage
8:1 reduction.
(a) AMP Motor Module [6]
(b) Closeup of Motor Gearbox
Figure 3.7: Drivetrain Components
Driving the motors are AC motor inverters positioned near the chassis center line,
controlled via CAN signalling. The specific models used are the PM100DX units produced
by Rinehart Motion Systems [37], as shown below in Figure 3.8a. These operate at up to
360v input, and up to 300A continuous draw. In the Equinox’s case, 356v DC is provided
by the battery pack, and each PM100DX’s 3-phase AC output is used to drive one motor.
A picture showing the inverter casing is shown below in Figure 3.8a.
The platform uses a set of air-cooled Lithium-Ion-Phosphate cells, produced by GBS
and shown in Figure 3.8b. 108 cells are used in the Equinox, connected in a single series
chain. Each cell provides a nominal voltage of 3.3V, a capacity of 100 Ah, and a peak
discharge rate of 10C. This combines to give the total vehicle a nominal pack voltage of
358V, and up to 1000A for the motors. The cells are reinforced with rectangular plastic
housings, which makes for easier pack building.
41
(a) AC Inverter Module [11]
(b) GBS 100Ah Cells [27]
Figure 3.8: High Voltage Power Systems
Each cell is connected to a monitoring board, which reports back to an Elithion Battery
Management System (BMS), which checks for voltage levels and internal resistance. During
charge cycles, these cell boards also have a small resistor to dissipate energy, and are used
in cell balancing. A current sensor located at the pack’s total output allows the BMS to
monitor discharge rates, and use coulomb counting to report usage and report state of
charge. The unit used in the Equinox is the Lithiumate Pro, produced by Elithion Inc. A
picture of this BMS is shown below in Figure 3.9a. To charge the cells, a power supply set
to the pack’s charging voltage provides energy to the pack. A relay controlled by the BMS
stops current flow during balance cycles, and re-enables during bulk charge. The charger
used in this project is the PFC-5000, produced by Elcon. A picture of this unit is provided
below in Figure 3.9b.
Much of the production electrical system ran o↵ a 12V lead-acid battery, charged in
turn by an alternator driven by the engine. Since the engine was removed, a DC-DC
converter is required to produce sufficient 12V for low power systems within the vehicle.
In the Equinox, a 2.2 kW model produced by Delphi corporation [12] is used. For starting
and initialization purposes, a lead-acid battery is still connected to the vehicle in parallel,
to supply power before dSpace initialization completes and turns on the DC-DC converter.
For validation, an Oxford Technical Solutions, RT2500 6-axis GPS/IMU [26] is used to
track vehicle forces and locations , and is mounted internally at the SUV’s CG as shown in
42
(a) Elithion Lithiumate Pro [13]
(b) Elcon PFC5000 Charger Unit [38]
Figure 3.9: Battery Charging and Management Systems
Figure 3.10a. To validate tire forces and moments around the wheel hub, a set of Michigan
Scientific MSCLW12.8 [8] load wheels are also mounted to the car, as shown below in
Figure 3.10b.
(a) Validation 6-axis GPS/IMU [26]
(b) Michigan Scientific Load Wheels
Figure 3.10: Validation Equipment
43
3.2.1
Physical Integration
The motor modules’ compact size enables it to fit within the space of the removed engine
components, as seen below in Figure 3.11 for the front sub frame, and Figure 3.12 for the
rear.
(a) Front Motor Packaging
(b) Side View, Front Motor Placement
Figure 3.11: Front Motor Packaging
(a) Rear Motor Packaging
(b) Rear Motor Subframe
Figure 3.12: Rear Motor Packaging
Powering the motors are the batteries, half of which are stored in the front of the car.
Figure 3.13a shows the front pack with the main ignition relay in the upper left, along with
one battery cover removed to show the internal wiring of the cell monitoring boards.
Immediately behind the front battery pack, high-voltage power lines are passed through
the chassis’s transmission tunnel, and routed along the main structural members rear-ward
as shown in Figure 3.13b.
44
(a) Front Ignition Relay
(b) DC-DC Converter Positioning
Figure 3.13: Front Vehicle Integration
The silver square in the middle of the picture is the liquid-cooled DC-DC converter
unit, with black glycol cooling lines connected to its top and bottom. To the left is a
high-voltage input, tapped o↵ the main battery line. In the middle-bottom is a safety
disconnect switch, which allows the battery pack to be physically disconnected for vehicle
servicing.
Continuing, the high voltage power lines are passed into a relay and fusing section
in the middle of the car, shown on the left in Figure 3.14a. These relays are controlled
via software, and provides power to the motor inverters. To the right of the picture,
the vehicle’s BMS is seen. The multiple grey wires leading into the box carry cell-board
communications in a channeled fashion, with each physical wire relaying information for
8-10 daisy chained boards. Behind the power relays are the rear motor inverters, as shown
in Figure 3.14b.
In the middle, the high-voltage distribution block is seen, which splits the main pack
voltage into three outputs for the two motor inverters and DC-DC converter. At the
bottom of each blue inverter, 3-phase wiring outputs are seen, which powers each motor.
The branched black hosing in this picture also shows the cooling loop, which provides
glycol for cooling the power switching electronics.
Behind the motor inverters lay the gas-tank battery, which can be seen as the large
silver box in Figure 3.15a. The mounted electric motor module can also be seen, as the
shiny cylindrical object behind the battery. An exploded view of the rear motor mounting
location is shown in Figure 3.15b.
45
(a) Relays and Fuses
(b) Inverter Layout
Figure 3.14: Vehicle Midsection
(a) Rear Underbody
(b) Rear Motor Mounting
Figure 3.15: Vehicle Rear
Finally, the back of the vehicle is shown in Figure 3.16a. An accessory pan was added
to provide extra mounting space under the vehicle, and holds the charger unit in addition
to a radiator and filter for cooling the motors, as shown in Figure 3.16b.
Despite the major retrofit conversions performed to the underbody, the vehicle’s interior
cabin was left mostly untouched. The only major modification of note to the driver cockpit
is an emergency stop as shown below in Figure 3.17a, which is directly wired to the primary
high-voltage battery relay to cut power in an emergency. The 6-axis IMU used for validation
purposes is mounted in the vehicle’s interior due to CG location as shown in Figure 3.17b,
but is completely removable as desired.
46
(a) Rear Pan
(b) Inside of Pan
Figure 3.16: Rear Accessory Pan
(a) Front E-Stop
(b) IMU Mounting Location
Figure 3.17: Vehicle Interior
47
Chapter 4
Software Design
The code was designed to be as modular as possible, to aid collaboration within the group
and also to aid in versioning and debugging of logical blocks. There are three main software
bundles:
1. Simulink Code for Logical Controls
2. Carsim Simulation Environment for Debugging
3. dSpace Control Desk for Physical Tuning
48
4.1
Simulink
The control code is created in Matlab-Simulink, cross-compiled to C code for execution on
the dSpace host for real time applications. The code is split into two main sections - a
component control level consisting of simple lower-level loops, and a high-level logic level
which includes the HCC. The HCC requires several supporting function modules, the data
flow of which is shown below in Figure 4.1.
Driver Input
MABX Input
Steer Angle
Brake Pressure
Motor Torque
IMU, Wheel Spd
Steering
BRFC
Wheel Forces
V X ,VY , r
Kinematic
Estimation
Tire Forces
IMU, Wheel Spd
Tire
Estimation
DCI
Pedal
ACPC
Desired Yaw
HCC
Pedal %
AWDC
Road μ
Redistributed
Torque
ΔTorque
TBC
Logic Level
Gear Position
Command Torque
Component Level
Dashboard
Data
Acq.
Cooling
Relays
Drive State
Motor CAN
Figure 4.1: Code Logic Flow
It is seen that flow at the logic level is data dependent, and thus requires a function
scheduler to trigger each block in a rational order to avoid data starvation. Details outlining
each of the logic-level blocks will be given in Section 4.1.1. The component level control
layer largely deals with direct hardware access via the dSpace embedded computer, and is
covered in Section 4.3.
49
4.1.1
Controls - Logic Level
This function block houses a bulk of the HCC intelligence, and represents the mathematical
processing of the control code.
ACPC (Accelerator Pedal Control)
The purpose of this block is to take in both redundant analog signals of the accelerator
pedal position, and compare their values to ensure that a faulty sensor does not result in
unintended acceleration. As output, a 0-100% representation of pedal actuation is given.
AWDC (All-Wheel Drive Control)
This module is responsible for the interpretation of desired driver torque, and handles feedforward distribution to the four wheels. Four functions covered within this module include
creep-torque generation, actuator fault tolerance, energy use optimization, and direction
setting based on gear selection position. A diagram showing the logic flow is shown below
in Figure 4.2.
Creep torque is a feature added to the system, in order to simulate the low-velocity
push that is often felt in automatic transmissions. This is done by adding a small pedal
percentage to the driver input, to trigger some movement to overcome stiction and create
minor movement. A piece-wise function was implemented as:
8
P D + CL ,
if Vx < VT 1
>
>
>
1
<P + C + (C
CL )(Vx VT 1 )(VT 2 VT 1 ) , if VT 1 < Vx < VT 2
D
L
H
PC =
(4.1)
>
P
if
V
D + CH ,
x > VT 2
>
>
:
PD ,
Otherwise
where CL and CH are low and high-speed creep constants respectively, VT 1 is the transition
speed at which the CL begins to ramp down, and VT 2 is the speed at which CH is reached.
PD is the original driver pedal input, while PC is resulting output to the system after
accounting for the creep. In cases where braking action is requested, this creep torque is
turned o↵ for pedal inputs of greater than 1%.
The main drive torque, meanwhile is a function of the each motor’s maximum available
torque, multiplied against the gas pedal’s percentage request. To enhance driver feel, a
non-linear pedal mapping was applied to the user input, as shown below in Figure 4.3a.
50
Power
Select
Driver Inputs
Gear
Select
Pedal
Creep
Torque
Generator
Motor
RPM
Pedal + Creep
Motor
Torque
Lookup
Pedal
Mapping
Desired %
Gear
Mode
Max Power
(kW)
Available
Torque
Wheel Torque Limiting
and
Distribution
Feed-Forward
Torques
Optimized
Torques
Energy Use Optimization
Direction
Setting
Out
Figure 4.2: AWDC Logic Flow
A sigmoidal function is implemented, which ramps response slowly for low pedal inputs
to make the car more controllable. Response improves in the middle of the range, and
eventually tapers o↵ for maximum acceleration. This is multiplied against each motor’s
maximum available torque, as shown in Figure 4.3b for the specific units used in the
Equinox.
Provisions for maximum power draw are also included, which compares the requested
power against a user-defined limit. In cases where this limit is exceeded, the maximum
value is divided against the number of active actuators to achieve saturation. The first stage
of fault tolerance also is taken into account by the AWDC, by zeroing torque requests to
51
250
80
200
Max Torque (Nm)
Mapped Pedal Output (%)
100
60
40
20
0
0
20
40
60
Pedal Input (%)
80
150
100
50
0
−50
100
(a) Pedal Mapping
0
50
100
150
Vehicle Speed (km/h)
200
250
(b) Maximum Motor Torque Curve
Figure 4.3: AWDC Mappings
failed corners. The total torque request is divided against remaining actuators until motor
limits are reached, to satisfy the requested longitudinal acceleration.
This feed-forward torque is then sent to the energy optimization routine covered in Section 2.5, which shifts the front-rear torque bias. Finally, the set of 4 torques are multiplied
against direction bits based on the current gear selection before being sent out of the block.
BRFC (Brake Force Control
This block provides a feed-forward predictor for tire torques. It consists of 4 parallel
branches representing each wheel, and sums motor torque feedback with a predicted brake
torque, using predefined lookup tables as shown below in Figure 4.4.
In the Equinox, there are larger brake calipers in the front as opposed to rear. This is
taken into account by using di↵erent tables for each axle, the values of which are shown
below in Figure 4.5. Of note is the maximum value in the front, which is exceeds maximum
motor torques at any speed; this is a good safety feature which guarantees the ability to
stop in case of emergency.
52
Figure 4.4: BRFC Block
Brake Torque (Nm)
3000
Front
Rear
2500
2000
1500
1000
500
0
0
2
4
6
Brake Pressue (mPa)
8
Figure 4.5: Brake Torques of Equinox Model
53
10
DCI (Driver Command Interpreter)
The DCI block consists of an embedded matlab function to represent the vehicle model
described in 2.2, with external modifiers to mainly a↵ect filtering of the feedback signals
as shown below in Figure 4.6.
Figure 4.6: DCI block
In the ”Faultmode Filter Override” function, the motor status array is monitored for
signs of failure. Once detected, a pre-defined backup filter mode is requested, along with
a new coefficient to nullify the deadband. The filter mode is passed onto the filter block
to apply the corresponding signal, while the dead deadband coefficient is implemented in
the main DCI block itself.
As output, the DCI generates values for the FX , FY , and GZ directions for reference,
54
as well as errors of all three for control purposes. As input, the orange values define
user-selectable parameters such as understeer coefficient, filter modes,creep torque transition points and controller gains. The green blocks meanwhile, represent configuration
parameters that are scripted and automatically loaded on a vehicle-specific basis.
Kinematic Estimation
The kinematic estimation blocks provide state feedback to the HCC, in the form of forces
and velocities at each wheel corner. Since these are not directly measurable from the
contact patch, estimation algorithms are used instead.
This function block is arranged in a cascade fashion, whereby each component is estimated individually and fed forward to generate other estimations. In total, five cascade
layers exist, and executed in the order of FZ , FX , FY , VX , VY .
Inputs to the system include the steering wheel input, IMU forces at the CG, wheel
speeds, and torques applied to each corner. Details of the algorithm may be attained in
[32] and [40]. In summary, a sprung mass model of the chassis is used to predict FZ forces
under roll and pitch conditions, while a dedicated wheel dynamics model estimates FX
using tire speeds and applied torque. These solved forces are then fed into another model,
and an Unscented Kalman Filter is used to predict for FY . Finally, VX is estimated based
upon measured wheel speeds, and all the available states are then used to solve for the
lateral velocity VY .
Tire Estimation
The tire estimation block’s main purpose in the HCC is to provide the system with an
estimate of road conditions. Of the most interest in literature is the LuGre tire friction
model, which replaces the tire surface with a series of small brushes, each with a sti↵ness
and coefficient of friction with the road [5]. As a brush encounters the ground, friction at
its tip generates a force that deflects its shaft. Since there is a spring sti↵ness associated
with this deflection, a reaction force is then created on the rim for propulsion. In the event
that deflection exceeds available friction, the brush is modeled by a sliding friction force.
By explicitly modeling the rubber sti↵ness in addition to its coulomb and static friction
with the ground, small elements can then be integrated over the contact surface to create
55
a final grip profile. The formulas governing a LuGre model are:
Vr = !r v
F = ( 0z +
1 ż
+
(4.2)
(4.3)
2 Vr )Fn
where F is the friction force, Fn the normal force, 0 the rubber sti↵ness, 1 the rubber
longitudinal damping, 2 the viscous relative damping, and Vr the relative velocity. z is
defined to be the deformation distance of the brush, the derivative of which is:
ż = Vr
0 |Vr |
g(Vr )
g(Vr ) = µc + (µs
Z, where
µc )e
|Vr /Vs |↵
(4.4)
.
(4.5)
Here, µc and µs are the Coulomb and Stribeck friction coefficients respectively, Vs the
Stribeck velocity, and ↵ a constant with which to specify the steady-state friction/slip
characteristic [5]. Under non-ideal road conditions, a modifying multiplier may be applied
to the equation. This takes the form :
g̃(Vr ) = ✓g(Vr )
(4.6)
where ✓ represents a road classification factor. This is the value used in the HCC for
calculating friction limits, and is akin to changing road friction coefficients.
Holistic Cornering Control
The physical coding of the HCC was designed to be as modular as possible, such that the
code could be portable between di↵erent platforms, and easily interchanged to experiment
with new algorithms.
Where possible, vehicle parameters such as mass, wheelbase, etc. are configured in
library files and linked upon model initialization. Inputs are grouped by functional purpose
into vectors, and passed to the HCC as a predefined MUX signal. A sample picture showing
the HCC code layout is shown below in Figure 4.7.
In all cases, input to the system is laid out on the left hand side, where any intermediary
signal processing is also performed. The HCC logic is located inside the blue block, which
simply outputs a vector of 4 motor torques once computation is complete. Inside the HCC
logic block are multiple iterations of the HCC, saved for experimental purposes. At the
time of this writing, current research has 9 HCC variants, performing things such as Model
56
Figure 4.7: HCC Simulink Code
Predictive Control (MPC), simplified analytical solutions, or numerical solver approaches.
To facilitate switching between these modes, a cascaded switch structure was implemented,
whereby a mode selection number triggers a case activation block to route signals through
the desired block as shown below in Figure 4.8.
For safety purposes, cut-o↵s were also implemented into the HCC. Specifically, a lowspeed cuto↵ of 1 km/h was added to ensure that torque vectoring would not be activated
when the vehicle is stopped or parked. Also, a dynamic saturation block was added to
limit the amount of torque that any wheel could request, in case of computation errors
during test trials. The layout of this block is shown below in Figure 4.9.
57
Figure 4.8: Multiple HCC Moding
58
Figure 4.9: HCC Safety Cuto↵s
59
Torque Blending Control
The Torque Blending Controller is the final stage before sending torque requests to the
motor, and acts to merge the HCC overlay torques to original driver requests. Three major
sets of outputs are generated, namely: 1)motor driver enable bits, 2) motor drive direction
bits, and 3) requested motor torques as shown below in Figure 4.10. Inputs to the TBC
include the HCC and AWDC torques, in addition to the current gear state for direction.
As a practical implementation, the velocity is also taken into account, whereby the
motors are disabled when brakes are applied and the vehicle is stationary (VX = 0). This
was done to prevent parasitic energy loss, and the generation of excessive EMF noise of a
stalled motor, which can cause CAN communication problems.
Figure 4.10: TBC block
Function Scheduler
The function scheduler’s objective is to serially trigger data-dependent function blocks,
such that processing progresses in an expected manner, and input-dependency errors are
avoided. The refresh rate of the control loop is also set here, based on the timing of the
trigger used. Currently, the function scheduler is set to trigger every 5ms, and the order
of essential operations dictated by the function scheduler are as follows:
60
1. Vehicle Speed Determination
2. Accelerator Pedal Validation
3. AWDC (All-Wheel Drive Control)
4. BRFC (Brake Force Control)
5. DCI (Driver Command Interpreter)
6. Kinematic Estimation
7. Sensor Fault Tolerance
8. Tire Estimation
9. HCC (Holistic Cornering Control)
10. TBC (Torque Blending Control)
11. Motor Controller Send
It should be noted that other code is also executed even if not explicitly triggered
by the function scheduler. Certain low-level control loops like the starting of a cooling
pump can progress in the background without requiring real-time guarantees, and are thus
free-spinning when computation cycles are available. In Simulink, a timed function-call
generator block is used as the master, followed by function-call splits to execute subsequent
trigger tags in linear sequence. In the current code, trigger tags are grouped into functional
groups, as shown below in Figure 4.11.
61
Figure 4.11: Function Scheduler block
62
4.2
Carsim Environment
A software simulation environment was created for code debugging and verification, by linking the Matlab code to a CarSim model for dynamics modeling and feedback. Attributes
under CarSim’s control include a driver model with which to follow velocity-dependent
drive cycles, road conditions, and all aspects of vehicle dynamics. By using the simulator to virtualize sensor feedback, identical variable names may be used and the control
code may stay unchanged, thus becoming fully portable from the simulation to physical
environment with minimal change.
As a brief overview, CarSim is a lookup table-based simulator, which extrapolates vehicle responses using empirical test data of individual components, and known relationships
between systems. By avoiding finite-element analysis, CarSim achieves a near real-time
simulation speed, which greatly aids debugging and controller tuning. Two sample screens
are shown in Figures 4.12 and 4.13 below, which show the vehicle mass and tire modeling,
respectively. Physical vehicle information was determined via weight scale and inertia swing
testing by technicians at a GM vehicle testing center, while slip ratios with a resolution of
0.01 are derived from Calspan tire testing [7].
Conversion from MABX code to Carsim involves two main additional blocks: 1)virtual
driver input, and 2) simulated sensor input into the control stack.
4.2.1
Driver Input
In the simulation environment, requested maneuvers from General Motors were converted
into functional blocks of consisting of timed steer/gas/brake signals, and injected into the
control code as if they were sensor inputs.
Multiple maneuvers are multiplexed into a switch, and selected manually via a numbered selection as shown below in Figure 4.14. A sample steering input from the specified
double lane change maneuver meanwhile, is shown in Figure 4.15
There are cases where a simple feed-forward driver model is insufficient, such as when
drive cycle simulations require tracking for target speeds over time. In these instances,
a driver model is implemented to keep tests consistent between di↵ering vehicle control
algorithms. A PI controller on the CarSim side is then applied, configured to request
acceleration as a function of velocity tracking error. An additional proportional gain was
63
Figure 4.12: Carsim Vehicle Model
added to translate this desired acceleration into pedal responses as follows:
(
Kg (Kp ⇤ Verr + Ki ⇤ Ierr ), if Verr 0
Pgas =
0,
if Verr < 0
Pbrake =
(
Kb (Kp ⇤ Verr + Ki ⇤ Ierr ), if Verr < 0
0,
if Verr 0
Here, Pgas and Pbrake are the gas and brake pedal positions in percent, Kg and Kb
are the gain constants for the gas and brake pedals respectively, Kp is the acceleration P
gain, and Ki the integral gain. Verr is the measured velocity tracking error, and Ierr is the
integral of Verr over time.
64
Figure 4.13: Carsim Tire Model
Figure 4.14: Simulated Driver Manoeuvring
65
Figure 4.15: Double Lane Change Simulator Input
66
4.2.2
Simulated Sensor Input
At the code level, CarSim is linked to Simulink via a special s-function block, which
performs bi-directional transfer as shown in Figure 4.16. Currently, 10 inputs are fed into
Carsim to drive the dynamic model: these involve the driving and braking torques at each
wheel, in addition to steering wheel angles and steering torque. 79 outputs are in turn taken
from Carsim to attain validation signals and drive the controller code. Primarily, these
signals involve simulated velocities, tire forces, CG forces, slip angles, and input requests
from the CarSim driver model. The interface is driven by two function-call triggers, which
times the reading of vehicle sensor signals at the start of each cycle, and to output requested
motor torques at the end.
Figure 4.16: Carsim Interface
After attaining raw carsim sensor data, a secondary block gathers all of the interface
signals, and converts the coordinate frames or units to match that of the production vehicle
sensors as needed. At the same time, filtering or noise generation is added as desired. As
output, the tags are renamed to be identical to those coming out of the actual sensors as
shown below in Figure 4.17.
67
Figure 4.17: MABX Input Simulation
68
As an example, the inertial measurement signals being internally routed for the BCM
are shown below in Figure 4.18. Conversions between sm2 and G units are shown, as well
inversions to some axes to satisfy the SAE standard. At the end, zero-order hold blocks
latch the signal values until the next iteration, to keep data consistency within a refresh
cycle.
Figure 4.18: BCM Signal Simulation
A tag labeled FILTER BCM is seen, which is a user-configurable number which routes
the signals through one of multiple processing filters, as shown in Figure 4.19.
Figure 4.19: Simulated Signal Filtering
69
4.3
dSpace
By setting the dSpace as a target for compiled code, Matlab is capable of cross-compiling
the simulink software into C code, to be run by the dSpace embedded computer. To
accomplish this, dSpace-provided RTI blocks are used whenever interfaces to the CANbus
are needed. The rest is an automated process, where Matlab accesses the required libraries.
CAN Configuration
Here, Real-Time Interface (RTI-CAN) blocks from the dSpace model set are used to configure each hardware channel, and to assign CAN libraries which define the layout of expected
messages on the bus. Three CAN buses exist in the Equinox platform, and their primary
purpose is shown below in Figure 4.20.
CAN Configuration
GM
High-Speed CAN
ANDYBUS
Sensor Bus
Vehicle Data
System Control
Data Acquisition
Figure 4.20: CAN Channel Functionality
All three buses are tied together at the dSpace, which coordinates I/O between the
devices, and uses information to perform HCC calculations.
70
The High-Speed CAN is a production vehicle network, and part of GM’s Global-A
architecture, which standardized the way vehicles communicate throughout di↵erent models and platforms. A GM-supplied Global-A CAN database was used to access the vast
amount of information located on this bus. Of specific relevance to the HCC are signals involving the Body Control Module (BCM) which provides vehicle IMU data, the Electronic
Brake Control Module (EBCM) which provides the brake pressure and wheel speed data,
the Electronic Power Steering (EPS) module which provides steering angle and torque
information, and the dashboard which outputs indicators for speed and other notifications.
The Andybus, meanwhile is a custom network, meant to control retrofit components
such as the DC-DC converter, BMS system, and motor controllers. This was created, since
the production GM bus was already at a high utilization rate, and adding throughput
involved the risk of data collision, and higher error rates.
The Sensor Bus is second auxiliary channel, meant to transmit high-bandwidth data
without over-utilizing either of the primary control buses. This bus carries information
from the GPS/IMU, laser speed sensor, and wheel load sensors, which output data at a
constant and high rate.
In CAN messaging, each bus is capable of sending messages of a unique ID, and varying
length to convey information. Each message is a grouping of related signals, which can be
de-multiplexed in Simulink.
An example is given below in Figure 4.21 below, which defines one of the messages
for the Rinehart AC Inverter. In messages, the packing order of signals are defined on a
per-bit basis, and grouped in the example by color.
In Simulink, the CAN dictionary for this message is called every time a message ID of
0X1AA is encountered, and its signals are parsed to produce the motor driver’s statuses as
shown in Figure 4.22. In this example, three desirable signals involving the system state,
motor direction, enable bit are selected.
71
Figure 4.21: Sample CAN Message Layout
Figure 4.22: Simulink CAN interface
72
MABX Inputs
Here, MABX is an acronym for ”Micro-Autobox”, and defines the various input signals
which are required for controller operation. For network-based data, CAN libraries described in Section 4.3 are used to define and route incoming signals. Otherwise, analog
signals are accessed through the hardware’s on-board ADCs. This module is organized
into 8 function blocks, logically separated by the source of these signals as shown below in
Tables 4.1 and 4.2.
Module
BCM (Body Control Module)
Signal
Steering & Gas Pedal Positions)
IMU Data (CG forces and Yaw Rates)
Instantaneous Brake Pressure
Ignition Switch Status
Miscellaneous System Statuses
BMS (Battery Management System)
Battery State of Charge
Current Draw
Total Energy In/Out
Pack Temperature
BMS temperature
Highest/Lowest Cell Voltage
Location of Lowest Cell
Total Pack Voltage
EPS (Electronic Power Steering Controller)
Boost Motor Speed
Boost Motor Torque
Torsion Bar Torque
Steering Angle
Current Draw
System Voltage
EBCM (Electronic Brake Control Module)
Wheel Speeds
Sensor Validity
Table 4.1: MABX Inputs from GM-HSCAN
73
Module
DC-DC Converter
Signal
Device Status
Temperature
GPS/IMU
CG Velocity Components
6-Axis IMU Signals
GPS Coordinate data
ADC
Gear Selector Position
Accelerator Pedal Position
Motor Controllers
Inverter Status
Temperature
Torque Feedback
Input Voltage
Table 4.2: MABX Input Signals for Andybus
The BCM returns a large quantity of chassis-level information, which are not all used.
Instead, a total of 18 signals are selected to satisfy the functioning of the HCC. BMS signals
are checked mostly for safety purposes. Eventually, many of these statuses are output to
a debugging screen to be checked during physical tests, to ensure that the battery does
not sustain damage from over-current draws, or excessive SOC depletion. Individual cell
voltages, and location numbers are recorded so that imminent failures, or sporadic faults
under load could be discovered and resolved before catastrophic cell damage.
The DC-DC converter is a fairly isolated component within the system, and is only
monitored for temperature warnings, and activity status to ensure that the low-voltage
bus is powered.
The EPS module provides debug information directly from the power steering module,
which provides enhanced detailed insight into the front wheel activity. Ultimately, the
steering angles and current draw may be used to design controllers for autonomous steering,
while the torsion bar torque may be used to deduce road friction conditions.
The Brake controller is used primarily for its wheel-speed encoder, which is used in
the Equinox for vehicle velocity estimation, and tire slip control. The signals harvested
from the third-party GPS/IMU unit are used mainly for validation purposes, and include
a 6-axis accelerometer output in addition to velocity and position readings.
74
Only three signals are polled through the on-board ADC. The signals are the gear
selector position (due to removal of the transmission controller), and two redundant gas
pedal position sensors (due to removal of the engine controller). The motor controllers are
polled, primarily for validation and safety purposes. Inverter state signals are monitored
for fault states, while temperature signals are used to trigger cooling pumps as needed.
Initialization Sequence
One feature of the Global-A from GM’s perspective is security; in order to discourage
vehicle theft and the sale of stolen parts on illegal markets, the main BCM checks an ID
and initialization string of each other controller within its scope. This way, if a component
from another vehicle is installed, the vehicle would purposefully shut down. Message IDs
are not public information, which further masks the purpose of each signal from potential
hackers. This, however presents a problem for an electric retrofit, since the ECM required
for ignition would be missing. Even if the ECM were present, the engine and its associated
sensors would be also be missing.
To get around this issue, all messages across the CAN network were recorded during
ignition, and analyzed using a CAN database to determine dependent signals, modules
and timing. This reverse-engineering led to the discovery of critical messages, which could
then be spoofed by the dSpace to report status to the security modules. Specifically, these
involved links from the ECM and transmission controller.
Critical messages that the BCM expects from the ECM are status updates regarding the
engine speed, temperature, fuel level, ignition status, target idle speeds, oil pressure, and
various validation signals for engine health. Meanwhile, spoofed transmission controller
messages tell the BCM about the current gear selector position, gear number, and engine
state.
The timing of these signals are an issue, as there is a time windows with which to
complete ignition. Otherwise, modules such as the EPS would not enable, and power
steering would be unavailable. To time the sequence of events, the vehicle’s wake-up pin is
wired into the dSpace, which triggers its wake-up signal. When the key is turned, or the
door is opened, the dSpace immediately comes alive and synchronizes to the BCM which
wakes up via the same signal.
In the Equinox, a timed sequence of signals mimicking the production network is sent
out first. Then, custom devices such as cooling pumps and relays are engaged. Finally,
high-voltage relays are engaged, and the motor controllers are powered on for operation.
75
Low Level Hardware
The remaining items under dSpace control are triggered based on simple outputs.
For instance, the stock Dashboard in the Equinox is driven by wire, and displays an
output based on certain CAN messages. This was used to show custom information via
remapping. Pack SOC was rerouted to the fuel gauge, motor temperatures were rerouted
to the engine temperature, and current drain was routed to the engine RPM meter. Hardware DACs are triggered based on system temperature thresholds; once reached, the code
commands driver boards to trigger relays for pumps and fans for cooling.
The remainder of dSpace programming involves graphically drawing Human Machine
Interfaces (HMI) for real-time plotting of data and parameter tuning, as shown below in
Figures 4.23 and 4.24.
Figure 4.23: Main Demonstration Screen
During testing, HCC modes are selectable via pull-down menus, and specific functions
such as simulated motor faults are clickable via buttons. On the tuning screen, parameters
a↵ecting the DCI driver feel, HCC gains, and traction control are all available. Real-time
motor feedback and HCC outputs are plotted, for visual inspection.
76
Figure 4.24: Tuning Screen
77
Chapter 5
Results
The HCC formulation was implemented on a variety of platforms for validation, but the
results contained in this chapter are for the Equinox test beds. Simulation data is performed
using real-time Simulink code connected to CarSim, while experimental data was acquired
from test runs at a local test track designed to train emergency service (police, firetruck)
drivers. This test track is an oval shape of relatively narrow width as shown in Figure 5.1a,
which generally restricted testing to lane-change and start-stop scenarios. An example of
one such maneuver is shown in Figure 5.1b, where the Equinox is undergoing double lane
change testing on a course laid out by pylons.
For testing, production sensors are used for steering wheel angles, IMU, and wheel
speeds. Stock Michelin Latitude tires were utilized, of P225/60R17 size. In the provided
results, the HCC code was implemented in its numerical solver form, with data logged via
the embedded dSpace computer.
78
(a) Test Track Layout
(b) Equinox Testing in Action
Figure 5.1: Vehicle Testing at UW Fire Research Facility
79
5.1
Energy Consumption
Drive-cycle analyses are performed to determine the total energy consumption over varying,
real-life driving conditions. Industry standard EPA drive cycles were used to simulate
driver behavior, specifically the aggressive, highway, and urban profiles [14]. The velocity
profiles of these are shown in Figure 5.2.
140
Velocity (km/h)
120
100
80
60
40
20
0
0
100
200
300
Time (s)
400
500
600
100
100
80
80
Velocity (km/h)
Velocity (km/h)
(a) EPA Aggressive Cycle
60
40
20
0
0
60
40
20
100
200
300
400
Time (s)
500
600
700
0
0
800
(b) EPA HWYFET Cycle
200
400
600
800
Time (s)
1000
1200
1400
(c) EPA urban Cycle
Figure 5.2: EPA Drive Cycles
Two performance metrics were used to determine the e↵ectiveness of the EMS:
1. Time time-average efficiency of the vehicle as shown in Table 5.1
2. Total energy consumption of the drive cycle as shown in Table 5.2
From Table 5.1, it is seen that the EMS is most e↵ective for cases where there is a
constant, lower demand for torque such as highway cruising. In such cases, the operating
80
Table 5.1: Average Motor Efficiency
Cycle
Urban
Hwyfet
Aggressive
EMS OFF (%)
81.07
57.45
73.02
EMS ON (%)
90.50
84.75
88.60
Improvement (%)
9.43
27.30
15.58
Table 5.2: Power Consumption
Cycle
Urban
Hwyfet
Aggressive
EMS OFF (kWh)
36.26
16.29
19.49
EMS ON (kWh)
34.29
15.47
18.11
Improvement (%)
5.43
5.03
7.08
point is closer to the lower fringes of the efficiency curve and has the most to benefit from
an upward shift to a single axle.
In Table 5.2, it is seen that the order of energy consumption rankings is inverted. The
EMS is most e↵ective for aggressive driving which contains high speeds and fast accelerations for this particular motor. In essence, the power consumed during large accelerations
exceed that consumed for constant-speed driving and provides the most opportunity for
net gains.
To ensure the validity of these results, the driver model was also analyzed to ensure
that velocities were being reliably tracked, To accomplish this, the velocity tracking errors
were recorded over time, and the RMS values calculated to give an indication of precision.
The results are given below in Table 5.3, and visualized in Figure 5.3.
Table 5.3: Driver Model Tracking Error Rates
Cycle
Urban
HWYFET
Aggressive
RMS, EMS OFF (kph)
0.368
0.169
0.555
RMS, EMS ON (kph)
0.366
0.171
0.556
Since all simulations indicated an RMS tracking error of under 1 kph, it was deemed
acceptable as the vehicle consistently achieved target speeds.
81
3
Tracking Error (km/h)
Tracking Error (km/h)
3
2
1
0
−1
−2
0
1000
2000
3000
4000
5000
Time (s)
6000
Tracking Error (km/h)
Tracking Error (km/h)
−1
1000
2000
3000
4000
5000
Time (s)
6000
7000
1.5
0.5
0
−0.5
−1
1000
2000
3000
4000
Time (s)
5000
6000
7000
1
0.5
0
−0.5
−1
−1.5
0
8000
(c) EPA HWYFET Cycle, EMS ON
1000
2000
3000
4000
Time (s)
5000
6000
7000
8000
(d) EPA HWYFET Cycle, EMS OFF
3
Tracking Error (km/h)
3
Tracking Error (km/h)
0
(b) EPA Aggressive Cycle, EMS OFF
1
2
1
0
−1
−2
0
1
−2
0
7000
(a) EPA Aggressive Cycle, EMS ON
−1.5
0
2
2000
4000
6000
8000
Time (s)
10000
12000
2
1
0
−1
−2
−3
0
14000
(e) EPA Urban Cycle, EMS ON
2000
4000
6000
8000
Time (s)
10000
12000
14000
(f) EPA Urban Cycle, EMS OFF
Figure 5.3: Vehicle Tracking Results
82
5.2
Energy Management Under Dynamic Maneuvers
To study the energy management system (EMS)’s possible e↵ects on dynamic response, a
sample case is given for a sinusoidal gas pedal and steering wheel input as shown below in
Figure 5.4. This input was chosen, such that a range of accelerations are requested while
the vehicle undergoes significant dynamic loading. An initial velocity of 30 kph was used.
80
Steering Wheel Input (rad)
2
Gas Pedal Input (%)
70
60
50
40
30
20
10
0
0
2
4
Time (s)
6
8
0
−2
0
10
5
10
Time (s)
(a) Pedal Input
(b) Steering Input
Figure 5.4: Driver Inputs for Simulated Run
Figure 5.5 below shows the feed-forward torques with and without the EMS, for the
left side of the vehicle. Deviations between the two lines are noted, and due to the active
redistribution between the front and rear axles.
1400
EMS ON
EMS OFF
EMS ON
EMS OFF
1200
Torque (Nm)
Torque (Nm)
1500
1000
500
1000
800
600
400
200
0
0
2
4
Time (s)
6
8
0
0
10
(a) Motor Torque, LF
2
4
Time (s)
6
(b) Motor Torque, LR
Figure 5.5: Comparison of Torques With and Without EMS
83
8
10
After these feed-forward torques are summed with the HCC torque vectoring oututs,
total requested motor torques are attained and shown below in Figure 5.6.
200
EMS ON
EMS OFF
150
Total Motor Torque (Nm)
Total Motor Torque (Nm)
200
100
50
0
−50
−100
0
2
4
Time (s)
6
8
150
100
50
0
−50
0
10
(a) Motor Torque, LF
EMS ON
EMS OFF
2
4
Time (s)
6
8
10
(b) Motor Torque, LR
Figure 5.6: Comparison of Torques With and Without EMS
It is seen that there are di↵erences between the EMS o↵ modes, versus on. The high
frequency switching areas are regions of active traction control, which indicates that the
vehicle has reached handling limits. The jagged nature of the torque curves meanwhile,
are due to the HCC overlay torques which are actively maintaining vehicle yaw tracking.
It should be noted that the torque vectoring overlay is nearly identical between the two
curves, confirming that yaw tracking outputs from the HCC are una↵ected by the baseline
torque.
Finally, Figure 5.7 below displays the results of the vehicle’s path tracking and yaw
rate tracking abilities. It is seen that without any active control, the vehicle takes on a
deviant path. With the HCC enabled however, the vehicle successfully tracks the DCI
generated reference, without interference from the EMS. It is seen that the path and yaw
rate tracking with the EMS enabled is virtually identical to the cases where it is disabled,
which confirms that no detrimental e↵ects are seen while conserving energy.
84
10
HCC OFF
EMS ON
EMS OFF
Y Coordinate (m)
5
0
−5
−10
−15
−20
−25
−30
0
50
100
X Coordinate (m)
150
200
(a) Vehicle Path
Yaw Rate (rad/s)
1
Driver Request
EMS ON
EMS OFF
0.5
0
−0.5
0
2
4
Time (s)
6
8
10
(b) Yaw Rate
Figure 5.7: Path and Yaw Rate Tracking Comparison With and Without EMS
85
5.3
Straight Line Acceleration
As explained in Section 2.4.4, some form of traction control is necessary for the HCC to
perform stably in the non-linear regions of the tire friction curve.
After empirical tuning, acceptable parameters for the slip-prevention controllers were
derived. Namely, a threshold slip ratio of 0.2 at each wheel was used to trigger a proportional controller with p = 50, 000 which constricted the friction ellipse. In both simulations
and empirical testing, this was found to provide satisfactory performance under both wet
and dry asphalt conditions.
A simulated case is given below for straight-line acceleration from 40 kph on a slippery
surface of µ = 0.6, with an accelerator pulse input as shown below in Figure 5.8. Tire slips
with the traction controller turned on are provided in Figure 5.9 below.
Gas Pedal Input (%)
100
80
60
40
20
0
0
5
10
Time (s)
15
20
Figure 5.8: Pedal Input for Straight-Line Acceleration Test
In this road condition, it is seen that the front wheels exhibit large slip ratios of up
to 90%. There is little slip in the rear, as the coefficient of friction is sufficient to carry
the torque given an extra boost to normal forces under accelerative weight shifting to
the rear. Slip with the HCC turned on are significantly better, and are held to the 0.2
slip threshold ratio mark. Figure 5.10 shows the final motor torque requests, with HCC
augmented torques overlaid upon the original driver requests.
In Figure 5.11, the tire force bounds for the HCC numerical solver are shown. At
approximately the 2.5s mark, it is seen that the upper and lower bounds converge at a
negative value due to positive tire slip, and forces the system to apply a negative corrective
torque. After the slip event is over, the bounds are seen to re-diverge, and give a range of
possible values for the HCC to resume torque vectoring. Between the 2 to 8 second mark,
86
1
HCC OFF
HCC ON
0.8
0.8
0.6
0.6
Slip Ratio
Slip Ratio
1
0.4
0.4
0.2
0.2
0
0
0
5
10
Time (s)
15
20
0
(a) Slip, Left-Front
0.8
0.6
0.6
Slip Ratio
Slip Ratio
0.8
0.4
0.2
0
0
10
15
20
15
20
0
(c) Slip, Left-Rear
HCC OFF
HCC ON
0.4
0.2
Time (s)
10
Time (s)
1
HCC OFF
HCC ON
5
5
(b) Slip, Right-Front
1
0
HCC OFF
HCC ON
5
10
Time (s)
15
20
(d) Slip, Right-Rear
Figure 5.9: Slip Ratios, Traction Control On
converging slopes can be observed, particularly in the rear wheels. In cases where traction
is not the limiting factor, available motor torque becomes the constraining factor. In this
experiment’s case, vehicle speeds have passed into the motor’s constant power/diminishing
torque region, thus explaining the contraction.
87
1500
Driver Request
HCC
1000
Torque (Nm)
Torque (Nm)
1500
500
0
−500
0
5
10
Time (s)
15
1000
500
0
−500
0
20
(a) HCC Torque, Left-Front
Driver Request
HCC
500
5
10
Time (s)
15
10
Time (s)
15
20
(b) HCC Torque, Right-Front
1000
0
0
5
1500
Torque (Nm)
Torque (Nm)
1500
Driver Request
HCC
1000
500
0
0
20
(c) HCC Torque, Left-Rear
Driver Request
HCC
5
10
Time (s)
15
(d) HCC Torque, Right-Rear
Figure 5.10: Slip Ratios, Traction Control On
88
20
4000
Upper Bound
Lower Bound
2000
Tire Force (N)
Tire Force (N)
4000
0
−2000
−4000
−6000
0
5
10
Time (s)
4000
15
−2000
−6000
0
20
10
Time (s)
4000
Upper Bound
Lower Bound
2000
5
15
20
(b) Permissible Tire Force Bounds, RightFront
Tire Force (N)
Tire Force (N)
0
−4000
(a) Permissible Tire Force Bounds, LeftFront
0
−2000
−4000
−6000
0
Upper Bound
Lower Bound
2000
Upper Bound
Lower Bound
2000
0
−2000
−4000
5
10
Time (s)
15
−6000
0
20
(c) Permissible Tire Force Bounds, LeftRear
5
10
Time (s)
15
20
(d) Permissible Tire Force Bounds, RightRear
Figure 5.11: Permissible Tire Force Bounds, µ = 0.6
89
A similar set of results are given in Figures 5.12 and 5.13 below for lower coefficient
surface, of µ = 0.3.
2
2
HCC OFF
HCC ON
1.5
Slip Ratio
Slip Ratio
1.5
1
0.5
0
0
5
10
Time (s)
15
1
0.5
0
0
20
(a) Slip, Left-Front
10
Time (s)
15
2
HCC OFF
HCC ON
20
HCC OFF
HCC ON
1.5
Slip Ratio
1.5
Slip Ratio
5
(b) Slip, Right-Front
2
1
0.5
0
0
HCC OFF
HCC ON
5
10
Time (s)
15
1
0.5
0
0
20
(c) Slip, Left-Rear
5
10
Time (s)
15
20
(d) Slip, Right-Rear
Figure 5.12: Slip Ratios, Traction Control On, µ = 0.3
It is seen that slip is very well controlled, not exceeding the target threshold of 0.2.
90
1500
Driver Request
HCC
1000
Torque (Nm)
Torque (Nm)
1500
500
0
−500
0
5
10
Time (s)
15
1000
500
0
−500
0
20
(a) HCC Torque, Left-Front
Driver Request
HCC
500
0
5
10
Time (s)
15
10
Time (s)
15
20
(b) HCC Torque, Right-Front
1000
−500
0
5
1500
Torque (Nm)
Torque (Nm)
1500
Driver Request
HCC
1000
500
0
−500
0
20
(c) HCC Torque, Left-Rear
Driver Request
HCC
5
10
Time (s)
15
(d) HCC Torque, Right-Rear
Figure 5.13: Slip Ratios, Traction Control On, µ = 0.3
91
20
5.3.1
Experimental Results, Split-Mu, Wet Asphalt
Gas Pedal Position (%)
Experimental results are given in this section for the vehicle accelerating in a straight line
on a water sprayed split-mu asphalt surface. In this, one side of the vehicle is driven on
top of a sealed asphalt surface which provides lower grip, while the other is a regular rough
asphalt. The RWD was chosen for this test, as rear wheel drive cars have an increased
tendency to spin out under harsh acceleration, which poses a larger problem for the HCC.
The pedal inputs for this experiment are shown in Figure 5.14.
HCC ON
HCC OFF
100
80
60
40
20
0
0
2
4
Time (s)
6
8
10
Figure 5.14: Pedal Inputs, Split-Mu Acceleration
Next, the vehicle yaw responses are shown in Figure 5.15. Here, it is seen that the
2
1
0.5
0
−0.5
−1
−1.5
−2
0
Driver Request
Actual
1.5
Yaw Rate (rad/s)
1.5
Yaw Rate (rad/s)
2
Driver Request
Actual
1
0.5
0
−0.5
−1
−1.5
2
4
Time (s)
6
8
−2
0
10
(a) HCC OFF
2
4
Time (s)
6
8
(b) HCC ON
Figure 5.15: Comparison of Yaw Rate Responses on a Split-Mu Surface
92
10
2000
2000
1500
1500
1000
1000
Torque (Nm)
Torque (Nm)
vehicle experiences a spin-out condition without the HCC, as evidenced by the large error
in vehicle yaw rate. The controlled system however, is able to maintain a very straight
path. The HCC augmentation torques used to achieve this result are shown in Figure5.16.
500
0
−500
500
0
−500
−1000
−1000
−1500
−1500
−2000
0
2
4
Time (s)
6
8
−2000
0
10
2
(a) Rear-Left
4
Time (s)
6
8
10
(b) Rear-Right
Figure 5.16: HCC Correction Torques For Driven Wheels
Finally, a comparison the slips measured at each wheel are shown in Figure 5.17.
1
1
HCC ON
HCC OFF
0.8
Torque (Nm)
Torque (Nm)
0.8
0.6
0.4
0.2
0
0
HCC ON
HCC OFF
0.6
0.4
0.2
2
4
Time (s)
6
8
0
0
10
(a) Rear-Left
2
4
Time (s)
6
8
10
(b) Rear-Right
Figure 5.17: Comparison of Slip At Driven Wheels
It is seen that without the traction controller, large magnitudes of slip occur. With the
HCC enabled however, slip levels remain controlled.
93
5.4
Double Lane Change
The main maneuver used to quantify dynamic vehicle performance is the double lane change
(DLC) due to its simple nature and ability to scale vehicle accelerations by controlling
speed.
Steering Wheel Input (rad)
The steering input used for the DLC is shown in Figure 5.18.
2
0
−2
0
5
Time (s)
10
Figure 5.18: Steering Input for Double Lane Change
To validate the DCI, this steering input is given over a range of speeds to determine
its accuracy at predicting vehicle behaviour in optimal conditions (µ = 1.0). The ideal
scenario is a DCI tuned such that under high-friction conditions, the feed-forward yaw rate
response closely matches that of the car without any active control. This guarantees that
the HCC would not be activated in normal conditions, and vehicle handling would not
be a↵ected. System responses for 40-120 kph trials are shown below in Figure 5.19. In
these, ”Driver Request” is the feed-forward response generated by the DCI, and used by
the HCC-ON mode. In the HCC-OFF mode, both the DCI and HCC are ignored and a
pure vehicle response is taken.
94
1
Driver Request
HCC ON
HCC OFF
Yaw Rate (rad/s)
Yaw Rate (rad/s)
1
0.5
0
−0.5
0
2
4
6
Time (s)
8
0.5
0
−0.5
0
10
(a) DLC Response, 40 kph
4
Time (s)
6
Driver Request
HCC ON
HCC OFF
0.5
0
2
4
6
Time (s)
8
8
10
(b) DLC Response, 60 kph
Yaw Rate (rad/s)
Yaw Rate (rad/s)
2
1
1
−0.5
0
Driver Request
HCC ON
HCC OFF
0.5
0
−0.5
0
10
(c) DLC Response, 100 kph
Driver Request
HCC ON
HCC OFF
2
4
Time (s)
6
8
10
(d) DLC Response, 100 kph
Figure 5.19: Comparison of Yaw Rate Responses at µ = 1.0
It is seen that in general, the DCI generated output closely matches the actual vehicle
response. Due to the small amount of error, it is also seen that the HCC enabled system
does not significantly stray away from the natural response. In all cases, a minor phase
lead is noted between the DCI and system feedback. This may be explained by compliance
in the system, such as tire deflections.
95
By applying the same steering inputs over a range of lower friction surfaces, the HCC’s
ability to maintain stability may be studied. A nominal entry speed of 60 kph is used in
the following examples, and surfaces of µ = 0.1, 0.3, and 0.6 are used to compare against
the reference case of µ = 1.0. The path tracking abilities of the car are shown below in
Figure 5.20.
40
20
10
0
−10
−20
−30
0
Reference
HCC ON
HCC OFF
30
Y Coordinate (m)
Y Coordinate (m)
40
Reference
HCC ON
HCC OFF
30
20
10
0
−10
−20
50
100
X Coordinate (m)
150
−30
0
200
50
(a) µ = 1.0
40
Reference
HCC ON
HCC OFF
200
Reference
HCC ON
HCC OFF
30
Y Coordinate (m)
30
Y Coordinate (m)
150
(b) µ = 0.6
40
20
10
0
−10
−20
−30
0
100
X Coordinate (m)
20
10
0
−10
−20
50
100
X Coordinate (m)
150
−30
0
200
(c) µ = 0.3
50
100
X Coordinate (m)
150
200
(d) µ = 0.1
Figure 5.20: Path Following Abilities of HCC Across Various Friction Surfaces
It is seen that in the reference case of µ = 1.0, path tracking of the car is not a↵ected
by the HCC, and a natural handling state is achieved. An overall upward trend in the path
is noted, despite a symmetric steering input. This is due to the fact that vehicle velocity
drops during the maneuver (no gas is applied), and the direction of the first turn incurs
more displacement than subsequent counter steers.
The µ = 0.6 case represents the limit of non-assisted handling for this maneuver, and
shows that the HCC does not add unwanted actuation to the system unless it is warranted.
Starting with the µ = 0.3 case, significant path deviations are seen for cases where the
96
HCC is o↵. Performance still very closely resembles the reference command at µ = 0.3,
but appreciable error is seen by µ = 0.1.
To gain a better understanding of vehicle heading and the HCC’s performance as a yaw
controller, rate responses are provided in Figure 5.21.
1
Driver Request
HCC ON
HCC OFF
Yaw Rate (rad/s)
Yaw Rate (rad/s)
1
0.5
0
−0.5
0
2
4
Time (s)
6
8
0.5
0
−0.5
0
10
(a) DLC Response, µ = 1.0
Driver Request
HCC ON
HCC OFF
0
2
4
Time (s)
6
4
Time (s)
6
8
10
(b) DLC Response, µ = 0.6
0.5
−0.5
0
2
1
Yaw Rate (rad/s)
Yaw Rate (rad/s)
1
Driver Request
HCC ON
HCC OFF
8
0.5
0
−0.5
0
10
(c) DLC Response, µ = 0.3
Driver Request
HCC ON
HCC OFF
2
4
Time (s)
6
8
10
(d) DLC Response, µ = 0.1
Figure 5.21: Comparison of Yaw Rate Responses on Di↵ering Surfaces
As implied from the path tracking results, vehicle stability is maintained with the
HCC, although response lags are seen at extremely low coefficients. This is due to lower
tire capacities with which to apply corrective yaw moments. Loss of control is clearly
shown in the yaw rate charts; without the HCC, divergence is seen after the 2s mark for
the µ = 0.3 and µ = 0.1 cases. In these, the vehicle spins with a positive yaw rate despite
a steering request of 0. By comparison, the actively controlled system returns to a stable
forward motion of r = 0 with minimal oscillation or overshoot.
To show how the HCC adapts to di↵ering surfaces, computation bounds for the front97
left tire are shown in Figure 5.22.
6000
2000
0
−2000
−4000
−6000
0
Upper Bound
Lower Bound
4000
Tire Force (N)
4000
Tire Force (N)
6000
Upper Bound
Lower Bound
2000
0
−2000
−4000
2
4
Time (s)
6
8
−6000
0
10
2
(a) µ = 1.0
6
6000
Upper Bound
Lower Bound
8
10
Upper Bound
Lower Bound
4000
Tire Force (N)
4000
Tire Force (N)
Time (s)
(b) µ = 0.6
6000
2000
0
−2000
−4000
−6000
0
4
2000
0
−2000
−4000
2
4
Time (s)
6
8
−6000
0
10
(c) µ = 0.3
2
4
Time (s)
6
8
10
(d) µ = 0.1
Figure 5.22: Permissible Tire Bounds for the Rear-Right Tire Over Various Friction Surfaces
It is seen that the system e↵ectively constricts the search space given diminishing
friction values, which works to prevent over-actuation of the tires. In the µ = 0.1 case, a
severely constricted search space enables any estimation error to over-torque the wheels to
result in slip. Once this happens, the traction control algorithm is activated, which results
in the rake-like corrective pulses.
98
Solving the HCC equation given the tire force constraints results in the final augmentation torques at each wheel. Corresponding values for the same front-left tire are shown
below in Figure 5.23.
1000
HCC Delta−Q (Nm)
HCC Delta−Q (Nm)
1000
500
0
−500
−1000
0
500
0
−500
−1000
2
4
Time (s)
6
8
10
0
2
(a) µ = 1.0
6
8
10
6
8
10
1000
HCC Delta−Q (Nm)
HCC Delta−Q (Nm)
Time (s)
(b) µ = 0.6
1000
500
0
−500
−1000
0
4
500
0
−500
−1000
2
4
Time (s)
6
8
10
0
(c) µ = 0.3
2
4
Time (s)
(d) µ = 0.1
Figure 5.23: Comparison of HCC Augmentation Torques on Di↵ering Surfaces
It is observed that unless slip limits are exceeded, the HCC results in smooth control
signals that scale with increasing yaw rate error. Downward spikes arising from the traction
control algorithm are first observed at 4s in the µ = 0.3 case, and eventually comes to
dominate control outputs at µ = 0.1.
99
0.4
0.4
0.3
0.3
0.2
0.2
Slip Ratio
Slip Ratio
Finally, Figure 5.24 shows the slip ratios for all four wheels in the extreme µ = 0.1 case,
to show e↵ectiveness of the traction controller operating within a dynamic maneuver.
0.1
0
−0.1
0.1
0
−0.1
−0.2
−0.2
−0.3
−0.3
−0.4
0
2
4
Time (s)
6
8
−0.4
0
10
2
0.4
0.3
0.3
0.2
0.2
0.1
0
−0.1
−0.3
Time (s)
6
10
8
10
0
−0.3
4
8
−0.1
−0.2
2
6
0.1
−0.2
−0.4
0
Time (s)
(b) Right-Front
0.4
Slip Ratio
Slip Ratio
(a) Left-Front
4
8
10
(c) Left-Rear
−0.4
0
2
4
Time (s)
6
(d) Right-Rear
Figure 5.24: Slip Ratios at Each Corner, µ = 0.1
100
5.4.1
Experimental Results, Sine Wave in Snow
In this section, results are provided for the vehicle under a freshly-fallen snow condition,
with approximately 1 inch of accumulation. Continuous lane change maneuvers were manually applied, at a speed of approximately 50 kph. Yaw rate responses for the car are
provided in Figure 5.25 below, to compare performance with and without the HCC. Vehicle speeds are recorded via GPS for both runs, and provided in Figure 5.26 below to ensure
consistency between both tests.
1
Driver Request
Actual
Yaw Rate (rad/s)
Yaw Rate (rad/s)
1
0.5
0
−0.5
−1
0
2
4
Time (s)
6
8
10
Driver Request
Actual
0.5
0
−0.5
−1
0
2
(a) HCC OFF
4
Time (s)
6
8
10
(b) HCC ON
Figure 5.25: Yaw Rate Response Comparison, Snowy Conditions
60
HCC ON
HCC OFF
Velocity (kph)
50
40
30
20
10
0
0
2
4
Time (s)
6
8
10
Figure 5.26: Vehicle Speeds During Maneuver
It is seen that without the HCC, major tracking errors are seen between the desired
response and actual feedback. Most importantly, a loss of control is encountered at the 7s
mark without HCC, while the actively controlled system is able to follow driver inputs.
101
2000
2000
1500
1500
1000
1000
Torque (Nm)
Torque (Nm)
The HCC augmentation torques used to achieve these results are provided in Figure
5.27 below.
500
0
−500
500
0
−500
−1000
−1000
−1500
−1500
−2000
0
2
4
Time (s)
6
8
−2000
0
10
2000
1500
1500
1000
1000
500
0
−500
−1500
Time (s)
6
8
8
10
0
−1500
4
6
−500
−1000
2
Time (s)
500
−1000
−2000
0
4
(b) HCC Torque, Right-Front
2000
Torque (Nm)
Torque (Nm)
(a) HCC Torque, Left-Front
2
10
(c) HCC Torque, Left-Rear
−2000
0
2
4
Time (s)
6
8
10
(d) HCC Torque, Right-Rear
Figure 5.27: HCC Torques, Snowy Conditions
The major di↵erence between simulation and experimental results is the high-frequency
switching around peak regions, mostly due to real-life sensor noise in the accelerometer and
wheel speed signals. Despite this, the vehicle still gains most of the benefit of the torque
vectoring, and stability is enhanced.
102
5.4.2
Experimental Results, Double Lane Change on Asphalt
In this section, vehicle performance on dry asphalt condition are provided. The RWD
platform is shown, to o↵er a view of performance given only have the actuators as seen in
snow. A comparison of vehicle yaw rates is shown below in Figure 5.28.
1.5
0.5
0
−0.5
−1
−1.5
5
Driver Request
Actual
1
Yaw Rate (rad/s)
1
Yaw Rate (rad/s)
1.5
Driver Request
Actual
0.5
0
−0.5
−1
6
7
8
9
Time (s)
10
11
12
−1.5
5
(a) Yaw Rate, HCC OFF
6
7
8
9
Time (s)
10
11
12
(b) Yaw Rate, HCC ON
Figure 5.28: Performance Comparison, Double Lane Change on Asphalt
Here, a loss of vehicle control is observed at the 8s mark for the vehicle with HCC. An
oversteer condition is encountered, and the vehicle continues spinning despite a countersteer action. A comparison of vehicle speeds through the run is provided below in Figure
5.29, to ensure comparability between tests.
80
HCC ON
HCC OFF
Velocity (kph)
70
60
50
40
30
20
10
0
5
6
7
8
9
Time (s)
10
11
12
Figure 5.29: Vehicle Speeds During Maneuver
The generated vectoring torques used to achieve these are shown in Figure 5.30.
103
1500
1000
1000
Torque (Nm)
Torque (Nm)
1500
500
0
−500
−1000
−1500
5
500
0
−500
−1000
6
7
8
9
Time (s)
10
11
12
(a) Rear-Left
−1500
5
6
7
8
9
Time (s)
(b) Rear-Right
Figure 5.30: HCC Vectoring Torques
104
10
11
12
Chapter 6
Conclusion
It is shown that the vehicle control structure proposed in this thesis was capable of significantly improving vehicle response through a range of conditions. A comprehensive
approach to vehicle design was undertaken, with two Equinox SUVs being retrofit with
electric motor drives and instrumented for experimental data collection. A simulation environment linking CarSim to Matlab/Simulink was created in parallel for design work and
debugging, while compiled code was generated for real-time experimentation on a dSpace
embedded computer. In drive cycle simulations, the proposed energy management module
conserved between 5-7% energy, with nothing more than software to realize the savings.
In experimental testing, a wide range of dynamic maneuvers were successfully executed,
including full-acceleration launches to prevent spin-out, sinusoidal steer inputs in snow to
test grip, and high-speed lane changes on asphalt to test vehicle stability. Overall, the vehicle controller proposed in this thesis is shown to be a viable production-oriented controller
that is highly tunable, modular, and performance enhancing. The goal of this controller,
namely the integrated control of stability and energy management controls for an electric
vehicle, was successfully achieved.
105
References
[1] Abtin Athari, Saber Fallah, Bin Li, Amir Khajepour, Shih-Ken Chen, and Baktiar
Litkouhi. Optimal torque control for an electric-drive vehicle with in-wheel motors:
Implementation and experiments. SAE International Journal of Commercial Vehicles,
6(1):82–92, 2013.
[2] Claus Beyer and Peter Dominke. Antilock braking system, January 11 1994. US
Patent 5,277,482.
[3] Stephen Poythress Boyd and Lieven Vandenberghe. Convex optimization. Cambridge
university press, 2004.
[4] G Burgio and P Zegelaar. Integrated vehicle control using steering and brakes. International Journal of Control, 79(05):534–541, 2006.
[5] C. Canudas de Wit, H. Olsson, K.J. Astrom, and P. Lischinsky. A new model for
control of systems with friction. Automatic Control, IEEE Transactions on, 40(3):419–
425, 1995.
[6] Green Car Congress. Amp unveils electric version of gm equinox; ”secret sauce” is
the drivetrain, 2010.
[7] Calspan Corporation. Calspan - safer highways.. safer skies, 2014.
[8] Michigan Scientific Corporation. Wheel force transducer system, 2014.
[9] Frédéric Delbos, Jean Charles Gilbert, et al. Global linear convergence of an augmented lagrangian algorithm for solving convex quadratic optimization problems.
2003.
[10] dSpace. Microautobox ii, 2013.
106
[11] New Eagle. Rinehart pm100dx integrates perfectly with a remy hvh250: New eagle
integrates perfectly with your ev/hev project, 2012.
[12] New Eagle. Dc-dc converter data sheet, 2013.
[13] Elithion. Lithiumate pro professional distributed li-ion bms, 2013.
[14] EPA. Dynamometer drive schedules, 2013.
[15] Saber Fallah, Amir Khajepour, Barıs Fidan, Shih-Ken Chen, and Bakhtiar Litkouhi.
Vehicle optimal torque vectoring using state-derivative feedback and linear matrix
inequality. IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, 62(4), 2013.
[16] H. Fujimoto and H. Sumiya. Range extension control system of electric vehicle based
on optimal torque distribution and cornering resistance minimization. In IECON 2011
- 37th Annual Conference on IEEE Industrial Electronics Society, pages 3858–3863,
2011.
[17] Youssef A Ghoneim, Shih-Ken Chen, Valery Pylypchuk, Nikolai K Moshchuk, and
Bakhtiar Brian Litkouhi. Real-time allocation of actuator torque in a vehicle, January 31 2011. US Patent App. 13/017,117.
[18] P.E. Gill, W. Murray, M.A. Saunders, and M.H. Wright. Numerical Linear Algebra
and Optimization. Basic Books, 1961.
[19] T.D. Gillespie. Fundamentals of Vehicle Dynamics. Society of Automotive Engineers,
1992.
[20] Nick I. M. Gould and Philippe L. Toint. Preprocessing for quadratic programming.
Math. Program., 100(1):95–132, 2004.
[21] Yoshikazu Hattori. Optimum vehicle dynamics control based on tire driving and
braking forces. R&D Review of Toyota CRDL, 38(4):23–29, 2003.
[22] Remy International Inc. Hvh250 series electric motors, 2013.
[23] Daofei Li, Shangqian Du, and Fan Yu. Integrated vehicle chassis control based on
direct yaw moment, active steering and active stabiliser. Vehicle System Dynamics,
46(S1):341–351, 2008.
[24] Daofei Li and Fan Yu. A novel integrated vehicle chassis controller coordinating direct
yaw moment control and active steering. Training, 2013:12–09, 2007.
107
[25] EK Liebemann, K Meder, J Schuh, and G Nenninger. Safety and performance enhancement: the bosch electronic stability control (esp). SAE Paper, 20004:21–0060,
2004.
[26] Oxford Technical Solutions Ltd. Rt2000 family, 2013.
[27] Zhejiang GBS Energy Co. LTD. Gbs12v100ah details, 2013.
[28] Jorge J Moré and Danny C Sorensen. Computing a trust region step. SIAM Journal
on Scientific and Statistical Computing, 4(3):553–572, 1983.
[29] J. Nocedal and S. Wright. Numerical Optimization. Springer Series in Operations
Research and Financial Engineering. Springer, 2006.
[30] Damrongrit Piyabongkarn, Jae Y Lew, Rajesh Rajamani, John A Grogg, and Qinghui
Yuan. On the use of torque-biasing systems for electronic stability control: limitations
and possibilities. Control Systems Technology, IEEE Transactions on, 15(3):581–589,
2007.
[31] Huihuan Qian, Guoqing Xu, Jingyu Yan, Tin Lun Lam, Yangsheng Xu, and Kun Xu.
Energy management for four-wheel independent driving vehicle. In Intelligent Robots
and Systems (IROS), 2010 IEEE/RSJ International Conference on, pages 5532–5537,
2010.
[32] A Rezaeian, R Zarringhalam, S Fallah, W Melek, et al. Cascaded dual extended
kalman filter for combined vehicle state estimation and parameter identification.
Training, 2005:12–15.
[33] Kaoru SAWASE and Yuichi USHIRODA. Improvement of vehicle dynamics by rightand-left torque vectoring system in various drivetrains. Mitsubishi Tech. Rev, 20:14–20,
2008.
[34] Xiaoming Shen and Fan Yu. Study on vehicle chassis control integration based on
a main-loop-inner-loop design approach. Proceedings of the Institution of Mechanical
Engineers, Part D: Journal of Automobile Engineering, 220(11):1491–1502, 2006.
[35] Motoki Shino, Naoya Miyamoto, Y-Q Wang, and Masao Nagai. Traction control
of electric vehicles considering vehicle stability. In Advanced Motion Control, 2000.
Proceedings. 6th International Workshop on, pages 311–316. IEEE, 2000.
108
[36] Motoki Shino and Masao Nagai. Independent wheel torque control of small-scale
electric vehicle for handling and stability improvement. JsAE Review, 24(4):449–456,
2003.
[37] Rinehart Motion Systems. Pm family data sheet, 2013.
[38] EV West. Pfc 5000, 2013.
[39] Dejun Yin, Sehoon Oh, and Yoichi Hori. A novel traction control for ev based on
maximum transmissible torque estimation. Industrial Electronics, IEEE Transactions
on, 56(6):2086–2094, 2009.
[40] Reza Zarringhalam, Ayyoub Rezaeian, William Melek, Amir Khajepour, Shih-Ken
Chen, and Nikolai Moshchuk. A comparative study on identification of vehicle inertial
parameters. In American Control Conference (ACC), 2012, pages 3599–3604. IEEE,
2012.
109
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising