Post on 13-May-2020
Faculty of Engineering, Computer &
Mathematical Sciences
School of Mechanical Engineering
Level IV Project 2007
Final Report
Authors: Supervisors:
1119931 Bowels, Cullen Dr. Ben Cazzolato
1144049 Cheong, Calvin Dr. Steven Grainger
1120899 Cole, Nicholas
1113693 Do, Quynh
1120026 Harsono, Adi
1105663 Keong, Philip
1119886 Martin, Josiah
1118845 Miller, Peter
1090807 Runnals, Joshua
i
ii
Executive Summary
This report describes the development, from concept to realisation, of a full-scale autonomous
ground target vehicle called the Thales Autonomous Radio-controlled Ground-basEd Target
or its corresponding acronym, The TARGET. This challenging and innovative project was car-
ried out by a team of nine Undergraduate Mechatronic and Mechanical Engineering students
from The University of Adelaide in South Australia for the partial fulllment of their nal
year Bachelor of Engineering study in 2007. The TARGET vehicle was designed to provide
a safe unmanned moving ground target for an Unmanned Aerial Vehicle (UAV) project be-
ing undertaken by Thales Australia, which is the Australian branch of a major international
defence corporation. In order to fulll this application, the TARGET project was dened
around the key objective of developing a safe ground target vehicle system that was capable
of switching between normal human driving, remote control and autonomous control modes
of operation.
The resulting TARGET solution comprises the core complementary elements of Actuation,
Radio Frequency (RF) Communications, State Measurement and Estimation, Onboard Com-
puter Systems, Autonomous Guidance Control, Motion Execution Control, Base Station and
Graphical User Interface (GUI), and Safety. These functional categories are discussed in detail
throughout the report.
The scale and complexity of this project was substantial for a nal year Undergraduate Engi-
neering project in the time-frame of a single year, and an allocation of only a third of the total
nal year educational workload. Nevertheless, despite a myriad of unforeseen challenges and
an ambitious project contract of agreed goals and specications, the TARGET vehicle has
been successfully operated by radio control in extended on-the-road testing representative of
its intended application. Additionally, many aspects of autonomous operation are in working
order, however due to unforeseen diculties involving the mounting arrangement of the In-
ertial Measurement Unit (IMU) which provides vehicle heading information, some aspects of
autonomous operation are yet to be completely veried. To date, eight out of eleven primary
project goals have been achieved according to plan in addition to one project extension goal.
The three remaining goals, which have been restricted from nal on-the-road verication
due to the IMU problems, are likely to be achieved in full prior to the Project Exhibition,
during which the TARGET vehicle will be on public display. The TARGET project was also
completed comfortably within budget.
iii
iv
The novel aspects of the project are summarised as the following:
• The development of a full-scale moving ground target vehicle system capable of switch-
ing between normal human driving, remote control and autonomous control modes of
operation;
• An automated system of actuating a vehicle's driving controls (steering, throttle, brake,
automatic transmission, and ignition) without inhibiting the normal human-driven op-
eration of the vehicle;
• The development of a dedicated real-time onboard computer system utilising a rapid
control systems prototyping package called xPC Target ;
• An Extended Kalman Filter that produces improved estimates of the vehicle states (posi-
tion, speed, and heading) by fusing GPS, IMU, speedometer, brake pressure transducer,
and steering angle potentiometer sensor data;
• A unique, multi-variable spatial Autonomous Guidance Controller founded on the prin-
ciples of the Virtual Vehicle Approach;
• A PID-based Motion Execution Controller for controlling vehicle steering, throttle, and
brake actuators;
• A purpose-built graphical user interface (GUI) for path denition, mode control and
telemetry;
• A multifaceted safety system incorporating numerous emergency stop systems, a wide
range of automated fault detection and response mechanisms, and an audio-visual warn-
ing system.
It is hoped that the TARGET vehicle developed in 2007 can be expanded in future years, with
the aim of achieving an obstacle-avoiding autonomous vehicle that is capable of competing
against other autonomous ground vehicles in the illustrious DARPA Grand Challenge.
Disclaimer
We, the authors of this project declare that all material in this report is our own work except
where there is an acknowledgment and reference to the work of others.
Bowels, Cullen (1119931)
Signature: Date:
Cheong, Calvin (1144049)
Signature: Date:
Cole, Nicholas (1120899)
Signature: Date:
Do, Quynh (1113693)
Signature: Date:
v
vi
Harsono, Adi (1120026)
Signature: Date:
Keong, Philip (1105663)
Signature: Date:
Martin, Josiah (119886)
Signature: Date:
Miller, Peter (1118845)
Signature: Date:
Runnals, Joshua (1090807)
Signature: Date:
Acknowledgments
Thanks to Thales Australia for providing nancial support and critical hardware components,
which have been essential in the success of the project.
This project could not have been completed without the outstanding contributions of our
supervisors, and sta members of the Mechanical Engineering Department's electronic and
mechanical workshops. The TARGET team extends thanks to:
• Ben Cazzolato, for continuous support and optimism throughout the entire project.
Without his guidance this project would not have been possible nor would it have been
completed to such a high standard.
• Steven Grainger, for his commitment towards the project. His expertise has impacted
profoundly upon the success of the project.
• Robert Dempster, for his outstanding quality of workmanship involved in installing the
mechanical systems into the vehicle. The project would not have been conducted in
such a good spirit and at such a high level without his professional input and positive
attitude.
• Silvio De Ieso, Philip Schmidt, Norio Itsumi and Joel Walker, for their continuing pa-
tience despite our persistent hassling regarding the electronics. Despite the extremely
small time frame they had to work with, the nal electronics of the TARGET vehicle are
a truly outstanding achievement, and is a reection of their dedication and commitment
towards this project and its members.
vii
viii
In addition, the TARGET team would like to thank the following people for their support
throughout the project:
• Adam Collins
• Billy Constantine
• Richard Craig
• Garth Denley
• Stephen Kloeden
• Dorothy Missingham
• David Osborne
• Richard Pateman
The TARGET team would also like to thank all our families and friends for their ongoing
support.
Glossary
AC Alternating Current
AGD84 Australian Geodetic Datum
AM Amplitude Modulation
ASCII American Standard Code for Information Interchange
CL Closed Loop
CMR Compact Measurement Record
COG Centre of Gravity
COM Reference to a Serial Port
CPU Central Processing Unit
CRC Cyclic Redundancy Checking
CRO Cathode Ray Oscilloscope
DARPA Defense Advanced Research Projects Agency
DC Direct Current
DOS Disk Operating System
ECEF Earth - Centered, Earth - Fixed
EKF Extended Kalman Filter
FEC Forward Error Checking
FHSS Frequency Hopping Spread Spectrum
FIFO First In, First Out
FM Frequency Modulation
FMEA Failure Modes and Eects Analysis
FPID Feedforward Proportional Integral Derivative
ix
x
GPS Global Positioning System
GUI Graphical User Interface
HMI Human Machine Interface
I/O Input/Output
ICC Intelligent Cruise Control
IMU Inertial Measurement Unit
ISM Industrial Scientic and Medical frequency band
LSB Least Signicant Byte
MSB Most Signicant Byte
NMEA National Marine Electronics Association
OL Open Loop
PC Personal Computer
PCM Pulse Code Modulation
PD Proportional Derivative
PI Proportional Integral
PID Proportional Integral Derivative
PPM Pulse Position Modulation
PWM Pulse Width Modulation
RC Radio Control
RF Radio Frequency
RTK Real Time Kinematic
SCADA Supervisory Control And Data Acquisition
SOP Safe Operating Procedure
TARGET The Thales Autonomous Radio-controlled Ground-basEd Target
UAV Unmanned Aerial Vehicle
UTM Universal Transverse Mercator
Contents
Executive Summary iii
Disclaimer v
Acknowledgments vii
Glossary ix
Contents xi
List of Figures xxi
List of Tables xxix
1 Introduction 1
2 Project Goals and Specication 7
2.1 Project Specication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Vehicle Selection and Maintenance . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Actuators and Actuator Control . . . . . . . . . . . . . . . . . . . . . 8
2.1.3 Phase One Communication . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4 Phase Two Communication . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.5 Motion Execution Control . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.6 Autonomous Guidance Control . . . . . . . . . . . . . . . . . . . . . . 11
xi
Contents xii
2.1.7 State Measurement and Estimation . . . . . . . . . . . . . . . . . . . . 12
2.1.8 HMI and GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.9 Provision of Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Extension Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Literature Review 19
3.1 Steering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Brake Actuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Transmission Actuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 State Estimation and Measurement . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.1 Sensor Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.2 Kalman Filter Comparison . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.3 Earth Coordinate systems . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 Autonomous Guidance Control . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.1 Theme One: Hierarchical Control Structure . . . . . . . . . . . . . . . 36
3.5.2 Theme Two: Path Tracking Control Methodologies . . . . . . . . . . . 37
3.5.3 Theme Three: Path Tracking Control Parameters . . . . . . . . . . . . 39
3.5.4 Summary and Recommendations . . . . . . . . . . . . . . . . . . . . . 41
3.6 Motion Execution Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6.1 Steering Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6.2 Throttle / Brake Switching Logic . . . . . . . . . . . . . . . . . . . . . 46
3.6.3 Throttle Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6.4 Braking Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.7 Path Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.7.1 Open Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
xiii Contents
3.7.2 Closed Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.8 Background Imagery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.9 RF Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.9.1 Handheld Remote-Control . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.9.2 RF Modems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4 Hardware Design 61
4.1 The Vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2 Onboard Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.1 xPC Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.2 Computer Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.3 Program Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3 Communication Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.1 Handheld Remote-Control . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.2 RF Modems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.4 Steering Actuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4.1 Steering Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4.2 Mounting Arrangement . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.4.3 Steering Angle Measurement . . . . . . . . . . . . . . . . . . . . . . . 75
4.5 Throttle Actuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.5.1 Vacuum Actuator Mounting . . . . . . . . . . . . . . . . . . . . . . . . 76
4.5.2 Vacuum Actuator Control . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.6 Brake Actuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.6.1 Primary Brake Actuation System . . . . . . . . . . . . . . . . . . . . . 78
4.6.2 Emergency Brake System . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.7 Transmission Actuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Contents xiv
4.7.1 Solenoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.7.2 Linear Actuator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.7.3 Gear Position Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.8 Electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.8.1 Power Electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.8.2 Safety Electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.8.3 Throttle Interface Board . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.8.4 Hall Eect Sensor Board . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.8.5 Tachometer Feedback Board . . . . . . . . . . . . . . . . . . . . . . . . 95
4.8.6 Ignition Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.8.7 Steering and Brake Amplier . . . . . . . . . . . . . . . . . . . . . . . 96
5 State Estimation and Measurement 99
5.1 General Structure of the Kalman Filter . . . . . . . . . . . . . . . . . . . . . . 100
5.2 System States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.3 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.3.1 Derivation of the System Model . . . . . . . . . . . . . . . . . . . . . . 104
5.3.2 System Model Implementation . . . . . . . . . . . . . . . . . . . . . . 109
5.3.3 Derivation of the Process Noise Covariance Matrix . . . . . . . . . . . 109
5.4 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.4.1 Global Positioning System (GPS) Unit . . . . . . . . . . . . . . . . . 111
5.4.2 Inertial Measurement Unit Sensor . . . . . . . . . . . . . . . . . . . . . 133
5.4.3 Hall-Eect Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
5.4.4 Potentiometer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
xv Contents
6 Control Strategies 145
6.1 Onboard Computer Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
6.1.1 I/O Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
6.1.2 Fault Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
6.1.3 Mode Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.1.4 Motor Comms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.1.5 Startup Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
6.1.6 Sound Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
6.2 Autonomous Guidance Control . . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.2.1 Autonomous Guidance Control Strategy . . . . . . . . . . . . . . . . . 165
6.2.2 Autonomous Guidance Controller Structure . . . . . . . . . . . . . . . 169
6.2.3 Simulation and Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
6.3 Motion Execution Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.3.1 Steering Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.3.2 Speed Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
7 Graphical User Interface 197
7.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
7.1.1 Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
7.1.2 Design Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
7.1.3 Creating a Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
7.1.4 Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
7.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
7.3 Final Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Contents xvi
8 Safety 205
8.1 Types of Emergency Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
8.1.1 Failure Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
8.1.2 Dragon Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
8.2 Safety Systems Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
8.2.1 The Van . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
8.2.2 Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
8.2.3 Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
8.2.4 Electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
8.2.5 Autonomous Guidance Control . . . . . . . . . . . . . . . . . . . . . . 210
8.2.6 Motion Execution Control . . . . . . . . . . . . . . . . . . . . . . . . . 210
8.3 Failure Modes and Eect Analysis . . . . . . . . . . . . . . . . . . . . . . . . 211
8.4 Safe Operating Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
9 Final Testing and Analysis 213
9.1 Actuators and Actuator Control . . . . . . . . . . . . . . . . . . . . . . . . . . 213
9.1.1 Selection of Suitable Hardware . . . . . . . . . . . . . . . . . . . . . . 213
9.1.2 Installation of Steering, Throttle, Brake and Transmission Lever . . . 214
9.1.3 Design of Local Control Loops for Each Actuator . . . . . . . . . . . 214
9.1.4 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
9.2 Remote Controlled Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
9.2.1 Vehicle Steering and Speed Control . . . . . . . . . . . . . . . . . . . . 215
9.2.2 Steering Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
9.2.3 Speed Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
9.2.4 Transmission Lever and Ignition Control . . . . . . . . . . . . . . . . . 220
9.2.5 Safe Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
xvii Contents
9.3 Selection, Installation and Maintenance of the Vehicle's Onboard Processor . 221
9.3.1 Select a Suitable Onboard Vehicle Processor . . . . . . . . . . . . . . . 221
9.3.2 Onboard Computer Program . . . . . . . . . . . . . . . . . . . . . . . 222
9.4 Autonomous Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
9.5 State Estimation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
9.5.1 The System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
9.5.2 GPS Field Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
9.5.3 Kalman Filter Simulation Results . . . . . . . . . . . . . . . . . . . . . 228
9.6 Phase One Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
9.6.1 Selection of a Suitable Communication System . . . . . . . . . . . . . 231
9.7 Phase Two Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
9.7.1 Selection of a Suitable Communication System . . . . . . . . . . . . . 232
9.8 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
9.8.1 Two-Way Communication . . . . . . . . . . . . . . . . . . . . . . . . . 232
9.8.2 Creation of a Simplied User Interface . . . . . . . . . . . . . . . . . . 233
9.8.3 Upgrade to a Graphical User Interface . . . . . . . . . . . . . . . . . . 233
10 Conclusion 243
10.1 Project Goal Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
10.2 Future Work and Recommendations . . . . . . . . . . . . . . . . . . . . . . . 247
10.2.1 xPC Target Computers . . . . . . . . . . . . . . . . . . . . . . . . . . 247
10.2.2 Pressure Transducer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
10.2.3 Brake Actuator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
10.2.4 IMU Mounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
10.2.5 Camera System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
10.2.6 Onboard Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
10.2.7 Range and Rate Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 249
10.2.8 Future Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Contents xviii
References 251
A Using xPC Target 257
A.1 Hardware Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
A.1.1 I/O Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
A.1.2 Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
A.1.3 Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
A.1.4 Hard Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
A.2 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
A.3 RS232 Serial Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
A.3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
A.3.2 Serial blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
A.3.3 Sending Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
A.3.4 Receiving Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
A.4 Sound Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
A.4.1 Triggered From Workspace Method . . . . . . . . . . . . . . . . . . . . 261
A.4.2 xPC Target From File Method . . . . . . . . . . . . . . . . . . . . . . 261
A.5 Data Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
A.6 xPC Target Embedded Option . . . . . . . . . . . . . . . . . . . . . . . . . . 262
A.7 Measurement Computing PCI-CTR05 . . . . . . . . . . . . . . . . . . . . . . 262
A.7.1 PWM Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
A.7.2 FM Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
A.8 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
B Budget 265
C FMEA 271
xix Contents
D Safe Operating Procedure 301
E System Flow Charts 305
F CAD Drawings 309
G Electronic Schematic Diagrams 325
H Selection of Communication Hardware 333
I Base Station User Manual 339
I.1 Setting Up the Serial Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
I.2 Setting the Vehicle Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
I.3 Using the Map Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
I.4 Logging Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
I.5 Generating Pictures from the Log File . . . . . . . . . . . . . . . . . . . . . . 341
I.6 Dening Background Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
J Manual Labour Hours 343
K Software CD 345
Contents xx
List of Figures
1.1 Illustration of the TARGET vehicle's intended application a moving ground
target for testing a vision-equipped UAV . . . . . . . . . . . . . . . . . . . . 2
1.2 Simplied systems owchart depicting the command ow in the TARGET ve-
hicle solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Simplied schematic / pictorial representation of the major TARGET vehicle
components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Princeton University DARPA Grand Challenge vehicle (Atreya et al., 2005) . 20
3.2 Autonomous Vehicle Systems DARPA Grand Challenge vehicle (Vest, 2005) . 21
3.3 Steering actuation system (Barton, 2001) . . . . . . . . . . . . . . . . . . . . 21
3.4 Brake actuation systems of Austin Robot Inc. . . . . . . . . . . . . . . . . . . 23
3.5 Possible arrangement connecting between the steel cable and the vehicle brake
pedal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 Possible mounting arrangement for the transmission actuation's linear actuator 24
3.7 The NAVSTAR GPS constellation (GPS) . . . . . . . . . . . . . . . . . . . . 25
3.8 The Novatel OEM4-G2 GPS processing card with accompanying Novatel GPS
AntennaTM Model 511 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.9 The Microstrain 3DM-GX1 IMU . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.10 The gyroscope assembly (Verplaetse, 1996) . . . . . . . . . . . . . . . . . . . . 29
3.11 The Honeywell GT1 Series 1GT101DC Solid State Hall-Eect Sensor (Honey-
well, 2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.12 The ETI Systems 10-Turn Wire-Wound 1 kΩ Rated Precision Potentiometer
(ETI Systems, 2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
xxi
List of Figures xxii
3.13 The Earth-Centered Earth-Fixed Datum . . . . . . . . . . . . . . . . . . . . . 34
3.14 The Geodetic Datum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.15 The Tangent Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.16 Follow-the-carrot and pure pursuit path tracking control strategy (sourced from
Barton (2001)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.17 Virtual vehicle spatial guidance control strategy . . . . . . . . . . . . . . . . . 38
3.18 Spatial guidance control parameters of cross-track error, d⊥, and heading error,
θe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.19 Simulated path following using a feedback controller (sourced from Barton (2001)) 42
3.20 Simulated path following using an additional feedforward term (sourced from
Barton (2001)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.21 Tuned PID controller (Sourced from Qiu and Zhang (2003)) . . . . . . . . . . 45
3.22 Tuned FPID controller (Sourced from Qiu and Zhang (2003)) . . . . . . . . . 46
3.23 Throttle / brake switching logic as implemented (Sourced from Kwon et al.
(2001)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.24 PI throttle controller block diagram (Sourced from Kwon et al. (2001)) . . . . 48
3.25 PI throttle controller test results (Sourced from Kwon et al. (2001)) . . . . . . 48
3.26 PID plus feed forward performance characteristics (Sourced from Kwon et al.
(2001)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.27 Linear splines between waypoints (Lu, 2007) . . . . . . . . . . . . . . . . . . . 50
3.28 Inserting pseudo points to generate a path (Lu, 2007) . . . . . . . . . . . . . . 51
3.29 Natural cubic splines, identied as a suitable method of path generation, shown
in an open path conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.30 The advantage of adding extra waypoints to construct a smooth and achievable
path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.31 The rst, and easiest, method for dening a background image. Dene a ref-
erence point and specify the height and width of the image. The top of the
image is assumed to be north. . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
xxiii List of Figures
3.32 The second, and more complicated method for dening a background image.
Place three points on the image. The location, orientation and skew can all be
dened by these points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.33 A typical handheld remote-control (RF Innovations Ltd Pty, 2007) . . . . . . 56
3.34 Caterpillar(TM) Trucks in open-pit mines (RF Innovations Ltd Pty, 2007) . . 58
3.35 An Automated Straddle control system by the Patrick Corporation (RF Inno-
vations Ltd Pty, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.1 The TARGET vehicle after being purchased and minor modications made . 63
4.2 Allocated frequency channels on the X2720 Remote-Control . . . . . . . . . . 67
4.3 The RFI-9256 RF Modem (RF Innovations Pty Ltd, 2006) . . . . . . . . . . . 68
4.4 Basic Hayes Dial-Up Network conguration (RF Innovations Pty Ltd, 2006) . 69
4.5 Data path operation of the RFI-9256 (RF Innovations Pty Ltd, 2006) . . . . . 69
4.6 Bisongear 348 Series PMDC Gearmotor (Bison Gear & Engineering Corp, 2007) 72
4.7 Steering column of TARGET vehicle . . . . . . . . . . . . . . . . . . . . . . . 73
4.8 TARGET Vehicle steering actuation system . . . . . . . . . . . . . . . . . . . 74
4.9 Steering potentiometer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.10 Instructions describing how to connect the actuator to the vehicle vacuum line
(Auscruise By Autron, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.11 TARGET throttle actuation system . . . . . . . . . . . . . . . . . . . . . . . . 77
4.12 Schematic showing the sequential operation of the primary brake actuation
system including feedback from pressure transducer . . . . . . . . . . . . . . . 78
4.13 Linear actuator's performance chart - Refer to 20:1 ratio for primary brake
actuation. This ratio represent the gear ratio embedded in the linear actuator
(Firgelli Automations, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.14 The TARGET vehicle's brake and transmission actuator assembly . . . . . . . 80
4.15 Pressure transducer GE Druck - PTX 1400 . . . . . . . . . . . . . . . . . . . 81
4.16 Modied circuit diagram of the pressure transducer to generate the desired
voltage output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
List of Figures xxiv
4.17 Mounting arrangement for the pressure transducer in the TARGET vehicle . 82
4.18 Pictorial representations of individual components and the assembled compo-
nent for brake line modication . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.19 Detailed pictorial representation of the brake cable attachment . . . . . . . . 84
4.20 Brake pedal and brake cable link of the TARGET vehicle . . . . . . . . . . . 85
4.21 Emergency Brake System of the TARGET vehicle . . . . . . . . . . . . . . . . 86
4.22 Transmission actuation block diagram . . . . . . . . . . . . . . . . . . . . . . 87
4.23 Modied gear transmission lever of the TARGET vehicle. Mechanical lever is
indicated by the red circle. The modication which enables linkage between
the linear actuator and transmission lever is indicated by the blue circle . . . 88
4.24 Linkage between transmission lever and actuator . . . . . . . . . . . . . . . . 88
4.25 Solenoid installation to the vehicle transmission lever. Highlighted in red-
coloured circle is the solenoid which connect the solenoid to the mechanical
lever . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.26 Modied dash-board of the TARGET vehicle for gear position signal acquisi-
tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.27 Close-up view of the TARGET electronics. Highlighted in yellow circle is the
PCB to accumulate gear position signal before connected to the onboard computer 91
4.28 TARGET electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.29 Jaycar Electronics 1000 W pure sine wave inverter (Jaycar Electronics, 2007) 93
4.30 Capacitive Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.31 Roboteq AX1500 DC motor controller (Roboteq, 2007) . . . . . . . . . . . . . 97
5.1 The Extended Kalman Filter Algorithm . . . . . . . . . . . . . . . . . . . . . 103
5.2 A visual representation of the states to be determined . . . . . . . . . . . . . 104
5.3 The GPS unit mounted on the rack in the TARGET vehicle . . . . . . . . . . 111
5.4 GPS antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.5 The GPS data decoding program . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.6 Subsystem to decode a four-byte single-precision oating-point number . . . . 116
xxv List of Figures
5.7 Subsystem to decode an eight-byte double-precision oating-point number . . 117
5.8 Subsystem to decode a four-byte long signed integer . . . . . . . . . . . . . . 117
5.9 Subsystem to decode a two-byte short unsigned integer . . . . . . . . . . . . . 117
5.10 ECEF to Geodetic datum conversion iteration, Kelly (1994b). . . . . . . . . . 119
5.11 The datum transformation of the position standard deviation . . . . . . . . . 120
5.12 Vector visualisation of the longitudinal position standard deviation . . . . . . 121
5.13 Vector visualisation of the latitudinal position standard deviation . . . . . . . 121
5.14 Vector visualisation of the height position standard deviation . . . . . . . . . 122
5.15 The Northing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.16 The Easting viewed looking down on the North Pole . . . . . . . . . . . . . . 123
5.17 The Easting viewed looking at the Earth from the side . . . . . . . . . . . . . 124
5.18 The IMU mounted on the rack in the TARGET vehicle . . . . . . . . . . . . . 133
5.19 The IMU data decoding program . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.20 Subsystem to decode a short signed integer . . . . . . . . . . . . . . . . . . . 136
5.21 The IMU mounted on the rack in the TARGET vehicle . . . . . . . . . . . . . 140
5.22 The State Measurement and Estimation Program . . . . . . . . . . . . . . . . 143
6.1 Onboard computer program (top level) . . . . . . . . . . . . . . . . . . . . . . 146
6.2 I/O signals subsystem (top level) . . . . . . . . . . . . . . . . . . . . . . . . . 147
6.3 Steering potentiometer low-pass lter performance. The green line shows the
signal before ltering, and the blue line shows the signal after ltering. . . . 150
6.4 Pressure transducer low-pass lter performance. The green line shows the signal
before ltering, and the blue line shows the signal after ltering. . . . . . . . 151
6.5 Fault detection subsystem top level . . . . . . . . . . . . . . . . . . . . . . . . 154
6.6 Mode chart top level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
6.7 Normal Operation state top level . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.8 Startup routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
List of Figures xxvi
6.9 General autonomous control ow . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.10 Autonomous control environment . . . . . . . . . . . . . . . . . . . . . . . . . 166
6.11 Speed guidance control scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 168
6.12 Illustration of the importance of speed guidance control when operating on
bounded roads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.13 Autonomous controller structure . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.14 Virtual vehicle search vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
6.15 Virtual vehicle point located behind current path segment . . . . . . . . . . . 173
6.16 Virtual vehicle point located beyond current path segment . . . . . . . . . . . 173
6.17 Vehicle located between path segments . . . . . . . . . . . . . . . . . . . . . . 174
6.18 Determining the orientation of the virtual vehicle path segment . . . . . . . . 175
6.19 Calculating the cross-track error, d⊥ . . . . . . . . . . . . . . . . . . . . . . . 176
6.20 Guidance Controller as implemented in Simulink . . . . . . . . . . . . . . . . 178
6.21 Autonomous control simulation model . . . . . . . . . . . . . . . . . . . . . . 180
6.22 Motion Execution Controller model . . . . . . . . . . . . . . . . . . . . . . . . 181
6.23 Unit step response of Motion Execution Controller model . . . . . . . . . . . 181
6.24 Simulink implementation of the Mathematical Vehicle Model . . . . . . . . . 183
6.25 Simulated open path tracking performance of the Autonomous Guidance Con-
troller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.26 Simulated closed-circuit path tracking performance of the Autonomous Guid-
ance Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.27 Steering Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.28 Roll Prevention Saturation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.29 Roll Prevention Analysis 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.30 Roll Prevention Analysis 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
6.31 Steering Lock Saturation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6.32 Speed Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
xxvii List of Figures
6.33 Speed Switching Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
6.34 Closed Loop Throttle Controller . . . . . . . . . . . . . . . . . . . . . . . . . 194
6.35 Closed Loop Brake Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 195
7.1 Various path types for the same ve waypoints. The vehicle is represented as
a blue dot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
7.2 Event sequence showing data inow, events and event recipients . . . . . . . . 200
7.3 Simplied ow diagram of the overall base station software. Blue represents an
internal manager, orange represents the visual objects on the monitor, yellow
represents data storage and green represents external objects. . . . . . . . . . 203
7.4 Screen shot of the current base station software . . . . . . . . . . . . . . . . . 204
8.1 Dragon Stop System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
9.1 Steering step response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
9.2 Braking step response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
9.3 The eect of constant System Model inputs . . . . . . . . . . . . . . . . . . . 225
9.4 The eect of constant inputs on the modied System Model . . . . . . . . . . 225
9.5 The System Model heading resulting from a constant steering angle and accel-
eration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
9.6 The System Model speed resulting from a constant steering angle and acceler-
ation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
9.7 The System Model heading resulting from a constant steering angle and accel-
eration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
9.8 The System Model heading resulting from a constant steering angle and accel-
eration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
9.9 GPS data gathered from testing . . . . . . . . . . . . . . . . . . . . . . . . . . 229
9.10 The Environment Generator Program interfacing with the Kalman Filter . . . 234
9.11 Simulated position results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
9.12 Simulated GPS standard deviation over time . . . . . . . . . . . . . . . . . . 236
List of Figures xxviii
9.13 Simulated speed results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
9.14 Simulated heading results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
9.15 Simulated acceleration results . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
9.16 Simulated IMU lateral acceleration . . . . . . . . . . . . . . . . . . . . . . . . 239
9.17 Simulated IMU yaw rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
9.18 Simulated potentiometer steering angle results . . . . . . . . . . . . . . . . . . 240
9.19 Logged path from the rst test day . . . . . . . . . . . . . . . . . . . . . . . . 241
9.20 The logged path from the second run of the test day . . . . . . . . . . . . . . 241
I.1 Screenshot of the base station software showing various dierent components
on the screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
I.2 The communication panel where the user can select the COM port and speed
of the serial connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
I.3 The vehicle mode panel which is used to change the operating mode of the
TARGET vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
I.4 The zoom panel which provides tools for zooming the map area . . . . . . . . 341
I.5 The picture panel which allows graphs to be generated from the log le . . . . 342
List of Tables
3.1 Kalman Filter comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Autonomous Guidance Control research criteria
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Comparison of PPM and PCM Systems for handheld remote-controls (Rother,
2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1 Comparison table between the required and actual performance of the linear
actuator (Firgelli Automations, 2007) . . . . . . . . . . . . . . . . . . . . . . . 80
4.2 Braking Conditions and the expected pressure range for Mitsubishi Express 1994 81
4.3 Specication for the electromagnet . . . . . . . . . . . . . . . . . . . . . . . . 86
4.4 Specication for the compressional spring . . . . . . . . . . . . . . . . . . . . 87
4.5 Comparison table between the expected performance of the linear actuator and
the selected specication of the actuator . . . . . . . . . . . . . . . . . . . . . 89
5.1 The header component of the BESTXYZB log . . . . . . . . . . . . . . . . . . 115
5.2 Format of the BESTXYZ log . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.3 Response of the 3DM-GX1 to the 0x31 command . . . . . . . . . . . . . . . 135
6.1 Input and output signals list . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6.2 Lowpass lter constants (τ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.3 Input signal scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.4 Faults monitored by onboard computer . . . . . . . . . . . . . . . . . . . . . . 155
6.5 Autonomous Guidance Control Performance Comparison . . . . . . . . . . . . 187
xxix
List of Tables xxx
7.1 A sample log le generated by the base station . . . . . . . . . . . . . . . . . 201
9.1 Steering controller step response characteristics . . . . . . . . . . . . . . . . . 217
9.2 Braking controller step response characteristics . . . . . . . . . . . . . . . . . 218
9.3 Properties of the Environment Generator Program . . . . . . . . . . . . . . . 230
9.4 RF9256's Diagnostic and Statistics Results . . . . . . . . . . . . . . . . . . . . 232
J.1 Costing Parameters for labour hours . . . . . . . . . . . . . . . . . . . . . . . 343
J.2 Total manual labour hours (up to September 30th) and costs per team member 343
J.3 Total manual labour hours and costs per workshop . . . . . . . . . . . . . . . 344
Chapter 1
Introduction
This report describes the development, from concept to realisation, of a full-scale autonomous
ground target vehicle called the Thales Autonomous Radio-controlled Ground-basEd Tar-
get or its corresponding acronym, The TARGET. This challenging and innovative project
was carried out by a team of nine Undergraduate Mechatronic and Mechanical Engineering
students from The University of Adelaide in South Australia for the partial fulllment of their
nal year Bachelor of Engineering study in 2007.
The TARGET vehicle at the centre of this undertaking is rst and foremost an unmanned
autonomous ground vehicle. The research eld of unmanned autonomous ground vehicles has
emerged as a growing area of technological pursuit and, despite its relatively young status,
such vehicles have already proved their signicant value in a surprisingly broad and expanding
range of applications in areas including defence, surveillance, security, mining, agriculture,
automotive transportation and space exploration. The utility of these vehicles essentially
arises from their potential to automatically and consistently follow a desired and recongurable
ground-based path to a high level of accuracy and without the need for a human driver.
These attributes advantageously predispose such vehicles to ground-based motion tasks that
are repetitive and monotonous, exposed to hazardous environments, and / or demand very
precise path tracking.
Through consultation with The University of Adelaide, the TARGET project was proposed
by Thales Australia, the Australian branch of a major international defence corporation, to
complement an Unmanned Aerial Vehicle (UAV) defence project that they were undertaking.
As illustrated in Figure 1.1, in order to test the tracking capabilities of their vision-equipped
UAV, Thales Australia required a cost-eective moving ground target vehicle. The potential
danger of the UAV colliding with the ground vehicle during testing created the need for the
moving ground target to be unmanned.
The TARGET project was therefore dened around the key objective of developing a safe
moving ground target vehicle system that was capable of switching between normal human
driving, remote control and autonomous control modes of operation. Such a vehicle would
1
2
Figure 1.1: Illustration of the TARGET vehicle's intended application a moving groundtarget for testing a vision-equipped UAV
possess two modes of unmanned operation (remote control and autonomous control) in ad-
dition to the normal human-driven operation which would enable easy transportation during
testing and after its nal commissioning.
The implementation of autonomous obstacle avoidance strategies was deemed to be beyond the
scope of the project due to monetary and time constraints, and though it would have been
a welcome and desirable addition, it was not necessary for the achievement of the project
objectives or for the development of an eective autonomous ground target vehicle suited to
the specied application. With reference to the major project subsystems, Chapter 2 details
the general project scope and full assortment of project goals and specications that were
written into the project contract at the beginning of the project as a benchmark against
which to compare the nal project outcomes.
The TARGET vehicle developed in this project was therefore a unique solution to a very
specic problem, but nevertheless one that extended from the body of established knowledge
regarding autonomous ground vehicles and allows future expansion into other more diverse
and equally challenging areas of research.
The completed TARGET vehicle system comprises the core complementary elements of:
• Actuation;
• Radio Frequency (RF) Communications;
• State Measurement and Estimation;
• Onboard Computer Systems;
• Autonomous Guidance Control;
• Motion Execution Control;
3 Chapter 1. Introduction
Figure 1.2: Simplied systems owchart depicting the command ow in the TARGET vehiclesolution
• Base Station and Graphical User Interface (GUI); and
• Safety.
A basic overview of the implemented TARGET vehicle solution is illustrated in Figure 1.2
and 1.3. With reference to Figures 1.2 and 1.3, the integrated vehicle system, built on a
Mitsubishi Express van, is equipped with an automated system of actuating the vehicle driving
controls (steering, throttle, brake, transmission, and ignition) without inhibiting its normal
human-driven operation. An embedded computer system onboard the vehicle interfaces with
the vehicle actuators and various sensors. This onboard computer also operates a software
program which, among many functions, facilitates Autonomous Guidance Control, Motion
Execution Control, State Measurement and Estimation, and an assortment of safety logic. In
State Measurement and Estimation, an Extended Kalman Filter fuses multiple sensor data
into improved estimates of the vehicle states (position, velocity, and heading). These estimates
are required for Autonomous Guidance Control, Motion Execution Control, and telemetry.
In Radio-Controlled (RC) mode, a remote user provides driving commands by operating a
handheld RC controller in a similar fashion to model aircraft piloting. These commands are
transmitted with a wireless transceiver to the onboard computer where they are executed
by the Motion Execution Controller which controls the vehicle actuators. In autonomous
mode, an operator at a remote base station computer enters a desired path into a graphical
user interface. This path is converted into multiple waypoints which are transmitted to the
onboard computer via a pair of RF modems. The Autonomous Guidance Controller then
determines the appropriate vehicle driving commands required to achieve path tracking, and
these commands are executed by the Motion Execution Controller.
The TARGET vehicle solution also incorporates a broad range of safety features including
multiple emergency stop systems, a wide range of automated fault detection and response
mechanisms, and an audio-visual warning system.
4
Figure 1.3: Simplied schematic / pictorial representation of the major TARGET vehiclecomponents
The report addresses each of the major TARGET systems separately and in detail, with the
report set out according to the following framework:
• Related works are discussed in Chapter 3 as a separate Literature Review which draws
upon various themes relating to the major functional categories used in the TARGET
project.
• Actuation design is discussed in Chapter 4 together with other hardware design aspects
such as vehicle selection, onboard computer components, and the RF communications
equipment.
• Chapter 5 is devoted to a detailed discussion of the State Measurement and Estimation
system.
• The Onboard Computer software, Autonomous Guidance Control, and Motion Execu-
tion Control systems have been presented together in Chapter 6 as components of the
unied TARGET control strategy.
• The Base Station and Graphical User Interface (GUI) and the TARGET Safety systems
have also been presented separately in Chapters 7 and 8 respectively.
• The results obtained from testing the integrated TARGET vehicle are presented in
Chapter 9, with specic analysis devoted to the performance of each major TARGET
system as well as a discussion of the overall eectiveness of vehicle's operation and mode
switching behaviour.
5 Chapter 1. Introduction
• The Conclusion (Chapter 10) summarises the report and presents the nal outcomes
and achievements of the TARGET project with reference to the contractual goals and
specications formulated at the beginning of the project. Some consideration is also
given to potential avenues for the project's expansion in future years.
• To facilitate (and indeed encourage) expansion of the TARGET project by nal year
Undergraduate Engineering students in future years, a project software CD has been at-
tached to Appendix K. This CD contains the Java code to date for the Base Station GUI
and the annotated Simulink / xPC Target block diagrams used to program the vehicle's
onboard computer. In addition, the TARGET's Safe Operating Procedure is presented
in Appendix D, and an outline of the various software-related issues encountered during
the project is provided in Appendix A.
• The TARGET project has been developed well within the budget constraints. The
budget has been included as Appendix B.
6
Chapter 2
Project Goals and Specification
This section of the report details the desired specications of the TARGET vehicle system
and the goals by which the nal project outcomes and performance could be measured. A set
of extension goals have also been specied.
2.1 Project Specification
This is an outline of the project specications for each subgroup. It covers the specic tasks
which will need to be completed for each subgroup. Some categories have been divided into
phase one and phase two. Where applicable, phase one refers to project areas that were to
be veried prior to phase two tasks.
2.1.1 Vehicle Selection and Maintenance
To allow adequate targeting of the autonomous ground vehicle from the Thales UAV, the
projected area of the vehicle as 'seen' by the UAV vision systems must be approximately 9
square metres and relatively rectangular in shape. As the projected area will be primarily
composed of the side of the vehicle, this specication implies height, length and shape require-
ments which most closely correspond to vans or people movers. The vehicle is intended to be
operated on sealed or well maintained unsealed surfaces, so rugged four wheel drive capacity
is not essential. It is required that the vehicle be able to maintain speeds greater than 40
kilometres per hour and possess a minimum turning radius of 7.5 metres or less. The vehicle
should be free of unrelated insignia and signage and provide a protective environment for the
necessary electronic equipment that will be installed and carried onboard. The University
of Adelaide also requires that the vehicle be equipped with a suitable cargo barrier for the
protection of passengers, and be able to t within the allocated University parking bay.
To signicantly simplify the task of automatic gear shifting, it is desirable that the vehicle be
equipped with an automatic transmission. A oor mounted gear shifter would be the preferred
7
2.1. Project Specification 8
conguration in terms of easy access and for mounting the shifting mechanism. Power steering
is also highly desirable as this would reduce the required steering torque, and therefore the cost
of the servo motor required for implementing automatic steering control. The performance of
the remote and autonomous control will be aided if the vehicle has relatively 'tight' steering
- that is, if the vehicle is capable of tracking a straight line with little driver input.
For the purpose of installing and mounting equipment and easy vehicle access, it would also
be preferential to select a vehicle with a at bed rather than rear seating - though it may
be possible to remove the rear seats of a passenger vehicle if necessary. In addition to these
factors, the vehicle should be selected on the basis of cost and mechanical soundness.
2.1.2 Actuators and Actuator Control
The goals of the actuators and actuator control section of the TARGET project is to provide
a means to gain full control of the TARGET vehicle. The actuation systems can be separated
into four main subsections, covering steering, throttle, braking and transmission actuation.
2.1.2.1 Selection of Suitable Hardware
It is desirable to have actuators that possess sucient torque and force to actuate the steering,
throttle, transmission and brake of the vehicle. These actuators must also move at a sucient
rate to mimic a human driver.
2.1.2.2 Installation
The locations of the actuators should be chosen so as not to interfere with the normal human
driven operation of the vehicle - that is, the vehicle should be capable of being safely and legally
driven by project team members when not being driven by remote or autonomous means.
Where practical, functionally appropriate and without contravening the previous statement,
actuators should generally be placed in locations that are readily accessible. Wiring should
be enclosed and arranged in a neat and tidy manner.
2.1.2.3 Design of Local Control Loops
Control loops for the actuators should maintain, as close as possible, the parameters provided
to them by either the Motion Execution or Autonomous Guidance controllers.
2.1.2.4 Safety
A reliable failsafe mechanism for manually overriding the actuators will be developed to enable
a person in the driving seat to either, immediately and easily stop, or regain manual control
of the vehicle at any time.
9 Chapter 2. Project Goals and Specification
2.1.3 Phase One Communication
2.1.3.1 Selection of a Suitable Communication System
The Phase One activity is concerned with establishing a 'drive-by-wire' system to provide
the capacity to maneuver the target vehicle using a human operated remote control. This
task will require a hand operated, short range, multichannel radio control (RC) transmitter
to translate remote human inputs of vehicle control commands (heading and speed) to a
corresponding onboard receiver over a one way radio frequency (RF) communication system.
PWM decoders will be used to enable the onboard processor (necessary for control) to read
incoming commands.
2.1.3.2 Installation and Commissioning of Hardware
The RF receiver of the command signals transmitted by the short range, handheld radio
controller will be installed onboard the vehicle and connected to the onboard processor. Its
antenna will be positioned on the vehicle in such a way as to obtain adequate reception of the
RC signal (on the roof if possible).
2.1.4 Phase Two Communication
2.1.4.1 Selection of a Suitable Communication System
The Phase Two communication system will support two way communication between the
vehicle's onboard processor and the remote base station computer allowing waypoint position
commands to be sent to the vehicle and vehicle status information to be received by the remote
base station for visual display and monitoring. High speed data transfers (approximately 100
kbps) over an approximate range of ten kilometres and at an adequate bandwidth would be
desirable for this purpose.
2.1.4.2 Selection of Capable Hardware
Phase Two communication will require the selection of a suitable modem and antenna to
be installed both at the remote base station and onboard the vehicle. A wide bandwidth is
desired to support high speed data transfer.
2.1.4.3 Installation and Commissioning of Hardware
The base station modem will be connected to the base station computer and an RF antenna.
This arrangement should be portable as the vehicle will be tested in a number of locations.
2.1. Project Specification 10
The secondary modem will be installed on the vehicle and connected to the onboard processor.
The onboard modem will be securely mounted on the vehicle in such a way as to minimise
interference with the GPS signal (accurate autonomous control relies on a relatively uncor-
rupted GPS signal), whilst also obtaining adequate reception. When placing all antennas,
care should be taken to ensure that the vehicle maintains an adequate height clearance to
enable travel on standard underpasses and in undercover car parks.
2.1.5 Motion Execution Control
2.1.5.1 Vehicle Steering and Speed Control
The desired vehicle steering and speed are to be transmitted to the onboard processor from the
handheld, human operated radio control via the one way communication link as inputs to the
Motion Execution Control system. When operating in autonomous mode, the desired vehicle
steering and speed will be generated by the Autonomous Guidance Control system and passed
on to the Motion Execution Controller. Closed loop feedback of the 'actual' vehicle steering
and speed will be provided by a Kalman Filter / estimator via a fusion of measurements from
the GPS, IMU, and other available vehicle sensors. The Motion Execution Control system
will then regulate output commands to the throttle, steering and brake actuators and ensure
that the vehicle responsively tracks the desired steering and speed.
2.1.5.2 Gearbox and Ignition Control
The Motion Execution Control system should also produce and handle control commands
to the vehicle ignition and gearbox, though local control loops embedded in the gearbox
and ignition actuator systems should be used to implement the automatic operation of these
devices.
2.1.5.3 Safe Operation
The controller must include appropriate safety logic to ensure safe operation of the vehicle,
though the vehicle should only be operated in an environment where the hazards posed to
human safety are minimal. The safety logic should include the ability to reliably override
autonomous control with radio / remote control at any time, an emergency stop mechanism,
logic to halt the vehicle during a loss of radio communications, and a roll prevention scheme.
It is also desirable for audio and visual warnings to be activated upon critical systems failure.
2.1.5.4 Selection, Installation and Maintenance of the Vehicle’s Onboard Processor
The vehicle's onboard processor will interface with many of the vehicle systems. It will however
be under the most load while processing the engagement of vehicle control, state estimation,
11 Chapter 2. Project Goals and Specification
and communication. The onboard processor platform should have sucient memory and
ops (oating point operations per second) to handle these tasks, and should be equipped
with enough peripherals and I/O ports to allow the seamless integration and interconnection of
the necessary devices. The processor platform should be able to operate under the vibration,
temperature, and other environmental conditions inside the vehicle. It should therefore be
enclosed in a suitable housing and securely mounted in a protected location within the vehicle.
For the purposes of systems integration, servicing, and maintenance, it is also desirable for
the processor platform to have a modular design and be easily accessible.
2.1.6 Autonomous Guidance Control
2.1.6.1 Waypoint Based Navigation and Guidance Control
The aim of the Autonomous Guidance Controller is to achieve safe and robust autonomous
closed loop vehicle navigation and guidance control based on a path delineated by a set of
position waypoint commands which are to be issued to the vehicle through the remote base
station computer. From a 'black box' perspective, the Autonomous Guidance Control system
should accept the position waypoint commands from the remote base station together with
a full feedback of actual vehicle state information (position, speed and heading) obtained
by the fusion of GPS, IMU and other vehicle sensory measurements in a Kalman Filter /
estimator, and as an output provide the Motion Execution Control system with the speed
and heading commands required to implement the desired motion. The intelligent internal
workings of this system should achieve a smooth and suciently rapid vehicle motion with
reasonably accurate conformity to the commanded waypoint locations. Vehicle speed should
be regulated to ensure the stability of the vehicle at all times. The design of this control system
will require the development of a mathematical model of the relevant vehicle dynamics.
2.1.6.2 Acceptance of Waypoint Commands
It is desirable for the vehicle navigation and guidance control system to be capable of accepting
waypoint commands from the remote base station in two modes: as a pre-programmed batch
of waypoints describing a xed course, or as waypoints entered 'on the y' describing a
dynamically changing path. In both cases, the vehicle should stop after the nal specied
waypoint has been reached.
2.1.6.3 Performance Criteria
The Autonomous Guidance Control system should provide accurate vehicle navigation at a
minimum operating speed of 40 kilometres per hour. Under normal autonomous operation, it
is desirable (though dependent on the performance characteristics of the available hardware -
2.1. Project Specification 12
particularly the GPS unit) that the vehicle not deviate from the desired path by more than
2 metres, so as to allow the vehicle the capacity to maintain a road bound course without
exceeding its outer boundaries. The vehicle should also possess a minimum autonomous
turning radius of 7.5 metres or less and be capable of continuous autonomous navigation over
a distance of 1.125 kilometres or greater.
2.1.6.4 Logic to Handle Loss of Communications
In the event of a critical sensor failure (that is, a failure of either the GPS or IMU) or an
unexpected loss of communications with the remote base station, the vehicle must immediately
and reliably decelerate to a stop or until normal communications or sensor function is restored.
2.1.6.5 Feedback of Data Back to Ground Station
The measured vehicle state information and controller commands should be transmitted to
the remote base station for inclusion in a vehicle status display.
2.1.6.6 Hardware Selection and Systems Integration
The Autonomous Guidance Control system will need to be integrated with the Kalman Filter
/ estimator and the Motion Execution Control system, and be programmed into the vehicle's
onboard processor platform. The task of selecting this platform has been described above,
and will depend on the requirements of a variety of tasks.
2.1.7 State Measurement and Estimation
2.1.7.1 Hardware Selection and Installation
The state measurement and estimation task will require the selection of a suitable GPS, IMU
and any additional vehicle sensors. Both the GPS and IMU should be mounted inside the
vehicle and preferably located along its centre line. All sensors (including the GPS and IMU)
will need to be connected to the onboard processor so that their measurements can be used
as inputs to the vehicle state estimator / Kalman Filter. A capable GPS antenna will also
have to be selected and this should be located to allow the unobstructed reception of the GPS
satellite signals. As previously mentioned, the GPS antenna should also be kept isolated from
the onboard RF transceiver antenna in order to avoid interference.
13 Chapter 2. Project Goals and Specification
2.1.7.2 State Estimator / Kalman Filter Design
A mathematical model of the sensors (describing information such as time delays and satura-
tion points) will be required to implement this stage. The knowledge of the sensor mathematics
will be used as a basis for the selection of an accurate and practically viable method of state
estimation (most likely a form of Kalman Filter). This state estimator should be able to fuse
the available sensor measurements into a single, more accurate set of 'actual' vehicle state
estimates including vehicle position, heading and velocity.
2.1.7.3 Systems Integration
The state estimator / Kalman Filter should be integrated with the Motion Execution and
Autonomous Guidance control systems (which are dependent on the state estimates for closed
loop operation) and be programmed into the vehicle's onboard processor platform.
2.1.8 HMI and GUI
2.1.8.1 Two Way Communication with the Onboard Processor
Commands to all actuators should be tested and veried. Known data will be sent from the
vehicle's onboard processor to the base station computer and the accuracy then veried. The
accuracy of the data sent from the base station to the onboard processor will also be tested.
2.1.8.2 Creation of a Simplified User Interface
This interface should simply require the user to provide a list of GPS waypoints, at the
base station computer, which will then be transmitted to the vehicle. Vehicle information
(including speed, heading and position) should also be fed back and displayed at the base
station.
2.1.8.3 Upgrade to a Graphical User Interface (GUI)
The GUI should consist of a graphical representation of the path to be taken by the vehicle (i.e.
a map displaying all waypoints). The position of the vehicle on this map should be displayed at
the highest attainable refresh rate (depending on the hardware available) using the information
relayed back from the vehicle. The remaining vehicle states should be displayed on the GUI.
2.2. Project Goals 14
2.1.8.4 Hardware Selection
This task requires the selection of a suitable base station computer (preferably a laptop) and
associated peripherals. The remote base station needs to be portable in order for the vehicle
to be tested in dierent locations. It is also unlikely that mains power will be available so the
selection of an appropriate power supply (such as a generator or a battery and inverter) will
also be necessary.
2.1.9 Provision of Power
All of the vehicle power requirements are to be tabulated and this information should be
used as the basis for selecting appropriate batteries, ampliers and inverters as necessary.
The steering servo motor will most likely consume the largest amount of power due to the
large torque required to physically steer the vehicle (particularly at low speeds). The power
ampliers and all other low current hardware should share a separate power supply to ensure
a stable and safe power supply.
2.1.9.1 General Hardware/Software Selection
At least three quotes should be obtained for every item that is to be purchased. Where
possible, it is advantageous to select equipment that is familiar to Thales Australia or the
University of Adelaide. All hardware and software should generally be selected on the basis
of performance (including accuracy and response time), cost, reliability, compatibility and
modularity, availability, power consumption, and size and weight.
2.2 Project Goals
Select a suitable vehicle platform
The suitability of the chosen vehicle platform will be evaluated against the criteria described
in Section 2.1.1.
Select a suitable onboard vehicle processor
The suitability of the chosen onboard vehicle processor will be evaluated against the criteria
described in Section 2.1.5.4 of the Project Specication.
15 Chapter 2. Project Goals and Specification
Establish an effective automated system of actuating the vehicle driving controlswithout interfering with the normal human driven operation of the vehicle
The performance of the actuation system will be veried in pre-installation testing, as well
as post-installation commissioning testing, and testing under remote controlled vehicle op-
eration. Functionality, response time, command following, and reliability will be important
benchmarks. The capacity for safe and unimpeded normal human driven vehicle operation
post-installation will also be assessed and veried as satisfactory.
Establish an effective short range oneway RF communication link between a hand-held radio control transmitter and the vehicle’s onboard processor
Progress in regards to establishing a short range one way RF communication link will be
measured via small scale laboratory tests that will verify when the performance required for
successful data transfers from the human operated handheld remote control to the target
vehicle is achieved. These Phase One tests will use a simplied version of the full scale
system to independently test the handheld remote control's operability factors such as range,
speed, stability, precision benchmarks (yet to be determined), and reliability. A Cathode Ray
Oscilloscope (CRO) will be used to analyse output signals and ensure that the PWM decoder
is capable of sending acceptable signals to operate parts of the vehicle such as the servo
motors. Testing will take place strategically at various stages throughout the construction of
the target vehicle.
Establish an effective two way RF communication link between the remote base sta-tion computer and the vehicle’s onboard processor
Progress in regards to establishing the two way RF communication link will be measured via
small scaled laboratory tests that will verify when the performance required for successful
data transfers between the target vehicle and the base station is achieved. These Phase
Two tests will use a simplied version of the full scale system to independently test the RF
modem's capability such as range (ten kilometres), speed, stability, precision, benchmarks
(yet to be determined), and data reliability. Desktop PCs will be used in the early testing
stages to replace the actual processors used in the full scale system. Temporary code running
in MATLAB or Simulink (on a real time target) or C will be used to assess maximum data
transfers and highlight any potential for data dropouts or loss of communications. Further
testing will take place strategically at various stages throughout the construction of the target
vehicle.
Derive an accurate mathematical model of the relevant vehicle dynamics
The accuracy of the vehicle control systems will rely to an extent on the accuracy of the math-
ematical modeling of the vehicle dynamics. It will be essential for the vehicle steering to be
2.2. Project Goals 16
modeled, and if time permits a model (either linear or nonlinear) of the vehicle's acceleration
and braking dynamics will also be incorporated. The accuracy of the mathematical model
can be ascertained by comparing the simulated vehicle behavior against the actual vehicle
behavior when both are exposed to the same stimuli.
Enable the effective fusion of all available sensor measurements into a single, moreaccurate set of ’actual’ vehicle states using a Kalman Filter / state estimator
Sensor fusion performance will be established from a comparison between raw sensor measure-
ments of vehicle states and fused measurements of vehicle states including vehicle position,
heading and velocity. This will involve logging the data entering the vehicle processor from
all sensors. The output states of the estimator will also be logged. A comparison will then
be made between the values of the estimated states and the raw sensor data, over time. The
performance of the estimator will be determined according to the continuity of the state data
and its derivatives (e.g. the position of the vehicle as sensed by the GPS unit may jump by
several meters within a split second, however the estimated position of the vehicle should not
do so).
Achieve successful remote controlled operation of the target vehicle
All of the pre-described safety mechanisms will be tested and their eective and consistent
dependability ensured before operating the vehicle by remote or autonomous means. The
performance of the remote control vehicle operation will be assessed in a number of trials.
The underlying Motion Execution Control system will also rst be tested in simulation before
being implemented in practice. Important criteria will include operability, responsiveness,
stability and reliability, and command following.
Provide a graphical user interface (GUI) for the visual display and monitoring of ve-hicle status at a portable remote base station, and allow the commanding of positionwaypoints both ’on-the-fly’ and as a pre-programmed batch
The graphical user interface (GUI) will be evaluated on the basis of functionality, utility,
ergonomics and reliability. The issuing and tracking of waypoint commands in both the 'on
the y' and pre-programmed modes will be examined in separate tests during autonomous
vehicle operation.
Achieve successful autonomous control of the target vehicle
The autonomous vehicle navigation and guidance will be assessed against the performance
criteria described in Section 2.1.6. Before operating the vehicle in autonomous mode, the
17 Chapter 2. Project Goals and Specification
failsafe safety mechanisms must be ensured, and the navigation and control system will be
rst tested in simulation. The autonomous system should be shown to achieve a smooth
and suciently rapid intelligent vehicle motion with reasonably accurate conformity to the
commanded waypoint locations.
Enable intelligent and safe switching between normal human driving, remote controland autonomous modes of operation
The seamless switching of vehicle control between a human driver, the remote controller, and
the remote base station (in autonomous mode) will be veried in trials.
2.3 Extension Goals
The extension goals listed below are not specied as being required for the completed vehicle.
They are intended to be extra goals that should be met if possible, working around time and
budget constraints.
• Investigate the possibility of making the vehicle street legal for normal human driving.
• Enable teleoperation of the vehicle using a handheld controller connected to the remote
base station computer.
• Attach an onboard camera to stream video footage to the base station GUI.
• Develop a virtual reality model of the autonomous vehicle as a whole.
• Incorporate additional controlled states (such as pitch, roll or turn rate) to further
enhance and expand the dynamic vehicle control.
• Develop and test dierent and / or more advanced control strategies.
• Develop and test dierent and / or more advanced methods of state estimation.
2.3. Extension Goals 18
Chapter 3
Literature Review
A literature review was conducted to investigate the various ways in which other teams and
researchers have tackled the challenge of designing the dierent systems comprising an au-
tonomous vehicle. A number of dierent sources were investigated including the Internet,
journal articles and books. The information gained during this research period helped to pro-
vide a starting point upon which the designs of the various systems of the TARGET vehicle
could be based.
The literature review was concentrated on six dierent areas of research and these will be
discussed further in this chapter:
1. Vehicle actuation systems
2. Motion execution control systems
3. Autonomous guidance control systems
4. State measurement and estimation
5. Vehicle path generation and imaging
6. Radio communications
3.1 Steering
Steering actuation, being the automated control of the steering of a motor vehicle, is a pivotal
element of the TARGET project. Although there is a paucity of relevant literature regarding
steering actuation, the current Literature Review aims to identify the strengths and weak-
nesses in the existing approaches in order to provide a rm basis for the development of a
steering actuation system in the TARGET project. As steering actuation is seldom utilized
19
3.1. Steering 20
in modern motor vehicles, the vast majority of the concerned literature is based upon vehicles
that participated in the DARPA Grand Challenge.
Analysis of steering systems found in reports from teams that participated in the DARPA
Grand Challenge found that there was no commonly adopted approach to actuate the steering
of an autonomous vehicle. However, there were common elements in many of the steering
actuation systems of vehicles of a similar age and layout to the vehicle platform being used
in the TARGET project. These common elements were to use an electric motor to provide a
driving torque and couple this to the steering column using a linkage system.
A steering actuation system developed by the Princeton University DARPA challenge team
is shown in Figure 3.1. This steering system consists of a motor which is coupled with the
steering column by a series of gears. Bodywork surrounding the steering column behind the
steering wheel has been removed in order to expose sections of the steering column to attach
the gears. The motor is placed below and parallel to the steering column (Atreya et al., 2005).
Figure 3.1: Princeton University DARPA Grand Challenge vehicle (Atreya et al., 2005)
Similar to the team from Princeton University, the Autonomous Vehicle Systems DARPA
Grand Challenge team (Figure 3.2) actuated the steering behind the steering wheel. However,
the Autonomous Vehicle Systems team utilized a toothed belt and pulley arrangement, by
tting pulleys around the steering column and DC motor shaft, and running the belt around
these two pulleys. The use of a toothed belt by the Autonomous Vehicle Systems Team
eliminated the risk of the belt slipping from its desired location (Vest, 2005).
Figure 3.3 shows a DC motor, in which the output shaft of the motor is perpendicular to the
output shaft of the gear head. This allows the motor to be mounted in the position shown,
as opposed to the parallel mountings illustrated in Figures 3.1 and 3.2. In this example, the
output shaft of the motor is coupled to the steering column with a chain and sprockets to
provide steering actuation. The position of the motor only interferes with the foot rest to
the left of the brake pedal, and does not interfere with any manual use of the pedals of the
vehicle. Therefore, the vehicle can still be operated both manually and autonomously.
21 Chapter 3. Literature Review
Figure 3.2: Autonomous Vehicle Systems DARPA Grand Challenge vehicle (Vest, 2005)
Figure 3.3: Steering actuation system (Barton, 2001)
3.2 Brake Actuation
The main objective of the brake actuation system was to enable vehicle deceleration during
autonomous and emergency operation modes. Furthermore, the modication performed to
the selected vehicle must not interfere with the normal operation of the vehicle.
The brake actuation system of the Austin Robot Inc. (a contestant for the DARPA Grand
Challenge) is achieved by two dierent means: the force produced by a linear actuator and
3.3. Transmission Actuation 22
the force produced by a tensional spring. The linear actuator is used to actuate the vehicle
braking system during autonomous operation. On the other hand, the force produced by the
tensional spring is used to activate the vehicle braking system during emergency situations.
The installation set-up for the Austin Robot Inc. brake actuation system is shown in Figure
3.4. With reference to Figure 3.4, the electromagnet was used to provide a holding force to
the tensional spring thus de-activating the emergency brake during autonomous and normal
human operation. There are three main advantages associated with this type of actuation.
Firstly, the possibility to locate the linear actuator at a distance from the vehicle brake pedal.
Secondly, enabling the on-board driver to manually override the system at anytime with no
interference. A highly reliable emergency systems is the third main advantage because the
secondary braking system does not require any electrical power to be activated. A steel
cable connector enables exibility in the mounting arrangement of the linear actuator. The
emergency braking system is incorporated into the bracket design via a tensional spring which
would otherwise depress without the electromagnet being activated. This type of system is
considered to be reliable, particularly during a failure of the vehicle which involves electrical
power loss. As a result, safe deceleration can still be achieved mechanically.
Two possible approaches for connecting a steel cable to the vehicle brake pedal are shown in
Figure 3.5.
3.3 Transmission Actuation
The main objective of the transmission system was to enable the vehicle to shift gear (i.e.
Park, Neutral, Drive, or Reverse) during autonomous and normal operation. The modication
performed to the vehicle must not interfere with the normal operation of the vehicle. In this
section of the Literature Review, the transmission actuation system of the Stanley Team and
Team UCF (both contestants in the DARPA Grand Challenge) will be discussed. Possible
means of actuation and mounting arrangements will also be discussed.
In order to operate the vehicle transmission lever, both the Stanley Team and Team UCF
utilised a linear actuator to facilitate the gear shifting during autonomous operation. The
mounting arrangement for each teams' linear actuator is depicted in Figure 3.6. It can be
observed from Figure 3.6 that the linear actuator was connected to the vehicle transmission
lever allowing it to locate the transmission lever at the desired location during operation. For
normal operation of the vehicle, the on-board driver will need to manually disconnect the
mechanical linkage between the linear actuator and the vehicle transmission lever (Harper
et al., 2006).
3.4 State Estimation and Measurement
The process of State Estimation and Measurement in relation to this project, involves the
real-time manipulation and improvement of data from a number of dierent vehicle sensors.
23 Chapter 3. Literature Review
(a) Electromagnet de-energized - emergency situation (Brog-don et al., 2005)
(b) Electromagnet energized - autonomous operation (Brog-don et al., 2005)
Figure 3.4: Brake actuation systems of Austin Robot Inc.
(a) Pull on brake pad (Barton, 2001) (b) Pull on brake lever (Brogdon et al., 2005)
Figure 3.5: Possible arrangement connecting between the steel cable and the vehicle brakepedal
3.4. State Estimation and Measurement 24
(a) Stanley's transmission system (Thrun et al., 2006) (b) Team UCF transmission system (Harper et al.,2006)
Figure 3.6: Possible mounting arrangement for the transmission actuation's linear actuator
The result of this process is a set of vehicle states (or variables), which may be used as
feedback to perform automatic control of the vehicle motion and to track a path. The aim of
this literature review section is to provide some of the background theory behind the practical
processes presented in the State Estimation and Measurement body section (see Section 5).
Firstly, a brief description of each of the sensors used in the State Estimation and Measurement
process is given, followed by a discussion of the advantages and disadvantages of the main
Kalman Filters currently in existence. Finally, the three Earth coordinate systems utilised in
the State Estimation and Measurement body section are dened.
3.4.1 Sensor Functionality
The four sensors used in the State Estimation and Measurement process of the TARGET ve-
hicle are the Novatel OEM4-G2 Global Positioning System (GPS) processing card with accom-
panying Novatel GPS AntennaTM Model 511 supplied by Thales Australia; the Microstrain
3DM-GX1 Inertial Measurement Unit also supplied by Thales Australia; the Honeywell GT1
Series 1GT101DC Solid State Hall-Eect Sensor and the ETI Systems 10-Turn Wire-Wound
1 kΩ Rated Precision Potentiometer. A brief description of the functional mechanism which
governs each of these sensors, and the errors which are likely to be encountered during their
operation in the TARGET vehicle follows.
The GPS Unit
The GPS unit receives and processes data from the GPS satellite constellation and outputs
its own position in space. The Navigation Satellite Timing and Ranging Global Positioning
System (NAVSTAR GPS) constellation comprises 24 satellites which orbit in 6 planes about
the Earth as shown in Figure 3.7.
25 Chapter 3. Literature Review
Figure 3.7: The NAVSTAR GPS constellation (GPS)
Each of these satellites transmits a navigation message, consisting of ephemeris data, a pseudo
random noise sequence and a variety of other data which is not relevant to this discussion.
The ephemeris data describes the current position of the transmitting satellite in its Keplarian
orbit and the pseudo random noise sequence is used to determine the time of travel of the
GPS signal from the satellites to the receiver. These signal travel times and the ephemeris
data provide sucient information for the receiver to trilaterate its own position in space
(of Defence, 1995). The receiver may also calculate its own velocity using the time delay
between successive position measurements; for this reason the GPS velocity is known as the
Doppler velocity.
The main causes of GPS position errors are listed in the following paragraphs and the correc-
tion method used by the Novatel OEM4-G2, shown in Figure 3.8, is also described.
Atmospheric Delays
The periodically varying density of the atmosphere causes the GPS signal to slow down as it
passes from the transmitting satellite to the GPS receiver unit. Unaccounted for, these delays
cause position errors which vary from zero to forty meters over the course of a year. However,
an accurate model of the Earth's atmosphere currently exists and may be used to drastically
reduce this error gure (Herrington, 1995). The OEM4 family user manuals do not mention
atmospheric delay corrections, however, since the atmosphere model is well documented, and
since the typical position error range of the OEM4 unit is stated to be in the order of two
3.4. State Estimation and Measurement 26
Figure 3.8: The Novatel OEM4-G2 GPS processing card with accompanying Novatel GPSAntennaTM Model 511
meters, it is assumed that the OEM4-G2 unit incorporates the model into its position solution
to correct for the majority of atmospheric delays.
Ephemeris Errors
Ephemeris errors occur when a satellite transmits its own position erroneously (Kelly, 1994c).
Since the receiver uses the satellite positions to determine its own position, ephemeris errors
result in a GPS receiver position error. This error is well described by zero-mean, Gaussian
noise with a standard deviation of the order of 0.5 meters (Herrington, 1995). The OEM4-G2
has no means of correcting against ephemeris errors.
Multipath
Multipath errors occur when the signal transmitted from a GPS satellite is refelcted o an
object prior to reaching the receiver. The reection results in an extended transmission path
which the GPS receiver does not account for and hence the position is miscalculated by the
receiver. To combat this unwanted phenomenon, GPS signals are broadcast at frequencies
of 1227.6MHz and 1575.42MHz (known as the L1 and L2 bands respectively) which tend to
undergo diuse reection, i.e. the reection is dispersed, (Herrington, 1995), thus reducing
the likelihood that the receiver will encounter a multipath signal. In addition, the majority
of multipath signals encountered in open areas (such as the test grounds for the TARGET
vehicle) approach the receiver antenna at an elevation angle close to, or below, the horizontal
since they are reected o the ground. To eliminate the majority of these multipath signals,
the Novatel GPS AntennaTM Model 511 masks satellite signals below a user-dened elevation
angle (Inc, 2003).
27 Chapter 3. Literature Review
Receiver Noise
Receiver noise is a product of quantisation noise and hardware inaccuracies within the GPS
receiver (Herrington, 1995). The OEM4-G2 does not prevent receiver noise, however it con-
stantly estimates the internal noise level (particularly thermal noise), and uses this gure to
compute the standard deviation of the position solution (Inc, 2003).
Dilution of Precision
Dilution of precision (or DOP) of the GPS position solution occurs when a signicant number
of the satellites visible to the receiver antenna are closely spaced (Herrington, 1995). The
eect of DOP is to amplify the other position solution errors, at most by a factor of three.
The OEM4-G2 calculates the DOP status from ephemeris data every 60 seconds and uses the
resulting value to update its estimate of the standard deviation of the position solution (Inc,
2003).
Signal Masking
Signal masking, also known as signal dropout, occurs when objects block or distort the trans-
mitted signals from a signicant number of GPS satellites, such that the position solution
becomes unavailable (Caron et al., 2006). Typical objects which are likely to cause signal
masking for the GPS receiver on the TARGET vehicle are trees, tall buildings, power lines
and the Earth itself. The Global Positioning System alone oers no remedy for signal masking,
however other sensors may be used to provide position data during periods of GPS unavail-
ability. This technique forms a major part of the State Estimation and Measurement process
covered in this report.
The combined eect of the above errors on the OEM4-G2 receiver is a GPS position solution
with superimposed zero-mean Gaussian noise (due to the atmospheric delays, ephemeris data
and receiver noise), occasional position jumps (due to multipath eects) and occasional total
position loss (due to signal masking). The position (containing multipath errors) and the
standard deviation of the Gaussian noise component of this signal are output by the OEM4-
G2.
The IMU Sensor
The technology used in Inertial Measurement Units (IMUs) varies greatly across the market,
with dierent brands sensing quantities as diverse as the inertial properties of light (Herring-
ton, 1995), and the nuclear properties of Cesium (Ces) to obtain the relevant data. Rather
than providing a review of the existing technologies, a forecast of the errors likely to be present
3.4. State Estimation and Measurement 28
in the output signal of the Microstrain 3DM-GX1 IMU is attempted in this section. There-
fore only the functional mechanism of the Microstrain 3DM-GX1 IMU, used in the TARGET
vehicle, is discussed.
The 3DM-GX1, shown in Figure 3.9, contains DC accelerometers, gyroscopes and magne-
tometers (MicroStrain, 2006). The DC accelerometers are mounted triaxially, i.e. parallel
to each of the three orthogonal axes. Each accelerometer consists of a capacitive plate xed
to the rigid structure of the IMU and separated from another capacitive plate by polysilicon
springs. The springs are positioned such that they do not distort the capacitance. The output
of the capacitors is a voltage, whose change is proportional to acceleration (Analogue Devices
Inc, 2004a). This setup enables measurement of positive and negative static accelerations
along the three orthogonal axes.
Figure 3.9: The Microstrain 3DM-GX1 IMU
The gyroscopes within the 3DM-GX1 are also installed in a triaxial conguration (MicroS-
train, 2006). Each consists of two tines axed to a dither frame, as shown in Figure 3.10.
The dither frame vibrates and causes the tines to resonate antiphase, such that the center of
gravity of the assembly does not move. When the assembly is rotated, a Coriolis acceleration
is produced causing the tines to vibrate as indicated in Figure 3.10. The capacitance between
electrically conducting plates axed to the ends of the tines, and plates located between the
tines attached to the solid structure of the IMU, provides a measure of the angular rate of
rotation (Analogue Devices Inc, 2004b).
The 3DM-GX1 also contains three magnetometers mounted orthogonally, each utilising a
uxgate setup to determine the strength of the Earth's magnetic eld. The uxgate setup
consists of an iron core encircled by two conductive and electrically insulated wires. In the
absence of a magnetic eld, when an AC current is passed through one wire, the other wire
is induced to output the same signal. However, in the presence of a magnetic eld, a phase
29 Chapter 3. Literature Review
Figure 3.10: The gyroscope assembly (Verplaetse, 1996)
dierence, approximately proportional to the strength of the sensed magnetic eld, exists
between the input signal and the output signal (Deak et al., 2000).
Each of the components which constitute the 3DM-GX1 have limitations and the 3DM-GX1
attempts to correct for these in some instances.
Accelerometer Errors
The variation in temperature alters the properties of the polysilicon springs in the accelerom-
eters thus introducing a bias. However, the 3DM-GX1 incorporates readings from an onboard
thermometer to virtually eliminate these temperature eects (MicroStrain, 2006). Also, due
to the natural resonances of the accelerometer structure, the dynamic response of the ac-
celerometers is poor. However, the 3DM-GX1 corrects this error by low-pass ltering the raw
accelerometer data. Another error in the acceleration readings is due to non-orthogonality of
the three accelerometers due to imprefect construction. The 3DM-GX1 quotes this bias at a
maximum of 0.2% over a wide temperature range, however no correction is provided for this
error.
Gyroscope Errors
The variation in temperature alters the stiness of the tines and dither frame within the gyro-
scope (refer to Figure 3.10), thus introducing an error in the scale of the angular rate reading.
Again, the 3DM-GX1 incorporates readings from the onboard thermometer to attempt to
eliminate these temperature eects (Microstrain, 2006). In contrast to the accelerometers,
the gyroscopes provide accurate dynamic results, but an inaccurate static response. To im-
prove the static response, the 3DM-GX1 fuses the gyroscope data with the data from the
magnetometers, which has a good static response. Non-orthogonality of the three gyroscopes,
resulting from imperfect construction, is also an issue. The 3DM-GX1 quotes this bias at a
maximum of 0.2% over a wide temperature range, however no correction is provided for this
error. The nal error is a saturation of the gyroscope angular rate reading, on the 3DM-GX1
3.4. State Estimation and Measurement 30
Figure 3.11: The Honeywell GT1 Series 1GT101DC Solid State Hall-Eect Sensor (Honeywell,2006)
this occurs at 300 degrees per second. However since it is impossible for a large vehicle to
rotate this quickly, this error has no implications on the TARGET vehicle system.
Magnetometer Errors
Temperature has no eect on Fluxgate magnetometers, however distortions in the local mag-
netic eld, such as those caused by rotating machinery and certain stationary metals, may
cause any angle of magnetometer error bias. The hard-iron calibration procedure for the
3DM-GX1 is inteded to correct for these errors. The calibration is conducted by axing the
unit to its intended platform and rotating the entire assembly (in the case of the TARGET
the IMU is xed in place, then the vehicle is driven in a circlar path). The unit gathers data
over the rotations and calculates the distortions in the local magnetic eld. These distortions
are then subtracted from the magnetometer readings to result in unbiased measurements.
Furthermore, misalignment during construction accounts for an orthogonality error of 0.2%
(MicroStrain, 2006).
The Hall-Effect Sensor
There are two broad categories of Hall-Eect sensors: those with magnetic pickups and those
with non-magnetic pickups. The Honeywell GT1 Series 1GT101DC Solid State Hall-Eect
Sensor, shown in Figure 3.11, uses non-magnetic pickups. This design and any inherent aws
are discussed.
Non-magnetic pickup hall eect sensors create and monitor a magnetic eld. Any ferrous
object in close proximity causes distortion of the eld and therefore may be sensed. The
Honeywell GT1 Series 1GT101DC Solid State Hall-Eect Sensor uses this principal to trigger
the rising edge of the unit's output pulse-wave voltage. The Hall-Eect sensor may be used
to monitor the speed of the vehicle by facing the the unit at equally spaced pickups axed
31 Chapter 3. Literature Review
to any shaft rotating in synchronisation with the wheels. The sensor has a good low speed
response and a bandwidth of 3600 RPM, (Honeywell, 2006) which is sucient for the speed
range of the TARGET vehicle. As already mentioned, the Honeywell 1GT101DC outputs
a pulse wave voltage; however for compatibility with the onboard computer, this voltage is
converted to an analogue value. A likely error, therefore, is analogue noise in the voltage
signal due to sources such as the vehicle distributor, starter motor and other power sources.
The sum of these errors may be modeled as Gaussian noise with a zero-mean distribution,
Carlson (2004).
The Potentiometer
The potentiometer is by far the simplest sensor utilised in the TARGET vehicle. The output
voltage from the sensor is proportional to the angular position of the sensor, as long as a
voltage is applied across the input terminals. The sensor is an ETI Systems 10-Turn Wire-
Wound 1 kΩ Rated Precision Potentiometer, shown in Figure 3.12, and is mounted via a belt
connection to the steering column.
Figure 3.12: The ETI Systems 10-Turn Wire-Wound 1 kΩ Rated Precision Potentiometer(ETI Systems, 2006)
The potentiometer is capable of turning 10 times, which is sucient to sense the angle of
the TARGET vehicle steering column from fully locked to the left to fully locked to the
right, when passed through the belt connection to the pulley assembly. Sensor fatigue is
not envisaged to be an issue as the sensor has a 25000 cycle lifespan (ETI Systems, 2006).
However, electrical noise on the analogue output voltage is likely to be the major source of
error in the potentiometer readings, since the output cable runs through the TARGET vehicle
cabin, near several motors and the distributor. This error may be modeled as Gaussian noise
with a zero-mean distribution, Carlson (2004).
3.4.2 Kalman Filter Comparison
As has already been mentioned, the process of State Estimation and Measurement involves
improvement of sensor data in real-time, to produce a set of states which may be used to
3.4. State Estimation and Measurement 32
perform automatic control. Based on the errors presented in Section 3.4.1 (in particular the
GPS dropout) the sensor data will require fusion if observability is to be maintained. Also
a form of ltering will be required, to remove the noise in virtually all of the signals. The
Kalman Filter, developed by Rudolph Kalman in 1960 (Welch and Bishop, 2001), achieves
all of these things. For these reasons vehicles which use the above sensor suite typically
employ Kalman Filters (Vest, 2005; Brogdon et al., 2005). Kalman Filters are essentially a
set of iterative equations which run in real-time and attempt to combine sensor data into an
optimal estimate of the vehicle states. Kalman lters come in many forms and these are listed
in Table 3.1.
Table 3.1 is used in Chapter 5 for the purpose of selecting a Kalman Filter for implementation
in the TARGET vehicle.
3.4.3 Earth Coordinate systems
The OEM4-G2 Global Positioning System sensor available to this project has the capacity to
output data in two coordinate systems (or datums): the Earth-Centered Earth-Fixed (ECEF)
datum and the Geodetic datum. If data, referenced to either of these datums, is required for
state updates by the Kalman Filter, then the datum of the data must rst be transformed to
the Tangent Plane datum. These three datums are now described.
The Earth Centered Earth Fixed (ECEF) Datum
The ECEF datum comprises three orthogonal axes whose origin is the Earth's center of
mass, as shown in Figure 3.13. The X-Axis passes through the intersection of the Greenwich
Meridian and the Equator, the Z-Axis is parallel to the rotational axis of the Earth and
passes through the North Pole, and the Y-Axis is dened such that the coordinate system is
right-handed. The locations at which the coordinate axes penetrate the surface of the Earth
remain constant for all orientations of the Earth, i.e. the coordinate axes turn as the Earth
turns (Xu, 2003).
The Geodetic Datum
The Geodetic Coordinate System, shown in Figure 3.14, comprises three dimensions - Lati-
tude, φ, Longitude, λ, and Height, h. The denitions of these three Geodetic dimensions rely
on a construction line which passes through the point of interest at a normal to the surface
of the Earth. This line is hereby referred to as the Normal Line. Latitude is dened as the
33 Chapter 3. Literature Review
Table 3.1: Kalman Filter comparisonsKalman Filter
TypeAdvantages Disadvantages
Linear• Provides an optimal estimateof the states, minimising sensornoise, (Kelly, 1994b).
• Pre-calculation of lter matri-ces reduces computational bur-den (Carlson, 2004; Rezaei andR., 2003).
• Easily understood and imple-mented
• Only applicable to sys-tems of purely linearrelationships (Conner,2000).
• Noise must be zero-mean, white and Gaus-sian (Rezaei and R.,2003).
Extended
• Applicable to both linear andnon-linear systems (Conner,2000).
• Relatively easily understood andimplemented
• Not a formally optimalsolution (Zhao et al.,2003).
• Only reliable for systemswhich are almost linearon the time scale of up-date intervals (Julier andJK, 1997).
• Noise errors accumulategradually over time (Ma-tia et al., 2006).
Unscented
• Noise is required to be Gaussian(Julier and JK, 1997).
• Superior performance to the Ex-tended Kalman Filter (Julierand JK, 1997).
• The mean and covariance prop-erties of the noise are calculatedthrough the unscented processand therefore need not be knownin advance
• Dicult to understandand implement
Fuzzy
• Noise is not required be sym-metrically distributed about themean (Matia et al., 2006).
• Noise errors may be forced notto accumulate over time (Matiaet al., 2006)
• The process is computa-tionally expensive
3.4. State Estimation and Measurement 34
Figure 3.13: The Earth-Centered Earth-Fixed Datum
angle between the plane of the Equator and the Normal Line and is positive for points which
lie above the Equator (i.e. the North Pole has a Latitude of 90o). Longitude is dened as the
angle between the projection of the Greenwich Meridian onto the plane of the Equator and
the projection of the Normal Line onto the plane of the Equator and spans −180o to 180o.
The Geodetic Height is dened as the distance from the surface of the earth (at mean sea
level) to the point of interest along the Normal Line (Xu, 2003).
Figure 3.14: The Geodetic Datum
The Tangent Plane
The Tangent Plane, shown in Figure 3.15, simply consists of a plane, tangential to the surface
of the Earth at the point of interest. Three axes dene the the Tangent Plane Datum,
35 Chapter 3. Literature Review
namely the North axis, N , which points along the lines of constant latitude, the East axis,
E, which points along the lines of constant longitude and the Height, H, which is dened
exactly the same for the Tangent Plane Datum as for the Geodetic Datum (Herrington,
1995). Continuously resolving the coordinates of a moving object into the Tangent Plane
eectively maps the trajectory of the object from the ellipsoid of the Earth to a single plane.
Figure 3.15: The Tangent Plane
3.5 Autonomous Guidance Control
The Autonomous Guidance Control section of the TARGET project encompasses the devel-
opment and systems-integration of an autonomous waypoint-based guidance controller for the
ground target vehicle. Literature was selected on the basis of relevance, research category,
publication date, and language criteria as outlined in Table 3.2.
Table 3.2: Autonomous Guidance Control research criteriaCriteria for Inclusion Criteria for Exclusion
Relevance Autonomous, motion /guidance / path tracking /path following / waypointfollowing control of car-likevehicles
Focus on obstacle avoidance;control of non-car-like vehicles(such as UAVs and AUVs)
Research Category Academic research in the areaof engineering, computerscience, and mathematics andassociated journals
Any other research category
Publication Date 1990 to 2007(but the more recent articleswere preferred)
Published before 1990
Language English Not English
3.5. Autonomous Guidance Control 36
As obstacle avoidance strategies were considered to be beyond the scope of the design project,
being nonessential for the achievement of the project goals (refer to Section 2.2) and unfeasible
within the given time and monetary constraints, this further reduced the eld of review.
The literature analysis revealed three central themes in the guidance control literature: hi-
erarchical control structures, path tracking control methodologies, and path tracking control
parameters. These themes will be discussed before oering a summary and a list of resulting
recommendations that were considered in the TARGET project's own autonomous controller
design.
3.5.1 Theme One: Hierarchical Control Structure
The notion of a hierarchical control structure was identied as a common element (either by
direct reference or underlying assumption) throughout much of the autonomous vehicle control
literature (Conner, 2000; Barton, 2001; Coelho and Nunes, 2003). The task of autonomous
motion control was generally divided into two complementary sections that could basically be
described as high-level control and low-level control.
The high-level control stage tended to be concerned with decision-making tasks including path
planning and path tracking responsibilities. It would therefore receive broad and intermittent
vehicle motion goals, generally in the form of position waypoints, along with vehicle sensory
information (such as position, heading and speed) and consequently make intelligent decisions
on the particular driving actions that the vehicle should take in order to best achieve the
specied motion goals. The high-level control could therefore be described as a form of
guidance control.
The low-level control stage, on the other hand, was generally responsible for implementing
the desired vehicle actions as determined by the high-level controller. Such action / motion
execution control would therefore regulate the control of the vehicle actuators (such as steering,
brake, and throttle motors) in order to safely, accurately and rapidly achieve the particular
vehicle motion setpoints provided by the high-level guidance controller (such as steering angle
and vehicle speed commands). Thus the high-level decision-based guidance control and the
low-level action-based motion execution control work together in series to provide a holistic
autonomous control of vehicle motion. Such hierarchical control architecture also clearly
reects a traditional conception of the general automatic control paradigm the perception
- decision - action philosophy (Fraichard, 2001). Thus for the purposes of the TARGET
vehicle project, the Autonomous Guidance Control section is concerned with the design of a
high-level decision-making guidance controller, whereas the lower-level action control is the
responsibility of the Motion Execution Control task (discussed in Sections 3.6 and 6.3).
37 Chapter 3. Literature Review
3.5.2 Theme Two: Path Tracking Control Methodologies
Having identied the general architecture that underlies much of the autonomous vehicle
control literature, it is appropriate to enter into a discussion of the generic systems that have
been suggested and developed for such an application. Suárez et al. (2003) have loosely divided
path tracking control systems into two main categories which they refer to as temporal and
spatial. The temporal label has been used to designate autonomous motion control regimes
that are based on the direct application of standard control theory in which the goal is to
reach a specied location at a specied time. Spatial, on the other hand, refers to control
regimes which stem more from geometric relationships, in which the goal is to simply stay as
close as possible to a specied geometric path (Egerstedt et al., 2001). However, this is not
necessarily a strict separation as many strategies combine both spatial and temporal aspects
to varying degrees. In the proceeding discussion some of the common spatial and temporal
autonomous motion control regimes will be introduced.
3.5.2.1 Spatial Regimes
The spatial category incorporates a range of motion control strategies which are known broadly
as pursuit techniques. Many geometric pursuit techniques and variations have been developed
for path tracking control including (in increasing complexity):
• follow-the-carrot (Barton (2001); Golconda (2005)),
• pure pursuit (Kelly (1994a); Mörtberg (2006); Caravita et al. (2007); Barton (2001)),
• and vector pursuit (Wit et al. (2004); Mörtberg (2006); Barton (2001)).
The pursuit strategies generally decide the appropriate path tracking action based on the
vehicle's instantaneous conguration (orientation and / or position) relative to a continuously
updated path reference point called the carrot or goal point, which is dened as the path
point that is a lookahead distance further along the path (Barton, 2001). The actual vehicle
motion decision process generally takes the form of a weighted sum involving the multiplication
of proportional gains with heading errors and / or lateral position errors measured between
the vehicle and the carrot point.
Figure 3.16 depicts the follow-the-carrot and pure pursuit path tracking control strategies,
both of which utilise a carrot point, lookahead distance and heading error. The dierence
between these two techniques relates to the trajectory generated by the controller when guid-
ing the vehicle towards the carrot point. The follow-the-carrot method attempts to steer the
vehicle directly towards the carrot point (along a straight line), whereas the pure pursuit
strategy seeks to return the vehicle via a circular arc trajectory (Caravita et al., 2007).
3.5. Autonomous Guidance Control 38
(a) Follow-the-carrot (b) Pure Pursuit
Figure 3.16: Follow-the-carrot and pure pursuit path tracking control strategy (sourced fromBarton (2001))
Figure 3.17: Virtual vehicle spatial guidance control strategy
The screw theory based vector pursuit method extends the approach to consider the orienta-
tion of the carrot point in addition to its location, and is also able to account for the vehicle's
nonholonomic constraints (such as a maximum steering angle and maximum turning rate)
which restrict its motion capabilities (Wit et al., 2004; Barton, 2001).
Another spatial strategy which diverges slightly from the above pursuit techniques is the vir-
tual vehicle approach, depicted in Figure 3.17. In the standard formulation of the virtual vehi-
cle approach, the vehicle's instantaneous conguration is compared to a continuously updated
reference point, loosely dened as the closest path point to the vehicle (see Section 6.2.1.1 for
more details), and its associated path segment (Barton, 2001). By considering the relative
orientation between the closest path segment and the vehicle (in addition to the relative po-
sition), the virtual vehicle technique also enables the guidance controller to align the vehicle
with the path orientation rather than simply guiding the vehicle directly towards a particular
position on the path (which inherently leads to overshoot problems). This essentially enables
a much smoother and intuitive path following ability.
39 Chapter 3. Literature Review
3.5.2.2 Temporal Regimes
The so-called temporal path tracking regimes can be loosely subdivided into control systems
that contain a kinematic or dynamic mathematical vehicle model and those which do not
(Castaño et al., 2004). Typically, temporal path tracking control systems, whether math-
ematical or non-mathematical, operate on errors between xed (waypoint-dened) vehicle
state commands and the actual measured states of the vehicle (such as position, heading,
and speed).
The mathematical category of temporal path tracking regimes describes a variety of state-
space techniques including the Linear Quadratic Regulator / LQR (Bevly et al. (2002); Naeem
et al. (2003)) and other linear (Coelho and Nunes, 2003) and non-linear (Switkes and Gerdes,
2005; Cordesses et al., 2000; Sharp et al., 2000) control laws. If provided with an accurate
mathematical vehicle model, such controllers are capable of very high precision path following
(Barton, 2001). For instance, Barton (2001) cites a case where an implemented state-space
based autonomous controller was able to achieve path tracking of a passenger vehicle to
within 0.15 metres in dry conditions, and 0.3 metres in wet. However, building an accurate
mathematical model of a non-linear, high dimensional system can also be a dicult and
labour-intensive task.
The other temporal category includes control systems based on the application of fuzzy logic
or neural networks, which do not require an explicit mathematical vehicle model and yet
are capable of providing control over highly non-linear processes including that of vehicle
guidance (Fraichard, 2001). Such systems tend to be based on rules formed from expert or
experiential knowledge of process behaviour, which in this case is vehicle driving behaviour.
These rule sets can become quite large for complex processes, and as a result the fuzzy control
styled approach can be relatively computationally expensive compared to some of the other
methods, though this varies depending on the choice of rule arbitration technique.
3.5.3 Theme Three: Path Tracking Control Parameters
While the literature's range of overarching path tracking control methodologies has been
reviewed, the discussion will now turn to the particular control parameters that have been
used within these strategies. It is worth rst noting that while high-level steering control has
been given extensive coverage throughout the autonomous motion control literature, high-
level speed guidance has received little attention. Rather, there seems to be a dominating
assumption that speed commands should simply be supplied along with position waypoints
(for example Holden (2004)). In some of the literature saturation / limiting has been described
as a means of ensuring that steering decisions are appropriate (and safe) given the vehicle's
speed (Kelly, 1994a; Sharp et al., 2000; Golconda, 2005). This is a gap in the current literature
that deserves to receive greater attention. Thus the control parameters presented in this
section are based on the steering component of autonomous guidance control alone, though
some may also prove to be useful for speed guidance.
3.5. Autonomous Guidance Control 40
Figure 3.18: Spatial guidance control parameters of cross-track error, d⊥, and heading error,θe
In the case of typical temporal control strategies the control parameters tend to simply be
the errors between the desired and actual vehicle states (such as position, orientation, and
speed). The spatial control strategies, however, naturally extend the possibilities of parameter
selection beyond the pure vehicle states and have therefore been found to have a variety
of parameters represented within the autonomous motion control literature. A number of
common spatial control parameters include cross-track error, heading error, and various forms
of feedforward.
3.5.3.1 Cross-track Error
As identied in Figure 3.18, the cross-track error, d⊥, (with a number of synonyms including
lateral deviation) is a term for the perpendicular distance from the relevant path point or
segment to the origin of the vehicle coordinate frame (Holden, 2004; Elkaim et al., 2006). It
is therefore a measure of the position error between the vehicle and the path. Consequently, a
guidance controller equipped with a cross-track control parameter attempts to minimise the
cross-track error and thereby return the vehicle to the desired path.
Proportional control of the cross-track error was the most common (Holden, 2004; Sharp
et al., 2000), however PI (proportional plus integral) control was presented in Suárez et al.
(2003) and also Elkaim et al. (2006). The added integral control had the advantage (in typical
fashion) of alleviating any steady-state cross-track error which prevents the error from being
driven to zero even after the control signal has settled (Suárez et al., 2003).
41 Chapter 3. Literature Review
3.5.3.2 Heading Error
Heading error (or orientation error), θe, as indicated in Figure 3.18, was another control
parameter frequently incorporated into path tracking controller designs. The particular con-
struction of the heading error depended on the overarching control strategy. In all cases, the
rationale of heading control was to direct the vehicle to the desired path, but in some cases
(such as with the virtual vehicle approach and vector pursuit) the objective was extended
to also returning the vehicle with an orientation that matched that path that is, to ap-
proach the desired path asymptotically. Control of heading error tended to be implemented
as proportional control (Sharp et al., 2000; Elkaim et al., 2006). However, a PID controller
for producing steering direction setpoints based on heading error was described in Golconda
(2005).
3.5.3.3 Feedforward Terms
In a number of cases the guidance controllers in the literature incorporated a feedforward
component to their path tracking. In relation to path tracking, feedforward generally refers
to the variety of path preview strategies that can be used to provide anticipatory path follow-
ing motion commands. It can also be used to account for delays in the implementation of the
control signal (Mörtberg, 2006). Without a feedforward term, the autonomously controlled
vehicle will tend to lag behind the desired path (especially when cornering) as the control
system can only produce a control action once there is an error between the vehicle congura-
tion and the path point or path segment (Barton, 2001). Appropriate feedforward terms can
eliminate this lagging behaviour by ensuring that the appropriate corrective action is taken
before the vehicle actually deviates from the path.
A basic form of feedforward control is inherent in the pursuit techniques that were previ-
ously described (Section 3.5.2.1) since the control action is determined by reference to a path
point (carrot point) that is a lookahead path distance beyond the vehicle. However, more
complicated feedforward strategies were also present in the literature. Sharp et al. (2000);
Sharp and Valtetsiotis (2001); Castaño et al. (2004) and Switkes and Gerdes (2005) all utilise
a feedforward technique based on a projected cross-track error. Barton (2001), on the other
hand, oers a feedforward parameter which is an estimate of the average steering angle of an
upcoming number of path segments. Barton (2001) has recorded signicant improvements of
this feedforward approach over equivalent feedback systems, as can be seen from a comparison
of the simulated results depicted in Figure 3.19 and Figure 3.20.
3.5.4 Summary and Recommendations
The Autonomous Guidance Control Literature Review has identied and discussed three
main themes relating to the guidance control of a car-like vehicle. The rst was the use of
3.5. Autonomous Guidance Control 42
Figure 3.19: Simulated path following using a feedback controller (sourced from Barton(2001))
43 Chapter 3. Literature Review
Figure 3.20: Simulated path following using an additional feedforward term (sourced fromBarton (2001))
3.6. Motion Execution Control 44
hierarchical control structures in which a high-level decision-making autonomous guidance
controller feeds vehicle motion setpoints into a lower-level motion execution controller which
in turn implements the motion setpoints by controlling the vehicle actuators. The second
theme was that of path tracking control methodologies which could be separated into spatial
(associated with geometry) and temporal (generated by standard control theory) strategies.
The nal theme introduced three commonly identied spatial path tracking control parameters
cross-track error, heading error, and various forms of feedforward.
In light of this review, the following recommendations were made for the TARGET project's
autonomous control task:
• The autonomous control be endowed with a hierarchical control structure in which a
high-level decision-making autonomous guidance controller feeds autonomous vehicle
motion setpoints into a lower-level action-based motion execution controller;
• The virtual vehicle approach and fuzzy control strategies be considered for their poten-
tial to provide good performance and a reasonably accessible design ow;
• Cross-track error (possibly in combination with PI control), heading error, and a path
preview form of feedforward such as a projected steering angle be considered as viable
path tracking control parameters.
The development of the TARGET vehicle's Autonomous Guidance Controller is discussed in
Section 6.2.
3.6 Motion Execution Control
Motion Execution Control aims to achieve control of the steering and speed of the vehicle,
with inputs from either the handheld remote-controller or the autonomous control system.
The steering controller achieves control of the vehicle's steering by sending signals to the
steering actuator, and the speed controller performs open loop and closed loop speed control
by sending signals to the brake and throttle actuator. The steering and speed controllers are
considered separately.
3.6.1 Steering Control
Many steering control systems have been designed using Proportional Integral Derivative
(PID) or a mixture of PI or PD control (Kodagoda et al., 2002) depending on the implemen-
tation of the actuators. These types of controllers allow for good set point following with
low overshoot and fast rise times if the controller is tuned properly. However, they are only
eective for systems that are linear, and are not as eective at controlling non-linear systems.
45 Chapter 3. Literature Review
A common vehicle model to use is the simple three degree of freedom lumped bicycle model.
This simple model can also be linearized easily and so can be applied to PID control.
A PID controller which also included a feed forward loop (FPID) was implemented in the
control of an o road agricultural vehicle (Qiu and Zhang, 2003). An electro-hydraulic steering
system was used in the vehicle, and the purpose of the feed forward loop was to compensate for
the dead band, saturation and non-linearity which are inherent in this type of actuation. The
comparison of results included the FPID controller as well as the feed forward controller alone
and the PID controller alone. Two of the Figures comparing the performance characteristics
are shown below (Qiu and Zhang, 2003). Figure 3.21 shows a tuned PID controller with a
sinusoidal and step steering input and Figure 3.22 shows a tune FPID controller with the
same inputs. As can be seen, the FPID controller gives slightly better performance, as there
is better set point following, however the PID also gives acceptable performance, with a
little higher overshoot in the step commands and a little steady state error in the sinusoidal
commands. The addition of this feed forward loop will not be necessary for the platform
vehicle chosen for this project, as complex vehicle model will not be required and a common
power steering system will be present.
Figure 3.21: Tuned PID controller (Sourced from Qiu and Zhang (2003))
3.6. Motion Execution Control 46
Figure 3.22: Tuned FPID controller (Sourced from Qiu and Zhang (2003))
3.6.2 Throttle / Brake Switching Logic
The speed controller will control the speed of the vehicle by actuating both the throttle and
brake pedal. The speed controller design requires that the throttle and brake are not actuated
simultaneously. This is to ensure that speed control is smooth, and extra wear and tear on
the braking system is avoided. So switching logic must be incorporated in the system. Speed
controller designs in literature have implemented switching logic by applying a boundary layer
to a switching line (Kwon et al., 2001). The switching line indicates the acceleration of the
vehicle when both actuators are in their minimum position, for any speed. Throttle control
is used when the desired acceleration is above the switching line, and brake control is used
when the desired acceleration is below. Switching between controllers only occurs when the
desired acceleration is not within the boundary layer. The boundary layer is a small area on
either side of the switching line. Controller switching does not occur while in the boundary
layer to prevent frequent switching between throttle and brake control. Figure 3.23 illustrates
the controller switching logic, with the switching line (line of minimum acceleration) and
boundary layer.
47 Chapter 3. Literature Review
Figure 3.23: Throttle / brake switching logic as implemented (Sourced from Kwon et al.(2001))
The switching line with boundary layer approach implemented by Kwon et al. (2001) achieves
successful switching between throttle and brake controllers, without allowing frequent switch-
ing. A similar switching logic is implemented on the throttle and brake controllers developed
for the TARGET vehicle. However, the controllers used in this project use speed as the feed-
back, unlike the controllers used by Kwon et al. (2001) which used acceleration as the input.
Therefore the switching line used by Kwon et al. (2001) is unnecessary, and is replaced with
logic that compares the current speed to the desired speed. The boundary layer approach
to the switching line is still highly relevant, and incorporating it into the design will prevent
frequent controller switching.
3.6.3 Throttle Control
The throttle control system aims to actuate the throttle of the vehicle to control speed. Several
throttle control designs have been identied from the literature, including a PI controller
(Kwon et al., 2001), a xed gain PID controller, a gain scheduled PID controller, and an
adaptive controller (Ioannou and Xu, 1994).
The PI throttle controller developed by Kwon et al. (2001) controlled speed of the vehicle by
manipulating the throttle. The desired speed was converted to a desired acceleration prole,
using optimal control to prevent large accelerations or decelerations that could cause driver
discomfort. A desired throttle angle position was calculated from the desired acceleration,
and this term was summed with a PI controlled acceleration term to give a controlled throttle
output (see Figure 3.24). Performing the calculations to obtain desired throttle angle from
desired acceleration is very dicult to achieve, as knowledge of the vehicle's gear and the
3.6. Motion Execution Control 48
engine map is required. The PI throttle controller achieved satisfactory control of vehicle
acceleration. Test results for step inputs to the controller are shown in Figure 3.25. Note that
the slow rise times of the vehicle's speed are desirable in this case to avoid driver discomfort.
Figure 3.24: PI throttle controller block diagram (Sourced from Kwon et al. (2001))
Figure 3.25: PI throttle controller test results (Sourced from Kwon et al. (2001))
The xed gain and gain scheduled PID controllers developed by Ioannou and Xu (1994) used
a slightly dierent approach to the PI throttle controller. The xed gain PID controller
simply introduced a derivative error term. The gain scheduled PID controller improved on
the performance of the xed gain controller by scheduling the gain for dierent operating
points. The method of gain scheduling was used to provide tuned gains for various operating
points, to overcome the problem of non-linearity. Test results for the two controllers found
in the literature show similar responses, and were considered satisfactory in both cases. The
xed gain controller was found to be slightly inferior to the gain scheduled controller, due to
oscillations in acceleration and driver discomfort at low speeds.
The adaptive controller developed by Ioannou and Xu (1994) was designed to provide a speed
controller that was self-adapting to the system parameters. The controller structure was too
complicated to be considered for use in the project. Test results for the controller showed a
response superior to the xed gain and gain scheduled PID controllers.
Four controller structures for the throttle were identied; a PI controller, a xed gain PID
controller, a gain scheduled PID controller, and an adaptive controller. As all controllers
achieved satisfactory control of the vehicle's speed, a classical control structure is clearly
adequate for the application.
49 Chapter 3. Literature Review
3.6.4 Braking Controller
An intelligent cruise control (ICC) system was developed as a joint eort between Hanyang
University in South Korea and the Hyundai motor company using a feed forward plus PID
control for the braking system (Kwon et al., 2001). The aim of the system was to provide
for cruise control with sensors to measure the distance to the next vehicle in front of the
development vehicle. If the gap between the two vehicles grew too small, the ICC would act to
increase this gap to a safe distance. Hence, this provides an ICC system which maintains a safe
distance between the development vehicle and the next vehicle ahead. The PID controller is
used to provide good set point following and to allow for fast response and settling times. PID
control usually gives very good performance in linear systems, but do not work very eectively
in non-linear systems. The feed forward loop is used to overcome the non-linear nature of this
system. This type of controller is fairly easy to implement and has a good response, however
the system's dynamic response must be known accurately to create a nonlinear system model.
The performance characteristics of this controller are shown below in Figure 3.26. In this
situation, a vehicle traveling at 90 km/h is used to cut in front of the ICC vehicle traveling at
110 km/h at a distance of approximately 40 m. As can be seen, the braking controller works
to maintain the distance at 40 m. The performance of the controller is acceptable, with fast
set point tracking as seen in Figure 3.26 (c) and (e). The settling times are also fast, and
there is minimal overshoot.
Figure 3.26: PID plus feed forward performance characteristics (Sourced from Kwon et al.(2001))
3.7. Path Generation 50
Figure 3.27: Linear splines between waypoints (Lu, 2007)
3.7 Path Generation
Path generation for the vehicle is essential in maintaining good levels of control. The path
must be generated from a list of user specied waypoints. These calculations were originally
to be carried out by the onboard target computer. However, path generation for the vehicle
was shifted into the base station computer for two reasons. The vehicle's onboard processor
will already be processing large amounts of data by running a Simulink model. Also, by
computing the path at the base station the path can be displayed to the user.
The method used must satisfy two conditions to be suitable for generating a path. Firstly,
the generated path should pass through every waypoint selected by the user. Some numerical
methods generate a function that does not directly pass through the specied points (Spath,
1974). Secondly, the path must be relatively smooth as the vehicle cannot make instantaneous
turns. Any sharp points in the path will be dicult for the vehicle to navigate.
To create a path for the vehicle, splines must be dened between each point. There are
several dierent methods for dening splines and each method will produce a dierent result.
The simplest method is linear splines. Linear splines are simply straight lines drawn between
each point (see Figure 3.27). This method generates a path through every point, but is not
suitable in almost every other characteristic as the path is not dierentially continuous at
each waypoint. The generated path contains sharp deviations and would be dicult for the
vehicle to navigate.
An extension of this method is one which denes a set of linear splines, but then applies
curves between them. This method still generates a simple path but is getting closer to the
path shape required for the vehicle. This path however does not pass through the dened
waypoints. Another method xes this problem by applying pseudo points around the dened
waypoints (see Figure 3.28) before applying the curves. However, for this method to provide
a good path the pseudo points must be strategically placed to prevent a large overshoot. The
resulting path could be generated to give multiple solutions that are feasible but may not be
appropriate.
51 Chapter 3. Literature Review
Figure 3.28: Inserting pseudo points to generate a path (Lu, 2007)
Figure 3.29: Natural cubic splines, identied as a suitable method of path generation, shownin an open path conguration
Two other methods investigated are more complicated requiring many iterations to nd a
solution. B Splines is one such method which uses successive cubic curves to generate a
smooth path. The resulting path is very smooth and continuous, but does not pass directly
through every waypoint dened by the user.
The nal method investigated is called Natural cubic splines. The path it generates is smooth,
continuous and passes through each of the dened waypoints. An example, with 12 waypoints
is shown in Figure 3.29. This is the prefered method for the project and will be discussed in
more detail below.
3.7.1 Open Path
To calculate natural cubic splines, each of the coordinates (longitude and latitude) must be
considered separately and a cubic polynomial is tted between each point. Each Yi (u) denes
3.7. Path Generation 52
a cubic polynomial between waypoint coordinates yi and yi+1. This method is outlined in
Bartels et al. (1987), the solution for the coordinates can be found using Equation (3.1).
Yi (u) = ai + biu + ciu2 + diu
3
where
ai = yi
bi = Di
ci = 3 (yi+1 − yi)− 2Di −Di+1
di = 2 (yi − yi+1) + Di + Di+1
(3.1)
The values of Equation (3.1) are found by solving the system of Equations (3.2). The com-
putational technique for solving this system is also outlined in Bartels et al. (1987).
2 11 4 1
1 4 11 4 1
.... . .
. . .. . .
. . .. . .
. . .
1 4 11 2
D0
D1
D2
D3
...
Dn−1
Dn
=
3 (y1 − y0)3 (y2 − y0)3 (y3 − y1)
...
3 (yn−1 − yn−3)3 (yn − yn−2)3 (yn − yn−1)
(3.2)
The system must be solved twice to obtain a longitude and a latitude path approximation
between the given waypoints. The method produces n − 1 polynomials from n waypoints.
By repeating this process over the entire range of waypoints an array of cubic polynomials
can be obtained. When combined together these polynomials form the smooth path required.
Four boundary conditions must be satised to ensure each polynomial connects smoothly with
the next. These four boundary conditions are dened in Bartels et al. (1987) and shown in
Equations (3.3) to (3.6).
Yi (0) = yi (3.3)
Yi−1 (1) = yi (3.4)
Y′i−1 (1) = Y
′i (0) (3.5)
Y′′i−1 (1) = Y
′′i (0) (3.6)
53 Chapter 3. Literature Review
3.7.2 Closed Path
One advantageous feature of the natural cubic splines is its ability to generate a closed path.
The majority of the automated driving competed by the vehicle will be done with a closed
path.
A method outlined in Bartels et al. (1987) also allows a closed loop path for natural cubic
splines to be calculated. Computational techniques can be adapted from Spath (1974) and
are similar to the open path method (see Equation (3.2)). Instead the values of Di are found
by solving Equation (3.7).
4 1 11 4 1
1 4 11 4 1
.... . .
. . .. . .
. . .. . .
. . .
1 4 11 1 4
D0
D1
D2
D3
...
Dn−1
Dn
=
3 (y1 − yn)3 (y2 − y0)3 (y3 − y1)
...
3 (yn−1 − yn−3)3 (yn − yn−2)3 (y0 − yn−1)
(3.7)
Several factors can aect the overall path generated when using natural cubic splines. If
long distances are left between waypoints then a large overshoot can occur. Due to the
methods used in Equations (3.2) and (3.7) placing waypoints too close together will also
produce a path that is impossible for the vehicle to follow. By introducing extra, strategically
placed, waypoints into the system these problems can be overcome (illustrated in Figure 3.30).
For the purposes of this application it is assumed the user can review the suitability of the
automatically generated path. If a path is unsuitable, the user can redene waypoints until a
suitable path has been generated.
3.8 Background Imagery
The background map is a critical part of the GUI. Without it the user would nd it very
dicult to input waypoints correctly and accurately. A main component of the onscreen
display is the background picture. In order for a picture to appear correctly in the background
the user must rst prepare the image, or at least know some crucial information about the
area in the picture. Several dierent processes can be used in order for the base station to
correctly display an image in the background.
Initially, only two dierent methods were identied for dening a background image. These
two methods are illustrated in Figures 3.31 and 3.32. The rst approach (see Figure 3.31)
requires the denition of just one point and two dimensions, two assumptions are also made.
The rst assumption is the position of the given point. It is assumed to be in the upper left
3.8. Background Imagery 54
(a) The path is impossible for the vehicle to follow around waypoint number 3 and has a large overshootbetween waypoints 4 and 5 caused by the large distance between waypoints 5 and 1
(b) Introducing extra, strategically placed, waypoints improves the path prole. Waypoints 2, 4 and 8have been added.
Figure 3.30: The advantage of adding extra waypoints to construct a smooth and achievablepath
hand corner of the image. The second assumption is that north is located at the top of the
image.
Figure 3.31: The rst, and easiest, method for dening a background image. Dene a referencepoint and specify the height and width of the image. The top of the image is assumed to benorth.
The second approach (see Figure 3.32) requires the denition of three points and requires no
assumptions. The three points will be sucient to completely dene the location, orientation
and skew of the image on the screen.
55 Chapter 3. Literature Review
Figure 3.32: The second, and more complicated method for dening a background image.Place three points on the image. The location, orientation and skew can all be dened bythese points.
Once the user has dened each background image and the conguration le has been gen-
erated, the images must be displayed onto the screen. This is described in more detail in
Chapter 7.
3.9 RF Communications
Wireless communications between the operator and the vehicle are by means of radio fre-
quencies. Short range RF communication is achieved by the use of handheld remote-controls
(handheld radio transmitters) operating at low frequencies while long range communications
require the use of RF modems operating at high frequencies. Details of both methods are
investigated to determine suitable devices that allow manual and autonomous operation of
the vehicle in short range and in long range respectively.
3.9.1 Handheld Remote-Control
The remote manual control operation of the vehicle can be compared to the way hobby aircraft
are controlled. The device for such control is the handheld remote-control (Figure 3.33) that
transmits data by emitting radio waves at low frequencies, typically in the range of 30 MHz
to 40 MHz. Further to the operation of the handheld remote-control is the transmission
of multiple sub-frequencies, also known as radio channels, where each channel is capable of
manipulating the dierent control surfaces of the hobby aircraft such as its ailerons, rudders
and elevators. The concept of controlling a number of control surfaces per radio channel
may be feasible in the project to manipulate the control aspects of the TARGET vehicle
such as speed, steering, transmission etc., hence achieving the goal of remote manual control
operations.
3.9. RF Communications 56
Figure 3.33: A typical handheld remote-control (RF Innovations Ltd Pty, 2007)
3.9.1.1 AM vs FM
RC systems send data signals using either frequency modulation (FM) or amplitude modula-
tion (AM). FM systems encode a signal by varying the frequency of the carrier wave causing
compressions and rarefactions. The receiving end will decode the modulated frequency to
obtain the original signal. AM systems operate using a similar concept with the exception of
varying the amplitude instead of the frequency. Both FM and AM systems are susceptible
to interference that cause changes in amplitude; however the AM signals are most aected
because it relies on correct amplitude readings. Since FM signals are independent of am-
plitude variations, interference levels are minimal for FM signals. For this reason, modern
RC transmitters employ the FM system as it better rejects interference than AM systems.
Therefore it is recommended to select a frequency modulated hand held remote-control.
3.9.1.2 PPM vs PCM
There are two other ways of transmitting data apart from FM and AM. These are Pulse Posi-
tion Modulation (PPM) and Pulse Code Modulation (PCM). Although PPM uses older tech-
nology than PCM, both are still readily used in today's market. The dierences, advantages
and disadvantages between PPM and PCM are summarised in Table 3.3. Despite signicant
dierences between PPM and PCM, it is a matter of personal preference when deciding which
system to operate; which is better for the application. Some handheld remote-controls give
options of both of the FM protocols (PPM and PCM) and is recommended for the project.
3.9.1.3 Frequency Channels
A handheld remote-control has a number of radio channels that are used to send dierent
signals to its receiver. Instead of using these signals to control a model aircraft, the signals
can be manipulated to enable full access to the vehicle controls such as steering, speed, and
ignition. Each of these control aspects require a separate channel in order for it to operate
57 Chapter 3. Literature Review
Table 3.3: Comparison of PPM and PCM Systems for handheld remote-controls (Rother,2007)
PPM PCM
Inherently compact, simplecircuitryAdvantage: inexpensive
Can be small, complexcircuitryDisadvantage: expensive
Analog technologyAdvantage: inexpensive andreceivers may be compatiblewith dierent brandedtransmitters
Digital Technology(microprocessors)Advantage: SophisticatedDisadvantage: must usereceiver of the same brandtype as its transmitter
Representation of signals arenot alteredAdvantage: Servo motorswill move erratically at end oftransmission range, givingearly warning to the operator.
Extremely accurate datasignalsAdvantage: undisturbedservo movementDisadvantage: lack of earlywarning signs can lead toincreased dilemmas
Momentary signal losses are'ironed out' due to inertia ofthe physical system.Disadvantage: cannotdetect error hence false datais present
Has error checking(checksum) and fail safeproceduresAdvantage: prevents falsedata signals and will stop tooshort/long pulses fromdamaging servos as PPMwould
independently. After some experimentation in the laboratory, it was concluded that handheld
remote-controls transmit frequency channels of two dierent types: proportional and switch.
Proportional channels are represented by movable control sticks on the transmitter, where
the frequencies are modulated continuously and in proportion to the positions of the control
sticks. The switch channel is represented by mechanical switches which manipulate discrete
data values. Today's market manufactures a multitude of handheld remote-controls which
typically have four proportional channels and any additional channels being of the switch
type.
3.9.2 RF Modems
Research shows that industrial applications which require long ranged wireless communica-
tions between their vehicles and base stations, nd their solution with RF modems. RF
modems are transceiver devices that modulate an analogue carrier signal to encode digital
information, and also demodulate such a carrier signal to decode the transmitted information
Nagrath (2007). RF modems are readily available on the market and are already being used to
provide wireless communication solutions to such industries as mining and agriculture. A se-
lection of a suitable RF modem for the project requires sucient data transfer rate, reliability
3.9. RF Communications 58
and long range.
Figure 3.34: Caterpillar(TM) Trucks in open-pit mines (RF Innovations Ltd Pty, 2007)
The common requirement between the project and industrial applications is the need of wire-
less communications from a control base station to a mobile platform. Caterpillar(TM)trucks
(Figure 3.34), employed by mining companies, use RF modems to establish an eective com-
munication link from the mining area to the control station for critical vehicle status and
diagnostics. This establishes remote-control over dangerous mining operations in hostile en-
vironments.
Another use for RF modems is for autonomous control in automated processing industries, for
example, Patrick Corporation who implements an automated straddle carrier (Figure 3.35)
using RF modems. In this application RF modems provide a reliable wireless communication
link which was critical to moving cranes eectively and autonomously when required.
Figure 3.35: An Automated Straddle control system by the Patrick Corporation (RF Innova-tions Ltd Pty, 2007)
The two examples given here form the basis of the use of RF modems of similar features of the
project. Mining companies use RF modems to constantly monitor mining vehicles' statistics
and perform diagnostics which is very useful when implementing the TARGET vehicle. Since
59 Chapter 3. Literature Review
the project also requires autonomous control of the TARGET vehicle, successful applications
such as the automated straddle control system gives condence that RF modems are most
suitable and reliable for the wireless communications in the project.
3.9.2.1 Modem Features
Fundamentally, most RF modems have the same features that provide eective wireless com-
munications. These include use of a spreading code, error checking, network protocols, data
rates and more. The more costly modems provide better quality in these features however
there are other dierences in RF modems that can be considered when selecting the most
suitable modem for the application. For example, the frequency range at which the modem
operates.
The spreading code of RF modems refers to the way data signals are transmitted. RF modems
dier from the ordinary radio transmitting device by using modern technology known as the
Frequency Hopping Spread Spectrum (FHSS). Unlike ordinary radio transmitters, the FHSS
signal does not stay on one frequency but 'hops' between frequencies that only the dedicated
receiver can recognise and sync with the signals hopping pattern. The FHSS signals are then
resistant to interference and can prevent monitoring or jamming by third parties. Therefore
FHSS modems oer secure and robust communication links.
Error checking is another import feature of the RF modem. It contributes to the reliability
of the communication link because it attempts to prevent data packets from being lost or
corrupted. Due to the nature of radio communications, it is inevitable that some data can
be lost or corrupted, especially in hostile environments where other radio equipment is in
close proximity. Error checking procedures include Cyclic Redundancy Checking (CRC) that
constantly monitor the data trac for any abnormalities, and packet retransmissions for any
lost or corrupted data bits.
RF modems support a range of network protocols that allow exibility in its use in many
applications. Common protocols include point-to-point, point-to-multipoint, Hayes dial-up
and repeater. The point-to-point protocol only allows communications between two modems
(master and slave) whereas the point-to-multipoint protocol, also known as broadcasting,
allows communication from one master (the synchroniser) modem to multiple slave modems.
Hayes dial-up protocol oers a more powerful method of operation than the previous two
protocols because it allows dedicated communication between a master and one of many
slaves.
RF modems mainly operate in the Industrial Scientic and Medical (ISM) band which includes
the typical 900 MHz and 2.4 GHz range. Operating at 900 MHz yields signicantly longer
range (approximately two times) than that is possible at 2.4 GHz (Maxstream Inc, 2007). In
comparison with the 900 MHz system, the 2.4 GHz system tends to readily malfunction in the
vicinity of other 2.4 GHz devices and particularly in rainy conditions. It has some advantages
3.9. RF Communications 60
over the 900 MHz band as it only requires small antennas, making the system compact. Also,
the 2.4 GHz system is globally license-free whereas the 900 MHz systems are only permissible
in fewer countries. The 900 MHz band are utilised by radio modems in Supervisory Control
And Data Acquisition (SCADA) applications which provide high reliability, interference re-
jection and the longest range in hostile, industrial environments. Fortunately, Australia is
one of the few countries that provide license-free operations of 900 MHz systems hence this
is a viable option for the project.
Chapter 4
Hardware Design
4.1 The Vehicle
Before work could begin on design and purchasing of any actuators a suitable vehicle platform
had to be selected. The selection criteria for a vehicle was split into two sections. The
rst detailed requirements and the other detailed desired features. Each criteria was given
a weighting where required features were weighted most heavily with 10. The following
weightings were determined:
• Power steering (10) - Power steering was a denite requirement for the vehicle. It allowed
smaller actuators that would consume less power and be much cheaper.
• Automatic gear shift (10) - The automatic gear shifter was also a denite requirement
as it would greatly reduce the complexity of gear shifting actuators.
• Correct price (10) - The allocated budget for the vehicle was $5000 so no vehicles beyond
this range were investigated.
• Adequate interior space for hardware (10) - To t the hardware (which is mainly stored
on the computer rack) adequate space is required. Vehicles with insucient space were
not investigated.
• Adequate exterior area (10) - To allow targeting of the vehicle by a UAV, an exterior area
of approximately nine square meters was required. Vehicles with inadequate exterior
area were not investigated.
• Good suspension (9) - Good suspension should ensure that the onboard hardware is not
damaged while driving on any rough roads the vehicle may encounter.
• No rust (9) - Rust, particularly on the mechanical components, causes weakening which
leads to breakages, thereby compromising the functionality of the vehicle. As it was
crucial for the success of the project that the vehicle runs, nine was allocated.
61
4.1. The Vehicle 62
• Tight steering (8) - Tight steering will ensure the vehicle can be controlled as desired and
maintain its commanded course. However, as the absolute position of the vehicle can
be sensed, corrections for loose steering can be made, so this criterion was not critical,
hence the score of eight.
• Cargo barrier (8) - The cargo barrier will ensure that the equipment in the rear of the
vehicle will not harm the occupants of the cabin (if any) in a crash. If the vehicle did not
already come with a cargo barrier, then one could be purchased separately at signicant
cost, so a weighting of eight was appropriate.
• Good tires (8) - Good tires will ensure that the vehicle has a good grip on the road and
therefore can be controlled as commanded. However if the vehicle does not already have
good tires these can be purchased at signicant cost, therefore a weighting of eight was
given.
• Air conditioning (8) - Air conditioning should ensure that the control hardware re-
mains at a good temperature. This is quite important in central Australia where high
temperatures are common.
• Low mileage (5) - Low mileage was desirable since a vehicle which has not traveled far
will be less likely to break down. However, breakdowns are quite unlikely based on this
criterion alone, so a weighting of ve was given.
• No logo decals (5) - The project does not wish to advertise by using the vehicle, so no
decal were permitted. However, decals could always be removed, after which repainting
is generally required, therefore a score of ve is allocated for the extra cost and eort
required.
• Low electrical noise (4) - Low electrical noise will ensure that the electrical signals pass-
ing between hardware are not distorted. However if the vehicle does produce electrical
noise, particularly from the distributor, this could be compensated for by electrical
shielding of wires and components. Since electrical isolation will be implemented re-
gardless of the vehicle (i.e. the vehicle noise should incur no extra cost), this criterion
is weighted at four.
• Valid registration (4) - To be driven on roads the vehicle must be registered. If the
vehicle did not come with registration, it must be purchased at a small cost. Therefore
a weighting of four was given.
While searching for a suitable vehicle these criteria were taken into consideration. After many
weeks of searching the range of possible vehicles identied was very small. Many vehicles
did not match one of the required (weighted 10) categories, with price being a major hurdle.
However, one vehicle was found that satised all of the required categories and was determined
to be suitable for the TARGET project's needs.
63 Chapter 4. Hardware Design
The identied vehicle was a Mitsubishi Express van. It had power steering, an automatic
transmission, adequate interior space, adequate exterior area, no logo decals and air condi-
tioning. Several modications had to be made to the van for it to be fully functional. Figure
4.1 shows the TARGET vehicle after these modications were made. The modications in-
cluded:
• a service to remedy some minor emission issues
• the installation of a cargo barrier
• the installation of a rack to hold the electronics
• the addition of the project and university insignia
Figure 4.1: The TARGET vehicle after being purchased and minor modications made
Once the vehicle was purchased the design, construction and installation of actuators could
begin.
4.2 Onboard Computer
The onboard computer is required to perform all of the computation required for control of
the van. A computer system compatible with MathWorks xPC Target was assembled to allow
the development of the program using this software package. The system includes four data
acquisition cards, a desktop computer, and other hardware.
4.2. Onboard Computer 64
4.2.1 xPC Target
MathWorks xPC Target is a rapid prototyping and hardware in the loop simulation environ-
ment. It enables Simulink models to be created on a host computer, and run in real time
on a target computer (the vehicle's onboard computer) with real input and output signals.
The xPC real time kernel handles the real time execution of the program, and is capable of
running the onboard computer program discussed in Section 6.1 at 50Hz. xPC Target has
been used in this project to enable the rapid development of all control systems for the vehicle
without requiring any programming in a low level language. The use of xPC Target imposes
several restrictions on the computer system hardware. The most signicant restriction is that
all data acquisition cards must be chosen from a relatively small list of supported devices.
The computer's Ethernet chipset must also come from a short list of supported chipsets.
To enable the deployment of the program on the vehicle's onboard computer, the xPC Target
Embedded Option was purchased. This is an extension to the xPC Target software, which
enables programs to be deployed as a stand-alone system. The stand-alone program created
with the embedded option boots from DOS, and runs without requiring a link to a host
computer.
4.2.2 Computer Hardware
The computer hardware consists of the computer itself and four peripheral I/O cards.
4.2.2.1 Computer
The onboard computer is a Pentium 4 desktop PC provided by Thales Australia. The com-
puter has a 2.8GHz Pentium 4 processor, and provides I/O expandability with ve PCI slots.
MathWorks xPC Target supports several form factors of computer hardware, including PCI,
compactPCI, and PC104. A PCI form factor has been used in this project predominantly
because a PCI computer was provided in-kind, but the form factor is also the fastest available
solution, and is supported with the cheapest and largest range of peripheral devices. A disad-
vantage of using a desktop PC is that it is not a particularly rugged platform. This has been
overcome by mounting the computer onboard the vehicle with foam for vibration damping.
The supplied computer also benets from coming with a supported Ethernet chipset.
4.2.2.2 Peripheral I/O devices
To meet the I/O requirements of the system, four peripheral I/O devices were purchased.
The I/O requirements comprises thirty nine signals - seven analogue inputs, one analogue
output, ve PWM inputs, twenty one lines of digital I/O, and four ports of RS232 serial
communications. A detailed list of the I/O signals is shown in Table 6.3. The four devices
65 Chapter 4. Hardware Design
purchased to meet these requirements are an analogue I/O card, a counter card, a digital I/O
card, and a RS232 serial communications card. The devices were chosen such that there is
room to interface more of each type of signal if the need arises.
Analogue I/O card - PCI-6040E
A National Instruments PCI-6040E was chosen to fulll the analogue input and output re-
quirements of the system. This card has sixteen analogue inputs, two analogue outputs, two
counters, and eight lines of digital I/O. The PCI-6040E was chosen as it was the lowest cost
card that could provide an 8kHz analogue output for sound generation (see Section 6.1.6),
and could provide decoding for at least one PWM signal.
Counter card - PCI-6601
A National Instruments PCI-6601 was chosen to provide decoding for four of the ve PWM
inputs to the computer. It has four counters with 32 bit resolution, each of which can decode
a single PWM. The PCI-6601 was chosen as it provided the cheapest solution for PWM
decoding - cheaper cards with more than four counters were available, but used two counters
to decode each PWM signal. This card also provides eight lines of digital I/O.
Digital card - PCI-6053
A National Instruments PCI-6053 provides twenty four lines of digital I/O for the computer.
The PCI-6053 was chosen for its low cost and high number of I/O lines.
RS232 serial card - ESC-100
A Quatech ESC-100 was chosen to provide the reqiured four ports of RS232 serial communi-
cations. The card has eight ports, and was chosen as it provides expansion room for devices
which may be added to the system later, such as the RF modem auxiliary port or a second
GPS unit.
4.2.3 Program Deployment
The onboard computer program has been deployed as an embedded system using the xPC
Target Embedded Option. An embedded program created by xPC Target requires the com-
puter to boot to DOS, from which the program is launched. A conventional hard drive could
not be used to boot to DOS due to the vibration present in the vehicle, so a solid state com-
pact ash card was installed. Installing DOS on the compact ash card was achieved using
instructions from Northwestern University Mechatronics Wiki (2007).
4.3. Communication Hardware 66
4.3 Communication Hardware
The following sections discuss the chosen hardware associated with RF and RC communica-
tions between the hand held controller, base station and onboard computer.
4.3.1 Handheld Remote-Control
The communication hardware design process that assisted in the remote manual control oper-
ations of the vehicle simply involved selecting a handheld remote-control which was capable of
providing independent control of the vehicle's control aspects. The handheld remote-control
was required to have enough frequency channels and type of frequency channels that could
independently control speed, steering, transmission, ignition and emergency stop activation.
The chosen handheld remote-control was JR Propo's X2720, a seven-channel digital pro-
portional radio control system. Most seven-channel handheld remote-controls in the market
have many and very similar features however for the purpose of the project's application, a
well-known manufacturer of radio transmitters with the appropriate number of channels were
suced.
As with all seven-channel handheld remote-controls, four channels are dedicated to propor-
tional control (proportional channels) and the remaining three are dedicated for discrete
control (switch channels). All channels are digitally transmitted using Pulse Width Modula-
tion (PWM) signals to manipulate voltage levels at the receiving end. For the purpose of the
project, only two proportional channels were occupied by the speed and steering control of the
vehicle. These are represented by the control sticks as shown in red of Figure 4.2. This was
most appropriate because the control sticks could move directly proportional to the output
voltage at the receiver. In this way, the speed of the vehicle was easily increased or decreased
by moving its control stick up or down, and the steering of the vehicle changed by moving
the direction of its control stick left to right.
The remaining three channels that provided discrete control gave discrete output voltages
at the receiver. These discrete values were used for the vehicle's discrete control surfaces
such as transmission, ignition and emergency stop activation. These discrete channels are
also shown in green of Figure 4.2 and are represented by mechanical switches. Initially,
when programming the switch channel that was used for the transmission of the vehicle, the
diculty was the incremental output voltage levels could not easily be distinguished from
each other. This was mostly likely be due to noise. The solution to this was to use the
base station software and RF modem to control the vehicle's transmission. The ignition and
emergency stop activation switches were simply controlled by the two-state (on/o) switches
on independent frequency channels.
The X2720 remote-control is a very sophisticated device which provided further exibility in
manipulating the seven frequency channels. It provided both PPM and PCM systems as was
67 Chapter 4. Hardware Design
Figure 4.2: Allocated frequency channels on the X2720 Remote-Control
discussed in the Literature Review section of handheld remote-control. The PPM system is
currently in use because it assisted in the detection of out-of-range communication. They
way out-of-range communication was detected is explained further in Section 6.1.2.3. The
seven channels were known to freeze (or be static) at its last known value when the receiver
had gone beyond the transmission range of approximately one kilometre. This made it easy
to detect when the vehicle was out of range and the initialisation of any appropriate actions
such as automatic emergency stop. The PCM system could also have been used for this
purpose because the X2720 allowed the user to program a set value of any frequency channel
in the case of out-of-range communication, which is automatically detected by the handheld
remote-control itself. This procedure was known as fail-safe, however since the rst option is
successfully working, no further time was dedicated to implement the fail-safe option.
4.3.2 RF Modems
The communication hardware design process that would assist in the remote autonomous
control operations of the TARGET vehicle was the selection of a quality RF modem that
possessed key features such as fast data transfer rates, reliability in data transmission, trans-
mission range and user friendliness. A competitive list of potential RF modems (see Appendix
H) were considered however the RFI-9256 RF modem (shown in Figure 4.3) from RF Inno-
vations was the chosen hardware for long range communications between the base station
and the TARGET vehicle. This particular modem's performance and features exceeded the
others because of its high quality and speed in data transmission and exibility in modem
optimisation parameters, which will be discussed in this section.
4.3.2.1 RFI-9256’s Unique Features
The RFI-9256 is a Frequency Hopping Spread Spectrum (FHSS) radio modem operating
in the international 900 MHz ISM band. It has the unique feature of dual RS232 data
ports that provided straight forward data transmission using the 'main' port and modem
statistics and diagnostics on the 'aux' port. The interface given by the manufacturer were
Windows Graphical User Interface programs which allowed the operator to easily change
4.3. Communication Hardware 68
Figure 4.3: The RFI-9256 RF Modem (RF Innovations Pty Ltd, 2006)
modem parameters and monitor statistics of the communication link such as signal and noise
levels.
The way that the RFI-9256 handled its data transmission showed that the established com-
munication link was robust. Contributing to this was the large 32-bit Cyclic Redundancy
Checking (CRC) error checking operation (most other modems on the market have only
16-bit CRC). In addition to the RFI-9256's CRC, was the Forward Error Checking (FEC)
operation which was also not present in other industrial modems. This feature detected if
there were any errors in a packet transmission that were amendable and would automatically
make the appropriate adjustments.
4.3.2.2 Protocol Operations
Protocol operations are modes that determine how the serial port data is interpreted and
converted in to data packets for transmission over the air (RF Innovations Pty Ltd, 2006).
The RFI-9256 supported four dierent protocol operations: Point-to-Point, Broadcast, Hayes
Dial-Up and SCADA. The project's application only involved two modems at two locations
which meant the Broadcast and SCADA protocols were not applicable. Although the Point-
to-point protocol could have been used, Hayes Dial-up was chosen because more exibility and
support was given regarding that protocol. In Hayes Dial-Up there exists a 'master' modem
which is the one that sets the parameters of any other modem that it connects to. The master
modem is also responsible for synchronising with the remote or 'slave' modem that it wishes
to connect to. Hence the most appropriate location to place the master modem was at the
base station computer where the operator had easy access to. The conguration of the master
and slave modem in a Hayes Dial-Up network was congured such that:
• They both had the same hopping pattern, network address, and security code
• The master and slave had dierent local addresses
69 Chapter 4. Hardware Design
• Both the master and slave had the Hayes Dial-Up protocol selected on the their
main/aux serial port
• The point-to-point destination address on the slave is set to the master's local address,
while the destination address on the master is set to the slave's local address (RF
Innovations Pty Ltd, 2006).
An example of such congurations is shown in Figure 4.4.
Figure 4.4: Basic Hayes Dial-Up Network conguration (RF Innovations Pty Ltd, 2006)
4.3.2.3 Overview of the RFI-9256’s Operation
The operation of the RFI-9256 modem is summarised in Figure 4.5. This shows the data
path of information being transmitted from one end to another in full duplex operation. The
transmission of one frame of data is divided into two packets where one carries the payload
of the master modem and the other carries the payload from the slave modem.
Figure 4.5: Data path operation of the RFI-9256 (RF Innovations Pty Ltd, 2006)
It is inevitable to have latency in any wireless communication system. There are three types
of latencies that the RFI-9256 modem inicts. The rst is the Serialisation Delay which is
caused by the time taken for the incoming RS232 bit stream to be converted back into bytes.
The second type of latency is called Framing Delays, which are caused when data packets
4.3. Communication Hardware 70
arrive at the start or end of frame times. Packets arriving half way through a frame will have
to wait until the start of the next frame is ready. The maximum latency caused by framing
delays is equal to the frame time which is the default, but user selectable, 20ms. Finally,
the third type of latency is due to the quality of the wireless communication link. A bad
link, usually due to RF interference, will cause the modem to resend any corrupted packets.
This is known as packet retries. The more retries that are required to send a packet through,
the greater the latency time. The overall latency can be somewhat minimised by setting the
appropriate conguration parameters as discussed in the next sub-section.
4.3.2.4 RFI-9256 Configuration Parameters
Transmit Power
The transmit power of the RFI-9256 (device only) can range from +0dBm to +30dBm. Cables
introduced loss and the antenna introduced gain, hence the transmitting power of the modem
was congured such that the power at the antenna's locations was as close to +30dBm as
possible.
Frame Time
The frame time is the amount of time that the RFI-9256 will spend on each channel in the
hopping pattern. A decrease in frame time caused a decrease in latency but also decreased
the data throughput and vice versa. Hence the frame time was set to a reasonable 20ms to
optimise data throughput while not causing too much latency in data transmission.
Directional Bias
The directional bias setting was enabled so that it allowed the user to conduct the majority
of data ow between the master and slave modem. This was achieved by increasing the data
packet sizes of either the master or slave modem. Having this feature was benecial to project
as most transmitted data would ow from the TARGET vehicle to the base station.
Packet Retries
Packet retries is the procedure of resending data packets that were detected lost or corrupted
during the rst attempt. The maximum number of retries per frame can be congured between
zero and two hundred and fty ve. Setting this number low caused the communication link
to be vulnerable to interference but would minimise latency. A high number of retries would
increase the robustness of the link however it would also increase signicant latency in the
presence of interference. The environment that the vehicle was tested in showed moderate
interference (+115dBm) as shown by the modem statistics menu, hence the number of packet
retries was set in the mid-range (200 retries).
RSSI Trigger Level
71 Chapter 4. Hardware Design
The Receive Signal Strength Indication (RSSI) trigger level sets the lowest RSSI that the
modem is to attempt to acquire data (RF Innovations Pty Ltd, 2006). In a noisy environment,
the background noise may rise above the modem's sensitivity of -108dBm. In this case the
RSSI trigger level must be set higher to allow the master and slave modems to communicate.
However, setting the RSSI trigger level too high will articially deafen the modem. For
previous testing, the the RSSI trigger level was set to -108dBm.
4.4 Steering Actuation
The steering actuation system of the TARGET project has the role of providing full steering
control to the vehicle platform. The steering actuation system can be separated into three
subsections, covering the steering motor, mounting arrangement and measurement of the
steering angle. The design of the overall steering system used in the TARGET project has
been based on the steering actuation systems discussed in Section 3.1. These systems, as well
as the steering actuation system used in the TARGET project, consist of an electric motor
coupled to the steering column of the vehicle. A chain and two sprockets have been used to
provide the linkage between the electric motor and steering column, and are shown in Figure
4.8.
4.4.1 Steering Motor
A motor was chosen to actuate the steering of the TARGET vehicle based on two design
considerations. These design considerations were the torque required to turn the steering
wheel and the speed at which the steering wheel needed to be turned. Measurements were
taken of the torque required to steer the vehicle when it was stationary, as this is where the
maximum amount of torque is required to turn the steering wheel. It was found that an
approximate torque of 5 Nm was required to steer the vehicle.
Selection of an electric motor to drive the steering was based on the measured torque as well
as a design factor. A design factor of 4 was chosen as this is regarded a critical design factor,
and the steering system of the vehicle is a critical system where errors could result in serious
safety issues. Using a design factor of 4 implied that an electric motor capable of providing a
20 Nm of torque was required to actuate the steering of the vehicle.
Selection of the speed of the motor was done by measuring how fast a driver needed to turn
the wheel to complete a track similar to that described in Chapter 2. The maximum speed
required to turn the steering wheel was found to be approximately 1 rev/s.
The motor selected for use in the steering actuation system was the 'Bison 348 Series PMDC'
gearmotor (shown in Figure 4.6). This motor is capable of providing 17 Nm of continuous
torque and can approach torques of up to 23 Nm for a limited amount of time. Averaging the
intermittent and continuous value yields an average torque provided of 20 Nm. This torque
4.4. Steering Actuation 72
Figure 4.6: Bisongear 348 Series PMDC Gearmotor (Bison Gear & Engineering Corp, 2007)
corresponds to a design factor of 4 relative to the measured torque of 5 Nm. The speed of
the motor is 64 rev/min which is slightly greater than the required speed of 1 rev/s. Control
of the motor is covered in Section 6.3.1 and the electrical connections are covered in Section
4.8.7. Some of the main features of the 'Bison 348 Series PMDC' gearmotor are listed in the
following points:
• Maximum current draw of 14 A
• Continuous output torque of 17 Nm
• Intermittent output torque of 23 Nm
• Shaft rotational speed of 64 rev/min
• Gear ratio of 28:1
4.4.2 Mounting Arrangement
Mounting of the steering system needed to be implemented in a fashion that did not interfere
with the regular operation of the vehicle as outlined in Chapter 2. An extension goal of the
TARGET project was to approve the vehicle to be road legal (see Chapter 2). To make the
vehicle road legal, the steering system needed to be mounted so that it was in compliance
with requirements set by Transport SA regarding safety of the vehicle. Transport SA's only
requirement for the steering system, was that it needed to be positioned between the steering
column and drivers seat, so that in the event of a collision, the existing safety collapsing
mechanism of the steering column was not interfered with.
Considerations were also made in deciding the mounting position of the steering system with
regard to the position of the linkage system between the gearmotor and the steering column.
The section of the steering column shown in Figure 4.7 that is highlighted in red was chosen
73 Chapter 4. Hardware Design
Figure 4.7: Steering column of TARGET vehicle
to be the linkage point between the gearmotor and the steering. This was considered to be a
suitable linkage position as it is a large and easily accessible area of the steering column.
The mounting position of the motor was chosen to be directly behind the section of the
steering column, shown by the yellow area in Figure 4.7. This position allows a driver of the
vehicle to place their feet either side of the actuation system where they would normally be
placed without interference. The accelerator and brake pedals are also not interfered with by
mounting the actuation system in this location.
Selection of the linkage system between the gearmotor and the steering column was largely
based on Section 3.1. From the three linkage systems found in Section 3.1, which were
gears, belt and chain, a chain was found to be the most suitable. This is due to the relative
simplicity of the chain and sprocket system, where the chain can be removed from the system
when needed by using a chain breaker. The other linkage methods discussed in Section 3.1
would require the steering column to be dismantled to remove the linkage system.
The sprockets used on the steering column and on the motor shaft have a gear ratio of 1:1,
with both sprockets having 17 teeth. This ratio was chosen as the Bison gearmotor already
had a gear ratio of 28:1, and supplied the required level of torque at the desired shaft speed,
so no further gear reduction was necessary. The installed chain is shown in Figure 4.8 (b).
To mount the gearmotor, a bracket and plate were used as shown in Figure 4.8. The bracket
is designed to hold the output shaft of the gearmotor parallel to the steering column so that
the sprockets are in the same plane. The bracket may also be moved backward and forward to
tighten or loosen the chain and can also be completely removed by removing bolts that hold
the bracket in place. The plate mounted on the oor of the vehicle provides extra support to
the oor of the vehicle so that it does not buckle when subjected to indirect loads applied to
it from the gearmotor.
4.4. Steering Actuation 74
(a) Steering system location
(b) Motor and steering column chain linkage
Figure 4.8: TARGET Vehicle steering actuation system
75 Chapter 4. Hardware Design
Figure 4.9: Steering potentiometer
4.4.3 Steering Angle Measurement
Feedback on the steering wheel angle was also required for the control of the vehicle's steering
(see Section 6.3.1). Due to the high accuracy of the on-board computers analogue inputs (see
Section 6.1.1), and also for simplicity of the system a potentiometer was used to generate
feedback for the steering position by coupling it to the steering column using a toothed belt
and pulleys (shown in Figure 4.9).
The potentiometer used was an 'ETI Systems, 10 Turn Wire wound Precision Potentiometer'
rated at 1 kΩ. Although the steering column only needs 3.5 revolutions to travel from lock
to lock, a 10 turn potentiometer was used as they are easily sourced. A gear ratio was used
on the pulleys connecting the steering column to the potentiometer to utilize a greater range
of the potentiometer. The gear ratio was 25 teeth on the steering column to 15 teeth on the
potentiometer. This gear ratio resulted in the potentiometer utilizing 5.8 revolutions of the
available 10 revolutions, producing a high quality signal output to the onboard computer.
Coupling the potentiometer directly to the steering column rather than the motor resulted in
the potentiometer only being required to be calibrated once, rather than every time the motor
is disconnected from the steering column. Another advantage of having the potentiometer
connected directly to the steering column is that in the unlikely event of the motor becoming
uncoupled from the steering column, the potentiometer reading will still be correct as it is
not dependent on the motor being connected.
To ensure the potentiometer shaft was not subjected to excessive force, a exible coupling
was installed into the system as shown in Figure 4.9. This was done as excessive force on
the potentiometer shaft can cause the potentiometer to ware, and over time fail. The exible
coupling is able to deform whilst still allowing the shaft of the potentiometer to rotate.
4.5. Throttle Actuation 76
4.5 Throttle Actuation
The throttle actuation system of the TARGET project has the objective of providing full
throttle control of the vehicle platform whilst allowing for a regular driver to operate the
throttle. This system has been implemented by using an actuator from a cruise control
system to actuate the throttle valve of the vehicle. The actuation is done in a similar manner
to how the cable connected to the foot pedal of the vehicle moves the throttle valve.
4.5.1 Vacuum Actuator Mounting
The actuator used from the cruise control system is a vacuum actuator. This actuator is
connected to the vacuum hose of the vehicle, and by controlling a series of valves with solenoids
a diaphragm inside the actuator can be moved in and out. This diaphragm is then connected
to a cable, which is connected to the throttle valve of the vehicle. The connection with the
vacuum hose is illustrated in Figure 4.10.
Figure 4.10: Instructions describing how to connect the actuator to the vehicle vacuum line(Auscruise By Autron, 2007)
The actuator itself was then mounted to the engine bay of the vehicle as shown in Figure
4.11(a), with the cable connected to the throttle valve as shown in Figure 4.11(b).
4.5.2 Vacuum Actuator Control
Control of the vacuum actuator is achieved by operating four pins, which control three
solenoids inside the actuator. The pins are usually connected to the electronics designed
by the cruise control manufacturer. However, in order to integrate the actuator for the re-
quired purpose of the TARGET project, the standard manufactures electronics were not used
77 Chapter 4. Hardware Design
(a) Vacuum actuator mounted inside the engine bay
(b) Throttle valve connection
Figure 4.11: TARGET throttle actuation system
and instead the actuator was controlled by digital lines from the on-board computer system
(see Section 6.1.4.2). The pins of the vacuum actuator are classied as follows:
Pin 1: Vacuum inlet solenoid. Activating this pin opens a valve that allows the vacuum line
of the vehicle to pull the diaphragm of the vacuum actuator in.
Pin 2: Control dump solenoid. Activating this pin allows a free ow of air through the
actuator. Activating pin 1 has no eect when pin 2 is activated.
Pin 3: +12 V supply to the actuator.
Pin 4: Safety dump solenoid. Activating this pin causes the actuator to completely release
the throttle in case of an emergency.
Activating the safety dump solenoid needs to be done from a capacitive brake sensor (covered
in Section 4.8.2) and the dragon safety system (see Section 8.1.2). Therefore electronics were
made so that when either of these signals were activated the throttle was released.
4.6 Brake Actuation
The brake actuation system of the TARGET project has the purpose of providing full brake
control of the vehicle platform. The brake system is designed to provide a controlled means
4.6. Brake Actuation 78
of decelerating the TARGET vehicle during autonomous and remote controlled operation.
Design of the brake system has also taken into consideration a secondary brake system to be
activated in the event of an emergency. Achieving successful implementation of these systems
was also carried out with regard to the extension goal (see Chapter 2) to not interfere with
the normal operations of the TARGET vehicle.
4.6.1 Primary Brake Actuation System
The primary brake actuation system of the TARGET vehicle has been implemented by using a
linear actuator, linked to the brake pedal of the vehicle with a cable, to provide a pulling force
on the brake pedal. This brake actuation system design was used because its implementation
had very low interference with the normal operation of the brake pedal.
The ow of the primary brake actuation system for the TARGET vehicle is illustrated in
Figure 4.12. The system consists of an amplier, linear actuator, pressure transducer, brake
cable and brake pedal. Each of these components will be further discussed in Sections 4.6.1.1
to 4.6.1.4.
Figure 4.12: Schematic showing the sequential operation of the primary brake actuationsystem including feedback from pressure transducer
4.6.1.1 Amplifier
The TARGET vehicle primary brake actuation system is controlled by the on-board computer
through the Roboteq AX1500 Amplier (see Section 4.8.7). With reference to Figure 4.12,
the amplier allows the on-board computer to position control the brake pedal through the
linkage with the linear actuator, and achieve vehicle deceleration.
4.6.1.2 Linear Actuator
A linear actuator was chosen for use in the primary brake actuation system of the TARGET
vehicle based on two design considerations. These design considerations include the force
79 Chapter 4. Hardware Design
Figure 4.13: Linear actuator's performance chart - Refer to 20:1 ratio for primary brakeactuation. This ratio represent the gear ratio embedded in the linear actuator (Firgelli Au-tomations, 2007)
required to apply full brake pressure and the time taken to move the brake pedal to this
position. Measurements were taken of the force required to push the brake pedal to a full
brake position. It was found that an approximate force of 100 N was required to achieve a
full brake position. The speed requirement of the primary brake system was based on the
time required to move the brake its full travel of 4 cm, which was found to be a maximum of
3 seconds when tested.
The linear actuator selected for use in the primary brake actuation system is the FA-150-S-
12-12, manufactured by Firgelli Automations. The FA-150-S-12-12" actuator is capable of
producing 667 N of pulling force, which gave a large design factor of 6.67 over the required
force of 100 N. The linear actuator is able to travel 14 mm/s when under maximum load,
which means the full brake can be achieved in 2.8 seconds, which is under the required time
of 3 seconds. In addition, the supply voltage of the actuator is 12 VDC and the maximum
current consumption at full load is 4 A.
Once the hardware had been selected, the materials and bracket dimensions required to mount
4.6. Brake Actuation 80
Table 4.1: Comparison table between the required and actual performance of the linear actu-ator (Firgelli Automations, 2007)
Description Required Performance Actual Performance
Pulling Force 100 N 667 N
Speed 13.3 mm/s 14 mm/s
Figure 4.14: The TARGET vehicle's brake and transmission actuator assembly
the hardware were selected. After consultation with both supervisors and an engineering
workshop assistant, the linear actuator was installed inside the TARGET vehicle as shown in
the Figure 4.6.1.4. The current installation was set up was to maintain an easy access to the
linear actuator to simplify maintenance and inspection processes.
The mounting brackets consist of four major components (Refer to Figure 4.6.1.4): the alu-
minum plate, U-shaped bracket, squared-blocked bracket, and the L-shaped bracket. An
aluminum plate with a thickness of 3mm was selected as a platform to mount the linear
actuator. Aluminum was used to mount the actuators for aesthetic purposes, whilst it still
providing sucient strength. The U-shaped and squared-block brackets were implemented
for the purpose of preventing the linear actuator from lateral and translational motions. The
L-shaped bracket was installed to hold the outer casing of brake cable in place.
4.6.1.3 Pressure Transducer
The pressure transducer was tted to the brake pressure line of the braking system to provide a
feedback signal from the brake to the on-board computer (Refer to Figure 4.12). The pressure
transducer selected was the GE Druck - PTX 1400 (Refer to Figure 4.15) manufactured by
General Electric. The GE Druck - PTX 1400 was selected based on the pressure range in
the brake lines, conrmed by Robert Dempster (2007, pers. comm. 3 July), which are listed
81 Chapter 4. Hardware Design
Figure 4.15: Pressure transducer GE Druck - PTX 1400
Table 4.2: Braking Conditions and the expected pressure range for Mitsubishi Express 1994Braking Condition Pressure Range Impact to the vehicle
Low 0 - 21 Bar None
Moderate 21 - 28 Bar Moderate deceleration
High 55 - 62 Bar Fast deceleration
Extreme 83 - 103 Bar All wheels locked up(Emergency Braking)
in the Table 4.2. The maximum amount of breaking pressure required to lock the brakes is
approximately 60 bar. The range of the pressure transducer was chosen to be 0 - 60 bar (0 -
870.23 psi) for this reason. This places the transducer in the fast deceleration pressure range
of Table 4.2. It ensures dangerously high pressures are not obtained and the wheels do not
lock.
The pressure transducer has a 4 - 20mA output. It is necessary to convert the output current
into an output voltage that it can be interpreted by the analogue card, discussed in Section
4.2.2.2 of the on-board computer (i.e. receiving 0-5 V, not 4-20 mA). Using Ohm's Law,
it was calculated that a 270Ω resistor will need to be added to the pressure transducer to
produce the desired output voltage. The circuit diagram used to convert the current output
to a voltage output is shown in Figure 4.16.
The pressure transducer was installed inside the vehicle, close to master cylinder, as illustrated
in Figure 4.17. The pressure transducer was installed inside the vehicle to prevent exposure
to excessive dust, dirt, and moisture.
Installation of the pressure transducer required modications to be made to the vehicle brake
pressure line. The components required for the installation were (Refer to Figure 4.18(a)):
10/1MM DPS 3-WAY Connector, 1/2x20 - 3/8x24 Adapter, 3/16 10x1MM Tube Nut, and
3/16-1/4 Straight PI (Refer to Figure 4.18(a)). These components were then installed as
shown in Figure 4.18(b).
4.6. Brake Actuation 82
Figure 4.16: Modied circuit diagram of the pressure transducer to generate the desiredvoltage output
Figure 4.17: Mounting arrangement for the pressure transducer in the TARGET vehicle
83 Chapter 4. Hardware Design
(a) Individual components
(b) Assembled components
Figure 4.18: Pictorial representations of individual components and the assembled componentfor brake line modication
4.6. Brake Actuation 84
(a) Outer casing support (b) Cable support
Figure 4.19: Detailed pictorial representation of the brake cable attachment
4.6.1.4 Brake Cable and Brake Pedal
The brake cable was used to enable the linear actuator to transmit the mechanical pulling
force from the actuator to the vehicle brake pedal. With reference to Figure 4.6.1.4, the L-
shaped bracket was used to provide support to the outer casing of the brake cable. The cable
was routed underneath the vehicle oor and then connected to the back of the brake pedal as
illustrated in Figure 4.20.
To feed the end of the brake cable in the required direction, two components were designed
as shown in Figure 4.19 (a) and (b). The outer casing support, shown in Figure 4.19 (a), was
installed together with the L-shaped bracket shown in Figure and also tted to the vehicle
oor panel as shown by the red-circle in Figure 4.20 (b). The cable support, shown in Figure
4.19 (b), was installed together with its bracket as shown in Figure (a) and further detailed
by the blue-coloured bracket as shown in Figure (b).
4.6.2 Emergency Brake System
The emergency brake system was implemented on the TARGET vehicle to act as a secondary
braking system, to be used only in specic emergency situations. The design of the emergency
brake system was based on the requirement that it should be operational with and without
electrical power.
As illustrated in Figure 4.21, the emergency brake system consists of two major components:
an electromagnet and a compression spring. The system is designed so that when the spring is
compressed, the brake is not activated, but when the spring is released, the brake is depressed.
The electromagnet was implemented to provide a compression force (i.e. to deactivate the
emergency brake system). The spring and electromagnet are further discussed in Sections
4.6.2.1 and 4.6.2.2.
85 Chapter 4. Hardware Design
(a) Brake cable and brake pedal link - Front View
(b) Brake cable and brake pedal link - Side view
Figure 4.20: Brake pedal and brake cable link of the TARGET vehicle
4.6. Brake Actuation 86
Figure 4.21: Emergency Brake System of the TARGET vehicle
Table 4.3: Specication for the electromagnetMagnet Armature Size 65 mm
Holding Force 1300 N
Voltage Supply 12 VDC
Power Consumption 9.8 Watts
4.6.2.1 Electromagnet
The electromagnet was selected based on its holding force. The electromagnet was required
to sustain more than 100 N of force (i.e. more than required to operate the brake pedal of
the TARGET vehicle). The electromagnet used was a 65 MM 12VDC holding electromagnet,
manufactured by Magnet - Schultz Ltd. The specications for the magnet are listed in Table
4.3.
4.6.2.2 Compressional Spring
The compression spring was selected based on the braking pressure listed in Table 4.2. It was
selected so that during the activation of the emergency brake, the braking pressure would not
exceed 900 Psi to prevent the wheels from locking up, yet still rapidly decelerate the car.
The calculations for the required spring characteristics was done by using the amount of force
required to produce the desired brake pressure combined with the desired deformation of the
87 Chapter 4. Hardware Design
Table 4.4: Specication for the compressional springForce 100N
Deformation 55mm
Spring Constant 1.81× 103N/m
Length 103mm
Figure 4.22: Transmission actuation block diagram
spring (F = kx). The pressure reading was obtained from the installed pressure transducer
using a multimeter, whilst applying the desired force to the vehicle brake pedal with the
assistance of a digital force gauge. The selected spring characteristics are listed in Table 4.4.
4.7 Transmission Actuation
The transmission actuation was implemented to allow the on-board computer to change gears
during autonomous and remote controlled operation. The system was implemented using a
linear actuator linked to transmission lever. A block diagram of the transmission actuation
operation is illustrated in Figure 4.22.
In order to actuate the transmission, modications were made to the vehicle's transmission
lever. To move the transmission lever, depression of an un-lock button is required to release
the transmission lever lock. An additional lever was attached to the un-lock button in order
for electronics actuation to take place. Figures 4.23(a) and 4.23(b) show the manufactured
lever mechanism (highlighted by the red-coloured circles). Figure 4.23(a) also shows the
modications made to the transmission lever to allow for the linkage between the actuator
and transmission (highlighted by the blue-colored circle). The linkage mount between the
transmission lever and linear actuator is shown in Figure 4.24. The mechanical linkage was
fabricated so that the length of the linkage could be adjusted.
The transmission actuation is activated by the on-board computer. The computer activates
a series of relays to enable the actuator to be moved forwards, backwards or held in place. A
solenoid has been used to depress the manufactured lever to unlock the transmission lever.
This solenoid automatically depresses the manufactured lever whenever the actuator moves
to unlock the transmission. As a result, gear shifting operation is achieved. In Figure 4.22,
4.7. Transmission Actuation 88
(a) Transmission Lever -Side view
(b) TransmissionLever - Front view
Figure 4.23: Modied gear transmission lever of the TARGET vehicle. Mechanical leveris indicated by the red circle. The modication which enables linkage between the linearactuator and transmission lever is indicated by the blue circle
Figure 4.24: Linkage between transmission lever and actuator
it should be noted that the feedback signals were acquired from the gear position indicator
of the vehicle (discussed in Subsection 4.7.3). The feedback allows the on-board computer to
determine the position of the transmission lever.
In the following subsections the solenoid, linear actuator and gear position indicators are
discussed in further detail.
4.7.1 Solenoid
The solenoid was implemented with the intention of locking and unlocking the vehicle's trans-
mission lever during autonomous and remote-controlled operations. This operation will then
permit the linear actuator to select between gears (i.e. Park, Drive, or Lower Gear). The
selected solenoid, LR8814 (obtained from Jaycar Electronics), is commonly used to actuate
car central locking systems. It is capable of providing 3kg of pulling force against the required
force (of 1kg) to operate the lever-mechanism of the transmission lever. Furthermore, the life
time for this type of solenoid is 100,000 cycles. For the specied application the listed life
time was considered suitable. The installed solenoid is illustrated in Figure 4.25.
89 Chapter 4. Hardware Design
Figure 4.25: Solenoid installation to the vehicle transmission lever. Highlighted in red-coloured circle is the solenoid which connect the solenoid to the mechanical lever
Table 4.5: Comparison table between the expected performance of the linear actuator andthe selected specication of the actuator
Description Required Performance Actual Specication
Pulling Force 24.55 N 155.68 N
Speed 48 mm/s 25 mm/s
4.7.2 Linear Actuator
The linear actuator chosen for use in the transmission system is the FA-35-S-12-12, manufac-
tured by Firgelli Automations. The FA-35-S-12-12" actuator is capable of producing 16kg of
pulling force using 12 VDC . With reference to Figure 4.13, 3 Ampere of current will be used
by the linear actuator at its maximum load (35lbs≈16kgf). Furthermore, the linear actuatorwill be able to operate at a speed of approximately 25 mm/s at its maximum load.
For the actual applications of the transmission actuation system, the linear actuator will only
be required to provide a pull/push force of 25 Newtons (≈ 5.62lbs). Hence, it should be
noted that the actual performance required from the linear actuator is approximately 6 times
lower than the force that the linear actuator is capable of producing. This is due to the
design factor (as advised by our supervisor) which was taken into consideration during the
selection process. Hence, the comparison between the required performance and the actual
performance for the linear actuator can be summarized as shown in the Table 4.5. The values
in Table 4.5 were obtained from the gear ratio 5:1 of Figure 4.13. The mounting arrangement
for the linear actuator is shown in Figure 4.6.1.4.
4.8. Electronics 90
(a) Dash board - Front End
(b) Dash board - Rear End
Figure 4.26: Modied dash-board of the TARGET vehicle for gear position signal acquisitions
4.7.3 Gear Position Indicator
The gear position indicator is used to provide a positional feedback to the on-board computer
hence allowing the on-board computer to place the gear transmission lever to the desired
position. In order to assist the specied applications, minor modications were performed to
the dash-board of the TARGET vehicle (Refer to Figure 4.26). The cable was extended and
connected to an electronics board as indicate by the yellow-circle depicted in Figure 4.27.
4.8 Electronics
The electronics of the TARGET project are a separate system to the existing electronics
of the vehicle platform. There are some systems however that do overlap with the existing
electronics. This section will cover the major areas of the electronics, but will not go into
a high level of detail discussing the layout of the boards manufactured by the Mechanical
Engineering Workshop.
91 Chapter 4. Hardware Design
Figure 4.27: Close-up view of the TARGET electronics. Highlighted in yellow circle is thePCB to accumulate gear position signal before connected to the onboard computer
The electronic boards mounted inside the target vehicle are shown in Figure 4.28. Many of
the boards have multiple functions incorporated into their design, and therefore the labels in
Figure 4.28 refer to the main function of that particular board. The schematics of the boards
manufactured by the Mechanical Engineering Workshop can be found in Appendix G.
4.8.1 Power Electronics
To provide power to the additional systems installed in the vehicle, a secondary battery was
installed into the vehicle. This battery was added using a dual battery isolator (shown in
Figure 4.28), which directs the current from the alternator to charge both batteries when the
vehicle is running. When the vehicle is o the isolator allows the secondary battery to be
drained with no eect on the main battery.
The secondary battery is rated at 100 AHr. After testing the battery, it was found that the
systems running o of the battery took approximately 10 hours to completely run down the
battery.
Components used in the TARGET project require a range of dierent supply voltages. The
required supply voltages, and the components that require that supply voltage are listed as
follows:
• 230 VAC
On-board computer
4.8. Electronics 92
Figure 4.28: TARGET electronics
93 Chapter 4. Hardware Design
Monitor
• 12 VDC
Steering motor (through steering and brake amplier - Section 4.8.7)
Steering potentiometer
Brake actuator (through steering and brake amplier - Section 4.8.7)
Brake pressure sensor
Throttle actuator
Transmission actuator
Capacitive brake sensor
GPS receiver
Warning lights
RF transceiver
Emergency brake electromagnet
• 9 VDC
IMU
• 5 VDC
RC receiver
To provide the 230 VAC a 1000 W pure sine wave inverter was used (Figure 4.29). Voltage
regulator circuits were used to supply the 12 VDC components and the RC receiver (shown in
Figure 4.28). A DC/DC converter (shown in Figure 4.28) was used as a supply for the IMU.
Figure 4.29: Jaycar Electronics 1000 W pure sine wave inverter (Jaycar Electronics, 2007)
4.8.2 Safety Electronics
Considerations regarding safety were made when designing the electronics for the TARGET
project. Safety systems incorporated into the electronics of the TARGET vehicle are switches
4.8. Electronics 94
Figure 4.30: Capacitive Sensor
to isolate the actuators from their power supply, and an isolating switch to cut power to all
auxiliary systems of the target vehicle excluding the inverter.
To ensure that power could be cut to the vehicle actuators at any time, a series of relays
were installed between the actuators and their power supply. These relays have been designed
to be operated by a digital line from the on-board computer, or by a switch located in the
center console of the TARGET vehicle. This switch is located such that someone sitting in
the driver or passenger seat is able to operate it. Cutting power to the actuation systems
allows someone sitting in the drivers seat to regain manual control of the vehicle, in the event
of a system failing or an emergency.
The onboard computer is required to cut power to the actuators if the brake pedal is pushed.
Sensing when the brake pedal is pushed is done using a capacitive sensor, which is activated
when an object is within a 10 mm proximity in front of it. This sensor is mounted above the
brake pedal, as shown in Figure 4.30. When a driver of the vehicle places their foot on the
brake, the capacitive sensor is able to detect it. The feedback from the capacitive sensor is
monitored by the onboard computer, and power is cut to the actuators if the brake pedal is
pushed by a manual driver.
An isolating switch that cuts power to all electronics connected to the secondary battery,
excluding the inverter, has been installed in the TARGET vehicle (shown in Figure 4.28).
The inverter does not have power cut to it from the isolating switch as a sudden loss of power
to the inverter could damage the onboard computer (which is connected to the inverter).
4.8.3 Throttle Interface Board
To allow the on-board computer to control the vacuum actuator (Section 4.5) an interface
board linking the computer and the vacuum actuator was used. The pins used to the control
the vacuum actuator described in Section 4.5.2 must be taken to ground to activate the
95 Chapter 4. Hardware Design
corresponding solenoid, excluding pin 3 which is connected to a +12 VDC supply. A board
was designed that allowed the computer to control the pins linked to the solenoids of the
actuator with digital lines from the onboard computer. Incorporated into the design of this
board was the ability of two digital lines to activate pin 4, the safety dump of the vacuum
actuator. This was done so that the throttle could be released by either the capacitive sensor
or the Dragon 12 Microcontroller (see Section 8.1.2).
4.8.4 Hall Effect Sensor Board
Digital feedback from the Hall eect sensor described in Section 5.4.3, was originally intended
to be interpreted by the digital cards of the on-board computer. However, the signal processing
required to interpret the feedback from the Hall eect sensor was using a large amount of CPU
processing power, and resulted in CPU overloads. To avoid the possibility of a CPU overload,
it was decided to manufacture a board to convert the digital signal from the Hall eect sensor
to an analogue voltage output. This board was manufactured so that the output voltage
related to speed, and the relationship is dened in Equation (4.1). This relationship was
found by measuring the voltage at a variety of dierent speeds and taking the linear curve of
best t between all the data points.
speed (km/h) = 78.4× voltage (V ) (4.1)
4.8.5 Tachometer Feedback Board
Feedback on the engine speed was required to control the throttle when the vehicle was in
park or neutral, as described in Section 6.3. To do this a board was made that provided an
analogue feedback to the on-board computer, by using the signal from the tachometer display
of the vehicle.
4.8.6 Ignition Board
Control of the ignition of the TARGET vehicle was a requirement of the TARGET project,
covered in Chapter 2. A board was made that was able to control the ignition from the
on-board computer. This board still allowed the vehicle to be started normally with a key.
To operate the ignition from the computer, the accessory electronics of the vehicle were still
required to be turned on with the vehicle key. Control of the ignition is covered in Section
6.1.4.4.
4.8. Electronics 96
4.8.7 Steering and Brake Amplifier
A DC motor controller was required to convert commands from the on-board computer to
the required outputs to the steering motor (see Section 4.4.1) and brake actuator (see Section
4.6). The controller selected for use was the 'Roboteq AX1500' and is shown in Figure 4.31
(a). The features that suited the AX1500 to the TARGET project are listed as follows:
• 2 output channels
• 30 A maximum current output
• Serial (RS232), analogue or PWM command modes
• 12 - 40 V operation
• Up to 60 Hz operation speed
The 2 output channels of the AX1500 are shown in Figure 4.31 (b), where the 'motor 1'
output is connected to the steering motor and the 'motor 2' output is connected to the brake
actuator. The current output from the motor controller is far greater than required by the
steering motor or brake actuator. The maximum current required by the steering motor is
14 A, and a maximum current of 3 A is required for the brake actuator. Previous experience
with similar products inuenced the decision to purchase a controller with a greater current
capacity than required. This was done as problems had been experienced with previous
projects where the controller could not supply the current claimed by the manufacturer.
The AX1500 is capable of serial, analogue and PWM control. For the TARGET project
serial control was used. Serial control was chosen as it is very accurate, and easy to integrate
with the on-board computers serial board. Both the brake actuator and steering motor are
controlled through a single serial port. Commands to the controller are streamed at 50 Hz
which is the same rate as the motor control loops are run, as covered in Section 6.1.
In addition to the serial commands received from the on-board computer, the brake and
steering systems need to be controlled by the Dragon 12 microcontroller. To do this an
RS232 switching board was manufactured by the Mechanical Engineering Workshop (shown
in Figure 4.28). If a digital line connected to the RS232 switching board from the Dragon
12 microcontroller is set to high, commands to the Roboteq AX1500 are received from the
Dragon 12 microcontroller. If the digital line connected to the Dragon 12 microcontroller is
set to low the Roboteq AX1500 responds to commands sent from the on-board computer.
97 Chapter 4. Hardware Design
(a) Image of the AX1500
(b) Motor and actuator inputs to the AX1500
Figure 4.31: Roboteq AX1500 DC motor controller (Roboteq, 2007)
4.8. Electronics 98
Chapter 5
State Estimation and Measurement
Before commencing this chapter, it must be noted that much of the terminology used here
is explained in the the State Estimation and Measurement Literature Review (Section 3.4).
The reader is strongly advised to return to this section of the Literature Review to refresh
their knowledge of the upcoming concepts.
This chapter focuses on the process of determining accurate estimates of the TARGET vehicle
states. As was discussed in the Literature Review, system states are often either not directly
available from sensors, or are corrupted with errors from these sensors. The purpose of the
state estimation process is to improve these corrupt measurements. The Kalman Filter, for
reasons outlined in the Literature Review, is selected as the primary tool for the state esti-
mation process. The Kalman Filter is implemented in software on the onboard computer. It
runs in real-time and fuses the incoming sensor data into optimal state estimates. The main
focus of the State Measurement and Estimation Section is on the suite of sensors onboard
the TARGET vehicle and the method of integrating them into the Kalman Filter. Section
5.1 describes the general structure and requirements of the Kalman Filter. Section 5.2 then
discusses the required system states and Section 5.3 describes the system model. The indi-
vidual sensor inputs into the Kalman Filter are described in Section 5.4, where an overview
of each sensor and the required techniques for data decoding are given. The method for inte-
grating the decoded sensor data into the Kalman Filter then follows. Once this information
has been provided for each sensor, the entire process of State Estimation and Measurement
is summarised with the aid of a high level ow diagram in Section 5.5.
Due to a problem with the IMU sensor, some aspects of the State Estimation and Measure-
ment program where never tested onboard the TARGET vehicle, hence eld-test results are
not avaliable for these aspects. However, an Environment Simulator Program, presented in
Section 9.5.3, shows that the overall State Measurement and Estimation program functions
as required.
99
5.1. General Structure of the Kalman Filter 100
5.1 General Structure of the Kalman Filter
The State Estimation and Measurement section of the Literature Review (Section 3.4) iden-
ties the Kalman Filter as the preferred solution to the problem of state estimation from
corrupt sensors. For this reason the Kalman Filter is selected to implement the process of
state estimation onboard the TARGET vehicle. The properties of a number of dierent forms
of Kalman Filters are also compared in the Literature Review. The two forms most applicable
to the TARGET vehicle are the Extended Kalman Filter and the Unscented Kalman Filter.
Both of these forms have the capacity to handle non-linear system dynamics, which is the case
for the dynamics of the TARGET vehicle, as explained in Section 5.3. However, the diculty
level involved in implementing the Unscented Kalman Filter is far greater than that involved
with the Extended Kalman Filter; hence the latter is selected. For greater ease of logical
switching, the Extended Kalman Filter is designed in an embedded MATLAB le within the
Simulink environment and downloaded to the xPC Target real-time kernel which runs on the
onboard computer. The discrete-time form of the Extended Kalman Filter rather than the
continuous-time form is therefore required. The iterations for the Extended Kalman Filter
are given in Equations (5.1) - (5.5), Kelly (1994b).
xk ⇐ Φk−1xk−1 + Γk−1uk−1 (5.1)
Pk ⇐ Φk−1Pk−1ΦTk−1 + Γk−1QΓT
k−1 (5.2)
Kk ⇐ PkHTk
(HkPkH
Tk + Rk
)−1(5.3)
xk ⇐ xk + Kk (yk − h (xk)) (5.4)
Pk ⇐ (I −KkHk) Pk (5.5)
The x term in these equations is known as the State Estimate vector. The core purpose of
these equations is to determine the values of the vehicle states which reside in the elements
of this vector. Equation (5.1) describes the motion of these state estimates at the current
time step, xk, as a function of the states at the previous time step, xk−1, and as a function
of the inputs at the previous time step, uk−1. The Φk−1 term in Equation (5.1) accounts for
the unforced response of the states, i.e. the response of the states to the initial conditions
of each time increment. The Γk−1 term accounts for the forced response of the states - i.e.
the response of the states due to the inputs. Equation (5.1) is known as the System Model
equation (Kelly, 1994a), and is the focus of Section 5.3. Note the use of the ⇐ sign, rather
than the = sign in the equations. This species that the term on the left hand side for the
101 Chapter 5. State Estimation and Measurement
equation is to be replaced by the evaluation of the terms on the right hand side. This formality
is simply better practice, when describing the implementation of the Extended Kalman Filter
iteration in software.
Equation (5.2) provides a measure of the accuracy of the system model before any corrections
are made by the sensors in later equations. For this reason Equation (5.2) is known as the
A-Priori State Covariance Equation, and Pk, at this point in the Extended Kalman Filter
iteration, is known as the A-Priori State Covariance Matrix. The A-Priori State Covariance
Matrix is a function of the unfamiliar A-Posteriori State Covariance Matrix, Pk−1, and Process
Noise Covariance Matrix, Q. The Process Noise Covariance Matrix describes the level of
process noise present in the system. In the case of the TARGET, this matrix describes the
eect of bumps in the road, gusts of wind and any other noise sources on the system states.
This Process Noise Matrix is discussed in full detail in Section 5.3. The A-Posteriori State
Covariance Matrix in Equation (5.2), Pk−1, provides a measure of the accuracy of the states
upon correction by the sensors. Note that in the rst iteration of the Extended Kalman Filter
Equations, the sensors have not had the chance to correct the states, therefore this matrix is
typically initialised to the identity matrix (Kelly, 1994a).
Equation (5.3) denes the instantaneous Kalman Gain Matrix, Kk, the vital component in
correcting the states with the sensor measurements (which is essentially the entire purpose
of the Kalman Filter). The unfamiliar terms in the calculation of the Kalman Gain Matrix
(Equation (5.3)) are the Measurement Matrix, Hk and the Sensor Noise Covariance Matrix,
Rk. The Measurement Matrix relates the states to the sensor measurements in the absence of
measurement noise and the Sensor Noise Covariance Matrix, Rk, describes this sensor noise,
which must be Gaussian if the lter is to function correctly. One or more Kalman Gain
Matrices are required for each individual sensor, implying that one or more Measurement
Matrices and one or more Sensor Noise Covariance Matrices are also required for each sensor.
The exact implementation of Equation (5.3) is covered in detail for each sensor in Section 5.4.
As has already been mentioned, the purpose of the Extended Kalman Filter is to correct the
state estimates with the available sensors. This is achieved using Equation (5.4) which is
known as the State Update Equation and essentially calculates the error between the Sensor
Measurement Vector, yk, and the Transformed State Estimates Vector, h (xk), multiplies it bythe Kalman Gain Matrix and adds the resulting matrix to the current state estimates. This
correction stage is implemented for every sensor and is described in greater detail in Section
5.4.
Finally, Equation (5.5) provides the method of updating the state A-Posteriori Covariance
Matrix, Pk. As mentioned earlier, this matrix provides a measure of the accuracy of the states
after they have been corrected by the sensors.
Equation (5.1) must be implemented at a xed time period, T , and Equation (5.2) must be
implemented once each time Equation (5.1) is executed. Equations (5.3) through (5.5) need
only be implemented every time new information is available from a sensor. The Kalman Filter
5.2. System States 102
equations are relatively complex and the process is hard to visualise, therefore a owchart has
been created, given as Figure 5.1, to better visualise the iteration procedure. This ow chart
only gives the EKF structure for two sensors, however it is intuitive how more sensors would
be incorporated.
5.2 System States
The states to be estimated by the Kalman Filter are dictated by the requirements of the
Motion-Execution Controller, which is discussed in detail in Section 6.3, and the Autonomous
Guidance Controller, which is discussed in detail in Section 6.2. These controllers both require
accurate knowledge of certain vehicle states, so that the errors between the commanded state
value and the actual (or very accurately estimated) state value may be minimised through
actuation of the TARGET vehicle. The Motion Execution Controller requires accurate knowl-
edge of the vehicle speed, v, and steering angle, φ; and the Autonomous Guidance Controller
requires accurate knowledge of the vehicle position, given in terms of Easting, E, and Nor-
thing, N , and heading, θ. The physical relationships between states are dened visually in
Figure (5.2).
The Kalman Filter requires that these states are placed in a vector, known as the State Vector,
which is given as
x =
E
N
θ
v
a
φ
=
x1
x2
x3
x4
x5
x6
(5.6)
Note that the forward acceleration state, a, is also included in this vector although it is
not directly required by the vehicle controllers. This state is included as a means to relate
acceleration data, given by the Inertial Measurement Unit, to the Kalman Filter. Every state
which is to be corrected by the Kalman Filter must be a function of a sensed quantity, which
clearly places requirements on the choice of sensors, discussed in Section 5.4.
In addition to the State Vector, a vector of system inputs, known as the Input Vector is also
required. The Input Vector ensures that the System Model, which is discussed in detail in
Section 5.3, mimics the true vehicle. The only requirement on the vector of inputs is that
it must provide sucient information to control the System Model. The obvious solution
is to set the system model input states to be similar to the inputs which a driver typically
uses to control a car, i.e. the traction force at the four wheels generated by torque from the
engine, the torque from the brakes on the wheels and the steering angle of the front wheels
(controlled by the accelerator pedal, the brake pedal and the steering wheel respectively).
It must be noted that within these three inputs, the engine torque and the braking torque
103 Chapter 5. State Estimation and Measurement
Figure 5.1: The Extended Kalman Filter Algorithm
5.3. System Model 104
Figure 5.2: A visual representation of the states to be determined
work cooperatively to eect a single quantity - the vehicle forward acceleration. Therefore
the engine torque and the braking torque may be condensed simply to the vehicle forward
acceleration, a. This acceleration is dened as positive when the vehicle is accelerating forward
and negative when the vehicle is decelerating. The remaining input is the steering angle, φ,
which does not require any further simplication. Therefore the Input Vector is given by
u =
[a
φ
](5.7)
The System Model, derived in Section 5.3, explains the process which relates the Input Vector
to the State Vector Equation (5.6).
5.3 System Model
In this section the System Model, or Mathematical Model, of the TARGET vehicle is derived
into a form which is easily utilised in the Kalman Filter. When the model formulation is
completed, the System Model inputs are dened. To function accurately, the Kalman Filter
requires a measure of the level of process noise within the system; therefore, techniques for
obtaining these noise values are presented in Section 5.3.3.
5.3.1 Derivation of the System Model
The model of the system consists of a matrix equation which describes how the system inputs,
u, drive the system states, x, over time. Equation (5.8), is the System Model Equation which
conducts this exact purpose. Note that this equation ocially forms part of the EKF structure,
already given as Equation (5.1).
105 Chapter 5. State Estimation and Measurement
xk+1 ⇐ Φkxk + Γuk (5.8)
The two vectors, u and x have been dened in Section 5.2 as Equations (5.7) and (5.6)
respectively. This section uses these same vectors, however the ˆnotation is now employed
to indicate that the quantities within these vectors are merely estimates. Furthermore, the
k notation used in Equation (5.8) indicates that the equation is a discrete-time, iterative
equation. As has already been mentioned in Section 5.1, this equation must run at a xed
rate of T seconds, otherwise the states will become unsynchronised with the TARGET vehicle
which the model describes. The Φk term in Equation (5.8), known as the State Transition
Matrix and describes the unforced response of the estimates of the vehicle states at the next
time-step, xk+1, due to the estimates of the vehicle states at the current time-step, xk. In the
case of the TARGET vehicle, the State Transition Matrix contains entries which are sinusoidal
functions of the current state estimates, implying that the matrix is non-linear. Therefore,
this matrix must be updated at each time-step, as implied by the k notation. The Γ term is
known as the Input Matrix which describes the forced response of the estimates of the vehicle
states at the next time-step, xk+1, due to the estimates of the inputs at the current time-step,
uk.
Consider rst the State Transition Matrix. Since this matrix is non-linear, it is dened as
Φk = Iunforced + T∂f∂x
(5.9)
where
f (x) = x (5.10)
and Iunforced is the identity matrix but with zero-valued diagonal entries for the states which
are controlled by the Input Vector, Equation (5.7). f (x) is simply a function of the states, x,
and describes the dynamics of the perfect system. The dynamic equations for a vehicle moving
on at ground are given as Equations (5.11) to (5.14) which are presented by Barton (2001)
and Anisi (2003). These equations are relatively intuitive upon inspection of the vehicle state
diagram in Figure 5.2.
v = a (5.11)
θ =v
Ltanφ (5.12)
E = v cos (θ + φ) (5.13)
N = v sin (θ + φ) (5.14)
5.3. System Model 106
Here L is the vehicle wheelbase length (measured to be 2.43 metres) and all of the other
variables are dened in detail in Section (5.2). Equations (5.11)-(5.14) are put into the same
form as Equation (5.10) to give Equation (5.15).
E
N
θ
v
a
φ
=
v cos (θ + φ)v sin (θ + φ)
vL tanφ
a
00
(5.15)
This implies that
f (x) =
v cos (θ + φ)v sin (θ + φ)
vL tanφ
a
00
=
f1f2f3f4f5f6
(5.16)
All the vectors and matrices required by Equation (5.9) have now been dened. Firstly the
Jacobian term in Equation (5.9) is expanded out as
∂f (x)∂x
=
∂f1∂x1
∂f1∂x2
∂f1∂x3
∂f1∂x4
∂f1∂x5
∂f1∂x6
∂f2∂x1
∂f2∂x2
∂f2∂x3
∂f2∂x4
∂f2∂x5
∂f2∂x6
∂f3∂x1
∂f3∂x2
∂f3∂x3
∂f3∂x4
∂f3∂x5
∂f3∂x6
∂f4∂x1
∂f4∂x2
∂f4∂x3
∂f4∂x4
∂f4∂x5
∂f4∂x6
∂f5∂x1
∂f5∂x2
∂f5∂x3
∂f5∂x4
∂f5∂x5
∂f5∂x6
∂f6∂x1
∂f6∂x2
∂f6∂x3
∂f6∂x4
∂f6∂x5
∂f6∂x6
=
∂v cos(θ+φ)∂E
∂v cos(θ+φ)∂N
∂v cos(θ+φ)∂θ
∂v cos(θ+φ)∂v
∂v cos(θ+φ)∂a
∂v cos(θ+φ)∂φ
∂v sin(θ+φ)∂E
∂v sin(θ+φ)∂N
∂v sin(θ+φ)∂θ
∂v sin(θ+φ)∂v
∂v sin(θ+φ)∂a
∂v sin(θ+φ)∂φ
∂ vL
tan φ
∂E
∂ vL
tan φ
∂N
∂ vL
tan φ
∂θ
∂ vL
tan φ
∂v
∂ vL
tan φ
∂a
∂ vL
tan φ
∂xφ∂a∂E
∂a∂N
∂a∂θ
∂a∂v
∂a∂a
∂a∂φ
∂0∂E
∂0∂N
∂0∂θ
∂0∂v
∂0∂a
∂0∂φ
∂0∂E
∂0∂N
∂0∂θ
∂0∂v
∂0∂a
∂0∂φ
=
0 0 −v sin (θ + φ) cos (θ + φ) 0 −v sin (θ + φ)0 0 v cos (θ + φ) sin (θ + φ) 0 v cos (θ + φ)0 0 0 1
L tanφ 0 vL cos−2 φ
0 0 0 0 1 00 0 0 0 0 00 0 0 0 0 0
(5.17)
Now, implementation of Equation (5.9) on the onboard computer requires Equation (5.17)
107 Chapter 5. State Estimation and Measurement
to be transformed into the discrete-time domain and Equation (5.17) to be written in terms
of the most accurate states available to the onboard computer, i.e. the estimated states.
Therefore, Equation (5.9) becomes
Φk = Iunforced + T∂f∂x
∣∣∣∣x=xk
=
1 0 0 0 0 00 1 0 0 0 00 0 1 0 0 00 0 0 1 0 00 0 0 0 0 00 0 0 0 0 0
+T
0 0 −vk sin(θk + φk
)cos
(θk + φk
)0 −vk sin
(θk + φk
)0 0 vk cos
(θk + φk
)sin
(θk + φk
)0 vk cos
(θk + φk
)0 0 0 1
L tan φk 0 vkL cos−2 φk
0 0 0 0 1 00 0 0 0 0 00 0 0 0 0 0
=
1 0 −T vk sin(θk + φk
)T cos
(θk + φk
)0 −T vk sin
(θk + φk
)0 1 T vk cos
(θk + φk
)T sin
(θk + φk
)0 T vk cos
(θk + φk
)0 0 1 T
L tan φk 0 T vkL cos−2 φk
0 0 0 1 T 00 0 0 0 0 00 0 0 0 0 0
(5.18)
Now that the state transition matrix, Φk has been fully dened (as Equation (5.18)), the
System Model (Equation (5.8)) is complete, except for the Input Matrix, Γ, which remains
to be identied. The inputs to the system model are dened in Section 5.2 as the forward
acceleration and the steering angle. Consequently, the input matrix, Γ, is dened as Equation(5.19).
Γ =
0 00 00 00 01 00 1
(5.19)
This concludes the derivation of the system model. The model is given in complete form as
Equation (5.20).
5.3. System Model 108
Ek+1
Nk+1
θk+1
vk+1
ak+1
φk+1
⇐
1 0 −T vk sin(θk + φk
)T cos
(θk + φk
)0 −T vk sin
(θk + φk
)0 1 T vk cos
(θk + φk
)T sin
(θk + φk
)0 T vk cos
(θk + φk
)0 0 1 T
L tan φk 0 T vkL cos−2 φk
0 0 0 1 T 00 0 0 0 0 00 0 0 0 0 0
xk
yk
θk
vk
ak
φk
+
0 00 00 00 01 00 1
[
ak
φk
](5.20)
To determine if this system model functions correctly, the model was simulated with the
MATLAB le vehicle_dynamics.m which is provided on the accompanying DVD. Results are
presented and discussed in Section 9.5.1. Following the results, the System Model becomes
Equation (5.21).
Ek+1
Nk+1
θk+1
vk+1
ak+1
φk+1
⇐
1 0 0 T cos(θk + φk
)0 −T vk sin
(θk + φk
)0 1 0 T sin
(θk + φk
)0 T vk cos
(θk + φk
)0 0 1 T
L tan φk 0 T vkL cos−2 φk
0 0 0 1 T 00 0 0 0 0 00 0 0 0 0 0
xk
yk
θk
vk
ak
φk
+
0 00 00 00 01 00 1
[
ak
φk
](5.21)
109 Chapter 5. State Estimation and Measurement
5.3.2 System Model Implementation
As was mentioned earlier, the system model must run in synchronisation with the vehicle
so that the estimated vehicle states mimic the true vehicle states in real time (or at least
attempt to do so). This implies that the two inputs a and φ to the system model must also be
determined in real time and passed to the system model equation. For the acceleration term,
the unltered acceleration from the Inertial Measurement Unit was used. For the steering
angle, the Potentiometer signal was fed through a low pass lter with a short time constant to
avoid lag. Note that use of sensors to drive the system model does not incur a large error, so
long as the sensors are not very noisy. Even if the model acceleration and steering angle were
the true values, the system model would not mimic the true system perfectly since the true
system responds to process noise in the remaining states which the model has no knowledge
of. Fortunately, this inexactness is accounted for by the Kalman Filter, so the system model
need only be accurate during the period when the correcting sensors are not operating (which
is generally for less than than one second).
5.3.3 Derivation of the Process Noise Covariance Matrix
The process noise covariance matrix is dened as the matrix product of the process noise
vector, w, and its own transpose, (Kelly, 1994b),
Q = wwT (5.22)
The process noise vector is dened as the standard deviation of each of the vehicle states due
to physical variations (as opposed to sensor disturbances), from the perfect System Model,
given by
w =
σE
σN
σθ
σv
σa
σφ
(5.23)
It is dicult to determine the standard deviations of the position and velocity quantities,
however the standard deviation of the acceleration may be thought of as being due to random
forces from the wind, bumps in the road and small inclines and dips acting on the vehicle in
all directions. The magnitude of this acceleration standard deviation must be estimated, say
σa = 0.1m/s2. Now the velocity is proportional to the product of the acceleration standard
deviation and the sample period, i.e.
σv ∝ Tσa
so the velocity standard deviation is approximately equal to σv = Tσa, (Lu, 2007). Similarly,
5.4. Sensors 110
from Equation (5.21) the following relationships are extracted:
E ∝ vT cos (θ + φ)
N ∝ vT sin (θ + φ)
Now taking the maximum value (and thus overestimating the process noise) the Easting and
Northing process noise standard deviations may be determined as
σN = σE = σvT
The heading and steering angle process noise values remain to be determined. Since steering
angle is an input to the System Model, this noise cannot be derived from higher order deriva-
tives, as with the Easting and Northing, therefore the standard deviation in steering angle is
simply estimated to a value of σφ = 0.1rad. From Equation (5.21), the following relationship
is determined between the heading and steering angle
θ ∝ Tφv
Lcos−2 φ
The heading standard deviation is then determined as
σθ =T
Lσφσv cos−2 σφ
which may be calculated from previous standard deviation values.
The process noise covariance matrix (Equation (5.22)) is expanded out as
Q =
σ2EE σ2
EN σ2Eθ σ2
Ev σ2Ea σ2
Eφ
σ2NE σ2
NN σ2Nθ σ2
Nv σ2Na σ2
Nφ
σ2θE σ2
θN σ2θθ σ2
θv σ2θa σ2
θφ
σ2vE σ2
vN σ2vθ σ2
vv σ2va σ2
vφ
σ2aE σ2
aN σ2aθ σ2
av σ2aa σ2
aφ
σ2φE σ2
φN σ2φθ σ2
φv σ2φa σ2
φφ
(5.24)
The elements of this matrix may be determined from the above analysis. However, any
two noise standard deviations in this matrix that are uncorrelated must be set to zero. For
example, if the noise in the steering angle emanates from a dierent source than the noise in
the vehicle forward speed, then the σ2φv and σ2
vφ terms cancel to zero.
5.4 Sensors
It was noted in Section 5.2 that the particular choice of states dictates to a certain extent the
sensors required in the State Estimation and Measurement process. The states are corrected
111 Chapter 5. State Estimation and Measurement
Figure 5.3: The GPS unit mounted on the rack in the TARGET vehicle
by the sensors in the Kalman Filter, so each state and its corresponding sensor(s) must be
transformed into the same datum. The sensors used in the State Estimation process for the
TARGET vehicle are a Global Positioning Unit (GPS), an Inertial Measurement Unit (IMU),
a Hall-Eect sensor and a potentiometer on the steering column. The GPS unit outputs data
which is used to correct the Easting and Nothing and speed states; the IMU outputs data to
correct the heading and acceleration states; the Hall-Eect sensor outputs data to correct the
vehicle speed and the potentiometer corrects the steering angle. To incorporate these sensors
into the Kalman Filter, the sensor signals are rst decoded (this is generally only required for
signals from a serial port), transformations are then performed to convert the decoded values
into a more meaningful datum, the transformed data is then placed in the appropriate vectors
and matrices required by the Kalman Filter to perform corrections.
5.4.1 Global Positioning System (GPS) Unit
As discussed in the literature review, Section 3.4, the GPS sensing system consists of a Novatel
OEM4-G2 processing card and a Novatel GPS AntennaTM Model 511. The GPS processing
card is housed within a sealed enclosure that protects it from dust, water and other elements.
This enclosure is xed to the rack of the TARGET vehicle as shown in Figure 5.3.
The GPS processing card receives data from the GPS satellite constellation via the antenna,
which is mounted on a stand attached to the front roof-rack of the TARGET vehicle, as shown
in Figure 5.4. The stand is higher than the strobe lights and loudspeaker, which are situated
on the same roof-rack, to ensure that the antenna has an unrestricted view of the sky.
The GPS processing card interfaces with the antenna via a coaxial cable. The Navigation
Messages (refer to the Literature Review Section 3.4) received from the antenna are decoded
and output to the onboard computer via a serial RS232 connection.
5.4. Sensors 112
Figure 5.4: GPS antenna
5.4.1.1 Device Configuration
The rst step in conguring the GPS card is to set up the GPS card serial port to match the
onboard computer serial port. This was achieved by connecting the GPS unit to the serial
port of yet another PC running the Windows operating system. The current baud rate of the
GPS unit was determined as the baud rate which displayed the message:
[COM1]
on the hyper terminal display upon resetting the GPS card. The command:
COM COM1,115200,N,8,1,N,OFF,ON
followed by the Enter key was then sent to the GPS card via the hyperterminal to congure
the GPS card serial port to 115200 bits per second with no parity, eight data bits, one stop
bit, no handshaking, and break detection.
The settings were then saved to the receiver's non-volatile memory by entering the command:
SAVECONFIG
followed by the Enter key. The GPS card was then disconnected from the PC and connected
to the onboard computer.
The Novatel OEM4 family are capable of outputting data in three formats: abbreviated
ASCII, ASCII and binary. The ASCII and abbreviated ASCII formats are well suited for
viewing by a user since the output information is either returned as character strings or
numerical values following the protocol laid out in the second volume of the OEM4 family
113 Chapter 5. State Estimation and Measurement
user manual (NovAtel Inc, 2003). However, since the individual output elds vary in length
(for example the latitude position eld may have a dierent number of decimal places each
time it is output) it is unnecessarily dicult for a computer to retrieve the individual elds
from the data. The binary format, on the other hand, is impossible for the user the understand
at a glance, however each eld has a pre-dened number of bytes which enables a computer
to retrieve the individual elds from the data with ease. Furthermore, all binary messages
output by the OEM4 family begin with three Sync bytes which may be used to determine the
start of a new message. Since the data is required for processing by the onboard computer
and not the user, the binary output format was selected for use.
The basic requirement of the GPS unit is to output the current position of the antenna. The
Novatel OEM4 family instruction set has many commands which will do this; the most note-
worthy of which are the GPGGA, GPGLL, RTKPOS, BESTPOS and BESTXYZ logs. The
GPGGA and GPGLL logs both output the position in the Geodetic Datum (refer to Sec-
tion 3.4 for a description of this datum) in accordance with the National Marine Electronics
Association (NMEA) standards. The BESTPOS and RTKPOS logs conforms to the com-
pact measurement record (CMR) message format developed for real time kinematic (RTK)
applications by Trimble Navigation Ltd. This log enables a GPS base station to provide dif-
ferential corrections to the vehicle GPS receiver for improved accuracy (NovAtel Inc, 2003).
The log outputs position and the position error, in the form of position standard deviations,
in the geodetic coordinate system. Finally, the BESTXYZ log outputs both position and
velocity and their respective standard deviations in the Earth-Centered, Earth-Fixed (ECEF)
coordinate system (described in Section 3.4).
As will be discussed in Section 5.4.1.3, the GPS unit data is used by the Kalman Filter to
correct the position estimates. This requires the position to be referenced to the Tangent
Plane in units of metres. Unfortunately none of the logs output by the Novatel GPS card
give a measure of the position in this datum, therefore the data must be transformed into
this frame. The transformation from the Geodetic Datum to the Tangent Plane is far simpler
than the transformation from the ECEF datum to the tangent plane, however none of the
Geodetic Datum referenced logs output the velocity. Although the velocity measurement
by the GPS unit is not essential since the combination of speed from the Hall-eect sensor
and heading from the IMU essentially comprises velocity; it seems a waste not to use every
available update of the vehicle states. Therefore the BESTXYZ log is selected for output by
the GPS unit. The log is entered in the form:
LOG BESTXYZB ONTIME 0.1
followed by a carriage return character (equivalent to the Enter key) from the onboard com-
puter. The LOG command indicates to the OEM4 unit that it will need to return data in
response to the given input. BESTXYZB species that the BESTXYZ data must be output
in the binary format briey described above. ONTIME 0.1 instructs the unit to output data
with a period of 0.1 seconds. The specic data which results from this log is described in
detail in Section 5.4.1.2.
5.4. Sensors 114
Figure 5.5: The GPS data decoding program
5.4.1.2 The Data Decoding Program
The high-level structure of the GPS data decoding program and its interface to the Kalman
Filter is shown in the ow diagram of Figure 5.5.
Figure 5.5 indicates that the GPS data emerges from the serial port as a vector of bytes
which is then decoded into decimal values by the Data Conversion subsystem. The decimal
values output from this subsystem, which are related to the position and velocity, are then
transformed from the ECEF Datum into the Tangent Plane Datum by the Datum Transfor-
mations and Logic subsystem. This subsystem also uses the solution status (extracted by
various dierent means from the GPS data) to determine if the GPS position and velocity
solutions are valid. If they are not, then the transformation of the relevant data from ECEF
to the Tangent Plane is prevented and the position and velocity values are set to arbitrary
constants; also a series of error ags are set according to the specic error. The Tangent plane
data and error ags are then passed to the Kalman Filter. How the Kalman Filter utilises
this transformed data is the topic of Section 5.4.1.3. In the following section the function of
the Data Conversion and Datum Transformations and Logic subsystems is discussed.
The Data Conversion Subsystem
To best explain the functioning of the Data Conversion subsystem it is necessary to discuss
the incoming data to the computer software from the serial port connected to the GPS unit.
As has been mentioned, this data corresponds to the response of the OEM4 unit to the
BESTXYZB command and is organised as a set of individual bytes. In total the BESTXYZB
log returns 144 bytes, however only 101 of these are required - the reminder are terminated.
The specic elds of the BESTXYZ log and their corresponding lengths are shown in Tables
5.1 and 5.2.
Note that the elds which provide useful data are in bold, the other elds are ignored in
this discussion. The purpose of the Data Conversion subsystem is merely to transform the
data within each eld into values which are meaningful to Simulink. The meanings of the
individual elds are the focus of later discussions.
From Tables 5.1 and 5.2 it is clear that the types of data to be decoded are Ushort, Enum,
Long, Ulong, Double, Float and Uchar. The only eld with a Ulong data type in use is
the Receiver Status eld. However, as is discussed in the following section, the information
required from this eld is only required in the form of individual bits rather than a single
115 Chapter 5. State Estimation and Measurement
Table 5.1: The header component of the BESTXYZB logField Name Field Data Type Field Size (Bytes)
Sync Char 1
Sync Char 1
Sync Char 1
Header Length Uchar 1
Message ID Ushort 2
Message Type Char 1
Port Address Char 1
Message Length Ushort 2
Sequence Ushort 2
Idle Time Ushort 2
Time Status Enum 1
Week Ushort 2
Milliseconds Long 4
Receiver Status Ulong 4
Reserved Ushort 2
Receiver Software Version Ushort 2
Table 5.2: Format of the BESTXYZ logField Name Field Data Type Field size
Position Solution Status Enum 4
Position Type Enum 4
x Double 8
y Double 8
z Double 8
σx Float 4
σy Float 4
σz Float 4
Velocity Solution Status Enum 4
Velocity Type Enum 4
x Double 8
y Double 8
z Double 8
σx Float 4
σy Float 4
σz Float 4
Base Station ID Char 4
Velocity Latency Float 4
Dierential Age Float 4
Solution Age Float 4
Number of Satellites Currently Observed Uchar 1
Number of GPS L1 Ranges in Use Uchar 1
L1 Ranges Above Mask Angle Uchar 1
L2 Ranges Above Mask Angle Uchar 1
Reserved Char 4× 132-bit Checksum Hex 4
5.4. Sensors 116
Figure 5.6: Subsystem to decode a four-byte single-precision oating-point number
value, therefore the conversion for a Ulong is not required. Furthermore, the elds in use
which require an Enum data type conversion, namely the Time Status eld, the Position
Solution Status and the Velocity Status eld only ever contain data in the least signicant
byte (LSB). Therefore the remaining bytes which constitute these elds are simply terminated
and the conversion is complete. The Uchar data type is, by denition, a single unsigned byte,
therefore this data type requires no conversion. For the remaining data types, namely Ushort,
Long, Double and Float there are currently no Simulink blocks which perform data conversions
on multiple input bytes. Therefore it was necessary to create subsystems which perform the
conversions into signed values intelligible by Simulink.
The rst of the four conversion subsystems follows the IEEE745 protocol (Horvat, 1985)
when performing the transformation from a four-byte oating-point single-precision value
(referenced simply as Float in the OEM4 manual) to a double precision value intelligible by
Simulink. This subsystem is shown in Figure 5.6.
Note that the Extract Bit blocks output unbiased integers, for example, if the third bit alone
is extracted and is found to be a 1 then the output of the block is the number 1 and not the
number 8d (= 1000b). The triangular gain blocks are used to perform bit shifting in Simulink
double precision for greater accuracy. It is unnecessary to discuss the IEEE745 protocol as
executed by the subsystem shown in Figure 5.6 at this point since the reference given is readily
available on the internet and is very comprehensive.
A similar subsystem is created to transform eight-byte double-precision oating-point values
(referenced simply as Double in the OEM4 manual) into a single value intelligible by Simulink.
This subsystem is shown in Figure 5.7.
The remaining two decoding subsystems translate integers to intelligible values and so are
more intuitive than the oating-point numbers. Figure 5.8 shows the subsystem used to
decode a four-byte long signed integer (referenced simply as Long in the OEM4 manual). It
is clear from the gure that if the most signicant bit of the rst byte is a 1 then the output
is a negative value and if it is a 0 then the output is a positive value; this conforms with the
signed integer protocol, (Horvat, 1985). It is also clear that the range of possible values is
117 Chapter 5. State Estimation and Measurement
Figure 5.7: Subsystem to decode an eight-byte double-precision oating-point number
Figure 5.8: Subsystem to decode a four-byte long signed integer
−231 =-2147483648 up to 20 + 21 + 22 + ... + 230 = 231 − 1 = 214743647 which is also correct
for a signed long integer.
Finally, a subsystem to decode a two byte short unsigned integer (referenced simply as Ushort
in the OEM4 manual) is required. This subsystem is shown in Figure 5.9 and merely consists
of the Most Signicant Byte (MSB) shifted up by 8 bits and added to the Least Signicant
Byte (LSB).
In future these four subsystems will be referred to as Float, Double, Long and Ushort respec-
tively, as per the OEM4 family manual (Inc, 2003).
Figure 5.9: Subsystem to decode a two-byte short unsigned integer
5.4. Sensors 118
The Datum Transformations and Logic Subsystem
The data passing out from the Data Conversion subsystem then ows into the Datum Trans-
formation and Logic subsystem. At this stage the data contained in the individual elds,
listed in Tables 5.1 and 5.2, are available in a form directly compatible with Simulink. The
Datum Conversion and Logic subsystem performs the coordinate transformations to a datum
which is directly compatible with the Kalman Filter as well as performing logical operations
to determine the validity of the position and velocity solutions. The process of transforming
the coordinate system is now discussed.
As has already been mentioned, the BESTXYZ log outputs the position and velocity and their
respective standard deviations in the ECEF Coordinate System. However, the states dened
in the state matrix of the Kalman Filter, Equation (5.6), are referenced to the Tangent Plane
Coordinate System. Clearly the necessary transformation then is from the ECEF coordinate
system to the Tangent Plane coordinate system. This conversion requires an intermediate
conversion to the Geodetic Coordinate System and may therefore be described symbolically
as
P (x, y, z)ECEF → P (λ, φ, h)GEO → P (E,N, h)Tangent
where
P is the position
x, y and z are the ECEF coordinate axes as shown in Figure 3.13
λ is the longitude angle
φ is the latitude angle
h is the height above sea level
E is the Easting and
N is the Northing
Since the Earth is not a perfect sphere, the process of transforming the ECEF coordinate
system to the Geodetic coordinate system is not simple. The method of approximating the
Earth as an ellipsoid is widespread and so is selected for use. The ow of this iterative process
is shown in Figure 5.10.
The inputs to the iteration are the current position on the ECEF coordinate axes, (x, y, z),the semi-major axis of the Earth, a, and the semi-minor axis of the Earth, b. The earth model
which best approximates the region of interest (Adelaide, South Australia) is the Australian
Geodetic Datum (AGD84) which denes the ellipsoidal axes as, Xu (2003),
119 Chapter 5. State Estimation and Measurement
Figure 5.10: ECEF to Geodetic datum conversion iteration, Kelly (1994b).
a = 6378160.0m
b = 6356774.72m
The algorithm of Figure 5.10 is written in an embedded MATLAB le within the Datum
Transformations and Logic subsystem shown in Figure 5.5. Note that the arctan 2 (y, x)function in Figure 5.10 is a MATLAB-specic function similar to the conventional arctan y
x .
Note however that if y < 0 and x < 0 then arctan 2 (y, x) ∈ (−90,−180)o whereas arctan yx ∈
(0, 90)o, i.e. the arctan 2 function outputs the angle in the correct quadrant, whereas the
arctan function does not.
The solution convergence of the algorithm is dened by the hk+1 ≈ hk and φk+1 ≈ φk criteria
within the diamond shaped query block in Figure 5.10. These conditions basically state that
the iteration is complete once the solution does not change from one iteration step to the
next. This process is implemented in MATLAB code by determining the errors in height and
latitude from one iteration step to the next, i.e. eh = hk+1 − hk and eφ = φk+1 − φk. Once
these errors fall below the user dened bounds, i.e. once eh < herror bound and eφ < φerror bound,
the solution has been solved. Data collected from the BESTXYZB log of the OEM4 GPS
unit indicated that an average of 8 iterations where necessary for the solution to converge
below the bounds herror bound = 10−20m and φerror bound = 10−20rad, i.e. to virtually no
error. Implementation of the remainder of the algorithm is intuitive and therefore will not be
explained.
5.4. Sensors 120
Figure 5.11: The datum transformation of the position standard deviation
Once the position transformations have been implemented, the next step is to transform the
ECEF position standard deviations, (σx, σy, σz), velocities, (x, y, z), and velocity standard
deviations, (σx, σy, σz), to the Geodetic datum. Unfortunately, these data sets cannot simplybe passed through the transformation algorithm in Figure 5.10, since, unlike the ECEF da-
tum, they are referenced to the current position, (x, y, z) , and not to the center of the earth.
One solution to this problem is to simply add the data set in question to the current position
in the ECEF datum, convert the new data set to the Geodetic datum using the transforma-
tion algorithm and then subtract the Geodetic current position. This process is described
symbolically as
T (x2, y2, z2) = T (x1 + x2, y1 + y2, z + z2)− T (x1, y1, z1)
where (x1, y1, z1) is the ECEF position, (x2, y2, z2) is the ECEF position standard deviation,
velocity, or velocity standard deviation and the T () notation denotes a datum transformation
To gain a better understanding, consider the case where the position standard deviation, in
this case denoted, σP , is to be transformed from the ECEF datum to the Geodetic datum.
As shown in Figure 5.11 the position standard deviation is added vectorially to the position,
P1, still in the original ECEF coordinate frame, resulting in a new position vector, P2.
Both the new position, P2, and the original position, P1, are then transformed to the Geodetic
datum. Note that the position standard deviation, σP , is not transformed since it is not
referenced to the center of the earth. The magnitude of the position standard deviation in
each of the three Geodetic dimensions is determined as ∆φσ = φ2 − φ1, ∆λσ = λ2 − λ1 and
∆hσ = h2 − h1, as depicted in Figures 5.12, 5.13 and 5.14.
The velocity and velocity standard deviations are computed identically to the position stan-
dard deviation. Note that this method involves treating the velocity and velocity standard
121 Chapter 5. State Estimation and Measurement
Figure 5.12: Vector visualisation of the longitudinal position standard deviation
Figure 5.13: Vector visualisation of the latitudinal position standard deviation
5.4. Sensors 122
Figure 5.14: Vector visualisation of the height position standard deviation
deviation as distance variables during the transformations and then re-interpreting these dis-
tances as velocities following the transformation.
Now that the procedure for converting the required variables from the ECEF datum to the
Geodetic datum has been fully described, the procedure for converting the variables from the
Geodetic datum to the Tangent Plane is described. The equations which convert data in the
Geodetic datum into data in the Tangent Plane datum are well documented. However, it
was found that when a set of Geodetic position-data was transformed with these equations
into Tangent Plane data, the resulting plot was inexplicably rotated by approximately −20o.
Therefore a more simplistic and intuitive approach, in which the earth is locally approximated
as a sphere, was conceived.
Consider the Northing. Figure 5.15 shows a side view of the earth. The Northing, is the
circumferential distance in the North direction and is marked as N.
The Northing, N , relies on the radius of the Earth, R, and the change in Latitude, ∆φ.
Mathematically it is calculated as the distance around the circumference of a sphere of radius
R, i.e.
N = R∆φ (5.25)
Due to the approximation of the Earth as a sphere, the smaller the change in Latitude which is
used, the more accurate the Northing value. The accuracy may also be improved by constantly
updating the value of the radius which is dened as
R =√
x2 + y2 + z2 (5.26)
where x, y and z are available from the ECEF coordinate system.
123 Chapter 5. State Estimation and Measurement
Figure 5.15: The Northing
Figure 5.16: The Easting viewed looking down on the North Pole
The derivation of the Easting is very similar to that of the Northing. Figure 5.16 shows the
Earth viewed looking down on the North Pole.
The Easting, E, relies on the change in longitude, ∆λ, and the projection of the radius of the
Earth at the current location onto the equatorial plane, Req, i.e.
E = Req∆λ
The projection of the radius of the Earth onto the equatorial plane is best determined from
the side view of the Earth, shown in Figure 5.17.
From Figure 5.17 it is clear that the projection of the radius of the Earth onto the equatorial
5.4. Sensors 124
Figure 5.17: The Easting viewed looking at the Earth from the side
plane is dened as
Req = R cos φ
Therefore the Easting is dened as
E = R cos φ∆λ (5.27)
Due to the approximation of the Earth as a sphere, the smaller the change in Longitude which
is used, the more accurate the Easting value.
The height in the Geodetic datum requires no transformation into the Tangent Plane datum
as the denition of height in both datums is synonymous.
Equations (5.25) and (5.27), therefore fully dene the conversion from the Geodetic datum
to the Tangent Plane datum. To convert the Geodetic position to the Tangent Plane datum
using these Equations, an origin point, (λo, φo, ho), is determined. For the TARGET this point
is selected as the position of the vehicle at the time when communications are established
between the GPS unit and the onboard computer. The change in Latitude, ∆φ, required
for Equation 5.15, is calculated as the dierence between the current Latitude and origin
Latitude, i.e. ∆φ = φ − φo. Similarly the change in Longitude, ∆λ, required for Equation
(5.27), is calculated as the dierence between the current Longitude and the origin longitude
∆λ = λ− λo.
The transformations of the position standard deviation, velocity and velocity standard devi-
ations are much more simple. Since these quantities have no specied location on the face of
the Earth and since the terms already refer to incremental changes in the Geodetic datum
axes, the change in Latitude term in Equation (5.25) is simply replaced by the Latitudinal
position standard deviation, Latitudinal velocity or Latitudinal velocity standard deviation.
Similarly the change in Longitude term in Equation (5.27) is simply replaced by the Longi-
tudinal position standard deviation, Longitudinal velocity or Longitudinal velocity standard
125 Chapter 5. State Estimation and Measurement
deviation.
This completes the transformation from the ECEF datum to the Tangent Plane datum for
the four required variables. The stages of this conversion may be summarised as:
1 Convert the ECEF position into the Geodetic datum, i.e.
(x, y, z)ECEF → (λP , φP , hP )GEO
2 Form ECEF pseudo position vectors for the position standard deviation, velocity
and velocity standard deviations by adding them to the ECEF position. Transform
these into the Geodetic datum, i.e.
(x + σx, y + σy, z + σz)ECEF → (λP+σP, φP+σP
, hP+σP)GEO
(x + x, y + y, z + z)ECEF → (λP+V , φP+V , hP+V )GEO
(x + σx, y + σx, z + σz)ECEF → (λP+σV, φP+σV
, hP+σV)GEO
3 Subtract the Geodetic position from the Geodetic position standard-deviation, ve-
locity and velocity standard-deviation vectors to form the true position standard-
deviation, velocity and velocity standard deviation in the Geodetic datum, i.e.
(λσP = λP+σP
− λP , φσP = φP+σp − φP , hσP = hP+σP− hP
)GEO
(λV = λP+V − λP , φV = φP+V − φP , hV = hP+V − hV )GEO
(λσV = λP+σV− λP , φσV = φP+σV
− φP , hσV = hP+σV− hP )GEO
4 Transform the Geodetic position, position standard-deviation, velocity and veloc-
ity standard-deviations into the Tangent Plane datum using Equations (5.25) and
(5.27), i.e.
(λP , φP , hP )GEO → (EP , NP , hP )Tangent
(λσP , φσP , hσP )GEO → (EσP , NσP , hσP )Tangent
(λV , φV , hV )GEO → (EV , NV , hV )Tangent
5.4. Sensors 126
(λσV , φσV , hσV )GEO → (EσV , NσV , hσV )Tangent
As implied by the name, the Datum Transformations and Logic subsystem contains code for
performing datum transformations and logical switching. The process of datum transforma-
tions, described in detail above, is reasonably complex and so is implemented with Embedded
MATLAB code for increased eciency. This code utilises the x, y, z, σx, σy, σz, x, y, z, σx,
σy and σz elds from Table 5.2. The remainder of the highlighted elds in Tables 5.1 and 5.2
are required for the switching logic. A brief overview of each of these elds and their use in
the Datum Transformations and Logic subsystem follows.
Idle Time
The Idle Time eld indicates the percentage of the GPS card's Central Processing Unit (CPU)
in use. The Datum Transformations and Logic subsystem has the option to log this quantity
onto the onboard computer so that, in the unlikely event of GPS failure, the log le may be
consulted to determine if the failure was due to an overload of the GPS CPU.
Time Status
The Time Status eld indicates the accuracy of the receiver's clock in relation to the time
decoded from the satellite Navigation Message data. To provide an accurate position solution,
the satellite time must match the receiver clock, which is constantly being steered to follow
the satellite time. If the time error is too great then the Time Status eld is set to the
binary value equivalent to 20d or 130d. 20d occurs when no satelite ephemeris data has been
decoded (generally only at startup) and 130d occurs when the time error grows beyond a
certain bound. The Datum Transformations and Logic subsystem constantly compares the
Time Status to these two values. If either value is detected then the datum transformations (of
all position and velocity related quantities) are halted and the position and velocity ags are
set to indicate that the current data set has not been calculated. However, Simulink requires
subsystems to produce output quantities, therefore the position and velocity quantities are
arbitrarily set to 0 and output.
Milliseconds
The Milliseconds eld provides the current number of milliseconds since the beginning of the
GPS week. The Datum Transformations and Logic subsystem uses this value to ensure that
one set of GPS position data is only ever transformed once. This ensures that TARGET CPU
does not overload by attempting to execute the datum transformations more frequently than
necessary.
127 Chapter 5. State Estimation and Measurement
Receiver Status
The Receiver Status eld contains information on 32 dierent hardware and software errors
which the GPS unit may enconter. Only two of these errors are deemed critical - the tem-
perature error and the voltage supply error. The temperature error indicates that the OEM4
card has either overheated or underheated, and the voltage supply error indicates that the
voltage to the OEM4 card is either too high or too low. If the Datum Transformations and
Logic subsystem detects either of these critical errors, a failure-mode ag is set and other
subsystems within the Simulink model ensure that the TARGET vehicle comes to a halt.
The GPS unit may then be inspected for damage, hopefully before the damage becomes too
severe. Other Receiver Status indicators which provide information on errors which are non-
critical are the (GPS card) CPU Overload Flag, the (GPS card) COM1 Buer Overrun Flag,
the Almanac Flag and the Position Solution Flag. If any of these errors occurs, the datum
transformations on the data are temporarily prevented and the position and velocity error
ags are set. The CPU Overload Flag is set when the GPS card CPU attempts to process to
much data at too high a rate; the eect of a CPU overload is random loss of data (NovAtel
Inc, 2003). Consequently, the position or velocity related terms output from the unit may be
incorrect if the CPU overloads. If this is the case then it is a waste of the TARGET CPU
to perform the datum conversions; hence the conversions are prevented and the Position and
Velocity Error Flags are set. The eect of an OEM4 COM1 buer overrun (this is the serial
port on the OEM4 card which is connected to the onboard computer) is identical to a CPU
overload, hence these two errors are dealt with in the same manner. The Almanac Error
and the Position Solution Error both essentially mean that the position solution cannot be
calculated by the OEM4 unit. It is therefore appropriate to cancel the datum conversions
and set the Position Error Flag. As discussed in the Literature Review (Section 3.4), the
GPS unit calculates velocity using Doppler measurements which rely on the position; if the
position is not available then the velocity cannot be correct, therefore for the Almanac Error
and the Position Solution Error ags the Velocity Error ag within the Datum Transforma-
tions and Logic subsystem is also set. The entire Receiver Status eld is also logged to the
onboard computer so that the hardware and software errors which occurred with the OEM4
unit during the run may be inspected.
Position Solution Status
The Position Solution Status eld indicates the level of accuracy of the position solution
as calculated by the OEM4. The Position Solution Status is set to 0 to indicate that the
position solution is acceptable. Other values in this eld correspond to position solutions which
may not give position errors in the Receiver Status eld but which may have unpredictable
accuracy. Therefore if the value of the Position Solution Status eld is not zero then the
Position Error Flag within the Datum Transformations and Logic subsystem is set and the
datum transformation process is temporarily halted.
5.4. Sensors 128
Velocity Solution Status
The Velocity Solution Status eld is equivalent the Position Solution Status eld, except that
it relates only to the velocity. If this eld returns any value other than 0 it indicates that the
velocity is not valid. Note that it is possible for the position to be valid and the velocity invalid
(for example if only one position measurement is taken then the Doppler velocity cannot be
known), therefore if this eld is a non-zero value then only the Velocity Error ag within the
Datum Transformations and Logic subsystem is set and only the velocity-related terms are
prevented from entering the datum transformation process.
Number of GPS L1 Ranges in Use
This eld states the number of GPS satellites from which ephemeris data is currently being
used to compute the position solution. The eld is logged to the onboard computer for interest.
Velocity Latency
This eld provides the exact number of seconds since the velocity solution was calculated
(to single precision oating point accuracy). The value is used to determine if the velocity
solution is current or not. If it is not current then the datum of the velocity related terms is
not transformed since this would simply involve re-transforming the same data. If the velocity
is not current, the Datum Transformations and Logic subsystem velocity error ag is set.
Note that all position error ags mentioned above are AND'ed together, as are the velocity
error ags. These error ags always occur in conjunction with the appropriate datum transfor-
mation being canceled (i.e. the position related variables are canceled in the case of a position
error ag and the velocity-related variables are canceled in the case of a velocity error ag).
These ags are then passed to the Kalman Filter, along with the Tangent Plane-referenced
position and velocity data.
5.4.1.3 Integrating the GPS Sensor into the Kalman Filter
Section 5.4.1.2 describes the inner workings of the GPS data decoding program. The purpose
of this program is to transform the geometric GPS data into a form which may be eciently
integrated into the Kalman Filter. The geometric data which ows out of the decoding
program and into the Kalman Filter consists of the position, the velocity, the position standard
deviation and the velocity standard deviation, each referenced to the Tangent Plane datum,
i.e.[(E,N, h) ,
(E, N , h
), (σE , σN , σh) ,
(σE , σN , σh
)]. Since it is possible that the position
data is available when the velocity data is not, the State Update equations are divided into
two sets of equations - GPS position updates and GPS velocity updates. Each of these sets
of Equations contains a Measurement Vector, a Measurement Matrix and a Sensor Noise
129 Chapter 5. State Estimation and Measurement
Covariance Matrix. These matrices and vectors are required to form the Kalman Gain Matrix
which in turn will update the States Vector and State Covariance Matrix.
Velocity State Updates from the GPS Unit
The measurement vector for the GPS velocity, yGPS−V , is dened as Equation (5.28).
yGPS−V =
[E
N
](5.28)
Note that the vertical speed, h, is omitted from this vector since the vehicle is assumed to
travel only on at ground. The rst step in deriving the measurement matrix for the velocity
component of the GPS sensor update equations, Equation (5.31), is to reduce the terms in
the measurement vector, Equation (5.28), to functions of the states, i.e.
yGPS−V = hGPS−V (x)
The relationship between the states and the variables of measurement is given in Equations
(5.13) and (5.14). Therefore the ideal state measurement vector becomes Equation (5.29).
hGPS−V (x) =
[v cos (θ + φ)v sin (θ + φ)
](5.29)
=
[hGPS−V1 (x)hGPS−V2 (x)
]The next stage in deriving the GPS sensor velocity measurement matrix is to take the Jacobian
of the ideal state measurement vector, h, with respect to the states; as per Equation (5.30).
HGPS−V (x) =∂hGPS−V (x)
∂x(5.30)
=
[∂hGPS−V1
(x)
∂x1
∂hGPS−V1(x)
∂x2
∂hGPS−V1(x)
∂x3
∂hGPS−V1(x)
∂x4
∂hGPS−V1(x)
∂x5
∂hGPS−V1(x)
∂x6∂hGPS−V2
(x)
∂x1
∂hGPS−V2(x)
∂x2
∂hGPS−V2(x)
∂x3
∂hGPS−V2(x)
∂x4
∂hGPS−V2(x)
∂x5
∂hGPS−V2(x)
∂x6
]
=
[∂v cos(θ+φ)
∂E∂v cos(θ+φ)
∂N∂v cos(θ+φ)
∂θ∂v cos(θ+φ)
∂v∂v cos(θ+φ)
∂a∂v cos(θ+φ)
∂φ∂v sin(θ+φ)
∂E∂v sin(θ+φ)
∂N∂v sin(θ+φ)
∂θ∂v sin(θ+φ)
∂v∂v sin(θ+φ)
∂a∂v sin(θ+φ)
∂φ
]
=
[0 0 −v sin (θ + φ) cos (θ + φ) 0 −v sin (θ + φ)0 0 v cos (θ + φ) sin (θ + φ) 0 v cos (θ + φ)
]Equation (5.30) gives the GPS Velocity Measurement Matrix in continuous form as a function
of idealised states. Since the chosen method to implement the Kalman Filter is in Embedded
MATLAB code on the onboard computer, the Measurement Matrix (Equation (5.30)) must
be converted to discrete form. This matrix is a function of the idealised states which are not
5.4. Sensors 130
available for use since these are the true (unobtainable) states of the vehicle; therefore the
best approximations of these states - the most recent state estimates, x, are used instead.
These substitutions are implemented in Equation (5.31).
HGPS−V (xk) =
0 0 −vk sin(θk + φk
)cos
(θk + φk
)0 −vk sin
(θk + φk
)0 0 vk cos
(θk + φk
)sin
(θk + φk
)0 vk cos
(θk + φk
) (5.31)
As explained in Section 5.1, the Sensor Noise Matrix contains the covariances of the measure-
ment updates arranged along the leading diagonal with the remainder of the elements in this
square matrix set to zero. The Measurement Noise Matrix for the velocity component of the
GPS sensor update is given as Equation (5.32).
RGPS−Vk=
σ2EGPSk
0
0 σ2NGPSk
(5.32)
The current Easting-rate covariance, σ2EGPSk
, and Northing-rate covariance, σ2NGPSk
, are sim-
ply the square of the standard deviations which are output from the Datum Transformations
and Logic subsystem to the Kalman Filter subsystem within the onboard computer program.
As the GPS unit provides a measure of the accuracy of its own velocity solution, in the form
of velocity standard deviations, the GPS velocity sensor noise matrix may be constantly up-
dated. This ensures that the Kalman Filter correctly updates the states, such that the best
possible state estimates are returned.
Note that the Kalman Filter is designed under the assumption that measurements of the
elements of the Velocity Measurement Equation (5.28) are randomly distributed with zero-
mean. Essentially this means that both the Easting velocity and the Northing velocity as
output from the GPS sensor may have noise, providing that it is distributed such that the
mean lies on the true Easting and Northing velocities.
All of the matrices required to calculate the instantaneous Kalman Gain Matrix, given as
Equation (5.33), have now been determined. The 6× 6 matrix of state estimate covariances,
Pk, used to calculate this matrix, is available either from the vehicle model a-priori covariance
(see Equation (5.2)) or from the posteriori covariance of any of the sensors which may have
been used to correct the states of the vehicle model (Equations (5.35), (5.42), (5.54) and
(5.61)).
KGPS−Vk⇐ PkH
TGPS−Vk
(HGPS−Vk
PkHTGPS−Vk
+ RGPS−Vk
)−1(5.33)
The error between the current GPS velocity sensor states , yGPS−Vk, and the current state
estimates transformed into the same dimensions as the GPS velocity sensor states, h (xk), is
131 Chapter 5. State Estimation and Measurement
then multiplied by the Kalman Gain Matrix and added to the previous estimate of the vehicle
states. This process, given as Equation (5.34), updates the states based on the most recent
velocity data from the GPS unit.
xk ⇐ xk + KGPS−Vk(yGPS−V − h (xk)) (5.34)
The state covariance matrix, P , dened as Equation (5.35), is also updated to give a measure
of the accuracy of the state update which just occurred.
Pk ⇐ (I −KGPS−VkHGPS−Vk
) Pk (5.35)
Position State Updates from the GPS Unit
The Measurement Vector for the GPS position, yGPS−P , is dened as
yGPS−P =
[EGPS
NGPS
](5.36)
Note that the height coordinate, h, is omitted from this vector since the vehicle is assumed to
travel only on at ground. The rst step in deriving the Measurement Matrix for the position
component of the GPS sensor update equations (Equation (5.38)) is to reduce the terms in
the Measurement Vector (Equation (5.36)) to functions of the states, i.e.
yGPS−P = hGPS−P (x)
Since the states and the variables of measurement are both dened as the coordinate axes of
the Tangent Plane datum, the ideal State Measurement Vector becomes
hGPS−P (x) =
[E
N
](5.37)
=
[hGPS−P1 (x)hGPS−P2 (x)
]The GPS-sensor Position Measurement Matrix is then determined as Equation (5.38) by
taking the Jacobian of the ideal State Measurement Vector, h, with respect to the states,
HGPS−P (x) =∂hGPS−P (x)
∂x(5.38)
=
[∂hGPS−P1
(x)
∂x1
∂hGPS−P1(x)
∂x2
∂hGPS−P1(x)
∂x3
∂hGPS−P1(x)
∂x4
∂hGPS−P1(x)
∂x5
∂hGPS−P1(x)
∂x6∂hGPS−P2
(x)
∂x1
∂hGPS−P2(x)
∂x2
∂hGPS−P2(x)
∂x3
∂hGPS−P2(x)
∂x4
∂hGPS−P2(x)
∂x5
∂hGPS−P2(x)
∂x6
]
5.4. Sensors 132
=
[∂E∂E
∂E∂N
∂E∂θ
∂E∂v
∂E∂a
∂E∂φ
∂N∂E
∂N∂N
∂N∂θ
∂N∂v
∂N∂a
∂N∂φ
]
=
[1 0 0 0 0 00 1 0 0 0 0
]Equation (5.38) gives the GPS Position Measurement Matrix. The noise in each of the sensor
states in this matrix is introduced to the Kalman Filter as Equation (5.39). As explained in
Section 5.1, the Sensor Noise Matrix contains the covariances of the measurement updates
arranged along the leading diagonal with the remainder of the elements in this square matrix
set to zero. The Measurement Noise Matrix for the position component of the GPS sensor
update is given as
RGPS−Pk=
σ2EGPSk
0
0 σ2NGPSk
(5.39)
The current Easting covariance, σ2EGPSk
, and Northing covariance, σ2NGPSk
, are simply the
square of the standard deviations which are output from the Datum Transformations and
Logic subsystem to the Kalman Filter subsystem within the onboard computer program. As
the GPS unit provides a measure of the accuracy of its own position solution, in the form
of position standard deviations, the GPS position sensor noise matrix may be constantly
updated. This ensures that the Kalman Filter correctly updates the states, such that the best
possible state estimates are returned.
Note that the Kalman Filter is designed under the assumption that the sensor measurements
of the elements of the Position Measurement Vector (5.36) are randomly distributed with
zero-mean. Essentially this means that both the Easting and the Northing as output from
the GPS sensor may have noise, providing that it is distributed such that the mean lies on
the true Easting and Northing.
All of the matrices required to calculate the instantaneous Kalman Gain Matrix, given as
Equation (5.40), have now been determined. The 6×6 matrix of State Estimate Covariances,
Pk, used to calculate this matrix, is available either from the vehicle model a-priori covariance
(see Equation 5.2) or from the posteriori covariance of any of the sensors which may have been
used to correct the states of the vehicle model (Equations (5.35), (5.42), (5.54) and (5.61)).
KGPS−Pk⇐ PkH
TGPS−Pk
(HGPS−Pk
PkHTGPS−Pk
+ RGPS−Pk
)−1(5.40)
The error between the current GPS position sensor states , yGPS−Pk, and the current state
estimates transformed into the same dimensions as the GPS position sensor states, h (xk),is then multiplied by the Kalman Gain Matrix and added to the previous estimate of the
vehicle states. This process, given as Equation (5.41), optimally updates the states based on
the most recent position data from the GPS unit.
133 Chapter 5. State Estimation and Measurement
Figure 5.18: The IMU mounted on the rack in the TARGET vehicle
xk ⇐ xk + KGPS−Pk(yGPS−P − h (xk)) (5.41)
The State Covariance Matrix, P , dened as Equation (5.42), is also updated to give a measure
of the accuracy of the state update which just occurred.
Pk ⇐ (I −KGPS−PkHGPS−Pk
) Pk (5.42)
This completes the State Update Equations based on data from the GPS unit. These equations
are implemented subject to the status of the Position and Velocity Error Flags. If either error
ag is set then the corresponding State Update equations are simply not executed and the
states are not updated with information from the sensor at fault.
5.4.2 Inertial Measurement Unit Sensor
The chosen Inertial Measurement Unit (IMU) sensor is a Microstrain 3DM-GX1, Firmware
Version 3.1.02. The IMU processing card is housed within a sealed enclosure which protects
it from dust, water and other elements. This enclosure is currently xed to the top of the
rack in an attempt to remove the unit from magnetic elds which were found to be greater
near the oor pan of the TARGET vehicle, as shown in Figure 5.18.
As discussed in detial in Literature Review in Section 3.4, the 3DM-GX1 combines the data
from three angular rate gyroscopes, three orthogonal accelerometers and three orthogonal
magnetometers to output the Euler angles, the Euler angular rates and the acceleration in
the three orthogonal axes of the unit. The IMU interfaces with the onboard computer via a
serial RS232 connection.
5.4. Sensors 134
Figure 5.19: The IMU data decoding program
5.4.2.1 Device Configuration
The speed of the serial port of the 3DM-GX1 was determined by plugging the unit into a
PC running Windows XP and running the Data Acquisition and Display software designed
specically for the 3DM-GX1. The serial port speed was found to be 115200 baud. For the
purposes of calibration, Section 5.4.2.2 requires the values which lie in registers 130 and 230
in the 3DM-GX1's EEPROM. These values where found to be 8500 and 13000 by again using
the Data Acquisition and Display software to read the EEPROM addresses. The 3DM-GX1
was then disconnected from the PC and connected to the onboard computer, which was set
up to match the rate of the serial port.
Data is retrieved from the 3DM-GX1 by sending it one of the byte-sized commands listed
in the instruction set through the serial connection. Depending on the command issued
by the host computer, the response may consist of the raw data from the accelerometers,
gyros and magnetometers, the temperature of the unit, the orthogonalised acceleration, the
instantaneous Euler angles, the gyro-stabilised Euler angles, the instantaneous angular rates
and the compensated angular rates. The command selected for use in the TARGET vehicle
project was command 0x31. In response to this command the 3DM-GX1 outputs the gyro-
stabilised Euler angles, the orthogonalised acceleration, the compensated angular rates, a
time stamp and a checksum. These values are output in the form of signed or unsigned short
integers (i.e. two bytes each) and were scaled by the appropriate gains to transform the data
into the correct units. The checksum is useful for ensuring that the data transmitted from
the 3DM-GX1 to the onboard computer is complete, and the timestamp is used to determine
if new data has been received.
5.4.2.2 Data Decoding Program
The high-level structure of the IMU data decoding program and its interface to the Kalman
Filter is shown in the ow diagram of Figure 5.19. The gure indicates that the IMU data
emerges from the serial port as a vector of individual bytes which is then decoded into decimal
values by the IMU Data Conversion subsystem. This subsystem both scales the data into the
correct units for the Kalman Filter and performs logical checks on the data to determined its
validity.
To best explain the functioning of the IMU Data Conversion and Logic subsystem it is nec-
essary to discuss the incoming data from the serial port. As has been mentioned, this data
135 Chapter 5. State Estimation and Measurement
Table 5.3: Response of the 3DM-GX1 to the 0x31 commandField Name Field Data Type
Header Byte Short Uint
Roll MSB Short Uint
Roll LSB Short Uint
Pitch MSB Short Uint
Pitch LSB Short Uint
Yaw MSB Short Uint
Yaw LSB Short Uint
X acceleration MSB Short Int
X acceleration LSB Short Int
Y acceleration MSB Short Int
Y acceleration LSB Short Int
Z acceleration MSB Short Int
Z acceleration LSB Short Int
Roll rate MSB Short Int
Roll rate LSB Short Int
Pitch rate MSB Short Int
Pitch rate LSB Short Int
Yaw rate MSB Short Int
Yaw rate LSB Short Int
Timer ticks MSB Short Uint
Timer ticks LSB Short Uint
Checksum MSB Short Uint
Checksum LSB Short Uint
corresponds to the response of the 3DM-GX1 to the 0x31 command and is organised as a
set of 23 individual bytes. The specic bytes resulting from the 0x31 command are shown in
Table 5.3.
The rst entry of Table 5.3, the header byte, is used by the onboard computer to determine
the beginning of the response. Since this byte always has the same value as the command
value (31H = 49d) the onboard computer simply waits for this value before reading the entire
IMU response into the program. Once the response enters the program, only the elds which
are bold are used and the remainder of the elds are terminated. The elds of data type Short
Uint are combined into a form more intelligible to Simulink by simply multiplying the most
signicant byte (MSB) by 28 (i.e. shifting it up by 8 bits) and adding it to the least signicant
byte (LSB). This subsystem has already been implemented in the GPS data decoding program
and is given as Figure 5.9. The conversion from two bytes to a single signed value (Short Int)
is similar, except that the most signicant bit of the most signicant byte is used to determine
the sign of the nal value. The subsystem used to implement this procedure is shown in Figure
5.20.
5.4. Sensors 136
Figure 5.20: Subsystem to decode a short signed integer
Once all of the individual bytes have been decoded, the normalisation and transformation
process is executed. This process involves multiplying the decoded values by a given constant
to transform them into the desired units, and ensuring that the denitions of the values
matches that expected by the Kalman Filter. Note that only the values in bold in Table 5.3
are required and hence are normalised and transformed.
The yaw is transformed into degrees by multiplying the decoded value by 36065535 . The value of
the yaw is then biased to ensure that zero is output when the unit is facing due East. This
is the denition of the yaw (which up until this point has been called the heading) as given
in Figure 5.2. The yaw is also subtracted from the value 360 to ensure that rotations in the
anticlockwise direction yield positive values. The yaw enters the Kalman Filter in degrees
where it is promptly converted to radians.
The accelerations are transformed into the units of meters per second per second by multi-
plying the decoded values by 9.81Reg23032768000 , where Reg230 = 13000 was determined in Section
5.4.2.1 and 32768000 is a scaling constant. No modications to the accelerations are required
before passing them to the Kalman Filter.
The yaw rate is transformed into the units of degrees per second by multiplying the decoded
values by Reg13032768000 , where Reg130 = 8500 was determined in Section 5.4.2.1. This value
requires multiplication by −1 to ensure that anticlockwise rotations yield positive yaw rate
values, as is the convention used in the Kalman Filter.
Scaling is not performed on the Checksum eld, since this eld is used to determine if the
incoming data is valid. The Checksum must be equal to the sum of all the previous bytes
(determined as the LSBs added together and then added the sum of the MSBs shifted up by 8
bits). If this Checksum fails then an error ag is set within the IMU data decoding program.
This error ag may also be set if any of the yaw, x acceleration, y acceleration and yaw rate
are out of their predened ranges or move at an unacceptable rate from one time step to the
next.
As will be discussed in Section 5.4.2.3, the timer-ticks are merely required by the Kalman
Filter to determine if the incoming data is new, therefore the timer ticks are left unscaled,
rather than scaling them to the same units as time.
137 Chapter 5. State Estimation and Measurement
5.4.2.3 Integrating the IMU Data into the Kalman Filter
Under the assumption that the TARGET vehicle drives only on at ground, the pitch, roll,
z-acceleration, pitch rate and roll rate are always zero and so are of no assistance when
attempting to estimate the vehicle states. The Measurement Vector for the IMU, yIMU , is
therefore dened to include the states which do vary as the vehicle drives on at ground,
namely those given in Equation (5.43).
yIMU =
yIMU
θIMU
θIMU
(5.43)
Note that the sensed quantity x (the forward acceleration) is not included in this vector since
it is used in raw form as one of the vehicle model inputs. yIMU is the acceleration normal
to the direction of vehicle motion, θ is the yaw or heading and θ is the yaw rate or heading
rate. The rst step in deriving the Measurement Matrix for the IMU sensor update equations
(Equation (5.50)) is to reduce the terms in the Measurement Vector (Equation (5.43)) to
functions of the states, i.e.
yIMU = hIMU (x)
The IMU heading, θIMU , is directly equivalent to the state, θ , however the normal acceler-
ation, yIMU , and the heading rate, θIMU , are not related so simply. The heading rate may
be written as a function of the states using one of the car-like mathematical vehicle model
equations, (Barton, 2001),
θ =v
Ltanφ (5.44)
For the normal acceleration, the equation of motion for a body under rotation, the following
is used,
y =v2
R(5.45)
where R is the radius of the instantaneous circular path. This radius is also dened as
Equation (5.46), which forms part of the car-like mathematical vehicle model equations.
R =v2
θ(5.46)
Substituting Equation (5.44) into Equation (5.46), yields Equation (5.47).
R =L
tanφ(5.47)
5.4. Sensors 138
Then substituting Equation (5.47) into Equation (5.45) gives Equation(5.48).
y =v2 tanφ
L(5.48)
An ideal IMU sensor, containing no noise, would therefore be expressible as a function of the
states, as given by Equation (5.49).
yIMU
θIMU
θIMU
=
v2 tan φ
L
θv tan φ
L
(5.49)
=
hIMU1 (x)hIMU2 (x)hIMU3 (x)
The IMU Sensor Measurement Matrix is then determined as Equation (5.50) by taking the
Jacobian of the ideal State Measurement Vector, h, with respect to the states.
HIMU (x) =∂hIMU (x)
∂x(5.50)
=
∂hIMU1
(x)
∂x1
∂hIMU1(x)
∂x2
∂hIMU1(x)
∂x3
∂hIMU1(x)
∂x4
∂hIMU1(x)
∂x5
∂hIMU1(x)
∂x6∂hIMU2
(x)
∂x1
∂hIMU2(x)
∂x2
∂hIMU2(x)
∂x3
∂hIMU2(x)
∂x4
∂hIMU2(x)
∂x5
∂hIMU2(x)
∂x6∂hIMU3
(x)
∂x1
∂hIMU3(x)
∂x2
∂hIMU3(x)
∂x3
∂hIMU3(x)
∂x4
∂hIMU3(x)
∂x5
∂hIMU3(x)
∂x6
=
∂ v2 tan φ
L∂E
∂ v2 tan φL
∂N
∂ v2 tan φL
∂θ
∂ v2 tan φL
∂v
∂ v2 tan φL
∂a
∂ v2 tan φL
∂φ∂θ∂E
∂θ∂N
∂θ∂θ
∂θ∂v
∂θ∂a
∂θ∂φ
∂ v tan φL
∂E
∂ v tan φL
∂N
∂ v tan φL
∂θ
∂ v tan φL
∂v
∂ v tan φL
∂a
∂ v tan φL
∂φ
=
0 0 0 2v tan φL 0 v2
L cos2 φ
0 0 1 0 0 00 0 0 tan φ
L 0 vL cos2 φ
Equation (5.50) gives the IMU Measurement Matrix which relates the vehicle states to the
IMU Sensor Measurement Vector, Equation (5.49), in the absence of sensor noise. The noise
in each of the sensor states in vector (5.49) is introduced to the Kalman Filter through the
IMU Noise Covariance Matrix as Equation (5.51).
RIMU =
σ2
yIMU0 0
0 σ2θIMU
00 0 σ2
θIMU
(5.51)
139 Chapter 5. State Estimation and Measurement
where σ2yIMU
is the covariance of the (zero-mean) Gaussian noise on the vehicle normal accel-
eration as measured by the IMU, σ2θIMU
is the covariance of the (zero-mean) Gaussian noise on
the heading as measured by the IMU and σ2θIMU
is the covariance of the (zero-mean) Gaussian
noise on the heading rate as measured by the IMU.
All of the matrices required to calculate the instantaneous Kalman Gain Matrix, given as
Equation (5.52), have now been determined. The 6×6 matrix of State Estimate Covariances,
Pk, used to calculate this matrix, is available either from the Vehicle Model A-Priori Covari-
ance Matrix (Equation (5.2)) or from the Posteriori Covariance of any of the sensors which
may have been used to correct the states of the vehicle model (Equations (5.35), (5.42), (5.54)
and (5.61)).
KIMUk⇐ PkH
TIMUk
(HIMUk
PkHTIMUk
+ RIMUk
)−1(5.52)
The error between the current IMU sensor states, yIMU , and the current state estimates
transformed into the same dimensions as the IMU sensor states, h (xk), is then multiplied
by the Kalman Gain Matrix and added to the previous estimate of the vehicle states. This
process, given as Equation (5.53) optimally updates the states based on the most recent data
from the IMU.
xk ⇐ xk + KIMUk(yIMU − h (xk)) (5.53)
The state covariance matrix, P , dened as Equation (5.54), is also updated to give a measure
of the accuracy of the state update which just occurred.
Pk ⇐ (I −KIMUkHIMUk
) Pk (5.54)
This completes the state update Equations based on data from the IMU sensor. These
Equations are implemented if the error ag output by the IMU Data Conversion and Logic
subsystem is zero and if the timestamp output from this same subsystem has changed since
the previous IMU sensor update. If either of these is not the case then the state update
equations are simply not executed and the vehicle states are not updated with information
from the IMU sensor.
5.4.3 Hall-Effect Sensor
The chosen Hall-eect sensor is a Honeywell GT1 series 1GT101DC solid state Hall-Eect
Sensor. The delicate components of the sensor are house within a rugged plastic container
which provides protection from water, dust vibration and shock. The sensor is mounted on
a bracket facing the constant-velocity (CV) joint of the tailshaft of the TARGET vehicle
as shown in Figure 5.21. In this conguration, the sensor measures the angular rate of the
tailshaft which is proportional to the speed of the vehicle.
5.4. Sensors 140
Figure 5.21: The IMU mounted on the rack in the TARGET vehicle
The Hall-Eect sensor outputs a voltage pulse every time one of the edges of the CV joint
passes beneath it. However, this conguration was found to be very intensive for the onboard
computer, so the pulse wave was modied to an analogue voltage with an electrical circuit,
as discussed in Section 4.8.4.
5.4.3.1 Integrating the Hall-Effect Sensor Data into the Kalman Filter
The analogue voltage from the Hall-Eect Sensor, which is read into the onboard computer,
is biased, scaled and low pass ltered before being passed on to the Kalman Filter. This
process is largely for the purposes of tuning the Motion Execution Controller in the absence
of a fully functioning Kalman Filter. The scaling and biasing eectively translate the voltage
into a speed in kilometers per hour; therefore upon input to the Kalman Filter, the speed is
converted to a value in meters per second, for consistency with the Kalman Filter units. The
Measurement Vector for the Hall-Eect Sensor, yHall, therefore is simply dened as
yIMU =[
vHall
](5.55)
where vHall is the speed as determined by the hall eect sensor. The rst stage in deriving
the Measurement Matrix for the Hall-Eect sensor update equations (Equation (5.57)) is to
reduce the terms in the Measurement Vector (Equation (5.55)) to functions of the states, i.e.
yHall = hHall (x)
If the Hall-Eect derived speed were perfect, then it would be directly equivalent to the speed
state, v, as given by Equation (5.56).
[vHall] = [v] (5.56)
= [hHall (x)]
The Hall-Eect Sensor Measurement Matrix is then determined as Equation (5.57) by taking
141 Chapter 5. State Estimation and Measurement
the Jacobian of the ideal State Measurement Vector, h, with respect to the states.
HHall (x) =∂hHall (x)
∂x(5.57)
=[
∂hHall(x)∂x1
∂hHall(x)∂x2
∂hHall(x)∂x3
∂hHall(x)∂x4
∂hHall(x)∂x5
∂hHall(x)∂x6
]=
[∂v∂E
∂v∂N
∂v∂θ
∂v∂v
∂v∂a
∂v∂φ
]=
[0 0 0 1 0 0
]Equation (5.57) gives the Hall-Eect sensor Measurement Matrix which relates the vehicle
states to the Hall-Eect sensor Measurement Vector, Equation (5.56), in the absence of sensor
noise. The noise in the velocity state in Equation (5.56) is introduced to the Kalman Filter
through the Hall-Eect Sensor Noise Covariance Matrix as
RHall =[σ2
vHall
](5.58)
where σ2vHall
is the covariance of the (zero-mean) Gaussian noise in the velocity as measured
by the Hall-Eect sensor. This quantity is very small since the value has already been low-pass
ltered. Its approximate value may be determined by logging the signal and observing the
spread of noise over time just before it enters the Kalman Filter, for a few constant vehicle
speeds.
All of the matrices required to calculate the instantaneous Kalman Gain Matrix, given as
Equation (5.52), have now been determined. The 6×6 matrix of State Estimate Covariances,
Pk, used to calculate this matrix, is available either from the Vehicle Model A-Priori Covari-
ance Matrix (Equation (5.2)) or from the Posteriori Covariance of any of the sensors which
may have been used to correct the states of the vehicle model (Equations (5.35), (5.42), (5.54)
and (5.61)).
KHallk ⇐ PkHTHallk
(HHallkPkH
THallk
+ RHallk
)−1(5.59)
The error between the current Hall-Eect sensor states, yHall, and the current state estimates
transformed into the same dimensions as the Hall-Eect Sensor states, h (xk), is then multi-
plied by the Kalman Gain Matrix and added to the previous estimate of the vehicle states.
This process, given as Equation (5.60) optimally updates the states based on the most recent
data from the Hall-Eect Sensor.
xk ⇐ xk + KHallk (yHall − h (xk)) (5.60)
The State Covariance Matrix, P , dened as Equation (5.61), is also updated to give a measure
5.5. Summary 142
of the accuracy of the state update which just occurred.
Pk ⇐ (I −KHallkHHallk) Pk (5.61)
This completes the state update Equations from the Hall-Eect Sensor. Prior to entering the
Kalman Filter, Error checking is implemented on the Hall-Eect Sensor signal, as discussed in
Section 5.4.3. If the reading is outside a specied bounds (0km/hr, 100km/hr) or a speciedrate of change (−50km/hr/step, 50km/hr/step), then a ag is set. The Kalman Filter takes
the ag as an input and when the ag is set the Hall-Eect Sensor update is simply not
executed.
5.4.4 Potentiometer
The chosen potentiometer is an ETI systems 1kΩ 10 turn wirewound potentiometer. The
output of the potentiometer is an analogue voltage which is proportional to the angle of
the steering column and hence the steering angle of the vehicle. This voltage contains some
electrical noise, therefore it is put through a digital low-pass lter in Simulink before being
output to the Kalman Filter. Following the low-pass lter, the signal is biased and scaled so
that a value of zero corresponds to the wheels pointing straight ahead and the range of angles
covers the values(−1, 1). The scaled and biased value is then tested for errors and unlikely
wheel angular rates. This ag is passed to the Kalman Filter along with the scaled and biased
steering angle. The potentiometer is not used for state updates in the ocial Kalman Filtering
sense, rather it is used as the input to the vehicle model, discussed in Section 5.3.
5.5 Summary
Since the above process is reasonably involved, the reader may have become so engrossed in
the ne points of the State Measurement and Estimation process as to have lost sight of the
overall aim. Therefore, it is appropriate to summarise the complete process and explain any
areas which until now have not been mentioned. An explanation of the program containing the
individual State Measurement and Estimation subprograms (such as the Kalman Filter and
the various sensor decoding subprograms) is perhaps the best means to provide this overview.
The State Measurement and Estimation Program is shown in Figure 5.22.
The ow of the program begins on the left where the sensor values are available in software
from the serial port and the analogue to digital converter card. Both the the GPS data and
the IMU data enter the respective decoding subsystems and are decoded into a format intel-
ligible by Simulink. The coordinate frames and datums of all sensors are then transformed
to the appropriate format required by the Kalman lter. For the GPS sensor, this involves
transformation from the Earth-Centered, Earth-Fixed datum to the Tangent plane datum; for
the IMU this involves both multiplication by certain scale factors to transform the readings
143 Chapter 5. State Estimation and Measurement
Figure 5.22: The State Measurement and Estimation Program
5.5. Summary 144
into SI units and biasing of the yaw to ensure that it is zeroed when facing east; for the Poten-
tiometer and Hall-Eect sensors this involves biasing the readings such that they are zeroed
for straight steering and zero speed respectively, and then scaling the readings into SI units.
Error checking is also implemented on all sensor signals and error ags are set accordingly.
In the case of sensors which communicate via serial this is achieved using checksums and
error words from the sensor data; in the case of the analogue sensors, errors are determined
on the basis of the data being out of range or changing by too great a rate over one sample
step. The error ags and the sensor data are then passed into the Kalman Filter for fusion
and optimisation. The Kalman Filter Embedded MATLAB block then outputs the estimated
vehicle states along with two error ags: Failure Mode and Serial Communications Ok. The
Failure Mode ag indicates that the GPS sensor readings have been unavailable for at least 20
seconds and hence to stop the vehicle. The Serial Communications Ok ag indicates that the
serial lines are still receiving data and is required elsewhere in the main program. The speed
and steering angle states pass into the Motion Execution Controller where they are used to
drive the vehicle to a certain speed and steering angle. The Easting, Northing and heading
states pass into the Autonomous Guidance Controller where they are used for feedback so
that the vehicle may track a desired trajectory.
Chapter 6
Control Strategies
The control systems of the TARGET vehicle are all software based applications. These control
strategies, consisting of the Motion Execution and Autonomous Guidance Controllers, were
both developed using MathWorks MATLAB and Simulink software. The purpose of the
Autonomous Guidance Controller is to provide steering and speed commands in order for the
vehicle to follow a dened path. The purpose of the Motion Execution Controller is to ensure
that steering and speed commands (given by the Autonomous Control System in autonomous
mode or the handheld controller in RC mode) are implemented onto the vehicle by sending
signals to the vehicle's actuators.
These two controllers have been integrated together along with many other smaller systems
(such as the I/O signals and fault detection systems) in the Onboard Computer Program.
This chapter will discuss the structure and operation of all software components that are run
on the onboard computer system in greater detail.
6.1 Onboard Computer Program
The onboard computer program is the software running on the vehicle's onboard computer.
The program interfaces with various inputs and outputs of the system, integrates the Kalman
Filter, autonomous control, and motion execution control systems together, and performs
mode control and fault monitoring. The program is structured using four main subsystems -
I/O signals, fault detection, mode control, and motor comms. Sound generation is also dis-
cussed in this section despite not being included in the nal program. The onboard computer
program runs at 50Hz, except where specied otherwise. Figure 6.1 shows the top level of the
onboard computer program.
6.1.1 I/O Signals
The I/O signals subsystem is where input and output signals are administered. Input signals
are sampled from peripheral devices, conditioned, and distributed to other parts of the pro-
145
6.1. Onboard Computer Program 146
Figure 6.1: Onboard computer program (top level)
147 Chapter 6. Control Strategies
gram. Output signals are collected and sent to peripheral output devices. There are six types
of input and output (I/O) signals - analogue inputs, counter inputs, digital inputs, digital
outputs, analogue outputs, and RS232 serial communications. These signals are handled by
the peripheral I/O devices discussed in Section 4.2.2.2, which are interfaced to the program
using xPC Target I/O blocks. Figure 6.2 shows the top level of the I/O signals subsystem.
Table 6.1 provides a list of all input and output signals of the system.
Figure 6.2: I/O signals subsystem (top level)
6.1.1.1 Input Signals and Signal Conditioning
The input signals to the program are sampled in the Analogue Inputs, Counter Inputs, and
Digital Inputs subsystems. The analogue and counter inputs are then passed to the Signal
Conditioning subsystem. This subsystem scales the signal to a useful range, and applies
low-pass lters to remove noise. After being conditioned, the signals are distributed around
the program using Goto tags in the blocks titled Get to (analogue, counter, and digital) in.
The Signal Conditioning subsystem treats dierent types of inputs dierently. The analogue
inputs not used for control (battery 1 and 2 levels and current consumption) remain unmod-
ied. Analogue inputs that are used for control are scaled to a working range, and low-pass
ltered. These signals are the steering potentiometer, brake pressure transducer, tachometer,
and hall eect speed sensor readings. Scaling for these signals is performed by rst multiply-
ing the signal by a gain, and then removing a bias. Table 6.3 lists the ranges for each signal
after scaling, along with the gain and bias used for scaling. Low-pass ltering of the signals
is performed using discrete low-pass lters. These lters were converted from continuous low-
pass lters using Tustin's approximation. The general form of the discrete low-pass lter is
6.1. Onboard Computer Program 148
Table 6.1: Input and output signals listAnalogue Inputs Board Channel
Battery 1 level PCI-6040E 1
Battery 2 level PCI-6040E 2
Current consumption PCI-6040E 3
Steering potentiometer PCI-6040E 4
Pressure transducer PCI-6040E 5
Tachometer PCI-6040E 6
Hall eect speed sensor PCI-6040E 7
Counter Inputs Board Counter
RC receiver Ch1 - Steering command PCI-6040E 1
RC receiver Ch2 - Speed command PCI-6601 1
RC receiver Ch3 - Gear command PCI-6601 2
RC receiver Ch4 - Ignition command PCI-6601 3
RC receiver Ch5 - Emergency stop command PCI-6601 4
Digital Inputs Board Port/Channel
Capacitive brake sensor PCI-6053 A.1
Transmission position - PARK PCI-6053 A.2
Transmission position - DRIVE PCI-6053 A.3
Transmission position - LOW PCI-6053 A.4
GPS error strobe PCI-6053 A.5
GPS position valid strobe PCI-6053 A.6
Motor running feedback PCI-6053 A.7
Heartbeat pulse from dragon board PCI-6053 A.8
E-brake microswitch PCI-6040E N/A
Digital Outputs Board Port/Channel
Warning light 1 PCI-6053 B.1
Warning light 2 PCI-6053 B.2
Warning light 3 PCI-6053 B.3
Transmission FORWARDS PCI-6053 B.4
Transmission BACKWARDS PCI-6053 B.5
Emergency brake PCI-6053 B.6
Car power PCI-6053 B.7
Starter motor PCI-6053 B.8
Heartbeat pulse to dragon board PCI-6053 C.1
Throttle control 1 PCI-6053 C.2
Throttle control 2 PCI-6053 C.3
Actuator relays PCI-6053 C.4
Analogue Outputs Board Channel
Siren PCI-6040E 1
RS232 Serial Communications Board Port
Roboteq amplier ESC-100 1
Base station computer ESC-100 2
GPS unit ESC-100 3
IMU ESC-100 8
149 Chapter 6. Control Strategies
Table 6.2: Lowpass lter constants (τ)Signal τ
Steering potentiometer 1/20
Brake pressure transducer 1/38
Tachometer 1/10
Hall eect speed sensor 1/20
Table 6.3: Input signal scalingSignal Gain Bias Scaled range Meaning
Steering potentiometer 0.6852 V −1 2.2477 -1 to 1 Left lock (-1) to rightlock (1)
Pressure transducer 0.3571 V −1 0.1429 0 to 1 Fully o (0) to fullbraking (1)
Tachometer 18519 RMP/V 7222 RPM RPM Output is in RPM
Hall eect speed sensor 78.431 km/h/V 0 km/h km/h Output is in km/h
RC receiver channel 1 55.556 d.c.−1 2.7222 -1 to 1 Steering command,Left lock (-1) to Right
lock (1)
RC receiver channel 2 55.556 d.c.−1 2.7222 -1 to 1 Speed command, -1 to1
RC receiver channel 3 55.556 d.c.−1 2.7222 1, 2, or 3 Gear command, Park(1) Drive (2) or Low
(3)
RC receiver channel 4 55.556 d.c.−1 2.7222 0 or 1 Ignition command
RC receiver channel 5 55.556 d.c.−1 2.7222 0 or 1 Emergency brakecommand
shown in Equation (6.1) where τ is the inverse of the lter's bandwidth. The values of τ are
shown in Table 6.2.
F (z) =z + 1
z(200τ + 1)− 200τ + 1(6.1)
The values of τ for each lter were determined using a trial and error approach, and the
performance of the lters for the steering potetiometer and brake pressure transducer are
shown in Figures 6.3 and 6.4. Note that the brake pressure transducer is suering from
excessive noise, and this problem should be rectied as future work.
The RC receiver inputs are PWM signals, with the duty cycle (d.c.) proportional to the
input on the RC transmitter. These signals are rst read using counters, which output the
duty cycle of the PWM, and are then scaled to -1 to 1. Scaling to -1 to 1 is performed
by multiplying a gain and then subtracting a bias. The inputs from digital channels (gear,
ignition, and emergency stop commands) are run through a comparator to produce a switch
position, and debounced to produce a reading consistent with the switch position. Table 6.3
shows the ranges of each input after scaling along with the gain and bias used for scaling.
6.1. Onboard Computer Program 150
Figure 6.3: Steering potentiometer low-pass lter performance. The green line shows thesignal before ltering, and the blue line shows the signal after ltering.
151 Chapter 6. Control Strategies
Figure 6.4: Pressure transducer low-pass lter performance. The green line shows the signalbefore ltering, and the blue line shows the signal after ltering.
6.1. Onboard Computer Program 152
6.1.1.2 Output Signals
Output signals are collected in the Collect (Digital and Analogue) Out subsystems, and
then passed to the Analogue Out and Digital Out subsystems to be output on peripheral
I/O cards.
6.1.1.3 RS232 Communications
There are four ports of RS232 serial communications in the system - communications with
the Roboteq amplier, base station computer via RF modem, GPS unit, and IMU. Serial
communications is handled using the xPC Target's FIFO-type serial block for the Quatech
ESC-100 board. This block enables multiple data streams to be read from each port.
Roboteq Amplifier Communications
The Roboteq amplier is used to control the steering and brake motors, as discussed in Section
4.8.7. The input to the amplier is an ASCII character string containing information about
the motor command. The message is streamed at 50Hz, chosen to be 10Hz lower than the
maximum rate allowed by the amplier. The output of this port is simply an echo of the
input, which is read at 100Hz and then terminated to prevent FIFO overow error messages.
Base Station Communications
This is the communications link between the base station computer and the onboard computer.
It handles data exchange comprising data to be logged at the base station, control messages
from the base station GUI, and waypoints. Data is sent at 2Hz, as this was found to be the
fastest possible rate at which the base station can receive the data stream. Data is received
at 10Hz, which has been found to be more than adequate for the system.
Sent data: Data to be sent from the onboard computer to the base station is predominantly for
logging purposes. Logged data mostly comprises measured vehicle states, such as position,
speed, heading, and brake pressure. Other variables transmitted are a heartbeat pulse for
monitoring the RF link, the current control mode of the vehicle, the fault type (if any), and
a sound ag to generate sounds on the base station.
Control messages: The control messages are inputs from the base station GUI that are used
to control the operation of the vehicle. There are seven in total:
1. Control Mode. This species the desired mode of operation of the vehicle, as discussed
in Section 6.1.3.
153 Chapter 6. Control Strategies
2. OL or CL Selector. This switches the desired mode of control when in RC mode between
open loop and closed loop, as discussed in Sections 6.1.3 and 6.3.2.
3. Stop or Go Flag. This acts as both a go button to commence operation of the vehicle,
and as an emergency stop button to halt the vehicle as soon as possible. The go
command is discussed in Section 6.1.3.2, and the emergency stop command is discussed
in Section 6.1.2.2.
4. Heartbeat Pulse. A heartbeat pulse is sent from the onboard computer to the base
station, and is then echoed and sent back to the onboard computer. The pulse is
monitored, and if it stops for more than six seconds the communications loss ag is
taken high.
5. Failure Recover Flag. This ag is taken high to recover the vehicle from failure mode
without requiring re-starting the vehicle, as discussed in Section 6.1.3.4.
6. Connect to Base Station Flag. This ag is taken high when the base station rst connects
to the onboard computer. It is used to prevent any information being sent to the base
station before the base station is ready to accept it; thereby avoiding FIFO overows on
the onboard computer. It is also used to prevent a communications dropout type error
being generated before the base station has connected to the onboard computer. The
implementation of this ag allows the base station, modems, and onboard computer to
be started in any order without generating errors on the onboard computer.
7. Driver Present Flag. This ag is set to 1 to indicate that a driver is present in the vehicle,
and to 2 to indicate that no driver is present. The ag is used to ignore the capacitive
brake sensor when no driver is present, to prevent accidentally entering manual mode
when there is no driver to control the vehicle.
Waypoints: Waypoints for autonomous control are sent from the base station to the onboard
computer, and stored in a matrix which allows for a maximum of 200 waypoints. The way-
points are read at 10Hz and are sent from the base station at 6.66Hz, which ensures that
all values are received. In addition to the waypoints, the base station sends a number which
indicates the total number of waypoints to be sent. This number is used to take a done ag
high, which in turn starts autonomous mode (see Section 6.1.3.2).
GPS Communications
The GPS communications uses a GPS ready ag to handle the order of operation. The order
of operation is as listed in the following section. This method used allows for a completely
non-specic start-up order of the system.
Power-on: The GPS is powered from the electronics board that is turned on at the commence-
ment of initialisation mode (see Section 6.1.3). The unit is ready to receive a log command
6.1. Onboard Computer Program 154
Figure 6.5: Fault detection subsystem top level
approximately 10 seconds after being turned on. When it is ready, the GPS unit sends the
ASCII message [COM1].
GPS ready: The onboard computer initially uses an ASCII read block to read [COM1] mes-
sage. When it is received, the GPS ready ag is set high.
Log command and binary read: The GPS ready ag is used to both send a log command,
and change the read method. On a rising edge of the ag, the ASCII message log bestxyzb
ontime 0.1\r is sent once. This commands the GPS to send a binary type log of position
data at 10Hz. When the GPS ready ag is high, the ASCII read block used to search for the
[COM1] message is disabled, and a binary read block used to read the GPS log is enabled.
IMU Communications
The IMU communications is straightforward. On receiving a command message, the IMU
returns a log in the form of a vector of bytes. A command byte of 49 is sent at 20Hz to the
IMU, and the unit returns information about the vehicle's angular rates and yaw each time it
receives the command. Data exchange with the IMU are discussed in more detail in Section
5.4.2.2.
6.1.2 Fault Detection
Fault detection is performed as a safety precaution, to determine when a potentially hazardous
fault in the system has occurred. Faults monitored predominantly comprise hardware and
communications failures. The fault detection routine initially passes all of the continuous
input signals (analogue and PWM duty cycle readings) through a rate and range checker.
Other faults are also collected from various parts of the program. The output of the rate and
range checker is placed along with the other faults onto a vector. This vector is nally passed
through the fault nder, to produce the output variables fault ag and fault type. Table
6.4 lists all of the faults monitored by the program. Figure 6.5 shows the top level of the fault
detection subsystem.
155 Chapter 6. Control Strategies
Table 6.4: Faults monitored by onboard computerFault
Number
Fault name Description
1 Battery 1 level range Sensor reading out of desired range
2 Battery 2 level range Sensor reading out of desired range
3 Current consumption range Sensor reading out of desired range
4 Steering potentiometer range Sensor reading out of desired range
5 Pressure transducer range Sensor reading out of desired range
6 Tachometer range Sensor reading out of desired range
7 Hall eect speed sensor range Sensor reading out of desired range
8 RC receiver Ch.1 range Sensor reading out of desired range
9 RC receiver Ch.2 range Sensor reading out of desired range
10 RC receiver Ch.3 range Sensor reading out of desired range
11 RC receiver Ch.4 range Sensor reading out of desired range
12 RC receiver Ch.5 range Sensor reading out of desired range
13 Battery 1 level rate Sensor reading exceeding desired rate limit
14 Battery 2 level rate Sensor reading exceeding desired rate limit
15 Current consumption rate Sensor reading exceeding desired rate limit
16 Steering potentiometer rate Sensor reading exceeding desired rate limit
17 Pressure transducer rate Sensor reading exceeding desired rate limit
18 Tachometer rate Sensor reading exceeding desired rate limit
19 Hall eect speed sensor rate Sensor reading exceeding desired rate limit
20 RC receiver Ch.1 rate Sensor reading exceeding desired rate limit
21 RC receiver Ch.2 rate Sensor reading exceeding desired rate limit
22
RC receiver Ch.3 rate Sensor reading exceeding desired rate limit
23
RC receiver Ch.4 rate Sensor reading exceeding desired rate limit
24 RC receiver Ch.5 rate Sensor reading exceeding desired rate limit
25 Emergency stop activation (GUI) Request from base station computer
26 GPS error strobe assertion GPS hardware failure
27 Kalman lter type error Error reported from Kalman lter
28 Modem communication dropout RF link with base station computer failure
29 RC communications loss RC communications loss
30 Emergency stop activation (RC) Emergency stop request from RC transmitter
31 Heartbeat failure (dragon) Heartbeat pulse from dragon board failure
32 Multiple simultaneous faults Multiple simultaneous faults present in system
6.1. Onboard Computer Program 156
6.1.2.1 Range and Rate Checker
The range and rate checker monitors the rate and range of the continuous input signals.
These signals are the analogue inputs and the PWM duty cycle values. The output of the
rate and range checker is a vector, with two elements for each signal monitored. One of these
elements is taken high if the signal is outside its desired static range, and the other element
is taken high if the signal is moving faster than its maximum desired rate. Signals must be
outside their static range limit for more than ten time steps to produce a range error. Signals
produced by the RC receiver are not monitored unless the desired operation mode is set to
RC by the base station user. The range and rate errors comprise entries 1 to 24 of Table 6.4.
Currently, the rate and range checker is not implemented. The range checker has not been
implemented due to severe spikes in the readings of all sensors, which render the maximum
range values meaningless. The rate checker has not been implemented yet as the vehicle is
still in its commissioning stage, and there has been no opportunity to determine the maximum
rates of the various inputs. For future work it is recommended to remedy the sensor spikes,
and determine rate and range limits to detect the associated faults.
6.1.2.2 Other Faults
The subsystem Other faults collects eight ags from other parts of the program indicating
faults. These faults are listed in entries 25 to 31 of Table 6.4. The Other faults subsystem
also includes a routine for detecting a loss of RC communications.
Fault 25 - Emergency Stop Activation (GUI): This fault is generated when the emergency
stop button is pressed by the user on the base station computer.
Fault 26 - GPS error strobe: The GPS error strobe is a digital output of the GPS unit. The
strobe is taken high in the event of a hardware failure.
Fault 27 - Kalman Filter type error: The Kalman Filter includes its own routine for monitoring
faults. If the Kalman Filter detects a critical fault, a Kalman Filter type error is generated.
Fault 28 - Modem communication dropout: This fault is generated if the heartbeat pulse sent
from the base station to the onboard computer is inactive for more than six seconds.
Fault 29 - RC communications loss: This fault is generated when RC communications are
oine, and is discussed in greater detail later in this section.
Fault 30 - Emergency stop activation (RC): This fault can be generated by the user pressing
the emergency stop activation switch on the RC transmitter.
Fault 31 - Dragon board heartbeat failure: The dragon board is linked to the onboard computer
by a two-way heartbeat pulse. This pulse is monitored on both ends. If the onboard computer
157 Chapter 6. Control Strategies
detects that the heartbeat pulse generated by the dragon board has stopped, a fault ag is
set high.
Fault 32 - Multiple simultaneous faults: This fault is generated when multiple faults occur in
a single time step. Using this fault allows the output of the fault detection system to be a
scalar whose value corresponds to a specic fault type.
6.1.2.3 RC Communications Loss Monitoring
The Other faults subsystem includes a routine for monitoring RC communications. This
routine exploits the fact that when the RC receiver cannot detect a transmitted signal, its
output is completely static. The communications loss monitor requires that the output of the
receiver is static for at least twenty time steps. There are two outputs of this routine. The
rst is a ag to indicate that RC communications have failed while the vehicle is in RC mode.
This output is treated as a fault. The second output of the routine is a ag to indicate that
RC communications are operating normally (RC comms OK). The RC comms OK ag is used
along with the emergency stop activation from the RC transmitter to determine if it is appro-
priate to generate a fault; i.e. a fault can be generated from the RC transmitter regardless of
the mode of operation, providing that RC communications are operating normally.
6.1.2.4 Fault Finder
The fault nder monitors the ags produced by the range and rate checker and by the other
faults subsystem. There are two outputs - fault ag and fault type. The fault ag is
taken high whenever any of the previously discussed faults occurs, and the fault type is a
scalar whose value corresponds to one of the faults. The fault ag is used by the mode chart,
discussed in Section 6.1.3, to determine when failure mode must be activated. The fault type
variable is latched to the current fault each time the fault ag goes high. Its value is shown
by the fault type entry in Table 6.4.
6.1.3 Mode Chart
The mode chart subsystem determines which mode the vehicle should be operating in. There
are ve main control modes - initialise mode, RC mode, autonomous mode, manual mode,
and failure mode. There are also two inner control modes, open loop or closed loop. A
state-machine type algorithm called the mode chart performs the mode control, and has been
programmed using MathWorks Stateow. Figure 6.6 shows the top level of the mode chart.
There are four states in the top level - Initialise, Normal Operation, Manual Mode, and Failure
Mode. The ve control modes and two inner control modes are accessed from within these
four states.
6.1. Onboard Computer Program 158
Figure 6.6: Mode chart top level
6.1.3.1 Initialise
Initialise is the default state. During this state, the vehicle is in initialise mode. On powering
on the computer, the mode chart enters this state. On entering, power is given to the vehicle's
electronics and the start-up routine is commenced. Once the start-up routine is complete,
this state is left for the Normal Operation state.
6.1.3.2 Normal Operation
The Normal Operation state is active when the vehicle is in normal operation, with no fault
present. It includes the main modes of normal operation - RC mode, autonomous mode,
and manual logging mode. There are also two other modes of operation, RC pause and
autonomous pause modes. Figure 6.7 shows the top level of the Normal Operation state. The
state defaults to the central wait state, with a control event (change of desired operating
mode) moving operation to the relevant state as required. If a fault occurs in the system, this
state is left for Failure Mode. Similarly, if the capacitive brake sensor is pressed, this state is
left for Manual Mode.
RC mode: During RC mode, the vehicle is controlled by the handheld RC transmitter. During
RC mode the inner control mode can be changed between open loop and closed loop at any
time, by pressing a button on the base station computer.
Autonomous mode: During autonomous mode, the vehicle is controlled by waypoints entered
on the base station computer. The inner control mode is set to speed control, as required by
the autonomous control system.
Manual logging mode: Manual logging mode can be activated if the user wishes to drive the
vehicle manually, when not in an emergency situation. The primary purpose for this is to drive
159 Chapter 6. Control Strategies
Figure 6.7: Normal Operation state top level
a test path, which is logged, and then reproduced as waypoints for autonomous operation.
During this mode all actuators are turned o to give the user full control of the vehicle.
RC pause and autonomous pause modes: When RC mode or autonomous mode is activated,
the mode initially defaults to RC pause or autonomous pause mode. In the pause mode the
respective mode is activated, but the vehicle is unable to move until the 'Go' button is pressed
on the base station computer. This prevents sudden and unpredictable vehicle operation when
users are not ready. Autonomous mode pause mode will also be activated until a done ag
is received indicating that all waypoints have been received, see Section 6.1.1.3.
6.1.3.3 Manual Mode
This state is always entered when the capacitive brake sensor is pressed. In this state, manual
mode is active. This mode is a safety precaution, which allows a driver to take control of the
vehicle at any time. During this mode all actuators are turned o to give the user full control
of the vehicle. Manual mode is not left unless the failure recover button is pressed on the
base station computer. This mode diers from manual logging mode only in the conditions
for entering and leaving.
6.1.3.4 Failure Mode
This state is entered when the vehicle is in one of the normal modes of operation (RC,
autonomous, or manual logging mode), and the fault ag is asserted. Entering this mode
causes the throttle to be released, brakes set to 75% pressure, and steering wheel latched to
its last position. After eight seconds of Failure Mode, the emergency brake system is activated
(see Section 4.6.2) to stop the vehicle in the case of a braking system failure. Once the vehicle
is stopped, the transmission is put into park, and nally the vehicle is turned o. Failure
6.1. Onboard Computer Program 160
Mode is left for Normal Operation if the failure recover button is pressed on the base station
computer.
6.1.3.5 Inner Control Mode
In addition to the modes of operation discussed previously, the vehicle can be set to operate
in closed loop or open loop mode. During closed loop mode, the throttle and brake actuators
are used alternately to make the vehicle follow a desired speed. Closed loop mode is always
active in autonomous mode, and can be set to active in RC mode. During open loop mode,
the speed command provides open loop control of the cruise control unit (when the command
is greater than 1) and pressure control of the brake actuator (when the command is less than
1). Open loop mode is always active during failure mode and initialise mode, and can be set
to active in RC mode.
6.1.4 Motor Comms
The motor comms subsystem handles communications with the various actuators in the system
- the steering and brake motors, the cruise control unit, transmission motor, and ignition. This
subsystem takes actuator commands from the motion execution control system, and converts
these commands into the format required by the actuators.
6.1.4.1 Steering and Brake Motors
The steering and brake motors are controlled by the Roboteq amplier via RS232 serial
communications. A desired speed for each of these motors enters the motor comms subsystem
as a value from -1 to 1. This command is then converted to the ASCII string required by the
Roboteq amp using an embedded m-le.
The brake motor communications includes an additional section that forces the brake to move
to its home (no braking) position when the brake pressure command from Motion Execution
Control is 0. On receiving a brake pressure command of 0 or lower, the brake motor is
automatically moved in the direction of home. A limit switch is mounted at the home position,
and once this switch is activated, the brake motor is prevented from moving any further. A
limit switch activation also turns o the integral control term of the brake pressure control
loop in Motion Execution Control, to prevent windup. This approach was taken to alleviate a
problem with the brake pressure transducer which was causing inconsistent readings, thereby
preventing the brake from consistently releasing fully.
161 Chapter 6. Control Strategies
6.1.4.2 Cruise Control Unit
The cruise control unit has three inputs - an inlet valve, outlet valve, and dump. The dump
is not controlled by the computer, and is discussed in Sections 8.1.2 and 4.8.2. The inlet and
outlet valves are controlled by digital outputs of the onboard computer. By manipulating the
inlet and outlet valves, the throttle can be moved either in (increase throttle), out (decrease
throttle), or held in place. The unit is operated as follows:
• To increase throttle, the inlet valve is open and the outlet closed.
• To decrease throttle the inlet valve is closed and the outlet valve is open.
• To hold the throttle in place both valves are held closed.
The throttle control routine receives a command between -1 and 1, where -1 releases the
throttle as fast as possible and 1 increases the throttle as fast as possible. The routine
generates a PWM whose duty cycle is proportional to the magnitude of the command. This
PWM is used to switch between increasing or decreasing the throttle (depending on the sign
of the command), and holding it still. This approach allows the throttle to be moved at a
variable rate, depending on the magnitude of the command. The throttle control routine is
run at 100Hz to achieve adequate resolution of the control signal.
6.1.4.3 Transmission Control
Control of the vehicle's transmission is achieved using a bang-bang (on-o) style approach.
The transmission control routine is capable of moving the transmission motor either forwards
or backwards using digital outputs. The routine uses feedback on the transmission position
to determine whether to move the transmission forwards, backwards, or not at all. There is
also a speed input to the routine, which is used to prevent changing gears unless the speed of
the vehicle is very low. A required speed for gear changing of zero could not be used as the
Kalman Filter will never return a speed of exactly zero.
6.1.4.4 Ignition Control
Ignition control is achieved using a command from either the mode chart when in autonomous
mode, or from the RC transmitter when in RC mode. When the command is received, the
starter motor digital output is taken high until the program receives feedback that the engine
has started.
6.1. Onboard Computer Program 162
6.1.5 Startup Routine
Successful operation of the TARGET vehicle relies on all actuators, sensors and communica-
tions equipment operating as expected. To check that these systems are operating as required
prior to testing, an automated startup routine has been implemented. The startup routine
carries out a series of tests which are listed in the following points, and are executed in the
numbered order:
1. Ensure the vehicle transmission is in park
2. Check that the communications are working by sending and then receiving data
3. Check a ag from the GPS to ensure it is in working order
4. Check a ag from the IMU to ensure it is in working order
5. Get a user to place their foot on the brake to ensure the capacitive sensor is operational
6. Move the transmission lever from park to drive and back again
7. Start the vehicle ignition
8. Test that the brake pressure transducer feedback is in an acceptable range
9. Test that the steering potentiometer feedback is in an acceptable range
10. Test the steering by moving it to its limits, then returning to the center position
11. Ensure the brake actuator is operational by applying the brakes
12. Test the throttle using feedback from the tachometer
When all of these tests have been performed successfully the vehicle is able to be operated.
However, if errors are found in the system testing cannot commence until these errors are
resolved, and the startup routine has been completed successfully.
The startup routine has been implemented using the Stateow package of Simulink. The
highest level of the startup routine Stateow program is shown in Figure 6.8. The startup
routine consists of two states at the highest level , which are 'STARTUP' and 'STOP'. The
startup routine begins in the 'STOP' state, where systems of the vehicle are not activated, and
all variables used in the startup routine are set to their initial values. As soon as an external
event 'START' is activated by the on-board computer, the state 'STARTUP' is entered an
the startup routine begins.
When in the 'STARTUP' state, the program carries out the tests listed previously. At any
time there is a fault, an event is activated and the 'STOP' state is entered again. Entering
the 'STOP' state causes the startup routine to halt. If there is an error, the startup routine
163 Chapter 6. Control Strategies
Figure 6.8: Startup routine
cannot proceed from where the error was encountered, but must start from the beginning
again.
Checking the actuation systems of the vehicle is done by checking positions the actuators can
move to and the rate they are able to move. Actuation system tests are carried out by giving
the actuator a command, and then waiting a prescribed amount of time and checking if the
actuator has reached its desired position. The time that the program waits before checking if
the actuator is in required position is determined by the rate the actuator is able to move at,
described in Section 6.1.2.1. The actuator is considered operational if it moves to the desired
position in the prescribed amount of time. If the actuator does not perform as expected the
startup routine is halted, and the cause of the problem must be found and resolved before
any testing can begin.
6.1.6 Sound Generation
The TARGET vehicle includes a siren intended for playing warning messages. Two techniques
for generating sounds using the onboard computer have been developed, but unfortunately
have not been included in the nal program due to the demanding amount of processing
power required. The most promising technique is discussed here, and is included in smaller
versions of the program such as the one that will be running during the project exhibition.
Both methods of sound generation are discussed in greater detail in Appendix A.
6.2. Autonomous Guidance Control 164
Figure 6.9: General autonomous control ow
The most promising method of sound generation involves reading a stored sound data le from
the onboard computer's hard drive, and playing the sound as an analogue output driving the
vehicle's siren. The sounds are rst read in MATLAB from a wave le recorded at 8kHz.
They are then put into a single data le in matrix form, with each row corresponding to a
single sound. Multiple les cannot be used, as xPC Target can only handle eight individual
les. To play a sound, all rows of this data le are read at 8kHz, and a single row is selected
and written to the analogue output device at each time step. This method requires too much
processing power to run along with the rest of the program, and therefore sound generation
has been excluded.
6.2 Autonomous Guidance Control
Autonomous guidance control forms the high level decision-making control in the TARGET
vehicle system and is responsible for ensuring that the autonomous vehicle is able to safely,
accurately, smoothly, rapidly and consistently follow a desired waypoint-dened path. The
autonomous guidance control has been implemented as an embedded software component of
the vehicle's onboard computer, and is executed in real time during the vehicle's autonomous
operation.
The Autonomous Guidance Controller essentially determines the appropriate vehicle motion,
in the form of steering angle and speed setpoints. This vehicle motion decision is based on
a comparison of the current vehicle information obtained from the Kalman Filter (actual
vehicle position and heading) and the path waypoints commanded from a remote base station
computer (describing desired vehicle position and speed). A diagram depicting the general
ow of the overall autonomous control system and the centralised role of the Autonomous
Guidance Controller is presented in Figure 6.9.
165 Chapter 6. Control Strategies
In autonomous mode, an operator at a remote base station computer enters a desired path
into a graphical user interface (GUI), as described in detail in Chapter 7. This path is
converted into multiple waypoints that are transmitted to the vehicle's onboard computer
via the Radio Frequency (RF) modems. The complete list of waypoints is supplied to the
Autonomous Guidance Controller together with the current vehicle state estimates (vehicle
position and heading) acquired from the Kalman Filter following its fusion of various sensor
data. The Autonomous Guidance Controller then determines the appropriate vehicle driving
commands (steering angle and speed) in the interest of achieving optimal path tracking, and
these commands are executed by the Motion Execution Controller which controls the vehicle
actuators in order to achieve the desired steering, acceleration and / or braking behaviour.
The autonomous guidance control task is closely linked to the following specic project goals:
• Derive an accurate mathematical model of the relevant vehicle dynamics
• Achieve successful autonomous control of the TARGET vehicle
• Enable intelligent and safe switching between normal human driving, remote control
and autonomous modes of operation
The detailed exposition of the Autonomous Guidance Control presented in the following sec-
tion describes the autonomous steering and speed guidance strategies, explains the structure
of the controller and associated control parameter calculations, and discusses the simulation
and tuning of the controller and the required mathematical vehicle model.
6.2.1 Autonomous Guidance Control Strategy
The Autonomous Guidance Controller comprises the two separate but related functions of
vehicle steering and speed guidance control, with steering guidance responsible for generating
a steering angle command, and speed guidance responsible for generating a vehicle speed
command, both of which are in the interest of achieving optimal and safe path tracking
performance.
This section will deconstruct the overall autonomous guidance control strategy into its sepa-
rate steering and speed guidance components, but before launching into this detailed discus-
sion it is rst necessary to outline the general control environment and reference structures.
For the purpose of autonomous guidance control, the TARGET vehicle is considered to be
located on a 2D spatial plane designated by the coordinate axes of Easting, E (or metres
East), and Northing, N (or metres North), as indicated in Figure 6.10.
Relative to this coordinate plane, the vehicle can be described by its position, [Ev, Nv], as
dened at the midpoint of the rear axle; heading, θv, dened as the vehicle orientation relative
to East; and steering angle, φ, as dened relative to the forward centreline axis of the vehicle.
6.2. Autonomous Guidance Control 166
Figure 6.10: Autonomous control environment
The path waypoints sent from the remote base station computer, [Ew, Nw, vw], each contain a
desired vehicle position, [Ew, Nw], and a desired vehicle speed, vw. The Autonomous Guidance
Controller interprets the waypoints as being connected by straight line segments to form a
piece-wise continuous path. Each straight line connecting a pair of consecutive waypoints is
known as a path segment. Although curved line segments would have yielded a smoother path,
they would have also severely increased the diculty of the control parameter calculations
(see Section 6.2.2.1) and placed a signicantly greater load on the vehicle's real-time onboard
computer system.
Having designated the autonomous control environment and reference structure, the discussion
will now progress to the specic control strategies used in steering and speed guidance control,
beginning with steering guidance.
6.2.1.1 Steering Guidance Strategy
The steering guidance uses the general principles of a spatial control technique known as the
Virtual Vehicle Approach to produce the required steering angle setpoint. While there are
many variations of this path tracking control technique (Egerstedt et al., 2001; Barton, 2001),
the Virtual Vehicle Approach basically compares the vehicle to a continuously updated path
reference point and its associated path segment. This continuously updated path reference
point is called the virtual vehicle point, and is dened as the closest point on the path to
the current vehicle position (that is, the position of the midpoint of the vehicle's real axle)
such that a line drawn between the virtual vehicle point and the vehicle position would be
perpendicular to the path. Referring to Figure 6.10, the virtual vehicle path segment is
167 Chapter 6. Control Strategies
highlighted in orange, while the virtual vehicle point is portrayed in red. This autonomous
guidance control technique is called the Virtual Vehicle Approach because the reference point,
which moves along the path as the real vehicle moves, is a virtual representation of the ideal
motion of the vehicle. Hence, if the vehicle were to follow the path perfectly, the vehicle's
position would at all times coincide with the virtual vehicle point.
With reference to the Literature Review in Section 3.5.2.1, the Virtual Vehicle Approach was
selected as the foundational strategy of the guidance controller because it had demonstrated
strong path tracking potential and a relatively accessible / ecient (as opposed to arduous)
design ow. Fuzzy control was also originally considered on a similar basis, but in order to
provide eective guidance for the complex nature of vehicle behaviour, this strategy would
have placed a signicantly greater burden on the vehicle's real-time onboard computer system.
Using the principles of the Virtual Vehicle Approach (particularly the form described in
Barton, 2001), the steering guidance incorporates three control parameters:
1. Cross-track error, d⊥
2. Heading error, θe
3. Projected steering angle, φproj
The rst steering guidance control parameter, cross-track error, d⊥, is the perpendicular
distance (measured in metres) between the virtual vehicle point and the actual vehicle position,
and hence gives a measure of the position error (between the desired and actual vehicle
position). By minimising the cross-track error the controller returns the vehicle to the desired
path.
The second control parameter, heading error, θe (measured in degrees), is the dierence be-
tween the orientation of the virtual vehicle path segment and the vehicle heading, both mea-
sured relative to East. By minimising the heading error the controller seeks to align the
vehicle heading with the path orientation. If properly tuned, this causes the vehicle to ap-
proach the path asymptotically rather than simply guiding the vehicle directly towards the
virtual vehicle point which can lead to signicant overshoot.
The third steering guidance control parameter, projected steering angle, φproj , is the approx-
imate steering angle (measured in degrees) required to track the average curvature of an
upcoming number of path segments (refer to Section 6.2.2.1 for the mathematical denition).
The steering guidance controller uses this control parameter to anticipate corners and adjust
the vehicle steering angle accordingly. Whilst the cross-track error and heading error are
purely reactive control parameters, that is they only produce control action once the vehi-
cle has actually deviated from the desired path (in terms of position and orientation), the
projected steering angle term adds an important feedforward element to the controller which
eectively helps the TARGET vehicle to track the curvature of the path without actually
deviating from it.
6.2. Autonomous Guidance Control 168
Figure 6.11: Speed guidance control scheme
Thus the steering angle setpoint generated by the steering guidance control is a function of
the cross-track error, heading error, and projected steering angle. For the mathematical de-
nition and calculation of these steering guidance control parameters, the reader is referred to
Section 6.2.2.1. The other side to the autonomous guidance control strategy, speed guidance,
will now be discussed.
6.2.1.2 Speed Guidance Strategy
The speed guidance component of the TARGET vehicle's autonomous guidance control system
also uses the general principles of the Virtual Vehicle Approach, but in a more liberal fashion.
A lack of engagement with speed guidance concepts in the available academic literature led
to the need for some creativity in the development of the TARGET's speed guidance control,
as discussed in Section 3.5.3 of the Literature Review.
Like the steering guidance control, the speed guidance uses three control parameters to pro-
duce an appropriate vehicle speed setpoint:
1. Desired speed, vw, as dened in the waypoints
2. Projected curvature, κproj
3. Cross-track error, d⊥
A ow diagram of the speed guidance control scheme is shown in Figure 6.11.
The desired speed, vw, dened in the waypoints provides the benchmark speed that the guid-
ance controller seeks to attain in the autonomous vehicle. Nevertheless, in the interests of
169 Chapter 6. Control Strategies
safety and eective path tracking, it is also desirable to have some intelligent backup speed
reduction mechanisms in place that are able to automatically reduce the vehicle speed to an
appropriate level in particular circumstances, such as when the vehicle is approaching a rel-
atively sharp corner or signicantly deviating from the desired path. Essentially, the desired
vehicle speed dened in the waypoints forms the vehicle speed setpoint unless the projected
curvature or cross-track error lead to a slower speed recommendation.
The projected curvature, κproj , which is the average curvature across a number of upcoming
path segments (and is therefore related to the aforementioned projected steering angle), is
used to produce an alternative speed recommendation called the approach speed, which is
based on maintaining a comfortable lateral acceleration of 0.3g (see Section 6.2.2.2). This
alternative speed recommendation forms the basis for the autonomous speed setpoint if it is
slower than the speed specied in the waypoints. This control mechanism helps to prevent
the vehicle from overshooting sharp corners due to excessive speed.
The speed guidance controller thus selects the slower of the two recommended speeds (that
is, either the desired speed dened in the waypoints and the recommended approach speed
determined from the projected curvature) and this recommended speed is then multiplied
and eectively ltered by a function related to the cross-track error, which is the third speed
guidance control parameter. The logic behind this lter function is that the vehicle should
experience a decrease in speed proportional to its deviation (cross-track error) once it has
drifted from the path beyond an allowable bound. This behaviour is desirable both as a safety
precaution, since the vehicle will ultimately stop once it has deviated beyond a maximum limit,
and as a control feature, since slowing the vehicle down allows the controller more time to
guide the vehicle back to the path. Since the vehicle is to be operated on plain roads (both
sealed and unsealed) as indicated in Figure 6.12, and is therefore required to remain within the
bounds of these roads, it has been decided to linearly reduce the vehicle speed when the cross-
track error is between half a metre and one metre (with one metre or greater corresponding
to a speed setpoint of zero as shown in Figure 6.11). A deviation of less than half a metre
will not meet a speed penalty. The speed lter settings may be adjusted depending on the
accuracy of the vehicle state estimates provided by the Kalman Filter.
Thus the speed setpoint generated by the speed guidance control is a function of the desired
speed, projected curvature, and cross-track error. The mathematical denition and calculation
of these speed guidance control parameters will be explained in the coming section on the
Autonomous Controller Structure.
6.2.2 Autonomous Guidance Controller Structure
The autonomous guidance controller has been constructed as a separate parameter calculator
and guidance controller connected in series, as shown in Figure 6.13.
The Parameter Calculator is responsible for calculating all of the control parameters based
on the controller's knowledge of the path waypoints and the current vehicle states supplied
6.2. Autonomous Guidance Control 170
Figure 6.12: Illustration of the importance of speed guidance control when operating onbounded roads
Figure 6.13: Autonomous controller structure
171 Chapter 6. Control Strategies
by the Kalman Filter. The Guidance Controller consists of the combined steering and speed
guidance and performs the actual control, generating the vehicle motion setpoints (steering
angle and speed commands) according to the values of the supplied control parameters. This
section will examine both of these autonomous control components in detail, beginning with
the parameter calculator.
6.2.2.1 The Parameter Calculator
The Parameter Calculator calculates all of the control parameters required by the Guidance
Controller at each time step of real-time execution, and was constructed as an Embedded
MATLAB Function using the high-level MATLAB programming language in the MathWorks
Simulink environment. The complete MATLAB code (for the Parameter Calculator) can be
found in Appendix K.
The ensuing paragraphs will explain the main functions and calculations performed by the
Parameter Calculator. These include nding the virtual vehicle path segment, calculating the
path orientation and vehicle heading error, calculating the cross-track error, and calculating
the projected steering angle and projected curvature.
Finding the Virtual Vehicle Path Segment
The rst task of the parameter calculator is to locate the current time-step's virtual vehicle
path segment. This is achieved with the use of vectors and the vector dot product.
The virtual vehicle path segment search algorithm begins by dening two vectors for the current
path segment under inspection. For the initial cycle of the search algorithm, the inspection
begins at the rst path segment, between the rst two waypoints in the waypoint matrix.
As indicated in Figure 6.14, the search algorithm denes one vector, labeled W, between the
start and end waypoints of the path segment such that:
W = Pw(n + 1)− Pw(n) = [Ew(n + 1), Nw(n + 1)]− [Ew(n), Nw(n)] (6.2)
where Pw represents the position component of the waypoints that is, without the desired
speed specication, vw.
Similarly, a second vector, labeled V, is dened from the segment start point to the vehicle
position, Pv = (Ev, Nv), such that:
V = Pv − Pw(n) = [Ev, Nv]− [Ew(n), Nw(n)] (6.3)
6.2. Autonomous Guidance Control 172
Figure 6.14: Virtual vehicle search vectors
The mathematical principle of orthogonal vector projection is used to determine if the virtual
vehicle point is on the current path segment, ahead of the current path segment, or behind
the path segment, by considering the orthogonal projection of the waypoint-to-vehicle vector
V onto the path segment vector W.
The orthogonal projection of V onto W is given by the equation:
|V| cos(α) =W •V|W|
(6.4)
where the vector dot product:
W •V = [w1, w1] • [v1, v2] = w1× v1 + w2× v2 (6.5)
Following from these relationships it can be shown that W •V < 0 implies that the projection
of V onto W extends backwards behind the start waypoint of the current path segment as
indicated in Figure 6.15, and hence the search algorithm must look behind the current path
segment in order to nd (or at least get closer to) the virtual vehicle point.
Otherwise, if W •V > 0 and V •V < V •W, then the projection of V onto W extends
beyond the current path segment as shown in Figure 6.16, and hence the search algorithm
must look beyond the current path segment in order to nd the virtual vehicle point.
Thus the search algorithm appropriately increments or decrements through the path segments
until the virtual vehicle path segment is discovered. This occurs when neither W •V > 0 nor
173 Chapter 6. Control Strategies
Figure 6.15: Virtual vehicle point located behind current path segment
Figure 6.16: Virtual vehicle point located beyond current path segment
V •V < V •W is true for the current path segment, indicating that the projection of V onto
W, and hence the virtual vehicle point, is between the segment's start and end waypoints.
Some additional logic has been included to handle the special case of autonomously negotiating
a closed circuit path, for which the beginning and end waypoints are connected. In this
situation, the last segment precedes the rst segment, and the rst segment follows on from
the last segment.
There are also some situations, such as the one indicated in Figure 6.17, when the vehicle (and
hence the projection of V onto W) is between path segments. In this case, the forward of the
two segments is treated as the virtual vehicle path segment, and this segment is eectively
extended to the virtual vehicle point. Similarly, if the vehicle starts behind the rst waypoint
in an open path, for which the beginning and end waypoints do not share the same location,
the rst path segment is treated as the virtual vehicle segment and extended back to the
virtual vehicle point. It should be noted that for both open and closed circuit paths, the
initial virtual vehicle path segment is not necessarily the rst path segment in the specied
path but approximately the closest path segment to the vehicle's starting position.
The virtual vehicle path segment search algorithm is an application and expansion of the
equations and algorithms described in Mörtberg (2006), Sunday (2006) and Kreyszig (1999).
6.2. Autonomous Guidance Control 174
Figure 6.17: Vehicle located between path segments
Calculating the Path Orientation and Vehicle Heading Error
Once the virtual vehicle path segment has been found, the guidance control parameters that
were introduced in Section 6.2.1 can begin to be calculated. These control parameters include
the vehicle heading error used in steering guidance.
The heading error, θe (measured in degrees), is the dierence between the orientation of the
virtual vehicle path segment and the vehicle heading, both measured relative to East. Thus,
with reference to Figure 6.10, the heading error is given by:
θe = θn − θv (6.6)
Which follows the generic form:
error = desired value − actual value (6.7)
The vehicle heading, θv, is supplied by the Kalman Filter via GPS and IMU measurements
(see Chapter 5), but the orientation of the virtual vehicle path segment, θn, is calculated using
the following equation, with reference to Figure 6.18:
θn = arctan(
y step
x step
)= arctan
(Nw(n + 1)−Nw(n)Ew(n + 1)− Ew(n)
)(6.8)
175 Chapter 6. Control Strategies
Figure 6.18: Determining the orientation of the virtual vehicle path segment
The heading error can then be calculated using Equation (6.8) to give values in the range
−180 < θe < 180, but manipulated such that a negative heading error corresponds to the
vehicle moving towards the left of the track, and a positive heading error corresponds to the
vehicle moving towards the right of the track. Note that the left and right directions are
referenced according to the vehicle's perspective.
Calculating the Cross-Track Error
The cross-track error control parameter is required for both the steering and speed compo-
nents of autonomous guidance control. Recall that the cross-track error is dened as the
perpendicular distance (measured in metres) between the virtual vehicle point and the actual
vehicle position.
Using the two vectors established in the virtual vehicle search algorithm as shown in Fig-
ure 6.19, the cross-track error calculation process is initiated by evaluating the orthogonal
projection of V onto W to determine the distance from the start waypoint of the virtual
vehicle path segment to the virtual vehicle point using the previously stated Equation (6.9):
dvv = |V| cos(α) =W •V|W|
(6.9)
The parametric equation of a line (Sunday, 2006) is then used to determine the location of the
virtual vehicle point. The line parameter value corresponding to the location of the virtual
vehicle point as a proportion of the virtual vehicle path segment length is obtained by dividing
dvv by the path segment length, |W|.
Hence the virtual vehicle point is derived using the parametric line equation:
Pvv = Pw(n) +dvv
|W|W (6.10)
6.2. Autonomous Guidance Control 176
Figure 6.19: Calculating the cross-track error, d⊥
Note also the following useful parametric value formula derived using Equation (6.9):
dvv
|W|=
(W•V|W|
)|W|
=W •VW •W
(6.11)
The unsigned cross-track error distance, d⊥(in metres), can then be determined by taking the
norm of a vector dened between the virtual vehicle point and the current vehicle position:
d⊥ = |Pv − Pvv| (6.12)
Equation (6.12) merely provides the magnitude of the cross-track error. For the cross-track
error to provide useful path tracking information it is necessary to distinguish which side of
the path the vehicle has deviated. Hence by carefully comparing the angle of the cross-track
error vector, ∠(Pv − Pvv), with the orientation of the virtual vehicle path segment, θn, the
cross-track error is assigned a negative value when the vehicle deviation is to the left of the
path, and a positive value when the vehicle deviation is to the right of the path. The left
and right directions are again referenced according to the perspective of the vehicle.
Calculating the Projected Steering Angle and Projected Curvature
The closely related projected steering angle and projected curvature control parameters are the
last to be calculated in the Parameter Calculator. Their calculation is based on a modied
version of the equations presented in Barton (2001).
177 Chapter 6. Control Strategies
Path curvature can be dened as the inverse of the path radius, as in Equation (6.13), or
equivalently as the change in orientation per unit length (Barton, 2001). According to the
latter denition, the projected curvature, which is the average curvature of a selected number
of upcoming path segments, can be calculated using the equation:
κproj =1N
n+N∑i=n
θn+1 − θn√(En+1 − En)2 + (Nn+1 −Nn)2
(6.13)
where N is the total number of path segments being projected or averaged. The projected
curvature has been congured to use a total of eight upcoming path segments.
By substituting Equation (6.13) into Equation (6.23), which is the heading angle formula
of the mathematical vehicle model described in Section 6.2.3.1, the projected steering angle
equation can be derived. The reader is referred to Section 6.2.3.1 for an explanation of the
mathematical vehicle model.
•θ =
δθ
δt=
v
Ltanφ (6.14)
φ = arctan(L
v· δθ
δt) (6.15)
∴ φ = arctan(L · δθ
δs) (6.16)
since v = dsdt , where s is vehicle displacement. Thus since curvature κ = δθ
δl , for an l length of
path, the following approximate relationship can be obtained:
φ ≈ arctan(L · κ) (6.17)
Thus the equation for projected steering angle can be written as:
φproj = arctan(L · κproj) (6.18)
The projected steering angle has been congured to use a total of four upcoming path segments
in its calculation.
A signicant amount of additional manipulation is required in order to ensure that positive
and negative path orientations, and also path segments near the end of the path, are handled
appropriately in Equations (6.13) and (6.18). The Parameter Calculator nally passes all of
the derived control parameter values to the Guidance Controller where the appropriate vehicle
motion guidance setpoints are determined.
6.2. Autonomous Guidance Control 178
Figure 6.20: Guidance Controller as implemented in Simulink
6.2.2.2 The Guidance Controller
The Guidance Controller consists of the combined steering and speed guidance controllers. At
every time step it accepts the control parameters provided by the Parameter Calculator and
outputs the steering angle and speed setpoints that are to guide the autonomous vehicle along
the desired path. The structure of Guidance Controller as implemented in the MathWorks
Simulink environment is presented in Figure 6.20.
The control parameters provided by the Parameter Calculator are shown in light blue on the
left-hand-side as inputs to the controller, and the controller outputs of steering angle and
speed setpoints are shown in orange on the far right. The top half of the guidance controller,
with inputs of projected steering angle, cross-track error and heading error, and an output
of the steering angle setpoint, is the steering guidance section of the controller. The speed
guidance section is the bottom half, with inputs of cross-track error, projected curvature and
desired speed, and a speed setpoint output. The structure of the steering and speed guidance
179 Chapter 6. Control Strategies
sections of the Guidance Controller will now be discussed separately, beginning with steering
guidance.
The steering guidance controller was tuned using the gain blocks shown in green in Figure 6.20.
This structure (much like a weighted sum) is similar to a PID controller, with proportional
control of the projected steering angle, proportional and integral control of the cross-track
error, and derivative-like control via the heading error. During the tuning process it was found
that heading error gain performed much like conventional derivative control. Increasing the
gain tended to reduce overshoot and settling time, but at higher gains the control signal
(steering angle setpoint) became jittery and sensitive to small disturbances. The steering
angle setpoint has been saturated to the physical turning limits of the vehicle (approximately
±35 degrees) and rate limited to ±384 deg/s, which is the maximum operational speed of the
steering motor.
The speed guidance section of the guidance controller is basically the Simulink implementation
of the owchart that was presented in Figure 6.11. At this point it is appropriate to elaborate
on the structure of the blocks used to generate a recommended approach speed based on the
projected curvature control parameter. The approach speed function, shown in the Figure 6.20
Simulink diagram as simply a magenta function block f(u), was derived from the equation
of centripetal acceleration:
a =v2
r(6.19)
with a velocity v (m/s) and circular motion of path radius r (metres). Now, since curvature
is dened as the inverse of radius, that is:
κ =1r
(6.20)
Equation (6.19) can be rewritten as:
a = κv2 (6.21)
According to Glennon (2006) and Glennon (2003), most human drivers cannot tolerate steady-
state lateral acceleration greater than 0.3g (that is, 0.3 × 9.81m/s2). Hence, substituting
this threshold of centripetal acceleration into Equation (6.21) and rearranging leads to the
following equation for calculating the recommended 'approach speed' based on a known path
curvature:
v =
√0.3g
κ=
√0.3× 9.81
κ(6.22)
Hence the speed guidance controller passes the projected curvature control parameter into this
equation in order to produce a recommended approach speed. Prior to this, the projected
6.2. Autonomous Guidance Control 180
Figure 6.21: Autonomous control simulation model
curvature entering the approach speed function is limited to a minimum of 0.003 m−1, corre-
sponding to a path with very low curvature. This eectively limits the maximum approach
speed recommendation to 31 m/s (approximately 113 km/h) for the purpose of restricting the
calculation to a practical and memory ecient range of values the autonomous vehicle is
not intended to be operated a such high speeds. In fact, the speed setpoint produced by the
guidance controller has been limited to between 0 and 40 km/h.
6.2.3 Simulation and Tuning
Prior to integration in the TARGET vehicle, the performance of the autonomous guidance
controller was veried in simulation. This involved establishing a model of the overall au-
tonomous control system using the MathWorks Simulink environment (essentially resulting in
a virtual model of the system owchart presented in Figure 6.9). The top level of the resulting
model is shown in Figure 6.21 and includes a waypoint denition block, the aforementioned
Parameter Calculator and Guidance Controller (refer to Section 6.2.2), a block representing
the Motion Execution Controller, and a mathematical vehicle model. The complete Simulink
model has been included in the Software CD provided in Appendix K.
The dummy Motion Execution Controller block contains two rst-order transfer functions
as shown in Figure 6.22, one for steering and one for speed. It was estimated that it would
take approximately one second for the real Motion Execution Controller (discussed in Sec-
tion 6.3) to control the actual vehicle steering to the commanded steering angle setpoint,
and approximately four seconds to achieve the speed setpoint. The time constants of the
rst-order transfer functions were therefore tuned to replicate these delays. Their unit step
response is shown in Figure 6.23.
6.2.3.1 Mathematical Vehicle Model
A mathematical model of the relevant vehicle dynamics was derived in order to test and
tune the Autonomous Guidance Controller prior to its integration with the actual TARGET
181 Chapter 6. Control Strategies
Figure 6.22: Motion Execution Controller model
Figure 6.23: Unit step response of Motion Execution Controller model
6.2. Autonomous Guidance Control 182
vehicle. The development of an accurate mathematical vehicle model had also been dened
as one of the project goals. The mathematical vehicle model needed to relate the vehicle
speed and wheel angle theoretically achieved by the guidance controller (in combination with
motion execution control) to the instantaneous vehicle states of heading (θ), Easting (E), and
Northing (N) which are required as inputs to the autonomous controller. Using the variable
conventions already established (refer to Figure 6.10), the equations of the mathematical
vehicle model can be written as:
θ =v
Ltanφ (6.23)
E = v.cos(θ + φ) (6.24)
N = v.sin(θ + φ) (6.25)
In these equations, θ is the vehicle heading (in radians), E is the vehicle East position (in
metres), N is the vehicle North position (in metres), φ is the vehicle steering angle (in radians),
v is the vehicle speed (in metres per second), and L is the vehicle wheelbase (in metres).
Integration is used to solve these equations for the required vehicle states, θ, E, and N . Thus
Equations (6.23) to (6.25) can be rewritten in discrete form based on a simulation sample
period of T seconds:
θk = θk−1 +T.vk
Ltanφk−1 (6.26)
Ek = Ek−1 + T.vk.cos(θk−1 + φk−1) (6.27)
Nk = Nk−1 + T.vk.sin(θk−1 + φk−1) (6.28)
These discrete equations follow the general form:
current state = previous state + change in state
This mathematical vehicle model is a combination of models oered by Barton (2001) and
Anisi (2003). A more common form of the (simple) car-like mathematical model (Anisi, 2003)
is simply:
θ =v
Ltanφ (6.29)
183 Chapter 6. Control Strategies
Figure 6.24: Simulink implementation of the Mathematical Vehicle Model
E = v.cosθ (6.30)
N = v.sinθ (6.31)
This model assumes that the vehicle travels in the direction of its previous heading (θk−1),
whereas the rst model (which was used to simulate the Autonomous Guidance Controller)
assumes that the vehicle travels in the direction of its previous steering angle dened relative
to East (θk−1 + φk−1). Note that the vehicle heading is dened as the forward direction
of the vehicle (relative to East), and since a turning vehicle will not travel in the forward
direction but rather in the direction that it is steering, the steering angle method (Equations
(6.23) to (6.28)) seemed to be the more intuitive approach. Both models are approximations,
assuming negligible wheel slip and ignoring the eects of Ackerman steering. However, the
chosen model proved to be suciently accurate for the purposes of preliminary testing and
tuning of the Autonomous Guidance Controller. The accuracy of the mathematical vehicle
model was explored during autonomous testing and is discussed in Section 9.4.
In the Simulink development environment the mathematical vehicle model was implemented as
shown in Figure 6.24, where the control ow is from right to left. For simulation purposes the
initial conditions of heading, E estimate and N estimate can be set within the corresponding
integrator blocks.
The same mathematical vehicle model, though implemented in a dierent form, was also used
in the Kalman Filter (see Section 5.1).
6.2. Autonomous Guidance Control 184
6.2.3.2 Simulated Performance Results
The performance of the Autonomous Guidance Control was simulated and tuned using the
Simulink model presented in Figure 6.21, which is equipped with the Mathematical Vehicle
Model detailed in the previous section (Section 6.2.3.1). The key performance measure for the
Autonomous Guidance Controller is the cross-track error, as this indicates the vehicle's lateral
deviation from the path. Aside from some minor adjustment in the Parameter Calculator,
the Autonomous Guidance Controller was essentially tuned by manually adjusting the four
control gains in the Guidance Controller block (refer to Figure 6.20).
The simulated path tracking performance of the well-tuned Autonomous Guidance Controller
to an open and closed-circuit waypoint-dened path is presented in Figures 6.25 and 6.26
respectively. The upper graph in these gures shows the vehicle trajectory (red) as it attempts
to autonomously follow the desired path (blue), and the corresponding time-based cross-track
error measurements which provides a more quantiable gauge of the autonomous path tracking
performance. In particular note the maximum, mean and standard deviation of the cross-
track error. The cross-track error varies over time rather than settling on a single steady-state
value because of the curvature variation in the desired paths. The other two graphs in each
gure indicate the steering angle guidance setpoint and actual vehicle speed response of the
autonomous vehicle for the given path. In both cases the waypoint-dened desired speed
was set to 40 km/h but, as indicated by the variation in the graphs, the actual vehicle speed
changed under the inuence of speed guidance which at times recommended a slower vehicle
speed for negotiating high-curvature sections of the path.
Note that the closed-circuit steering angle guidance setpoint response shown in Figure 6.26
experiences a small perturbation about the start / nish connection point. While it is de-
sirable to remove this eect, it will not result in a deterioration in the actual path tracking
performance of the autonomous vehicle as the steering actuator cannot respond to a command
at this rate.
These were impressive results. It should be kept in mind, however, that these simulations
were made using precise estimates of the vehicle's position and heading. In reality, additional
path tracking inaccuracy arises, through no fault of the Guidance Controller, as a result of
using estimated vehicle position and heading values. Although these vehicle state estimates
supplied by the Kalman Filter are an improvement on raw sensor information, they constitute
the primary limitation on the overall path tracking performance achievable in eld testing.
The simulated results of the Autonomous Guidance Controller reveal a signicant perfor-
mance improvement over the virtual vehicle based path tracking controller presented in Barton
(2001). Barton's controller was simulated using a constant vehicle speed of 20 km/h, a max-
imum steering angle command of 15 degrees, and a mathematical vehicle model very similar
to the one adopted in this project (Barton, 2001), thereby enabling reasonable comparisons
to be made with the simulation results of the TARGET Autonomous Guidance Controller. A
185 Chapter 6. Control Strategies
(a) Open path tracking performance
(b) Steering angle setpoint response for openpath tracking
(c) Speed response for open path tracking
Figure 6.25: Simulated open path tracking performance of the Autonomous Guidance Con-troller
6.2. Autonomous Guidance Control 186
(a) Closed-circuit path tracking performance
(b) Steering angle setpoint response for closed-circuit path tracking
(c) Speed response for closed-curcuit pathtracking
Figure 6.26: Simulated closed-circuit path tracking performance of the Autonomous GuidanceController
187 Chapter 6. Control Strategies
Table 6.5: Autonomous Guidance Control Performance Comparison
Cross-track errormeasurement (metres)
TARGETGuidanceController
Barton'sGuidanceController
PerformanceImprovement
(%)
Maximum < 0.03 0.6 95
Mean < 0.007 0.2 97
Standard deviation < 0.01 0.1 90
performance comparison is provided in Table 6.5. The closed-circuit path corresponding to
Barton's results is shown in Figure 3.20 of the Literature Review.
The on-the-road testing of autonomous operation is discussed in Section 9.4.
6.3 Motion Execution Control
The Motion Execution Control System acts as the link between driving commands and the
actuators. The system has two independent inputs, but only one of these inputs are active
at any given moment, depending on whether the vehicle is in radio control or autonomous
mode. In radio control mode, the Motion Execution Control System receives commands from
a human operator via the handheld controller. In autonomous mode, commands are received
from the Autonomous Guidance Control System. Its purpose is to ensure that these commands
are implemented eectively by sending the correct signals to the actuators (steering, brake
and throttle).
The controller is split into two separate systems: steering control and speed control. The
speed control loop contains two sub-loops to control the brake and throttle independently.
Switching logic is used between the throttle and braking systems in order to control the
vehicle's speed. This is to mimic the behavior of a human driver as the accelerator and brake
are never operated simultaneously. Therefore only one of these controllers will be operational
at any given moment. This provides for smoother speed control and also prevents wear and
tear on the braking system. The Motion Execution Control System has been developed using
MATLAB and Simulink and has been exported to run on the onboard computer using the
xPC Target software as discussed in Section 4.2.1.
The performance and tuning of the Motion Execution Control system is discussed in Section
9.2. This discussion is carried out with reference to the project specications and goals which
is discussed in Chapter 2.
6.3.1 Steering Control
The steering control loop provides automatic control of the steering system in the vehicle.
It receives a normalised input command between -1 to 1 corresponding to full steering lock
6.3. Motion Execution Control 188
left and full steering lock right respectively. Its output is the actual steering wheel position,
also normalised between -1 and 1. A top level block diagram of the steering control system is
shown in Figure 6.27.
Figure 6.27: Steering Control System
As shown in Figure 6.27, there are three main parts to the control system. These are the
roll prevention saturation block in white, steering position control loop in dark grey and the
steering lock saturation in light grey. These three parts will be discussed in further detail in
the following sections. The inputs are the steering setpoint, actual speed feedback (provided
by the Kalman Filter as described in Section 5.1) and the steering angle (provided by the
steering potentiometer as described in Section 4.4.3). The output is the steering command
and this is the signal sent to the steering actuator.
The setpoint to the steering position control loop is provided after roll prevention saturation.
The output of the control loop is given to the steering lock prevention block before being sent
to the steering actuator. Control is achieved using a Proportional Derivative (PD) feedback
control structure. Integral control was not included as the actuator itself integrates a speed
to a position. The feedback is provided by the potentiometer which gives an indication of
actual steering wheel position.
6.3.1.1 Roll Prevention Saturation
As the vehicle will be moving and cornering at speed, situations may arise where the steering
setpoint causes the vehicle to turn too sharply and roll over, damaging the vehicle, the installed
hardware and injuring the occupants (if present). The purpose of the roll prevention subsystem
is to ensure that the van does not turn too sharply at higher speeds. This is achieved by using
the actual vehicle speed (feedback from the Kalman Filter) to limit the steering setpoint using
a dynamic saturation block. This is shown in Figure 6.28.
A small oset is included in order to prevent mathematical singularities if a vehicle speed of
0 is received. The value of the constants was found using analysis of the vehicle dynamics.
This analysis was carried out using standard metric units. However, the actual vehicle speed
is normalised between 0 and 1 (0 km/h to 40 km/h) so a scaling factor is also included in
189 Chapter 6. Control Strategies
Figure 6.28: Roll Prevention Saturation
order to convert to metric units so the correct saturation is provided. The actual analysis
follows:
Consider a motor vehicle traveling in an arc on a at road as depicted in Figure 6.29.
Figure 6.29: Roll Prevention Analysis 1
The parameters shown are dened as follows:
COG The centre of gravity of the vehicle
r The instantaneous turning radius of the vehicle's path
h The height of the centre of gravity above the road
b The vehicle's track width
G The acceleration due to gravity
n Safety factor (not shown in diagram)
6.3. Motion Execution Control 190
The vehicle will tip over if the velocity is greater or equal to the following (Bosch, 2004):
v ≥ π
n
√br
2hms−1 (6.32)
The critical value of velocity occurs when the inequality becomes an equality. This can be
rearranged to nd:
r =2h
b
(vn
π
)2m (6.33)
Now consider the vehicle moving in a small time period along a circular arc, from position 1
to position 2 as shown in Figure 6.30. Also shown in Figure 6.30 is a vector view of the two
velocity vectors V1 and V2, and the angle θ between them.
Figure 6.30: Roll Prevention Analysis 2
Circular motion gives an instantaneous radius:
r =v
θ(6.34)
Now substituting this into Equation (6.33) and rearranging gives:
θ =bπ2
2hvn2(6.35)
191 Chapter 6. Control Strategies
Substituting the actual vehicle characteristics (b = 1.38 m, h = 1.90 m) and a safety factor
n = 1.2 gives the value used for the constant in the roll prevention saturation:
θ =4.978
v(6.36)
The value of the safety factor was chosen in order to allow for a safety buer in the roll
prevention subsystem without severely limiting the turning circle of the vehicle.
6.3.1.2 Steering Lock Saturation
The purpose of this subsystem is to ensure that the steering actuator does not continue to
turn when it reaches full lock left or full lock right. The actuator is is capable of producing
a large torque, so if it continues to turn at full lock, it could damage the sprockets, chain or
the steering column itself. This system is shown in Figure 6.31.
Figure 6.31: Steering Lock Saturation
This system uses the steering angle feedback (provided by the steering potentiometer) in order
to completely cut the steering command signal when the steering wheel reaches 85% of its
full lock and the controller continues to turn it towards full lock in either direction. This is
to ensure that there is a safety buer between the actual steering wheel position and full lock
at all times.
6.3. Motion Execution Control 192
6.3.2 Speed Control
The speed control system provides automatic control of the vehicle's throttle and brake by
sending signals to the actuators. Its structure is more complex than the steering controller as
can be seen in Figure 6.32.
Figure 6.32: Speed Control System
It has two modes of operation, open loop and closed loop. In open loop, the speed controller
receives a scaled input of -1 to 1 (full brake to full throttle). The throttle actuator is used
when the setpoint is between 0 and 1 (no throttle to full throttle). The brake actuator is used
when the setpoint is between 0 and -1 (no brake to full brake). In this mode of operation,
there is no speed control, only normalized position control for the brake and throttle. Open
loop mode is used only in remote control mode in conjunction with the handheld controller.
The darker grey blocks in Figure 6.32 shows the open loop control section.
Closed loop mode activates speed control for the vehicle. The setpoint in this mode is be-
tween 0 and 1 (0 km/h to 40 km/h). Closed loop mode incorporates speed switching logic
(discussed further in Section 6.3.2.1) and speed control loops for both the throttle and the
brake (discussed further in Sections 6.3.2.2 and 6.3.2.3 respectively). Closed loop can be used
for RC mode and it is necessary for use in autonomous mode, as the autonomous control
system will produce a speed setpoint as its output. The lighter grey blocks in Figure 6.32
shows the closed loop speed control section.
6.3.2.1 Speed Switching Logic
As mentioned previously in Section 6.3, the purpose of the speed switching logic is to ensure
that the brake and throttle are operated individually and not simultaneously. This will allow
193 Chapter 6. Control Strategies
for smoother driving and also minimises wear and tear on the vehicle's braking system. The
speed switching logic is used only in closed loop operation.
Figure 6.33: Speed Switching Logic
As shown in Figure 6.33, this system looks at the dierence between the desired speed (speed
setpoint) and the actual vehicle speed (provided by the Kalman Filter). Both of these are
provided as normalized values between 0 and 1 (0 km/h to 40 km/h). If the speed dierence
is equal to or above -0.05 (-2 km/h), the vehicle will be traveling slower than desired and
the switching logic will activate the closed loop throttle control system. This will cause the
vehicle to accelerate if the speed dierence is positive, and also coast to a slower speed if the
dierence is slightly negative. This also mimics aspects of human driving: usually people will
coast and allow friction and drag to slow the car down if fast braking is not required. The
closed loop brake control system will be activated if the dierence is below -0.05 (-2 km/h).
6.3.2.2 Throttle Control
In open loop mode, there is no throttle control provided. The setpoint between 0 and 1 (no
throttle to full throttle) is simply routed straight to the actuator. In closed loop mode, there
are two further sub - modes for the throttle controller. When the vehicle transmission is in
park, the throttle controller aims to control the speed of the engine. Feedback is provided
directly from the tachometer needle of the vehicle. Engine speed control is used mainly
for demonstration and exhibition purposes whilst the van is in remote control mode, as the
throttle control systems can be demonstrated without actually moving the vehicle. This mode
is not used in conjunction with autonomous mode.
When the vehicle is in drive, the throttle controller controls the actual speed of the vehicle.
Feedback in the form of actual vehicle speed is provided by the Kalman Filter. Throttle speed
control can be used in both remote control and autonomous modes. Both engine speed control
and speed control can be seen in Figure 6.34. The blocks associated with speed control can
be seen in light grey and the engine speed control can be seen in dark grey. The white blocks
are associated with signal routing to the actuators.
6.3. Motion Execution Control 194
Figure 6.34: Closed Loop Throttle Controller
Both engine speed control and speed control use a PID feedback control structure in order to
control their respective outputs of engine revolutions and vehicle speed.
The speed control loop also contains a throttle enable delay. This block enables the throttle
speed controller only once the brake actuator reaches its home position and releases the brakes.
This is once again to ensure that the throttle and brake are not operated simultaneously.
6.3.2.3 Brake Control
In open loop mode, the brake controller controls the normalized brake pressure as this is
directly related to the amount of braking applied. The setpoint to this controller is provided
from the handheld controller between 0 and -1 (no brake to full brake). The brake pressure
is controlled using a PID feedback control structure. The feedback is provided by the brake
pressure transducer as discussed in Section 4.6.1.3.
In closed loop mode, the brake controller controls the actual speed of the vehicle through
braking. It consists of two sub controllers, both of which use a PID feedback control structure.
The rst controller uses the actual vehicle speed feedback to generate a required braking
pressure. This braking pressure setpoint is then passed through to the same controller as for
the open loop brake control in order to send the right signal to the braking actuator. This is
illustrated in Figure 6.35.
195 Chapter 6. Control Strategies
Figure 6.35: Closed Loop Brake Controller
6.3. Motion Execution Control 196
Chapter 7
Graphical User Interface
7.1 Software
The base station software serves as the primary interaction between user and vehicle. The
Graphical User Interface (GUI) must provide all the tools necessary to control the vehicle at
its full potential. It must also feed back the information necessary to monitor all aspects of
the vehicles motion. To do this, the software must be able to:
• Set up communication through a serial port to the TARGET vehicle (see Section 4.3.2)
• Provide the user with:
Waypoint editing functions
Vehicle status
Log les to review
• Store the list of user dened waypoints
• Generate a smooth path between the dened waypoints; and
• Eectively communicate the smooth path to the vehicle
Java was chosen as a suitable programming language to complete these tasks since it is a
safe and robust language that can provide high performance, cross-platform, object oriented
programs (Harold, 2000). In addition, Java:
• is widely used and so contains signicant documentation and support
• was used in similar previous projects conducted at the University of Adelaide; and
197
7.1. Software 198
7.1.1 Software Requirements
The base station software has been designed and tested on a Windows XP computer that was
installed with the following software packages:
• Eclipse IDE Version 3.3.0 - An application that aides in software development
• Java JRE 1.6.0 & JDK 1.6.0.02 - Core language for the base station software
• RXTX - A native library providing serial and parallel communication for Java
• JFreeChart - A library providing extensive support for graph, chart and dial construction
for Java
7.1.2 Design Solution
The constructed base station software has many dierent java class les and has a source code
containing 800+ lines of code. It represents many hours of research, development and testing
to make sure every aspect performs correctly. Each le has been designed and written with
a specic function, and when combined together the les form an overall program. In this
section some of the les and their functions will be explained in detail.
Each major segment of the program has been constructed with a Manager associated with
it. The manager is responsible for all operations to do with that particular section and any
action must have permission from the manager. This system has proven to work very well
with the base station software.
Some of the main class les and managers incorporated in the base station are the Waypoint
Manager, Serial Manager, File Manager, Sound Manager, Picture Manager, MainWindow
and Vehicle States. These seven main class les work together to achieve most of the program's
major functions.
The Waypoint Manager
The waypoint manager is responsible for four separate internal lists of GPS waypoints. Each
waypoint contains specic information which is used to describe a point on the earth's surface.
Other important information contained within a waypoint includes the desired speed, if the
waypoint is selected and if the waypoint has been automatically generated. The four internal
lists are used to maintain information and ensure that data is not lost or accidentally removed.
They can be described as:
1. A list of waypoints that have been dened by the user.
199 Chapter 7. Graphical User Interface
(a) Open Cubic (b) Open Linear
(c) Closed Cubic (d) Closed Linear
Figure 7.1: Various path types for the same ve waypoints. The vehicle is represented as ablue dot.
2. A list of waypoints representing the smooth path displayed on the screen. These way-
points are automatically generated and also include the waypoints in list #1 above.
3. A list of waypoints that has been sent to the onboard computer. This list is a copy of
list #2, but is updated and displayed separately.
4. A list of waypoints stored to remember the actual path of the vehicle. Ideally the path of
the vehicle will be identical to list #3, but this is not guaranteed. This list of waypoints
is also used to automatically generate a path from no-user-input waypoints.
The waypoint manager has been given the ability to add, edit and delete waypoints from all
four lists as required by the user or onboard computer. The waypoints are either added by
the user, added from the log le or automatically generated. In the case where waypoints are
generated automatically, the waypoint manager is also responsible for the iterations required
to form a path (see Section 3.7). There are four separate path types that can be generated.
Paths can either be generated as open or closed loop paths and can be generated by using
either linear or cubic splines. Figure 7.1 illustrates how the waypoint manager draws these
four dierent path types between the vehicle and a collection of waypoints.
The Serial Manager
The serial manager is responsible for opening and maintaining the serial port communication
with the TARGET vehicle. All data sent to and received from the serial port is managed by
the serial manager. Another main function of the serial manager is to trigger events, which
calls other objects in the program to perform an action. An example is when the position of
the vehicle changes. The change in position must be correctly displayed on the screen and
7.1. Software 200
Figure 7.2: Event sequence showing data inow, events and event recipients
the serial manager triggers this event. The information included in the event is sucient
to identify what actions must be taken by the receiving objects. Figure 7.2 illustrates what
occurs when data is received on the serial port. An event is generated and passed to all objects
registered to listen for serial manager events.
Setting up a serial port connection is very simple. Controls have been interfaced between the
MainWindow and the serial manager to help during testing stages. The user has two options
relating to the serial port which is used. The speed and serial port number can easily be
changed by selecting the correct settings on the visual display.
The File Manager
The le manager is responsible for all the interactions that the program has with external
les. There are three main le types the program must interact with. These include:
• Conguration Files are used to help dene the background images. The le manager
reads and interprets the information and can pass all the required data to the picture
manager where the pictures are stored.
• Background Images are requested by the picture manager. The data is read by the le
manager and then passed to the picture manager.
• Log Files
Log les are exclusively written to and read from by the le manager. The le manager
contains internal functions that correctly format data and arrange information correctly to
be logged. The le manager will also decode the log le to extract useful data. The useful
data is passed to the picture manager which has the ability to generate graphs of the logged
data. A sample of such a log le is shown in Table 7.1.
201 Chapter 7. Graphical User Interface
Table 7.1: A sample log le generated by the base stationTime (ms) Action Data Type Data
102734 Received TH 5.0102750 Received BR 1.0102765 Received SA 3.0
Four critical pieces of information are stored in each entry of a log le. The rst entry,
time, indicated the number of elapsed milliseconds since the base station was started. In the
example, the three entries occur between 102.734 and 102.765 seconds after the base station
was started. The second entry indicates the action that has been performed. The majority of
actions occurring during normal operation relate to the serial port. The actions of Received
and Sent are most common. The data type is a prex to the data and uniquely identies
and gives meaning to the data value. There are approximately 18 data types which range
from error numbers, GPS coordinates and commands. The example in Table 7.1 shows the
serial port receiving a throttle percentage (TH) of 5%, a brake percentage (BR) of 1% and a
steering angle (SA) of 3 degrees.
7.1.3 Creating a Path
There are two methods implemented in the base station software for creating a path of way-
points. The rst requires that the user input the waypoints manually by clicking on the screen
in the designated area. In this area is a user dened background image which can be used to
help guide the users placement of these waypoints. The accuracy of this method is dependent
on how the background images are dened (discussed in Section 3.7). The GPS coordinates
of the background image are dened separately by the user and so may contain some system-
atic errors. If the coordinates specied by the user do not agree with those recorded by the
vehicle's GPS equipment (see Section 5.4.1), the vehicle will drive o course. In order to help
overcome the errors in this method a second path generation method was developed.
The second, and most accurate method of dening a path is to restore waypoints from a log
le. To do this the vehicle must be manually driven around its desired course. During this
time the velocity and positions visited are logged and recorded into a log le. At any later
date the information located in this log le can be retrieved and the path restored with little
or no input from the user. The coordinates recorded have no bearing on the location of the
background image and hence are not subject to the same systematic errors experienced by
the rst method.
7.1.4 Known Issues
Memory Consumption
The base station software can be asked to import and display any number of images and so
issues have risen with the memory consumption of the program. The default allocation of
7.2. Hardware 202
memory for a Java program is 64Mb, however after loading ve images of reasonable size, an
'OutOfMemory' error was triggered and some images would not be displayed. To overcome
this, the memory allocation for the program must be increased.
Increasing the memory allocated to the Java program cannot be done from within the program
itself. The extra memory must be allocated before the program is run and nothing can be
added to this allocation once initialized. To increase the allocated memory some additional
arguments must be used. The argument '-Xmx###m' must be added, where '###' rep-
resents the number of megabytes to be allocated. It was found that an allocation of 128Mb
(or double the default allocation) was sucient to display the test images. An allocation of
512Mb has since been recommended and used. The argument can either be implemented
within Windows or included in a batch le used to initialise the base station software.
Background Image Definition
The accuracy of a background image denition is not the best it could be. Of the three
methods discussed in Section 3.8, only the rst and most basic has been implemented. The
problems and a possible solution has also been discussed in Section 7.1.3.
7.2 Hardware
The base station hardware consists of a computer, a serial modem and a power source. Because
the base station software is Java based and can be compiled for nearly all operating systems,
there is only one requirement for the computer. The computer must have at least one but
preferably two serial ports. The base station computer was initially budgeted as a Dell
desktop, but due to the large cost of such an item, it was provided 'in kind' by the university
for use throughout the project.
The selected power source is a portable generator. During normal operation the generator
would have to power the base station computer (including the monitor) and the serial modem.
During testing, however, the generator would also be required to power an additional computer
and monitor which must be used as the xPC host computer. The cost of a small generator
was signicantly lower than purchasing a battery and inverter. The useful running time of
the generator is also around 6 hours, which is signicantly longer than any suitable battery
could provide.
7.3 Final Design
The nal design of the base station software does not show many of the components described
in Section 7.1. Many of the components described in Section 7.1.2 can be seen both in Figures
203 Chapter 7. Graphical User Interface
7.3 and 7.4. Figure 7.3 represents a simplied ow diagram of the overall base station software.
Figure 7.4 shows a screen shot of the software package and a user manual has been included
in Appendix I.
Figure 7.3: Simplied ow diagram of the overall base station software. Blue represents aninternal manager, orange represents the visual objects on the monitor, yellow represents datastorage and green represents external objects.
7.3. Final Design 204
Figure 7.4: Screen shot of the current base station software
Chapter 8
Safety
Safety is very important in most situations and this is especially true for this project. Because
the TARGET vehicle is a large van, all the dangers associated with a moving vehicle are
present. In addition, RC and autonomous modes introduce further risks associated with
computer based control, as there may not be a human present inside the vehicle. During its
operation, there is the potential for the TARGET vehicle to inict damage on itself, its users,
bystanders, and the surrounding environment. Because of this potential for damage, many
dierent independent systems have been developed to ensure the safety of all equipment,
people, and the surroundings. This chapter will discuss the types of emergency stops used in
the vehicle, summarise the safety systems discussed throughout the report, and also introduce
the Failure Mode and Eects Analysis and Safe Operating Procedure.
8.1 Types of Emergency Stop
Two dierent types of emergency stop are implemented on the TARGET vehicle. Each of these
correspond to dierent situations and they are mutually exclusive. The particular emergency
stop which is activated depends upon the problem encountered.
8.1.1 Failure Mode
This emergency stop is activated by the onboard computer. It can be activated by the fault
detection routine on the onboard computer, or by a user from a switch on the RC controller,
or by a user from a button on the base station computer. As discussed in Section 6.1.2, the
fault detection routine can nd 31 separate faults and any one of these faults will cause the
vehicle to enter Failure Mode. These 31 faults include the emergency stop activation signals
from both the RC controller and base station, and also a heartbeat failure from the dragon
board (which is discussed further in Section 8.1.2). Once failure mode is entered, the onboard
computer runs the emergency stop routine which:
205
8.1. Types of Emergency Stop 206
• Releases the throttle by using the throttle dump (discussed in Section 4.5.2)
• Sets the brake pressure to 75% using the brake pressure control loop (discussed in Section
6.3.2.3)
• Latches the steering wheel to its last position using the steering control loop (discussed
in Section 6.3.1)
• Activates the emergency brake system (discussed in Section 4.6.2 8 seconds after acti-
vation
• Puts the vehicle into park using the transmission actuator (discussed in Section 4.7) 13
seconds after activation
• Turns o the engine once the vehicle is in park
• All warning lights on the vehicle are activated
• The corresponding fault sound is played on the base station
The throttle is set to dump so that the brakes can be applied eectively. The brakes are only
set to 75% rather than 100% in order to provide signicant braking without locking up the
wheels as the van is not tted with an anti - lock braking system. The steering is set to its
last known value to accommodate for a failure during the negotiation of a corner. In this
situation, it would be desirable to continue cornering rather than moving straight ahead. The
emergency brake system is activated after a period of time has elapsed in case the primary
braking system (as discussed in Section 4.6.1) has failed to stop the vehicle. Putting the
vehicle in park and turning the engine o ensures that the vehicle cannot move further and
is safe to approach.
Activating the warning lights on the vehicle provides a visual indication from a distance that
the TARGET has entered Failure Mode. The fault sound provides an audio indication of
Failure Mode at the base station and also allows for easy identication of the fault type
encountered. The dierent fault types are discussed in 6.1.2.
8.1.2 Dragon Stop
The Dragon Stop system has been developed in the event of a systems failure associated with
the onboard computer. In this case, the onboard computer will not be able to control the
vehicle. If this occurs, control of the steering, brake and throttle actuators is given to the
Dragon Stop system. This emergency stop mode is referred to as the Dragon Stop due to the
name of the micro - controller board used. The system was been developed in MATLAB and
Simulink and has been exported to run on an MC9S12 Dragon12 micro - controller board.
A top level block diagram of this system is shown in Figure 8.1. The Dragon Stop system
monitors the onboard computer using a heartbeat signal pulse. The onboard computer also
207 Chapter 8. Safety
monitors the redundant control system using a heartbeat signal pulse. This is so each of
the systems can monitor if the other is operating correctly. If the Dragon Stop system stops
detecting the heartbeat given by the onboard computer, it will activate Dragon Stop mode.
If the onboard computer stops detecting the heartbeat given by the Dragon Stop system, it
will enter Failure Mode.
Figure 8.1: Dragon Stop System
Once Dragon Stop has been activated, three events occur:
• The throttle actuator is set to dump - this will completely release the throttle.
• The brake pressure is set to 75% of its full value using a PID controller identical to that
discussed in Section 6.3.2.3.
• The steering wheel is set to hold at its last known value using a PID controller identical
to that discussed in Section 6.3.1.
These three events occur simultaneously and are designed to bring the van to a stop quickly
and safely. The reasons for these three events are identical to those given in Section 8.1.1. It
is unlikely that the onboard computer will fail, so it was considered adequate that only the
events listed above (and not the other events listed in Section 8.1.1) are adequate for Dragon
Stop mode.
The heartbeat detection and the Dragon Stop routine has been tested and conrmed to work
in simulation. But unfortunately, this system has not been integrated completely with the
rest of the TARGET. This is due to an unforeseen problem with RS232 communications and
the amplier that controls the steering and brake actuators (discussed in Section 4.8.7). The
8.2. Safety Systems Summary 208
amplier only accepts 7 data bits with even parity and this cannot be changed. The Motorola
microcontroller included on the Dragon12 board supports multiple options for parity, however
is limited to 8 or 9 data bits. The correct commands are being sent by the Dragon12 board
(as tested using Hyperterminal and RS232 communications) but the format between the two
boards is incompatible.
Due to limitations with time, another system has not been developed and so an operator
should always be present within the vehicle in RC and autonomous modes to ensure that they
can take control if the onboard computer crashes.
8.2 Safety Systems Summary
The various safety systems have already been discussed in their respective sections throughout
this document. This section will summarise all of these previously mentioned systems and
list the appropriate sections as a reference.
8.2.1 The Van
It was important that the van chosen as the vehicle platform was roadworthy and safe to
drive as testing and transport requires the vehicle to be driven both manually by a human
and automatically in RC and autonomous modes. A cargo barrier was installed to ensure
that any equipment in the rear of the vehicle will not harm the occupants of the cabin in a
crash. The details of the vehicle selection are outlined in Section 4.1.
8.2.2 Communications
The handheld controller includes a switch to activate Fault Mode remotely, as discussed in
Section 4.3.1. This is to allow the user to manually stop the vehicle in RC mode. In addition,
a routine is included in the onboard computer program to allow for monitoring of the signal
transmitted by the handheld controller. When the RC receiver cannot detect a transmitted
signal, its output is completely static. The fault detection routine checks to see if the output
is static and activates Fault Mode if communications loss is detected. This fault detection
routine is detailed further in Section 6.1.2.3.
The RF link between the base station and the onboard computer is monitored using a heart-
beat pulse which is echoed back and forth between the two computers. If this heartbeat pulse
is not received, then the vehicle will enter Fault Mode mode as discussed in Section 6.1.1.3.
209 Chapter 8. Safety
8.2.3 Actuators
The actuators and mounting were chosen with regard to ensuring safety.
The steering motor chosen incorporates a large design factor which ensures that it can produce
more than enough torque to turn the steering wheel at all times, even in the event that power
steering is lost. To ensure the vehicle was road legal, the actuator was mounted so that it was
in compliance with requirements set by Transport SA regarding safety of the vehicle. This
was to ensure that in the event of a collision, the existing safety collapsing mechanism of the
steering column was not interfered with. This is discussed further in Section 4.4.
The throttle actuator incorporates a safety dump so that the throttle can be completely
released at any time (this is discussed in further detail in Section 4.5.2). This ensures that
the onboard computer or Dragon Stop System can release the throttle quickly at any time.
The mounting of the primary braking system discussed in Section 4.6.1 ensures that the driver
(if present) can operate the brake pedal safely and without any interference. The actuator was
also chosen with a large design factor to ensure the brake pedal can be completely depressed.
The emergency brake system acts as a secondary braking system. It was designed to allow the
vehicle's brake pedal to be operated if electrical power is lost. The emergency brake system
is used when the vehicle enters Fault Mode as discussed in Section 8.1.1 and also if electrical
power is lost. This system is detailed in Section 4.6.2.
8.2.4 Electronics
The electronics for the TARGET vehicle have been designed with considerations made to
safety.
The existing car battery was complemented by adding a second, deep discharge battery whose
performance allows for the onboard systems to run for approximately 10 hours. A dual battery
isolator was also installed to allow for both batteries to be charged by the alternator when
the engine is running. This ensures that there will always be enough power for the onboard
systems. This is detailed further in Section 4.8.1.
Three separate safety electronic systems were implemented as discussed in Section 4.8.2:
1. A series of relays allows power to be cut to all the actuation systems on the vehicle.
This can be operated digitally by the onboard computer system, or manually using a
large red switch located in the center console in the vehicle. This allows a driver (if
present) to regain manual control of the vehicle.
2. A proximity sensor was installed onto the brake pedal. This senses if an object (i.e. the
driver's foot) is close to the pedal and also cuts power to all the actuators allowing the
driver to regain manual control of the vehicle.
8.2. Safety Systems Summary 210
3. An isolating switch was installed which cuts power to all electronics connected to the
secondary battery excluding the inverter.
In addition, many fuses have been installed (in addition to the vehicle's existing fuses) to
prevent large power surges damaging equipment inside the TARGET vehicle.
8.2.5 Autonomous Guidance Control
The Autonomous Guidance Controller contains a number of strategies to provide safe control
of the vehicle whilst in autonomous mode. A general feature of this system is that it is an
enabled subsystem of the larger onboard computer program. This means it is not running
all the time and is only activated when it is deemed safe to do so by the user.
The steering guidance controller has eective performance and consistent behaviour. This
helps create smoother steering for the vehicle whilst in autonomous mode. The output of the
steering guidance controller is also limited in range and rate to provide for smoother steering
and also decreases the chance that the vehicle will roll over. This is discussed in Section
6.2.1.1.
The speed guidance controller contains an approach speed function which checks the curvature
of a number of the upcoming path segments and suggests a safe speed. This is to maintain
a comfortable lateral acceleration of 0.3g for any occupants and also decreases the chance of
the vehicle rolling over. The speed guidance controller also contains a speed lter which slows
down and eventually stops the TARGET vehicle if it signicantly deviates from the desired
path. The speed of the vehicle is also limited to 40 km/h in autonomous mode. All of these
safety features are discussed in further detail in Section 6.2.1.2.
8.2.6 Motion Execution Control
The Motion Execution Controller also contains a number of strategies to provide for safe
control of the vehicle both in RC mode and autonomous mode.
As discussed in Section 6.3.1.1, the steering control system incorporates roll prevention. The
Autonomous Guidance Controller's steering output is range and rate limited (as discussed in
Section 6.2.1.1) which helps to prevent roll. However, this does not mean that the vehicle will
not be able to roll over if turning too sharply at high speeds. The roll prevention system in
the Motion Execution Controller ensures that the steering becomes limited as the vehicle's
speed increases and so prevents the vehicle from rolling over. This system operates in both
autonomous and RC modes.
The steering control system also incorporates a subsystem which prevents the actuator from
turning when the steering wheel is close to its full lock to the left or right as discussed in
211 Chapter 8. Safety
Section 6.3.1.2. Since the motor is powerful and can produce a large torque, this subsystem
prevents the motor from damaging the mounting brackets, sprockets, chain or the steering
column itself.
A speed switching logic is included in the speed controller as discussed in Section 6.3.2.1. This
ensures that the brake and throttle are operated individually and not simultaneously, which
provides for smoother and safer speed control of the vehicle. This also means less wear and
tear on the braking system of the vehicle.
8.3 Failure Modes and Effect Analysis
All designs which have been implemented have been made with safety as the rst priority.
This is well illustrated in the Failure Modes and Eects Analysis (FMEA), which can be
found in Appendix C. The FMEA documents the safety issues for all sections of the project
(Communications, Actuators, State Measurement and Estimation, Autonomous Guidance
Control, Motion Execution Control and GUI). This document is a standard procedure for large
projects and identies the things which can go wrong, how this can eect the performance
of the project and how these can be prevented. By identifying these issues, the design of the
various sections of the project have been improved to be safer. The FMEA includes:
• Failure Mode - this identies ways in which each component can fail
• Eect of Failure - outlines the eect the failure will have on the TARGET vehicle
• Severity Rating - the degree of severity on a scale from 1 to 10 (minor to catastrophic)
for each failure
• Potential Cause of Failure - self explanatory
• Occurence Rating - the likelihood of the failure occuring on a scale from 1 to 5 (practi-
cally never to very likely)
• Possible Means of Detection - self explanatory
• Detection Rating - the degree of diculty in detecting the failure from 1 to 10 (easily
detectable to not detectable)
• Preventative Action - self explanatory
• Action to be Taken in Case of Failure - self explanatory
8.4. Safe Operating Procedure 212
8.4 Safe Operating Procedure
A document outlining the required safe operating procedure of the TARGET vehicle has been
generated to ensure the safety of the project members and general public. The document
covers the safety procedures and requirements that must be met during the testing process.
The document is separated into the following sections:
• The procedure that must be carried out before manual transportation of the vehicle
• The start up procedure that must be carried out before testing
• General safety practices
• The procedure that must be carried out in the event of an emergency
The safe operating procedure document can be found in Appendix D.
Chapter 9
Final Testing and Analysis
This chapter will discuss the nal testing and analysis associated with the TARGET vehicle
systems. Particular reference will be made to the project goals and specications in Chapter 2.
9.1 Actuators and Actuator Control
This section assesses the goals of the actuators and actuator control section of the TARGET
project. The goals cover the areas of: selection of suitable hardware, installation of hardware,
design of the local control loops and the safety of the actuation systems.
9.1.1 Selection of Suitable Hardware
It is desirable to have actuators that possess sucient torque and force to actuate the steering,
throttle, transmission and brake of the vehicle. These actuators must also move at a rate quick
enough to mimic a human driver (Refer to Chapter 2).
The actuators used in the TARGET vehicle successfully provided adequate force (brake,
transmission and throttle) and torque (steering) to actuate the vehicle driving controls. The
selected steering motor possessed sucient torque to actuate the steering and this was demon-
strated in testing. The motor was also capable of providing enough torque to dry steer the
vehicle. The speed at which the steering column could be turned was greater than the required
speed of 1 rev/s (see Section 4.4.1).
The selected actuators for the brake and transmission have been tested and thus conrmed
their capability in providing sucient force to operate the vehicle brake pedal and transmission
lever. The speed at which the actuators can operate the vehicle brake and transmission lever
has also been tested. Their speed is adequate to mimic that of a human driver (refer to Section
4.6 and 4.7). Nevertheless, a brake actuator with a faster operational speed is desirable since
213
9.1. Actuators and Actuator Control 214
it would allow for rapid deceleration of the vehicle. However, this problem was successfully
overcome by the implementation of emergency brake system to the TARGET vehicle (refer
to Section 4.6.2).
The vacuum actuator used to actuate the throttle of the vehicle was able to provide adequate
force to move the throttle valve, and also moved it at a suitable rate. Using the vacuum
actuator, the vehicle achieved the required speed of 40 km/h during testing (see Chapter 2).
9.1.2 Installation of Steering, Throttle, Brake and Transmission Lever
The locations of the actuators should be chosen so as not to interfere with the normal human-
driven operation of the vehicle that is, the vehicle should be capable of being safely and legally
driven by project team members when not being driven through remote or autonomous means.
Where practically possible, functionally appropriate and without contravening the previous
statement, actuators should generally be placed in locations that are readily accessible. Wiring
should be enclosed and arranged in a neat and tidy manner (Refer to Chapter 2).
The mounting positions of the actuation systems did not interfere with the normal human
driven operation of the vehicle. Furthermore, the mounting arrangements for the actuators
were in compliance with requirements set by Transport SA regarding the safety of the vehicle,
hence making the vehicle road legal (discussed in Section 4.4.2). The actuators were mounted
so that they are easily accessible for maintenance and inspection purposes. Wiring to the
actuators was enclosed in a neat and tidy manner.
9.1.3 Design of Local Control Loops for Each Actuator
Control loops for the actuators should maintain, as close as possible, the parameters provided
to it by either the Phase One or Phase Two control loops (Refer to Chapter 2).
The control loops generated were Incorporated into the Motion Execution Controller. Desir-
able results were achieved and the performance is discussed in Section 9.2.
9.1.4 Safety
A reliable, fail safe mechanism for manually overriding the actuators will be developed to
enable a person in the driving seat to either immediately and easily stop or regain manual
control of the vehicle at any time (Refer to Chapter 2).
A series of relays were installed into the TARGET vehicle to ensure that the actuators could
be disabled at any time (see Section 4.8.2). When the actuators have been disabled, a human
driver is able to regain manual control of the vehicle. Operation of the brake and throttle are
215 Chapter 9. Final Testing and Analysis
unaected when power is cut to the actuators. To steer the vehicle manually the steering motor
must be back driven, which can be done with ease. To manually operate the transmission,
the transmission lever and actuator can be disconnected by removing the R-pin holding them
together.
9.2 Remote Controlled Motion
The project goal associated with Remote Controlled Motion of the TARGET project is:
Achieve successful remote controlled operation of the target vehicle
All of the pre-described safety mechanisms will be tested and their eective and consistent
dependability ensured before operating the vehicle by remote or autonomous means. The per-
formance of the remote control vehicle operation will be assessed in a number of trials. The
underlying Motion Execution Control system will also rst be tested in simulation before being
implemented in practice. Important criteria will include operability, responsiveness, stability
and reliability, and command following. (see Section 2.2)
The safety systems included onboard the TARGET vehicle (apart from the Dragon Stop
system) have all been implemented and tested. These are outlined in further detail in Chapter
8. The Motion Execution Controller was tested in simulation using Simulink to conrm the
control strategy, and also in the laboratory whilst the vehicle was raised up on stands. This
was to ensure that the behaviour of the control system was as expected, before the vehicle was
taken for eld testing. Remote controlled motion of the TARGET vehicle has been successfully
achieved in the eld using both open loop and closed loop speed modes (discussed further in
Section 6.3.2).
The Motion Execution Controller is responsible for remote controlled motion of the TARGET
vehicle. Analysis of the Motion Execution Controller includes the tuning and performance of
the control systems (steering and speed controllers) with reference to the project goals and
specications (as discussed in Section 2.1.5). The Motion Execution Controller is associated
with implementing the commands from the Autonomous Guidance Controller in autonomous
mode and commands from the handheld controller in RC mode. However, the performance
of the Motion Execution Control system is identical in both autonomous and RC operation,
as the only dierence is the source of the inputs. Hence, this section will only discuss the
performance of the Motion Execution Control System whereas Section 9.4 will discuss the
performance of the Autonomous Guidance Controller.
9.2.1 Vehicle Steering and Speed Control
The desired vehicle heading and speed are to be transmitted to the onboard computer from the
handheld, human operated radio control via the one way communication link as inputs to the
9.2. Remote Controlled Motion 216
Motion Execution Control system. When operating in autonomous mode, the desired vehicle
heading and speed will be generated by the Autonomous Guidance Control system and passed
on to the Motion Execution Controller. Closed loop feedback of the 'actual' vehicle steering
and speed will be provided by a Kalman Filter / estimator via a fusion of measurements from
the GPS, IMU, and other available vehicle sensors. The Motion Execution Control system
will then regulate output commands to the throttle, steering and brake actuators and ensure
that the vehicle responsively tracks the desired steering and speed. (see Section 2.1.5)
The Motion Execution Controller successfully achieves control of the vehicle's steering and
speed by sending signals to the actuators. It is able to receive steering and speed inputs
from both the handheld controller in RC mode and the Autonomous Guidance Controller in
autonomous mode and implement these commands onto the vehicle. The local control loops
for the actuators were originally included under the Actuator and Actuators Control subgroup
but have been developed within the Motion Execution Controller and are discussed in Section
9.2.2 and Section 9.2.3.
9.2.2 Steering Controller
As discussed in Section 6.3.1, the structure of the steering controller consists of a PD controller
in a closed loop with feedback provided by the steering potentiometer. This PD controller
was tuned manually on the y using a trial and error method. Tuning methods such as the
Zeigler - Nichols method were initially considered over trial and error. However this may have
taken longer because the calculated controller gains would most likely require further tuning
using a trial and error method. The acceptable gains were found to be:
Proportional
Derivative 0.1
These nal gains were chosen based on visual monitoring of the rise time for a setpoint as
compared with a human user operating the wheel. The rise times observed in the steering
controller were low, signicantly faster than a human could operate the wheel. A step response
for the steering system was obtained whilst the vehicle was lifted up on stilts (in the laboratory
during testing) and this is shown in Figure 9.1. Although the wheels of the vehicle were not
in contact with the ground, the response with the vehicle resting fully on the ground would
not dier signicantly because the steering actuator is capable of producing large torques -
enough to dry steer the vehicle without any problems. A setpoint of 0.5 was chosen so that the
steering system does not approach the steering lock saturation subsystem discussed in Section
6.3.1.2. A setpoint of 0.5 corresponds to half lock in the clockwise (right) direction. Also listed
in Table 9.1 are the approximate performance characteristics for the steering controller. These
values were found from the step response of the system as shown in Figure 9.1.
217 Chapter 9. Final Testing and Analysis
Figure 9.1: Steering step response
Table 9.1: Steering controller step response characteristicsCharacteristic Value
Overshoot 0 %
Rise Time (63% of nal value) 2 secs
Settling Time 2.4 secs
Final Value 0.495
As can be seen from Figure 9.1 and Table 9.1, no overshoot is observed in the system, which
is very desirable. The nal value of 0.495 is also very close to the setpoint, with a steady
state error of only 1% which is also very desirable. The rise time and settling time for the
step response is fast, with approximate values of 2 seconds and 2.4 seconds respectively.
From the centre position, it takes 1.5 turns of the wheel to reach full lock in the clockwise
direction, so the setpoint corresponds to 0.75 turns of the steering wheel. A human is able
to turn the wheel at approximately 1 rev/s at maximum speed, and approximately 0.3 to 0.4
rev/s in normal driving conditions (tested in the laboratory and in the eld). From the step
response, the controller is able to turn the wheel at 0.32 rev/s which is adequate to mimic a
human driver. The initial behaviour of the system, after the step response is received, appears
to be associated with a non-minimum phase zero, however a non mimimum phase zero is not
present in the system. This anomalous behaviour can be attributed to sensor noise from the
steering potentiometer. The jagged rise of the step response can be attributed to the bracket
mounting system, which allowed for slight movement in the steering motor as it turns.
The steering controller used for Remote Controlled Motion can be seen to have good perfor-
mance. This is because it provides good set point following, very low steady state error, fast
response, and is able to mimic the approximate turning speeds of a human driver.
9.2. Remote Controlled Motion 218
9.2.3 Speed Controller
Discussion and analysis of the performance and tuning of the speed controller must be split
into two parts: open loop mode and closed loop mode. The details of these two modes are
discussed further in Section 6.3.2.
9.2.3.1 Open Loop Mode
As discussed in Section 6.3.2, throttle control is not provided in Open Loop Mode. The
throttle setpoint (provided between 0% and 100%) is routed straight to the actuator. Hence,
the only performance characteristics to discuss are related to the brake pressure control loop.
As discussed in Section 6.3.2.3, this control loop is a closed loop PID controller with feedback
provided by the brake pressure transducer. As with the steering controller, this PID controller
was tuned manually on the y using a trial and error method. This was due to the same reasons
as discussed in Section 9.2.2. The acceptable gains were found to be:
Proportional 8
Integral 0.2
Derivative 0.5
These gains were determined based on their ability to provide good set point following with
minimal overshoot. The step response of the system was monitored in real time and the gains
were altered until an acceptable response was found. The step response of the system with
the nal controller gains is shown in Figure 9.2. A setpoint of 0.5 instead of 1 was chosen
so that overshoot in the system could be observed. Listed in Table 9.2 are the approximate
performance characteristics for the brake pressure controller. These values were found from
the step response of the system as shown in Figure 9.2.
Table 9.2: Braking controller step response characteristicsCharacteristic Value
Overshoot 4 %
Rise Time 3.1 secs
Settling Time 4.5 secs
Final Value 0.52
The overshoot observed in the step response (shown in 9.2) is very low, which is desirable in
the controller. A very small steady state error of approximately 4% can be seen, and this is
desirable. However, the rise time and settling time of 3.1 seconds and 4.5 seconds respectively
is slow. These slow times are due to the limited speed of the actuator as discussed in Section
4.7.2. As discussed in Section 10.2.2, a linear actuator with greater speed would be desirable,
and would greatly improve the braking performance in Remote Controlled Motion.
219 Chapter 9. Final Testing and Analysis
Figure 9.2: Braking step response
Although the rise times and settling times for the brake pressure controller are quite slow,
the controller still provided adequate control of the brake in Radio Controlled Motion. Good
setpoint following was achieved, and the responsiveness of the vehicle's braking is still accept-
able. This is because deceleration of the vehicle occurs as soon as the brake pressure rises
above zero.
In a similar manner to the steering step response discussed in Section 9.2.2, the initial response
of the brake pressure controller appears to be associated with a non minimum phase zero.
However, a non minimum phase zero is not present in the system. Again, this behaviour can
be attributed to sensor noise in the brake pressure transducer.
9.2.3.2 Closed Loop Mode
Closed loop control provides speed control using a speed switching logic which enables either
the throttle or the brake. The details of the control strategy are discussed in Section 6.3.2.
This controller consists of the closed loop throttle and closed loop brake control subsystems
as discussed in Sections 6.3.2.2 and 6.3.2.3 respectively.
Closed Loop Mode was developed successfully and was tested in simulation, in the laboratory,
and in the eld. Much of the eld testing time was consumed by tuning Closed Loop Mode
and trying to achieve autonomous operation. Due to time constraints, step responses for
closed loop mode were unfortunately not generated and the performance of Closed Loop
Mode cannot be discussed.
9.2. Remote Controlled Motion 220
However, the nal gains for the closed loop mode were obtained. For the closed loop throttle
controller, the gains are:
Proportional 1
Integral 0.5
Derivative 0.5
The gains for the closed loop brake controller are:
Proportional 0.1
Integral 0.01
Derivative 0.01
These gains were tuned on the y using a trial and error method whilst observing the overshoot
and setpoint following characteristics of the closed loop controller. The reasons for using this
method are the same as for tuning the steering controller and these are listed in Section 9.2.3.
Although the performance of the controller cannot be quantied due to the lack of step
responses, these gains gave reasonable setpoint following with minimal overshoot for the closed
loop throttle and the brake controllers.
9.2.4 Transmission Lever and Ignition Control
The Motion Execution Control system should also produce and handle control commands to
the vehicle ignition and transmission lever, through local control loops embedded in the gearbox
and ignition actuator systems should be used to implement the actual automatic operation of
these devices. (Taken from Section 2.1.5)
Successful computer control of the transmission lever and ignition has been developed. The
transmission control system is discussed further in Section 6.1.4.3 and the ignition control
system is discussed further in Section 6.1.4.4. Both of these systems have been tested and
worked as expected. However there are still some technical issues with both systems.
The mounting bracket of the linear actuator used to control the transmission lever has been
damaged due to a mechanical problem with the transmission lever. Due to time constraints,
this system has not been re-implemented with the rest of the vehicle.
The computer controlled ignition system still activates the correct switches in order to start the
vehicle. However, a problem lies in the starter motor of the van. It only works intermittently,
even whilst operated by a user with the key for manual ignition. The starter motor needs to
be replaced, but due to time constraints, this has not yet been done.
221 Chapter 9. Final Testing and Analysis
9.2.5 Safe Operation
The controller must include appropriate safety logic to ensure safe operation of the vehicle,
though the vehicle should only be operated in an environment where the hazards posed to human
safety are minimal. The safety logic should include the ability to reliably override autonomous
control with radio / remote control at any time, an emergency stop mechanism, logic to halt
the vehicle during a loss of radio communications, and a roll prevention scheme. It is also
desirable for audio and visual warnings to be activated upon critical systems failure. (Taken
from Section 2.1.5)
The safe operation of the Motion Execution Controller and the rest of the TARGET's systems
has been tested and conrmed. The numerous successful safety systems developed have been
summarised in Chapter 8.
A roll prevention scheme has been developed and included in the steering controller. This
system limits the amount of steering left or right as the vehicle's speed increases - hence,
ensuring that the van cannot turn too sharply whilst traveling at high speeds. The roll
prevention scheme is discussed in detail in Section 6.3.1.1. This system has been tested in the
lab and has been shown to limit the steering of the vehicle as its speed increases. However,
this has not been tested in the eld. This is because in order for this system to be tested
accurately, the vehicle must be purposely put in situations where it will roll over and this was
deemed to be too dangerous.
Further discussion of all safety systems incorporated in the TARGET vehicle can be found in
Chapter 8.
9.3 Selection, Installation and Maintenance of the Vehicle’s On-board Processor
The project goal associated with the onboard processor is to select a suitable onboard vehicle
processor. Another major task identied during the project was the development of the
onboard computer's software.
9.3.1 Select a Suitable Onboard Vehicle Processor
The suitability of the chosen onboard vehicle processor will be evaluated against the criteria
described in Section 9.3 of the Project Specication. (Taken from Section 2.2)
This goal has been achieved in accordance with the specications listed in Section 2.1.5.
The vehicle's onboard processor will interface with many of the vehicle systems. It will however
be under the most load while processing the engagement of vehicle control, state estimation,
9.3. Selection, Installation and Maintenance of the Vehicle’s Onboard Processor 222
and communication. The onboard processor platform should have sucient memory and ops
(oating point operations per second) to handle these tasks, and should be equipped with enough
peripherals and I/O ports to allow the seamless integration and interconnection of the necessary
devices. The processor platform should be able to operate under the vibration, temperature, and
other environmental conditions inside the vehicle. It should therefore be enclosed in a suitable
housing and securely mounted in a protected location within the vehicle. For the purposes of
systems integration, servicing, and maintenance, it is also desirable for the processor platform
to have a modular design and be easily accessible. (Taken from Section 2.1.5)
The onboard processor chosen selected for the TARGET vehicle was a desktop PC. The com-
puter has a n Intel 2.8 GHz Pentium 4 processor and provides I/O expandability with ve
PCI slots as discussed in Section 4.2.2.1. This computer has been running the entire onboard
computer program successfully in the lab and also in the eld. It includes all necessary in-
puts and outputs required as discussed in Section 6.1.1. It has been mounted in the rack
inside the vehicle using an easily removable bracket which allows for easy access for main-
tenance. Mounting foam is also used to ensure that the computer is isolated and protected
from vibrations.
9.3.2 Onboard Computer Program
Another major task identied in the project was the development of the onboard computer
program. The onboard computer program has been shown to perform as required during in-
vehicle testing. The program has been to developed to interface I/O signals, monitor faults,
control the mode of the vehicle, handle motor communications, and integrate all of the other
systems together, as discussed in Section 6.1.
• I/O Signals
The I/O signals have been successfully integrated with the hardware and electronics of the
TARGET vehicle. Analogue signals are scaled and ltered as needed. Digital signals are
debounced where required to correct for fast switching. RS232 serial communications handled
in a robust manner, with a completely non-specic starting order for all pieces of hardware.
• Fault Detection
The fault detection system has been proven, with each fault monitored able to take the van
into failure mode, thereby safely stopping the vehicle. A range and rate checker has been
implemented in the software to ensure that all sensor readings are within desired bounds.
While the range and rate checker is not currently operational, it is simply a matter of dening
the correct range and rate limits for various sensors. A number of other faults will consistently
trigger failure mode, such as communications loss with the RC transmitter or base station
computer.
223 Chapter 9. Final Testing and Analysis
• Mode Control
Mode control has also been proven to perform as desired in a robust fashion. The mode can
be changed between RC, autonomous and manual modes by an input from the base station
computer. Manual mode can also be triggered by the driver pressing the brake pedal. Failure
mode is entered whenever a fault is detected in the system, and has been demonstrated to
consistently bring the vehicle safely to a stop.
• Motor Communications
The motor communications system has also been shown to perform as required, as all actuation
systems in the vehicle are functioning satisfactorily.
• Systems Integration
Integration between various systems is nearly complete. The only work remaining on systems
integration is to integrate the startup routine, and perform nal testing of the Kalman lter
and autonomous guidance control systems. The onboard computer program has therefore
achieved all of its aims, and would allow further development of the vehicle system.
9.4 Autonomous Motion
While the TARGET vehicle has been successfully operated in radio control mode over ex-
tended periods, autonomous operation has faced some setbacks as a result of sensor integration
problems. Autonomous operation requires sensor feedback of the vehicle position, heading,
speed, steering angle, brake pressure. Ideally, the accuracy of this sensor-based vehicle infor-
mation is improved using the Kalman Filter (discussed in Chapter 5). However, for the initial
testing of autonomous operation the raw sensor data provides a sucient level of accuracy.
The primary source of vehicle heading is the IMU's magnetometer (see Section 5.4.2). Unfor-
tunately, at this stage the data from this sensor has been unreliable. While accurate heading
information appeared to be obtained in the laboratory and as mounted in the stationary TAR-
GET vehicle, erroneous heading values are produced when the vehicle is in motion. This is
most likely due to some form of magnetic interference and though another onboard mounting
conguration was trialled, the IMU will probably need to be located externally on the vehicle
and away from possible magnetic sources. The IMU problems were rectied after the original
report submission by performing a hard iron calibration with the IMU mounted in the vehicle.
During the calibration process the vehicle was rotated in a 360 degrees circle to determine
the true orientation of the earth's magnetic eld relative to other interfering magnetic elds
around the vehicle.
9.5. State Estimation Results 224
The Hall-eect sensor which provides the primary source of vehicle speed feedback also proved
to be dicult to integrate eectively. After trying multiple CV Joint mounting congurations,
and suering multiple Integrated Circuit (IC) failure on the corresponding electronics board
due to a faulty power supply, a functional conguration was eventually established.
These sensor integration problems, combined with other ongoing issues such as intermittent
power failure, have thus far delayed verication of autonomous operation. However, it is
believed that this can be achieved prior to the Project Exhibition, in which the TARGET
vehicle will be on display together with the other School of Mechanical Engineering nal year
projects. Thus, while the Autonomous Guidance Controller and Mathematical Vehicle Model
(refer to Section 6.2) have been veried in simulation, there has not yet been an opportunity to
acquire 'on-the-road' performance data for these systems. The simulated performance results
for the autonomous system are presented and discussed in Section 6.2.3.2.
9.5 State Estimation Results
The test results, both from simulation and from implementation in the TARGET vehicle, are
presented in this section. Section 9.5.1 uses a simulation to verify the accuracy of the System
Model, Section 9.5.2 describes the accuracy of the GPS Data Decoding Program based on
eld tests, and Section 9.5.3 assesses the accuracy of the Extended Kalman Filter based on
simulation results.
9.5.1 The System Model
The simplest test to determine if the System Model (see Equation (5.20)) is performing as a
real vehicle should, is to set the System Model inputs to constants (i.e. a constant steering
angle and acceleration) and observe a plot of the Easting state against the Northing state.
As the fundamental Equations (5.11) to (5.14) do not allow for sideslip, the observed path
should be circular. However, the resulting path, shown in Figure 9.3, is clearly not circular.
The reason for this unexpected result is unknown. However, it was found by chance that
when the State Transition matrix was changed to that shown in Equation (9.1), the circular
path, shown in Figure 9.4 was achieved.
Φk =
1 0 0 T cos(θk + φk
)0 −T vk sin
(θk + φk
)0 1 0 T sin
(θk + φk
)0 T vk cos
(θk + φk
)0 0 1 T
L tan φk 0 T vkL cos−2 φk
0 0 0 1 T 00 0 0 0 0 00 0 0 0 0 0
(9.1)
225 Chapter 9. Final Testing and Analysis
Figure 9.3: The eect of constant System Model inputs
Figure 9.4: The eect of constant inputs on the modied System Model
Equation 9.1 diers from its parent (Equation 5.20) since two of the elements of the matrix
are set to zero. These elements corresponded to the eect of the vehicle heading on the
East position and the North position. It is reasonably intuitive that non-zero terms for these
elements these might not result in a circular path, however no faults are apparent in the
derivation process and the dening equations are well established, therefore the source of the
error is unknown. Nevertheless, the new State Transition Matrix dened by Equation (9.1),
is to be used henceforth. The remaining states (heading, speed) and input states (forward
acceleration and steering angle) are shown for the same inputs which were used to create
Figure 9.4, in Figures 9.5, 9.6, 9.7 and 9.8 respectively.
9.5. State Estimation Results 226
Figure 9.5: The System Model heading resulting from a constant steering angle and acceler-ation
Figure 9.6: The System Model speed resulting from a constant steering angle and acceleration
With the simulated vehicle moving in circular motion, the plot of the heading state over
time is expected to vary from 0 radians to 2π radians. However, inspection of Figure 9.5,
reveals instead that the heading state increases indenitely over time. This result is due to
the cumulative nature of the System Model, Equation (5.21), which determines the current
227 Chapter 9. Final Testing and Analysis
Figure 9.7: The System Model heading resulting from a constant steering angle and acceler-ation
heading based on the previous heading. To ensure that the Kalman Filter adequately corrects
this state, the apporiate integer multiple of 2π is subtracted or added to the heading so that
the result lies between 0 and 2π. The speed state output from the System Model, shown in
Figure 9.6, increases linearly over time. This is expected for a vehicle moving with constant
acceleration. The simulated vehicle acceleration is shown to be a constant 0.2m/s2 over time
in Figure 9.7, and the simulated vehicle steering angle is shown to be a constant 0.05rad over
time in Figure 9.8. Since these results all appear qualitatively correct, no further modications
to Equation (9.1) are necessary.
9.5.2 GPS Field Tests
The GPS eld test was conducted by running the GPS Data Decoding Program on the
onboard computer with the TARGET vehicle in motion. The vehicle was driven around a
circuit of streets in North Adelaide with a good view of the sky, for GPS visibility. A plot of
the resulting Easting against Northing output data is shown in Figure 9.9. The data contains
no gaps, indicating that there was GPS visibility for the entire time. Furthermore, it can be
seen that the data is very consistent and hence relatively noise free, which was not expected.
The data is in units of metres in a continuous Tangent Plane coordinate system indicating
that the relatively complex conversions are capable of functioning in real-time on the onboard
computer.
9.5. State Estimation Results 228
Figure 9.8: The System Model heading resulting from a constant steering angle and acceler-ation
9.5.3 Kalman Filter Simulation Results
The original intention for this report was to present test results demonstrating the performance
of the Kalman Filter in a eld-type situation. However, due to failure of the IMU at a critical
time in the development of the project, the tests had to be postponed. An Environment
Generator Program was created several weeks before the testing date, to ensure that the
Kalman Filter performed as expected in simulation. The simulated results of the Kalman
Filter when driven by this program are the only results presented in this section. However,
since the Environment Generator program aims to mimic to true sensor outputs, the this
simulation is expected to represent a real scenario to high accuracy.
The Environment Generator Program is contained within a single Embedded MATLAB le,
and is shown to the left of the Kalman Filter in Figure 9.10.
The Environment Generator uses the same Vehicle Model as that developed in Section 5.3;
however process noise (input through the two noise blocks on the far left of Figure 9.10) is
added to all six states. The states are then made to simulate the sensor readings through
the relevant transformations and addition of sensor noise. Both the process noise and sensor
noise properties used in the Environment Generator are listed in Table 9.3. These noise levels
are estimated to be reasonably indicative of the true noise levels in the system.
229 Chapter 9. Final Testing and Analysis
Figure 9.9: GPS data gathered from testing
Since the Environment Generator completely emulates the outputs of all the sensor decoding
programs, GPS dropout may also be simulated simply by setting the GPS error ag output
within the Environment Generator Program. The chosen simulation scenario involves the
vehicle steering angle varying sinusoidally from an angle of 10 degrees to the left to an angle
of 10 degrees to the right. The acceleration is set to 1m/s2 for a period of 14 seconds after
which it is set to zero, corresponding to a speed change of aproximately 50km/hr. The vehicle
states are initialised to zero and the length of simulation is 30 seconds.
Figure 9.11(a) shows a plot of the GPS sensor data in the given area over time. The Y axis
corresponds to Northing and the X axis corresponds to the Easting. Figure 9.11(b) shows the
estimated path output from the Kalman lter. Clearly the estimated path is far less noisy
than the GPS data which is extremely noisy (in fact it is more noisy than the true data given
in Section 9.5.2). However, since the GPS unit outputs a measure of its own error (in the
form of a standard deviation) this should not be a problem when the Kalman Filter is fed
with data from the actual hardware.
The simulated variation in standard deviation of the GPS position is shown in Figure 9.12.
The vertical axis has units of metres and the horizontal axis has units of time (in seconds).
Simulated results from the hall eect sensor speed are given in Figure 9.13(a). The data has
been zeroed and scaled to units of kilometres per hour (in the vertical axis) and the units are
time (in seconds) on the horizontal axis. Figure 9.13(b) shows the Kalman Filter estimate
9.5. State Estimation Results 230
Table 9.3: Properties of the Environment Generator ProgramProperty Name Property Symbol Allocated Value Property Units
Process noise forwardacceleration standard
deviation
σx 0.01 m/s2
Process noise steering anglestandard deviation
σφ 0.001 rad
Process noise headingstandard deviation
σθ 4e-6 rad
Process noise speed standarddeviation
σv 0.001 m/s
Process noise Eastingstandard deviation
σE 1e-6 m
Process noise Northingstandard deviation
σN 1e-6 m
IMU forward accelerationstandard deviation
σxIMU 0.1 m/s2
IMU lateral accelerationstandard deviation
σyIMU 0.1 m/s2
IMU yaw standard deviation σθIMU2 deg
IMU yaw rate standarddeviation
σθIMU0.1 rad/s
GPS Northing standarddeviation
σNGPS(1.2, 1.8) m
GPS Easting standarddeviation
σEGPS(1.2, 1.8) m
GPS Northing rate standarddeviation
σNGPS(0, 0.06) m
GPS Easting rate standarddeviation
σEGPS(0, 0.06) m
Hall-Eect Sensor speedstandard deviation
σvHall0.1 km/hr
Potentiometer steering anglestandard deviation
σφpot 0.5 deg
of the speed in metres per second over the same time period. Clearly the noise has been
reduced, however the accuracy of the speed (which should ramp up to a given constant) has
been degraded. This is likely to be due to the eect of the GPS velocity corrections, which are
very noisy, on the estimated speed. A possible solution to this problem is to trick the Kalman
Filter into giving less credibility to the speed corrections by the GPS sensor. This may be
acheived by multiplying the standard deviations of the GPS velocity by constant values so
that they are seen by the Kalman Filter to be larger than is truely the case.
Figure 9.14(a) shows the heading reading from the IMU and Figure 9.14(b) shows the esti-
mated heading output from the Kalman Filter. In this case the estimated value appears to
be far less noisy then the pure sensor reading, whilst not incurring any noticeable error on
the heading. The vertical axis has units of radians and the horizontal axis has units of time.
231 Chapter 9. Final Testing and Analysis
Figure 9.15(a) shows the simulated forward acceleration output straight from the IMU. The
vertical axis has units of metres per second and the horizontal axis has units of seconds.
Figure 9.15(b) shows the forward acceleration output from the Kalman Filter. Note that the
noise in (b) appears larger since the scaling on the vertical axes is dierent, in actuality the
magnitudes are identical. Note also that although the forward acceleration emerges from the
Kalman Filter this value is not actually modied during the state estimation process. This
is because the forward acceleration is simply an input to the system model, rather than a
quantity which is to be updated from sensors.
The lateral acceleration of the IMU of the specied trajectory is shown in Figure 9.16. The
Kalman Filter does not estimate this quantity, therefore no estimation exists for this sensor
state.
The IMU yaw rate is shown in Figure 9.17. As with the lateral acceleration there is no
corresponding state estimate of the yaw rate. The gure is simply included to indicate the
level of noise present in the signals input into the Kalman Filter.
Finally the simulated steering angle from the potentiometer is given in Figure 9.18(a). The
steering angle output from the Kalman Filter is shown in Figure 9.18. The vertical axis for
both gures has units of radians and the horizontal axes have units of time in seconds. As
specied, the steering angle varies sinusoidally. In a similar manner to the forward accelera-
tion, the steering angle is an input to the Vehicle Model within the Kalman Filter and so is
not modied as a result of passing through the lter structure.
9.6 Phase One Communication
9.6.1 Selection of a Suitable Communication System
The Phase One activity is concerned with establishing a 'drive-by-wire' system to provide the
capacity to manoeuvre the target vehicle using a human-operated remote-control. This task will
require a hand-operated, short range, multichannel radio control (RC) transmitter to translate
remote human inputs of vehicle control commands (heading and speed) to a corresponding
onboard receiver over a one-way radio frequency (RF) communication system. PWM decoders
will be used to enable the onboard processor (necessary for control) to read the incoming com-
mands.
The chosen handheld remote-control was the JR X2720. This controller provides seven fre-
quency channels. As explained in Section 4.3.1, these frequency channels were successfully
used to control speed, steering, ignition and emergency stop activation during the testing
stages. The vehicle transmission was initially to be controlled by one of the frequency chan-
nels on the handheld remote-control. However, due to limitations of the transmitted radio
channels, the control of transmission was moved to the base station's software. A range of
approximately 1.2 kilometres was obtained when the receiver's antenna was placed in the
open.
9.7. Phase Two Communication 232
Table 9.4: RF9256's Diagnostic and Statistics ResultsFrame count 366518 Empty Frames 197
Good packets 10259 Bad packets 0
Lost packets 0 Retries 5
Good headers 17842 Bad Headers 79
Lost frame lock 0 Low RSSI 0
Data Recv 542866 Data Sent 84839
Rx Overows 0 Rx Overruns 0
Tx Overows 0 Busy waits 0
9.7 Phase Two Communication
9.7.1 Selection of a Suitable Communication System
The Phase Two communication system will support two-way communication between the ve-
hicle's onboard processor and the remote base station computer allowing waypoint position
commands to be sent to the vehicle and vehicle status information to be received by the remote
base station for visual display and monitoring. High speed data transfers over an approximate
range of ten kilometres and at an adequate bandwidth would be desirable for this purpose.
Two-way communication between the TARGET vehicle and the base station was successfully
achieved using the two RFI-9256 radio modems. The RFI-9256 radio modems operated with
maximum high-speed data transfers of 115.2 kbps at the modem-to-computer interface as
well as 'over-the-air'. During testing, the radio diagnostic and statistics were recorded and
are shown in Table 9.4. It can be concluded that the modems performed well because there
were no bad data packets or lost data packets during data transmission. A worst-case-scenario
range test was conducted in Adelaide City and yielded a range of approximately 1.5 km.
9.8 GUI
In the initial project contract there were four separate and specic goals set out for the GUI.
These goals ranged from establishing communication with the vehicle processor, to displaying
an on-screen map showing all waypoints. Over the duration of the project the goals have been
studied and the base station software tailored to meet or exceed these goals. Testing of these
goals has been carried out both in laboratory and real-world testing procedures.
9.8.1 Two-Way Communication
Commands to all actuators should be tested, although the vehicle will not be running at this
early stage. Known data will be sent from the vehicle's on board processor to the base-station
233 Chapter 9. Final Testing and Analysis
computer and the accuracy then veried. The accuracy of the data sent from the base-station
to the on board processor will also be tested.
Data has been successfully transmitted to and received from the onboard computer. The
accuracy of data sent has been veried correct to at least 17 signicant gures. Data received
from the onboard computer has been successfully logged at 2Hz.
9.8.2 Creation of a Simplified User Interface
This interface should simply require the user to provide a list of GPS waypoints, at the base
station computer, which will then be transmitted to the vehicle. Vehicle information (including
speed, heading and position) should also be fed back and displayed at the base station.
A simplied user interface was the rst project goal to be achieved. The components created
in this simplied user interface remain as integral components of the nal software package. A
list function has been created to display the path of waypoints in text form. Waypoints could
be added and removed from this list through simple mouse and keyboard commands. Serial
communication was established and display dials were constructed to display information that
was being received.
9.8.3 Upgrade to a Graphical User Interface
The GUI should consist of a graphical representation of the path to be taken by the vehicle (i.e.
a map displaying all waypoints). The position of the vehicle on this map should be displayed at
the highest attainable refresh rate (depending on the hardware available) using the information
relayed back from the vehicle. The remaining vehicle states should be displayed on the GUI.
The simplied user interface was extended to include a dynamic map overlay of the vehicle and
its surroundings. Functions were added to facilitate adding, editing and deleting waypoints
from the map area. Additional checks and failsafe mechanisms were also added to enhance
the reliability an overall functionality of the package. Figures 9.19 and 9.20 show the vehicle,
its logged path and its surroundings during the rst test day. The buildings in Figure 9.19
are temporary and were not at this location on the test day.
9.8. GUI 234
Figure 9.10: The Environment Generator Program interfacing with the Kalman Filter
235 Chapter 9. Final Testing and Analysis
(a) Simulated GPS position
(b) Estimated Position
Figure 9.11: Simulated position results
9.8. GUI 236
Figure 9.12: Simulated GPS standard deviation over time
237 Chapter 9. Final Testing and Analysis
(a) Hall-Eect Sensor speed
(b) Estimated speed
Figure 9.13: Simulated speed results
9.8. GUI 238
(a) IMU heading
(b) Estimated heading
Figure 9.14: Simulated heading results
(a) IMU forward acceleration (b) Estimated forward acceleration
Figure 9.15: Simulated acceleration results
239 Chapter 9. Final Testing and Analysis
Figure 9.16: Simulated IMU lateral acceleration
Figure 9.17: Simulated IMU yaw rate
9.8. GUI 240
(a) Potentiometer steering angle
(b) Estimated steering angle
Figure 9.18: Simulated potentiometer steering angle results
241 Chapter 9. Final Testing and Analysis
Figure 9.19: Logged path from the rst test day
Figure 9.20: The logged path from the second run of the test day
9.8. GUI 242
Chapter 10
Conclusion
In conclusion, this report has described the development, from concept to realisation, of a
full-scale autonomous ground target vehicle by a team of nine Undergraduate Mechatronic
and Mechanical Engineering students in their nal year of Bachelor study at The University of
Adelaide in South Australia. The integrated vehicle system, known as the Thales Autonomous
Radio-controlled Ground-basEd Target or its corresponding acronym, The TARGET, was de-
signed to provide a safe unmanned moving ground target for an Unmanned Aerial Vehicle
(UAV) project being undertaken by the international defence corporation, Thales Australia.
The TARGET project was therefore dened around the key objective of developing a safe
ground target vehicle system that was capable of switching between normal human driving,
remote control and autonomous control modes of operation.
The report has detailed the TARGET vehicle design with specic reference to the primary
systems of Actuation, Radio Frequency (RF) Communications, State Measurement and Es-
timation, Onboard Computer Systems, Autonomous Guidance Control, Motion Execution
Control, Base Station and Graphical User Interface (GUI), and Safety. The scale and com-
plexity of this project was substantial for a nal year Undergraduate Engineering project in
the time-frame of a single year and an allocation of only a third of the total nal year educa-
tional workload for students. Nevertheless, despite a myriad of unforeseen challenges and an
ambitious project contract of agreed goals and specications, the TARGET vehicle project
has achieved some impressive results. In summary, these outcomes include:
• Developing a full-scale moving ground target vehicle system capable of switching be-
tween normal human driving, remote control and autonomous control modes of opera-
tion although at this stage only normal human driving and remote control operation
have been veried in on-the-road testing;
• Successfully establishing wireless RF communications between the vehicle's onboard
computer and both the base station computer and a handheld radio control transmitter;
243
10.1. Project Goal Completion 244
• Equipping and operating the chosen vehicle (a Mitsubishi Express van) with an auto-
mated system of actuating the vehicle driving controls (steering, throttle, brake, trans-
mission, and ignition) without inhibiting the normal human-driven operation of the
vehicle;
• Developing a dedicated real-time onboard computer system, utilising a rapid control sys-
tem prototyping package called xPC Target, to facilitate and perform top-level control
and interface with the various vehicle actuators and sensors;
• Constructing an Extended Kalman Filter which (at least in simulation) produces im-
proved estimates of the vehicle states (position, speed, and heading) by fusing GPS,
IMU, speedometer, brake pressure transducer, and steering angle potentiometer sensor
data;
• Developing a unique, high precision (according to simulated results), multi-variable
spatial Autonomous Guidance Controller founded on the principles of the Virtual Vehicle
Approach;
• Establishing a PID-based Motion Execution Controller for controlling the vehicle steer-
ing, throttle, and brake actuators;
• Creating and testing a purpose-built GUI for path denition, mode control and teleme-
try;
• Implementing and successfully testing a multifaceted safety system incorporating nu-
merous emergency stop systems, a wide range of automated fault detection and response
mechanisms, and an audio-visual warning system;
• Achieving a fully-equipped TARGET vehicle whilst remaining comfortably within the
allocated project budget.
At this stage, problems related to sensor integration have precluded the full realisation of
autonomous operation. However, it is believed that these diculties can be surmounted in
time to achieve on-the-road testing of autonomous operation prior to the Project Exhibition.
The following section (Section 10.1) details the current level of project goal completion. Fi-
nally, recommendations and future work are presented in Section 10.2.
10.1 Project Goal Completion
Eight of the eleven project goals have been achieved in full to date. The three remaining
goals have been conrmed through extensive simulated testing, but require nal vehicle-based
verication. These goals are expected to be achieved prior to the Project Exhibition, in which
the TARGET vehicle will be put on public display. The completion of the primary project
goals is discussed as follows:
245 Chapter 10. Conclusion
1. Select a suitable vehicle platform
A Mitsubishi Express van was selected as a suitable vehicle platform according to the
criteria described in Section 2.1.1. This van was inexpensive and possesses the desired
features of power steering, automatic transmission, a large visual footprint, large interior
space, the capacity to maintain speeds up to 40 km/h, a turning radius of less than 7.5
metres.
2. Select a suitable onboard vehicle processor
The vehicle's onboard computer is a 2.8 GHz Pentinum 4 desktop PC provided in-kind
by Thales Australia and meets the selection criteria outlined in Section 9.3. This CPU
provides the necessary processing power required for the computationally demanding
real-time execution of the onboard computer program, as discussed in Chapter 6. The
ve PCI slots available on the PC were also essential for integrating the required I/O
hardware that connects to the various vehicle systems. The ethernet card had the
required chipset necessary for xPC Target.
3. Establish an eective automated system of actuating the vehicle driving controls without
interfering with the normal human-driven operation of the vehicle
The vehicle has been equipped with an eective automated system of actuating the
vehicle driving controls. The location and mounting conguration of each actuator has
been carefully selected so as to avoid inhibitting the vehicle's normal human-driven
operation. Actuator cuto relays have been incorporated into the actuator systems in
order to allow a human driver to regain normal manual driving control of the vehicle at
anytime.
4. Establish an eective short range one-way RF communication link between a handheld
radio control transmitter and the vehicle's onboard processor
The handheld RC transmitter has been successfully integrated with the TARGET on-
board computer according to the criteria outlined in Section 2.1.3.
5. Establish an eective two-way RF communication link between the remote base station
computer and the vehicle's onboard processor
The chosen RF modems allow for an eective two way RF communications link between
the base station computer and the TARGET onboard computer. This system meets
criteria listed in Section 2.1.4 which requires that the communications link can be used
for high speed data transfers in both directions over a long range.
6. Derive an accurate mathematical model of the relevant vehicle dynamics
A mathematical vehicle model has been constructed for simulating the autonomous op-
eration of the vehicle prior to its nal integration. This model relates known vehicle
wheel angle and speed inputs to a corresponding vehicle trajectory dened by the in-
stantaneous vehicle position and heading. The mathematical vehicle model that has
been implemented combines two simple models developed by other academics. It is an
10.1. Project Goal Completion 246
intuitive and suciently accuracy model which ignores the eects of Ackerman steering
and wheel slip. Once an reliable source of heading has been established, the accuracy
of the mathematical vehicle model will be quantied by comparing the simulated and
true vehicle trajectories resulting from identical steering angle and speed setpoints.
7. Enable the eective fusion of all available sensor measurements into a single, more
accurate set of 'actual' vehicle states using a Kalman lter / state estimator
An Extended Kalman Filter for estimation of the desired vehicle states has been devel-
oped and extensively simulated. The simulation outputs show that the state estimation
approach is working successfully. However, the Kalman Filter has not yet been im-
plemented onboard the computer due to problems attaining a reliable vehicle heading
reading from the IMU. It is intended to rectify this problem by relocating the IMU.
Successful verication of the Kalman Filter is likely to be achieved in full prior to the
Project Exhibition.
8. Achieve successful remote controlled operation of the TARGET vehicle
The remote controlled operation of the TARGET vehicle has been proven through on-
the-road testing. This testing has involved verication of the appropriate safety re-
sponse for RC communications drop-out and signal ranges and rates exceeding the
acceptable bounds; verication of the desired functionality of all remote controller com-
mands; successful remote control operation at speeds in excess of 40 km/h; the acquisi-
tion of Motion Execution Controller step response data for steering and brake control;
and conrmation of a remote control turning radius less than 7.5 metres.
9. Provide a graphical user interface (GUI) for the visual display and monitoring of vehicle
status at a portable remote base station, and allow the commanding of position waypoints
both 'on-the-y' and as a pre-programmed batch
An eective GUI has been developed for the base station computer using Java. It is
capable of visually displaying feedback of the vehicle's states, logging this data and
switching the vehicle's modes of operation. It also allows the user to create waypoints
and generates suitable paths from these waypoints. These waypoint commands can be
sent on-the-y or through a log le. An eective base station computer and a portable
generator has also been selected to provide power. The GUI has been discussed in detail
in Chapter 7.
10. Achieve successful autonomous control of the target vehicle
The autonomous operation of the TARGET vehicle has been simulated to good eect us-
ing the Autonomous Guidance Controller, a model of the Motion Execution Controller,
and a mathematical model of the relevant vehicle dynamics. On-the-road testing of
the autonomous vehicle has been inhibited by sensor integration problems, such as a
lack of reliable vehicle heading estimates. It is intended to rectify the heading problem
by repositioning the IMU. Successful on-the-road verication of autonomous operation
is likely to be achieved in full prior to the Project Exhibition.
247 Chapter 10. Conclusion
11. Enable intelligent and safe switching between normal human driving, remote control and
autonomous modes of operation
Mode switching between manual human driving, remote control (open and closed loop),
failure mode and autonomous operation has been eectively implemented on the onboard
computer and modes can be easily switched from the base station software. This permits
a human operater at the base station to change between the various modes of operation,
and also recovery from failure mode.
In addition to the primary project goals, the following extension goal has been achieved:
• Investigate the possibility of making the vehicle street legal for normal human driving.
The actuators do not interefere with the normal human operation of the vehicle. In
order for the vehicle to be street legal and hence obtain registration, Transport SA
required the steering actuator system to be mounted behind the steering column. This
specication arises from the need to avoid interfering with the existing safety collapsing
mechanism of the vehicle steering column. The actuator design conformed with this
requirement and the TARGET vehicle passed the Transport SA roadworthy test and is
currently registered as street legal vehicle.
10.2 Future Work and Recommendations
As discussed in Section 10.1, the current priority and recommendation is to achieve complete
verication of the three remaining primary project goals by the Project Exhibition:
1. Achieve successful autonomous control of the target vehicle
2. Enable the eective fusion of all available sensor measurements into a single, more
accurate set of 'actual' vehicle states using a Kalman lter / state estimator
3. Derive an accurate mathematical model of the relevant vehicle dynamics
In addition, there are numerous recommendations that could be made regarding modications
to the existing project or advise for similar projects these are described in Sections 10.2.1
to 10.2.6.
10.2.1 xPC Target Computers
Sound generation was not included in the project due to issues involving a lack of available
CPU power, as outlined in Section 6.1.6 and Appendix A.4. A future project could incorporate
10.2. Future Work and Recommendations 248
sound generation by implementing a second on-board computer that is also programmed using
xPC Target. The second computer would have the PCI-6040E analogue I/O card installed
and handle all of the analogue input requirements of the system. Analogue inputs read by
this card would then be passed to the other onboard computer via a RS232 serial link. Thus
with this proposed installation, the second computer would have adequate CPU power to play
sounds using one of the methods described in Appendix A.4.
10.2.2 Pressure Transducer
The use of a pressure transducer to monitor pressure in the brake lines caused problems in
the brake actuation system. The pressure transducer did not provide consistent feedback,
as the pressure values recorded varied, even when the brake was held in a constant position.
Although there was a general pressure range where full brake force and no brake force could
be measured, the performance of the controller was still limited, as the feedback was not
consistent. The pressure transducer also suers from excessive noise, see Figure 6.4.
A possible alternative to the pressure transducer to provide brake feedback was a potentiome-
ter. A potentiometer could be used to sense the position of the brake pedal. Position feedback
from the brake pedal would not represent the amount of force being applied to the brake, but
after performing system identication, it could be determined how far the brake pedal needed
to be moved to apply a required deceleration to the vehicle.
10.2.3 Brake Actuator
The brake actuator used in the TARGET project provided suitable braking actuation of the
vehicle platform. However, a similar linear actuator that could move at a faster rate would
produce a better result. When full brake was applied, the current system encountered an
approximate two second delay between the move-forward command and the actual forward
motion of the actuator. This was because the actuator had to return to its home position
(where no braking force is applied) before the throttle could be actuated. Moving the brake to
its home position from a full brake position took approximately two seconds. A faster actuator
would minimize the amount of time it takes to release the brake, and therefore reduce the
delay before the vehicle begins to move. This would result in a more ecient braking system.
10.2.4 IMU Mounting
The IMU used in the TARGET vehicle was originally mounted on the oor pan inside the
vehicle directly above the rear dierential. However this location resulted in magnetic in-
terference causing unpredictable yaw readings. This problem was resolved by temporarily
relocating the IMU to the top of the vehicle rack. Tests are yet to be performed on this
location to determine the level of magnetic interference; if it is signicant the unit may need
to be relocated again.
249 Chapter 10. Conclusion
10.2.5 Camera System
One extension goal of the project was to incorporate a video camera into the driving position
of the vehicle and have the video streamed back to the base station. This function would allow
the user at the base station to identify obstacles and obtain a more complete picture of the
vehicle's surroundings. However, obtaining the images back to the base station using wireless
communication was dicult as it requires an extensive baud rate that is only available in
'high class' communication equipment. The video camera system could be made feasible if
the video data can be streamed back to the base station via analogue signals. The hardware
required to transmit and receive an analogue signal would have to be purchased separately.
10.2.6 Onboard Power
During the testing of the TARGET vehicle, issues with the onboard power have been encoun-
tered. These issues involve the vehicle batteries running low, which cause a reduction to the
actuation performance. This is mainly due to continuous power consumption by the auxiliary
electronics (see Section 4.8), especially when the engine is not running. This problem had
temporarily been resolved by charging the secondary battery of the vehicle prior to testing.
To provide a long term solution to this problem a larger alternator could be installed into the
vehicle, providing sucient charge to the batteries when the vehicle is running.
10.2.7 Range and Rate Limits
The range and rate limits for various sensor readings have not yet been determined (see
Section 6.1.2.1). This is due to spikes in the readings of all sensors which render the range
limits meaningless, and also due to the fact that the vehicle is still in its commissioning stage.
An early step of any future work should be to remedy the source of the sensor spikes, and
determine the range and rate limits for the input signals.
10.2.8 Future Development
Incorporating obstacle avoidance into the TARGET vehicle is the next major step in the
development of the TARGET vehicle. Using obstacle avoidance means the TARGET could
eventually participate in competition events for autonomous vehicles, such as the DARPA
Grand Challenge.
10.2. Future Work and Recommendations 250
References
Analogue Devices Inc. Single/Dual Axis Accelerometer. Analogue Devices Inc, 0 edition,
2004a.
Analogue Devices Inc. Single Chip Yaw Rate Gyro with Signal Conditioning. Analogue Devices
Inc, 2 edition, 2004b.
D. A. Anisi. Optimal motion control of a ground vehicle. Technical report, FOI Swedish
Defence Research Agency, Stockholm, Jul 2003.
A. Atreya, A. Saxe, B. Collins, B. Cattle, and G. Franken. Prospect Eleven, DARPA Grand
Challenge 2005 Technical Paper, 2005.
Auscruise By Autron. Cruise Control Installation Manual, 2007.
R. Bartels, J. Beatty, and B. Barsky. An introduction to splines for use in computer graphics
and geometric modelling. 1987.
M. J. Barton. Controller development and implementation for path planning and following
in an autonomous urban vehicle. Master's thesis, School of Aerospace, Mechanical and
Mechatronic Engineering, The University of Sydney, Nov 2001. URL http://www.acfr.
usyd.edu.au/projects/research/ute/publication/M.%20Barton%20thesis.pdf.
D. Bevly, J. Gerdes, and B. Parkinson. A new yaw dynamic model for improved high speed
control of a farm tractor. Journal of Dynamic Systems, Measurement, and Control, 124:
659667, 2002.
Bison Gear & Engineering Corp. 2007. URL www.bisongear.com.
J. Brogdon, R. Dunlap, P. Dyson, A. M. de Nicolas, J. M. de Nicolas, J. M. de Nicolas,
D. McCauley, D. Miner, J. O'Quin, S. Polkowski, and J. Roever. Austin robot technology,
inc. darpa grand challenge 2005. Technical report, 2005.
L. Caravita, A. Tsourdos, N. Aouf, B. White, and P. Silson. Control strategies applied
to waypoint navigation and obstacle avoidance guidance. Technical report, Department
251
References 252
of Aerospace, Power & Sensors, Craneld University (Defence College of Management
UK Technology)., 2007. URL http://www.avia-it.com/act/militaravia/eventi_ami/
Militaravia_ami_agg_febb_07/2_CaravitaL_PaperACODS2007.pdf.
C. Carlson. Estimation with Applications for Automobile Dead Reckoning and Control. PhD
thesis, Department of Mechanical Engineering, Stanford University, Apr 2004.
F. Caron, E. Duos, D. Pomorski, and P. Vanheeghe. Gps/imu data fusion using multisensor
kalman ltering: Introduction of contextual aspects. Information Fusion, 7:221230, Sep
2006.
A. Castaño, A. Ollero, B. Vinagre, and Y. Chen. Synthesis of a spatial lookahead path
tracking controller. In 16th IFAC World Congress. IFAC, Praga, Czech Republic, 2004.
P. Coelho and U. Nunes. Path-following control of mobile robots in presence of uncertainties.
IEEE Transaction on Automatic Control, 21:2, 2003.
D. C. Conner. Sensor fusion, navigation, and control of autonomous vehicles. Master's thesis,
Mechanical Engineering, Virginia Polytechnic Institute and State University, 2000.
L. Cordesses, C. Cariou, and M. Berducat. Combine harvester control using real time kine-
matic gps. Precision Agriculture, 2:147161, 2000.
J. Deak, R. Koch, G. Guthmiller, and R. Fontana. Dynamic calculation of the responsivity
of monodomain uxgate magnetometers. IEEE Transactions on Magnetics, Jul 2000.
M. Egerstedt, X. Hu, and A. Stotsky. Control of mobile platforms using a virtual vehicle
approach. IEEE Transaction on Automatic Control, 46:11, 2001.
G. Elkaim, J. Connors, and J. Nagle. The overbot: An o-road autonomous ground vehicle
testbed. Technical report, University of California, Redwood City, 2006.
ETI Systems. MW20 Wirewound Precision Multi-Turn Potentiometer. ETI Systems Inc.,
2006.
Firgelli Automations. Technical report, Firgelli Automations, 2007. URL www.firgelliauto.
com.au.
G. Fraichard. Fuzzy control to drive car-like vehicles. Robotics and Autonomous Systems, 24:
122, 2001.
J. C. Glennon. Thoughts on a new approach for signing roadway curves. Technical report,
John C. Glennon, Chartered, Jan 2003. URL http://www.johncglennon.com/papers.
cfm?PaperID=18.
J. C. Glennon. Calculating critical speed: A motor-vehicle crash reconstruction method
fraught with error. Technical report, John C. Glennon, Chartered, 6917 West 76th Street,
Overland Park, KS 66204, Aug 2006. URL http://www.johncglennon.com/papers.cfm?
PaperID=42.
253 References
S. Golconda. Steering control of a skid-steered autonomous ground vehicle at varying speed.
Technical report, The Center for Advanced Computer Studies, University of Louisiana,
Lafayette, 2005.
E. Harold. The Java Developer's Resource, 2000. URL www.cafeaulait.org/books/jdr/
chapters/01.html. accessed 15th April 2007.
D. Harper, K. Hua, H. Foroosh, Q. Leonessa, D. Harper, R. Pillat, D. Norvell, S. Santiago,
T. Collins, G. Stein, S. Stickler, G. Decker, R. Andres, Y. Shen, H. Chen, and F. Xie.
Technical paper darpa grand challenge 2005 team university of california. Technical report,
Team University of California, 2006.
J. B. Herrington. Uniform Framework for GPS/IMU Integration using Kalman Filtering. PhD
thesis, Department of Aeronautics and Astronautics, Naval Postgraduate School, Monterey,
California, Jan 1995.
M. Holden. Low-cost autonomous vehicles using just gps. In Proceedings of the American
Society for Engineering Education Annual Conference and Exposition. American Society
for Engineering Education, 2004.
Honeywell. Honeywell sensing and control GT1 series. Honeywell, 1 edition, 2006.
M. Horvat. Standard for Binary Floating Decimal Point ANSI/IEEE 745. IEEE, 1985.
N. Inc. OEM4 User Manual - Volume 2 Command Log Reference. NovAtel Inc, 12 edition,
2003.
P. Ioannou and Z. Xu. Throttle and brake control systems for automatic vehicle following.
California PATH Program, Institute of Transportation Studies, 1:1 to 32, 1994.
Jaycar Electronics. 2007. URL www.jaycar.com.au.
S. Julier and U. JK. A new extension of the kalman lter to nonlinear systems. Techni-
cal report, Oxford, UK, 1997. URL http://www.robots.ox.ac.uk/~cvrg/hilary2003/
Julier1997_SPIE_KF.pdf.
A. Kelly. A feedforward control approach to the local navigation problem for autonomous
vehicles. Technical report, The Robotics Institute, Carnegie Mellon University, Pittsburgh,
1994a.
A. Kelly. A 3d state space formulation of a navigation kalman lter for autonomous vehicles.
Technical report, The Robotics Institute, Carnegie Mellon University, Pittsburgh, may
1994b.
A. Kelly. Modern innertial and satelite navigation systems. Technical report, The Robotics
Institute, Carnegie Mellon University, Pittsburgh, may 1994c.
K. Kodagoda, W. Wijesoma, and E. Teoh. Fuzzy speed and steering control of an agv. IEEE
Transactions on Control Systems Technology, 10(1):112 to 120, 2002.
References 254
E. Kreyszig. Advanced Engineering Mathematics. John Wiley & Sons, Inc., 8 edition, 1999.
Y. Kwon, S. Lee, and K. Yi. An investigation of intelligent cruise control laws for passen-
ger vehicles. Proceedings of the Institution of Mechanical Engineers, Part D: Journal of
Automotive Engineering, 215:159 to 169, 2001.
T. Lu. Robotics m lecture notes. Faculty of Engineering, Computer & Mathematical Sciences
School of Mechanical Engineering University of Adelaide, Australia, 2007.
F. Matia, A. Jimenez, B. Al-Hadithi, D. Rodriguez-Losada, and R. Galan. The
fuzzy kalman lter: State estimation using possibilistic techniques. Techni-
cal report, may 2006. URL http://www.sciencedirect.com/science?_ob=
MImg&_imagekey=B6V05-4K4WG2S-1-1&_cdi=5637&_user=162644&_orig=search&_
coverDate=08%2F16%2F2006&_sk=998429983&view=c&wchp=dGLbVtb-zSkWW&md5=
ae2c73357b90686c9eb4cdcb392be9de&ie=/sdarticle.pdf.
Maxstream Inc. Choosing a Radio Modem, 2007. URL www.maxstream.net/wireless/
find-rf-solution.php?p=900-MHz-and-24-GHz-Solutions. accessed 4 October 2007.
MicroStrain. Technical Product Overview of the 3DM-GX1 Gyro Enhanced Orientation Sen-
sor. Microstrain Inc., 2006.
H. Mörtberg. Control and dynamic modelling of an autonomous ground vehicle. Technical
report, FOI Swedish Defence Research Agency, Sweden, 2006.
W. Naeem, R. Sutton, and S. Ahmad. Lqg/ltr control of an autonomous underwater vehicle
using a hybrid guidance law. Technical report, IFAC, 2003.
L. Nagrath. Router Vs Modem, 2007. accessed on 28 September 2007, available from
<http://bsnldataonerocks.blogspot.com/2007/07/router-vs-modem.html>.
Northwestern University Mechatronics Wiki. Creating an xpc ash boot disk, 2007. URL
hades.mech.northwestern.edu/wiki/index.php/Creating_an_xPC_Flash_Boot_Disk.
T. U. S. D. of Defence. Global positioning system standard positioning service signal specica-
tion. Technical report, Jun 1995. URL http://www.navcen.uscg.gov/pubs/gps/sigspec/
gpssps1.pdf.
H. Qiu and Q. Zhang. Feedforward plus proportional integral derivative controller for an
oroad vehicle electrohydraulic steering system. Journal of Automobile Engineering, 217:
375 to 382, 2003.
S. Rezaei and S. R. Kalman lter based integration of dgps and vehicle sensors for localization.
Technical report, Department of Civil Engineering, University of California at Berkeley,
2003.
RF Innovations Ltd Pty. Rf modem applications. available from
<www.rnnovations.com.au>, 2007. accessed 15 May 2007.
255 References
RF Innovations Pty Ltd. RFI-9256 Radio Modem User Manual. RF Innovations 22 Boulder Rd
Malaga, WA Australia 6090, 4.0 edition, 2006. available from <www.rnnovations.com.au>.
Roboteq. 2007. URL www.roboteq.com/ax1500-folder.html.
P. Rother. PCM or PPM 'Possibilities, Performances', 2007. accessed 15 May 2007, available
from <www.aerodesign.de/peter/2000/PCM/PCM_PPM_eng.html>.
R. Sharp and V. Valtetsiotis. Optimal preview car steering control. In Selected papers from the
20th International Congress of Theoretical and Applied Mechanics, pages 101117. ICTAM,
Chicago, 2001.
R. Sharp, D. Casanova, and P. Symonds. A mathematical model for driver steering control,
with design, tuning and performance results. Vehicle System Dynamics, 33:289326, 2000.
H. Spath. Spline algorithms for curves and surfaces. Utilitas Mathematics Publishing Incor-
porated, 1974.
D. Sunday. About lines and distance of a point to a line (2d & 3d). Technical report, softSurfer,
2006. URL http://www.softsurfer.com/Archive/algorithm_0102.
J. Suárez, B. Vinagre, and Y. Chen. Spatial path tracking of an autonomous industrial vehicle
using fractional order controllers. In Proceeding of ICAR 2003, pages 405410, Portugal,
2003. The 11th International Conference on Advanced Robotics.
J. Switkes and J. Gerdes. Guaranteeing lanekeeping performance with tire saturation using
numerically computed polynomial lyapunov functions. In Proceedings of the 2005 ASME
IMECE, pages 110, Orlando, Florida, USA, 2005. ASME International Mechanical Engi-
neering Congress and Exposition.
S. Thrun, M. Montemerlo, H. Dahlkamp, D. Stavens, A. Aron, J. Diebel, P. Fong, J. Gale,
M. Halpenny, G. Homann, K. Lau, C. Oakley, M. Palatucci, V. Pratt, P. Stang, S. Ro-
hband, C. Dupont, L. Jendrossek, C. Koelen, C. Markey, C. Rummel, J. van Niekerk,
E. Jensen, P. Alessandrini, G. Bradski, B. Davies, S. Ettinger, A. Kaehler, A. Nean, and
P. Mahoney. Stanley: The robot that won the darpa grand challenge. Journal of Field
Robotics, 23(9):661692, 2006.
C. Verplaetse. Inertial proprioceptive devices: Self-motion-snening toys and tools. IBM
Systems Journal, 35:639650, 1996. URL https://www.research.ibm.com/journal/sj/
353/sectione/verplaetse.html.
M. Vest. DARPA Grand Challenge 2005 Technical Paper for Flying Fox, 2005.
G. Welch and G. Bishop. An Introduction to the Kalman Filter. ACM, 2001.
J. Wit, C. Crane, and D. Armstrong. Autonomous ground vehicle path tracking. Journal of
Robotic Systems, 21:8, 2004.
G. Xu. GPS: Theory, Algorythms and Applications. Springer, 2003.
References 256
L. Zhao, W. Ochieng, M. Quddus, and R. Noland. An extended kalman lter algorithm
for integrating gps and low cost dead reckoning system data for vehicle performance and
emissions monitoring. The Journal of Navigation, 56:257275, 2003.
Appendix A
Using xPC Target
MathWorks xPC Target is a software package that allows you to run Simulink models in real
time with real input and output signals. Models are written on a host computer (any PC
with the software installed) and run on a target computer. While xPC Target provides the
user excellent capabilities for the rapid development of control systems, there are many quirks
and a few bugs that can make using the environment dicult at rst. This appendix aims
to provide a reference for future users of xPC Target on how to get started, and avoid issues
that were encountered as part of this project.
A.1 Hardware Setup
The rst step of using xPC Target is to set up the target computer. The computer itself, I/O
cards, communications method, and hard drive will need to be considered.
A.1.1 I/O Cards
The target computer needs to contain I/O cards to interface the system to the outside world.
These cards must be supported by xPC Target; the list of supported cards is obtainable
from the xPC Target section of the MathWorks website. For analogue I/O, digital I/O, and
counter cards, look at National Instruments and Measurement Computing. These companies
have suppliers in Australia and the cards are relatively cheap. National Instruments cards
are highly recommended for use with xPC Target; three NI cards were used in this project
without causing a single problem. Before purchasing any card, have a look at the Simulink
blocks that interface your model to the cards to make sure you're making the right choice.
For example, Measurement Computing counter cards are cheaper than National Instruments
cards, but if you're buying the card to decode a PWM signal, the Measurement Computing
cards use two counters per signal, and are therefore the more expensive option. Some cards
listed on the MathWorks website as being supported actually have no Simulink blocks, and
257
A.2. Getting Started 258
are therefore not actually supported. In addition to analogue, digital, and counter cards,
RS232 communications are commonly necessary, note that xPC Target supports the RS232
ports already on the target computer.
A.1.2 Computer
The target computer itself can be chosen from several form factors, including PCI, compact-
PCI, and PC104. PCI is the least rugged of the form factors, but has the highest number
of supported I/O cards, and is probably the cheapest and easiest. The computer itself must
have an Intel or AMD 32-bit processor, in this project the target computer was a Pentium 4.
A.1.3 Communications
The target computer connects to the host computer via either RS232 or TCP/IP. In the case
of RS232, simply connect the host computer to a serial port on the target with a null modem
cable. TCP/IP communications requires the target computer to have an Ethernet controller
with a supported chip, the list of supported chips is available on the xPC Target section of the
MathWorks website. For this project an Intel Pro/100 M Ethernet controller was purchased
for the connection. However, the chipset on the motherboard was an Intel 8229, which was
suitable for use with xPC Target.
A.1.4 Hard Drive
xPC Target supports the use of a hard drive formatted in a FAT le system. A hard drive is
optional but very useful. In this project it was used for reading from les for sound generation,
for data logging, and for storing the program when using the xPC Target Embedded option
(all of which are discussed later). MathWorks claim that the FAT32 le system is supported,
but during the project a compact ash card formatted in FAT32 was found to work temper-
amentally. The problem was solved by purchasing a smaller (1GB) compact ash card that
could be formatted in FAT16, and it is uncertain whether the problem was in the ash card
or the xPC Target le system.
A.2 Getting Started
MathWorks provides a tutorial on how to get started using xPC Target, available in the
MATLAB help. Follow this tutorial to learn the basics. When you set up the Simulink
conguration parameters in the xPC Target Application section, you must also uncheck the
entry Limit data points to last: in the Data Import/Export panel. If you have this box
checked and are using a target scope you may get an error at runtime, depending on how many
259 Appendix A. Using xPC Target
samples you are displaying on the scope. There is also a known xPC Target bug in R2007a
that forces you to compile each model twice. If you are using R2007a, download the patch
to x this bug from the MathWorks site http://www.mathworks.com/support/bugreports/
details.html?rp=359545.
A.3 RS232 Serial Communications
xPC Target handles RS232 serial communications in a fashion that is dicult to use at rst,
but very quick and easy to use once you're familiar with it. This section aims to give a
brief explanation of how to use RS232 in xPC Target, and discuss some problems that were
encountered during the project. There are several demos on RS232 communications in the
xPC library, looking at these will be very helpful if you are stuck. Note that some of the
demos use a display block to display data, but these blocks will not work with xPC Target.
A.3.1 Hardware
xPC Target supports the serial ports on the target computer (baseboard ports). If your
target computer needs more ports than this, you will need to buy a card. The only supported
RS232 cards are produced by Quatech, and can be purchased from Interworld Electronics www.
ieci.com.au. MathWorks lists the supported cards as the ESC-100 and QSC-100, but these
cards are no longer produced by Quatech - instead you need to purchase an ESCLP-100 or
QSCLP-100. To use one of these cards you will need to install a patch for xPC Target, available
from the Mathworks site http://www.mathworks.com/support/bugreports/details.html?
rp=341814.
A.3.2 Serial blocks
Start by putting a block for your serial device into your model. There are two options, a
FIFO block and a non-FIFO block. The blocks dier in the way in which data is read from
the receive lines. FIFO blocks enable you to search the input for strings with a number of
dierent header strings, while non-FIFO blocks are only useful for reading very simple data
streams.
A.3.3 Sending Data
Sending data is a simple task. To send ASCII strings, connect an ASCII encode block to the
send line of the serial block. To send nothing, connect the send line to a ground block. This
can be used to send a message once - for example, a detect change block and a switch could
be used to let the message through to the send line only when it changes, and otherwise the
send line is connected to ground.
A.4. Sound Generation 260
A.3.4 Receiving Data
Receiving data is handled dierently depending on whether you are using a FIFO or non-FIFO
block. In either case, if you are reading data that is streamed at a regular rate, you must
make sure that you are reading from the serial block at a faster rate than the data is coming
in. If a non-FIFO serial block is being used, the receive line can be connected to an ASCII
decode block to read ASCII strings, or the binary data (in bytes) can be read directly. If a
FIFO block is being used, the receive line must be connected to a FIFO read block. There
are three FIFO read blocks - an ASCII read, binary read, and a simple block for use with
very simple data streams only.
• The FIFO ASCII read block searches the receive buer for strings with specied header
strings (you can enter as many as you like) and a specied terminator string (all strings
you read must have a common terminator). The outputs of this block should be con-
nected to ASCII decode blocks. Note that this block does not behave like a true FIFO,
if more than one string with the same header is present in the buer the newest string
will be read, and the older strings discarded. This means that you will lose data if you
are reading from the FIFO slower than the data is coming in.
• The FIFO binary read block searches for strings with specied headers that are of a
specied length. The output of the block is a vector of bytes. Usually these blocks are
set up to read data with a count byte; in this case the rst byte of the output is a
number indicating how many bytes follow. Again, make sure that you read from the
FIFO at a faster rate than data is entering.
The FIFO serial block has no option to specify the rate at which you read from the buer,
it instead defaults to reading at the base sample rate. This can cause problems in models
with a very high base sample rate, as serial communications is quite CPU intensive. The
problem can be avoided by breaking the link with the block and the library, and specifying
the desired receive rate in the rate transition block immediately after the RCV line (under
the serial block's mask).
A.4 Sound Generation
During the project, two methods of sound generation were developed. Each of the methods
had a limitation that prevented it from being used in the nal version of the program. For
both methods, sounds were recorded as wave les, read using the MATLAB function wavread,
and output onto a DAC driving a speaker.
261 Appendix A. Using xPC Target
A.4.1 Triggered From Workspace Method
This method used a triggered from workspace block to read the sound le. The sound data
(output of the wavread function) must be entered into the workspace before compilation of
the model. The triggered from workspace block is then used to read the data, with a clock
triggering the block at the sample rate of the wave le. This method suers from the limitation
that the sound data is compiled along with the rest of the model. There is a limit on the size
of models of 4MB when using the embedded option, so only a few sounds can be used. There
is also a bug associated with the triggered from workspace blocks, a workaround provided by
MathWorks sta is as follows:
A workaround for you is to disable and break the links for the Triggered Signal from
Workspace blocks. Then right-click and open the Subsystem Parameters for these blocks. For
Real-Time Workshop system code select Function and for Real-Time Workshop function
name options select Use subsystem name".
A.4.2 xPC Target From File Method
This method uses the xPC Target from le block to read the sounds from a le on the
target computer's hard drive. The limitation of this method is that it is prone to causing
CPU overloads. Only eight les can be read using from le blocks, so one le must contain
several sounds. Each sound in the le must be read at each timestep, and the correct sound
selected. This is very CPU intensive and could not be included in our nal program. The
method for creating and reading from les is as follows:
1. Create the le using the xpcbytes2le function. Each sound should be entered as a
separate row (i.e. the sounds should be row vectors). The sounds must all be the same
length, so put zeros at the end of sounds to make them meet a common length.
2. Copy the le to the target PC's hard drive.
3. Put a from le block into your model. Set the block up to have an output port width
of the number or sounds multiplied by 8, assuming sound data is in doubles (MATLAB
default). The sample rate of the block should be the same as the sample rate of the
sounds. You will probably need to increase the disk read size and buer size, depending
on the number of sounds in the le. Change the setting when reaching EOF to be seek
to beginning. Make sure that the name of the sound is entered along with the folder the
sound is in, i.e. if the sound is just on C: and not in a folder, enter C:\SOUND.DAT
(for a le called SOUND.DAT, obviously). If you do not include this information, the
le will not always be able to be read.
4. Unpack the output of the from le block using an unpack block. The output port
dimensions should be a list of 1s the same length as the number of sounds in the le,
A.5. Data Logging 262
i.e. for three sounds enter 1,1,1. Select the output line corresponding to the desired
sound using a multiport switch, with as many inputs as you have sounds.
5. Finally, put the blocks into an enabled subsystem. To play a sound, enable this subsys-
tem for the length of a sound, and select the correct sound using the multiport switch.
A.5 Data Logging
xPC Target File type scopes enable you to create a log of a signal on the target computer's
hard drive. File scopes behave slightly dierently to the other scope types, so are briey
discussed here. The scope can be set up by entering an xPC scope, and setting it to type
'le'. For this scope type, the number of samples option species how many samples you
want to log in total. The output of the scope is a le on the target computer's hard drive.
To read the le rst copy it to the host computer's hard drive, and then read it using the
MATLAB function 'readxpcle'. File type scopes cannot handle more than seven inputs each,
if you have more than this number of inputs your model will either crash or not run at all.
Data logging when in StandAlone mode (when using xPC Target Embedded Option) suers
from a bug where le scopes will not start at run-time. This can be circumvented by setting
the trigger mode to scope triggering, and triggering the scope from another scope somewhere
else in your model that starts at run-time. The scope should be set up to trigger on the rst
sample of the other scope. Make sure the scope is also changed from lazy to commit mode.
A.6 xPC Target Embedded Option
The xPC Target Embedded Option allows you to deploy models as a stand alone system that
does not require a host computer. The program is instead stored on the hard drive of the
target computer, which must be set up to boot to DOS. A rather dicult problem encountered
in this project was setting up a compact ash card to boot to DOS. A walkthrough to set up a
compact ash card in this way can be found online from Northwestern University Mechatronics
Wiki (2007).
A.7 Measurement Computing PCI-CTR05
A Measurement Computing PCI-CTR05 counter board was purchased for use in this project,
but was not actually used due to changed system requirements. While the board was not
actually included in the project, a number of issues were found.
263 Appendix A. Using xPC Target
A.7.1 PWM Outputs
The board cannot produce accurate PWM signals. The output above and below a certain
range latches to fully on or fully o. To attain the highest range of operation, use a much higher
frequency base than is necessary. This problem is especially pronounced at low frequencies,
and it is recommended to control digital output lines if possible, rather than using PWM
outputs.
A.7.2 FM Inputs
The PCI-CTR05 board has a block for reading the frequency of a FM (frequency modulated)
signal. This block was found to use approximately 10% of the CPU power of our Pentium
4 processor at steady state. To give this some perspective, our entire model (including the
FM block) used approximately 20% of the CPU power, and periodically overloaded the CPU.
A highly recommended alternative is to electronically convert the FM signal to an analogue
value.
A.8 Miscellaneous
This section lists problems encountered in xPC Target that have not already been discussed.
• RT bug
If you have a block in your model that is titled 'RT', your model will not compile successfully.
• Detect change blocks
The model created in this project stopped compiling successfully after a certain number of
detect change blocks were included. Fortunately these blocks are not dicult to make using
integer delay blocks, simply compare the current value of the signal to the value at its previous
timestep. This bug occurred for detect change, detect increase, and detect decrease blocks.
• Discrete derivative blocks
Discrete derivative blocks were also found to cause problems. Compilation of our model failed
when a certain conguration of discrete derivative blocks was used, and we suspect it was
an issue involving having two discrete derivatives in a row. Regardless of the cause of the
problem, it was easily xed by replacing the discrete derivative block with a discrete transfer
function block. The transfer function should be (z−1)fs×z , where fs is the sample rate of the
block.
A.8. Miscellaneous 264
• Scopes
xPC Target scopes can accept vector inputs, but will crash the target computer if there are
too many elements in the vector. Host and Target scopes can handle ten inputs per scope,
while File scopes can handle only seven inputs per scope. Normal Simulink scopes in your
model will cause an error in compilation.
• From le blocks
From le blocks have already been discussed in Section A.4.2. When using these blocks, only
eight separate les can be read from. Reading from more than eight les causes your model
to not run. It is suspected that reading more than eight les was also corrupting the les that
were read, but this was never fully ascertained.
Appendix B
Budget
265
269 Appendix B. Budget
270
Appendix C
FMEA
271
299 Appendix C. FMEA
300
Appendix D
Safe Operating Procedure
301
304
Appendix E
System Flow Charts
305
306
307 Appendix E. System Flow Charts
308
Appendix F
CAD Drawings
309
310
311 Appendix F. CAD Drawings
312
313 Appendix F. CAD Drawings
314
315 Appendix F. CAD Drawings
316
317 Appendix F. CAD Drawings
318
319 Appendix F. CAD Drawings
320
321 Appendix F. CAD Drawings
322
323 Appendix F. CAD Drawings
324
Appendix G
Electronic Schematic Diagrams
325
332
Appendix H
Selection of CommunicationHardware
333
337 Appendix H. Selection of Communication Hardware
338
Appendix I
Base Station User Manual
The base station software has been described in very general terms in Chapter 7 and in
Sections 3.7 and 3.8. This appendix has been aimed at providing the user a manual for
the base station. An overall screenshot is shown in Figure I.1 and it shows all the controls
necessary to operate the vehicle at its full potential.
Figure I.1: Screenshot of the base station software showing various dierent components onthe screen
339
I.1. Setting Up the Serial Port 340
I.1 Setting Up the Serial Port
The rst step in controlling the TARGET vehicle is establishing communication. Without
communication with the onboard computer most of the base station software will not function
properly. The base station provides three options when connecting to the onboard computer
(see Figure I.2). The rst two options relate to the serial port where the user can select
the COM port and connection speed. The default speed when connecting to the vehicle is
115200bps. The third option is a small tick box which indicates if the user wants the incoming
data logged. Once all three options have been completed, press the connect button to make
a connection with the vehicle. NOTE: if another application has control of the selected serial
port, the base station software will be unable to connect. If there are any problems try
closing any other applications using the serial port or select a dierent COM port and try to
reconnect.
Figure I.2: The communication panel where the user can select the COM port and speed ofthe serial connection
I.2 Setting the Vehicle Mode
The panel in Figure I.3 is used to manually change the operating mode of the onboard com-
puter on-the-y. To change the operating mode, simply click on the desired mode and a
message is sent to the vehicle. When the vehicle acknowledges the mode has been changed,
the displayed mode will change. When in failure mode, a 'Recover' button has been provided.
The user should press the stop button, then press the recover button to recover the vehicle
from a failure. The recover button will remove any failure mode from the vehicle and return
it to normal operation. The recover button should be used with extreme caution because the
user can potentially override failures that have occurred in the vehicle.
Figure I.3: The vehicle mode panel which is used to change the operating mode of the TAR-GET vehicle
341 Appendix I. Base Station User Manual
I.3 Using the Map Area
The map area has the responsibility of representing the vehicle and its surroundings in a
graphical nature. The map area has many dierent functions that allow the user add, edit
and delete waypoints as well as manipulate and zoom on any path created. Zooming is
achieved by using the zoom panel (see Figure I.4). By default zooming is set to automatic.
Automatic zooming will maintain a central view of all paths and waypoints being displayed
on the screen. The zoom is updated in real time to provide the user with the best possible
view of the environment. Switching to manual zoom mode allows the user to manually zoom
in and out as well as move up, down, left and right.
Figure I.4: The zoom panel which provides tools for zooming the map area
To add a waypoint to the screen area simply click on the desired location. Waypoints can be
deleted by holding shift and clicking on a waypoint. The selected waypoint will be coloured
green and all other waypoints should be coloured red. Waypoints can be moved by clicking
and dragging them across the screen. By using the scroll wheel on the mouse the number of
the selected waypoint can be moved up and down. This is useful when adding waypoints to
the middle of an already established path.
I.4 Logging Data
Data is logged automatically when the 'Log' checkbox is ticked in the communication panel
(see Figure I.2). The relevant data is automatically displayed in the status panel at all times.
I.5 Generating Pictures from the Log File
Graphs of the log le can be generated by using tools in the picture panel (see Figure I.5).
The tools allow the user to select what section of the log le to use. The user can select four
dierent options:
1. Use all data in the log le
I.6. Defining Background Images 342
2. Use a section (from time A to time B) of the log le
3. Use the rst Ams of the log le
4. Use the last Ams of the log le
Figure I.5: The picture panel which allows graphs to be generated from the log le
Once the selection has been made, press the 'Generate Pictures' button and wait for the
images to be created. The images are created and stored in the same directory as the log le
(C:\TARGET\LOG\logname) and can take several minutes to complete depending on the
number of log entries processed.
I.6 Defining Background Images
The user must supply the base station with a compatible picture format (*.jpg or *.png). The
pictures should be placed in C:\TARGET\IMAGES and be accompanied by a conguration
le named cfg.mf. The conguration le denes the coordinate systems of all the pictures
to be included in the background of the base station map area. The conguration le has a
syntax:
lename;latitude;height;longitude;width;
The latitude and longitude represent the location of the top left corner of the image. The
height and width refer to the height and width of the image represented in GPS coordinates.
An example
picture.jpg;-34.71438;-0.0090111;138.59635;0.0147444;
Multiple images can be included by dening each of the individual images on a seperate line.
Appendix J
Manual Labour Hours
Extensive hours and eort have been dedicated to the TARGET vehicle project. This section
summarises the amount of hours spent by the team members as well as the mechanical and
electronic workshop of The University of Adelaide. The recorded hours were then used to
calculate the labour cost of the project using the parameters in Table J.1.
Table J.1: Costing Parameters for labour hoursAnnual Salary $50,000
Hourly Rate (Students) $26
Hourly Rate (Workshop) $50
Direct Costs 30%
Indirect Costs 130%
Table J.2: Total manual labour hours (up to September 30th) and costs per team memberTeam
MemberTotal(hours)
Total(Salary)
Total(Direct)
Total(Indirect)
Total Cost
Cullen 581.5 $14,910 $4,473 $19,383 $38,767
Calvin 221.25 $5,673 $1,702 $7,375 $14,750
Nicholas 561 $14,385 $4,315 $18,700 $37,400
Andrew 481.5 $12,346 $3,704 $16,050 $32,100
Adi 530 $13,590 $4,077 $17,667 $35,333
Philip 400 $10,256 $3,077 $13,333 $26,667
Josiah 490.5 $12,577 $3,773 $16,350 $32,700
Peter 773 $19,821 $5,946 $25,767 $51,533
Joshua 776.78 $19,917 $5,975 $25,893 $51,785
Total 4815.53 $123,475 $37,043 $160,518 $321,035
Combining the hours and costs of both project team members and the workshop yields a total
of 5263.53 hours and $379,275 respectively.
343
344
Table J.3: Total manual labour hours and costs per workshopWorkshop Mechanical Electronic Total
Total (hrs) 204 244 448
Total (Salary) $10,200 $3,660 $22,400
Total (Direct) $3,060 $3,660 $6,720
Total (Indirect) $13,260 $15,860 $29,120
Total Cost $26,520 $31,720 $58,240
Appendix K
Software CD
345