final report - university of adelaidedata.mecheng.adelaide.edu.au/robotics/projects/2007... ·...

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

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


eration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227


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.

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.


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,


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 -


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.


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.


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


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.


(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.


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


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).


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


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


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


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


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


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


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


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,


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).


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).


(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.


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.


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).


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


Figure 3.19: Simulated path following using a feedback controller (sourced from Barton(2001))


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.


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))


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.


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


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.


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.


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)


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.


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


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


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


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


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


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


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


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


• 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


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


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


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


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


(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


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


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


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).


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


(a) Individual components

(b) Assembled components

Figure 4.18: Pictorial representations of individual components and the assembled componentfor brake line modication


(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.


(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


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


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.


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.


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


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


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.


(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


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).


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)


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)


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).


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


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


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)


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


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


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


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


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),


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


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.


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


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.


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


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


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.


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.


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


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


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.


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)


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.



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


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


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.



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


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


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


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



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


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.


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.


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.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.


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


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.


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





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


22

RC receiver Ch.3 rate Sensor reading exceeding desired rate limit

23

RC receiver Ch.4 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.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


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.


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


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


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.


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.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


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.


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.


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.


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


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.


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


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


Figure 6.12: Illustration of the importance of speed guidance control when operating onbounded roads

Figure 6.13: Autonomous controller structure


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)


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


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).


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)


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)


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).


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.


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


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


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


Figure 6.22: Motion Execution Controller model

Figure 6.23: Unit step response of Motion Execution Controller model


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)


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.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


(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


(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


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


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


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)


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)


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.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


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.


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.


Figure 6.35: Closed Loop Brake Controller

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.


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


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.


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


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.


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.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.


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.


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.


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.


• 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


0 0 0 1 T 00 0 0 0 0 00 0 0 0 0 0

(9.1)


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.


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



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.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.


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


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.


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


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


(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


(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


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


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.


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.


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

http://www.acfr.usyd.edu.au/projects/research/ute/publication/M.%20Barton%20thesis.pdf

http://www.acfr.usyd.edu.au/projects/research/ute/publication/M.%20Barton%20thesis.pdf

www.bisongear.com

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.

http://www.avia-it.com/act/militaravia/eventi_ami/Militaravia_ami_agg_febb_07/2_CaravitaL_PaperACODS2007.pdf

http://www.avia-it.com/act/militaravia/eventi_ami/Militaravia_ami_agg_febb_07/2_CaravitaL_PaperACODS2007.pdf

www.firgelliauto.com.au

www.firgelliauto.com.au

http://www.johncglennon.com/papers.cfm?PaperID=18




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.

www.cafeaulait.org/books/jdr/chapters/01.html

www.cafeaulait.org/books/jdr/chapters/01.html

www.jaycar.com.au

http://www.robots.ox.ac.uk/~cvrg/hilary2003/Julier1997_SPIE_KF.pdf

http://www.robots.ox.ac.uk/~cvrg/hilary2003/Julier1997_SPIE_KF.pdf

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.

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




www.maxstream.net/wireless/find-rf-solution.php?p=900-MHz-and-24-GHz-Solutions

www.maxstream.net/wireless/find-rf-solution.php?p=900-MHz-and-24-GHz-Solutions

hades.mech.northwestern.edu/wiki/index.php/Creating_an_xPC_Flash_Boot_Disk

http://www.navcen.uscg.gov/pubs/gps/sigspec/gpssps1.pdf

http://www.navcen.uscg.gov/pubs/gps/sigspec/gpssps1.pdf

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.

www.roboteq.com/ax1500-folder.html

http://www.softsurfer.com/Archive/algorithm_0102

https://www.research.ibm.com/journal/sj/353/sectione/verplaetse.html

https://www.research.ibm.com/journal/sj/353/sectione/verplaetse.html

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.

http://www.mathworks.com/support/bugreports/details.html?rp=359545


www.ieci.com.au

www.ieci.com.au



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.


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.


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

Appendix C

FMEA

271

299 Appendix C. FMEA

Appendix D

Safe Operating Procedure

301

Appendix E

System Flow Charts

305

307 Appendix E. System Flow Charts

Appendix F

CAD Drawings

309

311 Appendix F. CAD Drawings

Appendix G

Electronic Schematic Diagrams

325

Appendix H

Selection of CommunicationHardware

333

337 Appendix H. Selection of Communication Hardware

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

final report - university of adelaidedata.mecheng.adelaide.edu.au/robotics/projects/2007... ·...

Documents