Download Currier_Thesis

Development of an Automotive Ground Vehicle
Platform for Autonomous Urban Operations
Patrick Norman Currier
Thesis submitted to the faculty of the Virginia Polytechnic Institute and State
University in partial fulfillment of the requirements for the degree of
Master of Science
in
Mechanical Engineering
Dr. Charles F. Reinholtz, Co-Chairman
Alumni Distinguished Professor, Virginia Tech
Chair, Mechanical Engineering, Embry Riddle Aeronautical University
Dr. Alfred L. Wicks, Co-Chairman
Associate Professor of Mechanical Engineering
Dr. Dennis W. Hong
Assistant Professor of Mechanical Engineering
April 28, 2008
Blacksburg, Virginia
c
Copyright 2008,
Patrick N. Currier
Development of an Automotive Ground Vehicle Platform for
Autonomous Urban Operations
Patrick N. Currier
ABSTRACT
Autonomous ground vehicle operations, such as those found in the 2007 DARPA Urban Challenge, require a reliable and capable vehicle platform. To meet this requirement,
an autonomous ground vehicle platform based on a 2005 Ford Escape Hybrid was developed for operations in urban environments. The vehicle conversion, dubbed Odin,
contains a drive-by-wire system that is highly integrated with the OEM systems, providing throttle, steering, shifting, and braking actuation. The vehicle also includes a
controller that provides low-level longitudinal using a map-linearized PI controller and
lateral curvature control using a bicycle model. The control algorithms proved capable
of controlling the vehicle at a level acceptable for autonomous operations. Communications are implemented using the Joint Architecture for Unmanned Systems (JAUS) using
custom messages to enhance interoperability potential. The net result is a highly capable
autonomous vehicle platform that was validated when Odin successfully completed the
60 mile Urban Challenge.
This work received support from the Defense Advanced Research Projects Agency, General Dynamics Robotics Systems, Caterpillar, Inc., National Instruments Corporation,
Ford Motor Company, and TORC Technologies, LLC.
Acknowledgments
The Urban Challenge project at Virginia Tech was a team triumph. Team VictorTango
was nearly stillborn more times than I would like to remember, and I was told point-blank
by people in high places that, given the obstacles we faced, we were trying to do the
impossible. They were undoubtably correct, but apparently the impossible is achievable,
because when all was said and done we had been proven to be equal to the best the world
had to offer. The source of this triumph was the team, of which I was a small part.
Despite the endless hours, everyone continued to turn out amazing work, and amazingly
even managed to like each other. This was a team that didn’t need leadership; I have never
worked with a more talented and dedicated group of people, and I doubt that I ever will.
The first acknowledgments therefore have to go to the members of Team VictorTango,
especially the grad students and TORC people who formed the core of the team: Tom
Alberi, Dave Anderson, Andrew Bacha, Cheryl Bauman, Steve Cacciola, Aaron Dalton,
Jesse Farmer, Ruel Faruque, Jesse Hurdus, Peter King, Chris Terwelp, Mike Webster, and
Dave VanCovern. They did more to make this project a success than I ever could have.
I wish I had room to acknowledge the rest of the team members by name, but you know
who you are and your efforts were appreciated.
Next on the list are my advisors, Dr. Charles Reinholtz and Dr. Al Wicks. I really
appreciate the academic a research advice that both of you have provided, but we’ve been
through a lot more than academics over the last three years, and it will be your example
of strength and fortitude that I will remember longest. Thanks also goes to Dr. Hong for
always being there and for making me perform all of the academic niceties that I hate so
much.
And finally, I must thank my family. It is due to you that I grew up thinking that
earning a graduate degree was a normal thing to do. Now that I have done it, I realize that
was crazy, but I still know that you always have been and always will be there for me.
iii
Contents
Chapter 1: Introduction
1.1 Background . . . . . . . .
1.2 Literature Review . . . . .
1.3 Motivation and Objectives
1.4 Overview . . . . . . . . .
.
.
.
.
.
.
.
.
Chapter 2: Hardware Systems
2.1 Ford Escape Hybrid . . . . . .
2.2 Architecture . . . . . . . . . .
2.3 Throttle . . . . . . . . . . . .
2.4 Shifter . . . . . . . . . . . . .
2.5 Steering . . . . . . . . . . . .
2.5.1 Steering Sensor . . . .
2.5.2 Steering Actuation . .
2.6 Brakes . . . . . . . . . . . . .
2.6.1 Electrical Approach .
2.6.2 Actuator Approach . .
2.7 Controller . . . . . . . . . . .
2.7.1 CompactRIO . . . . .
2.7.2 Relay Interface Board
2.8 Accessories . . . . . . . . . .
2.9 Emergency Systems . . . . . .
2.10 Auxiliary Systems . . . . . . .
2.10.1 Power . . . . . . . . .
2.10.2 Wiring . . . . . . . .
2.10.3 Computing . . . . . .
2.10.4 Sensors . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
3
5
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
9
11
13
15
15
18
20
20
21
24
24
26
28
28
30
31
33
34
34
Chapter 3: Control Systems
3.1 Software Overview . .
3.2 Operational Modes . .
3.3 Speed Control . . . . .
3.3.1 Implementation
3.3.2 Test Results . .
3.4 Directional Control . .
3.4.1 Vehicle Model
3.4.2 Implementation
3.4.3 Test Results . .
3.5 Communications . . .
.
.
.
.
.
.
.
.
.
.
36
36
37
37
38
43
45
46
48
49
52
Chapter 4: Conclusions
4.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Recommendations and Future Work . . . . . . . . . . . . . . . . . . . .
53
53
54
References
57
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
List of Figures
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
Ford Escape Hybrid . . . . . . .
Throttle Voltages . . . . . . . .
Shifter Voltages . . . . . . . . .
Installed Steering Sensor . . . .
Steering Torque Sensor Voltages
Brake Actuator Diagram . . . .
Brake Actuator Cutaway . . . .
CompactRIO Controller . . . . .
Relay Interface Board . . . . . .
TORC SafeStop . . . . . . . . .
Power Systems . . . . . . . . .
Computer Systems . . . . . . .
Sensor Suite . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
12
14
16
19
22
23
25
27
30
31
35
35
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
Vehicle Mode Hierarchy . . . .
Speed Control Implementation .
Speed Control Map . . . . . . .
Speed Control Response . . . .
Bicycle Model Representation .
Curvature Response to Speed . .
Effective Understeer Coefficient
Steering Control Response . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
41
42
44
47
49
50
51
4.1
Odin Crossing the Finish . . . . . . . . . . . . . . . . . . . . . . . . . .
55
vi
List of Tables
3.1
JAUS Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
52
Acronyms and Abbreviations
ABS Anti-lock Brake System
BSCM Brake System Control Module
CAN Controller Area Network
COTS Commercial, Off-the-Shelf
CPLD Complex Programmable Logic Devices
CVT Continuously Variable Transmission
DARPA Defense Advanced Research Projects Agency
DAQ Data Acquisition unit
DBW Drive-by-Wire
eCVT Electronic Continuously Variable Transmission
EMC Electronic Mobility Controls, LLC.
EMI Electromagnetic Interference
E-stop Emergency Stop
FESM Ford Escape Service Manual
FPGA Field Programmable Gate Array
GPS Global Positioning System
IMU Inertial Measurement Unit
INS Inertial Navigation System
viii
JAUS Joint Architecture for Unmanned Systems
KVM Keyboard, Video, Mouse
LIDAR Light Detecting and Ranging
MOSFET MetalOxideSemiconductor Field-Effect Transistor
NI National Instruments
NiMH Nickel Metal Hydride
NQE National Qualifying Event
OEM Original Equipment Manufacturer
OP-AMP Operational Amplifier
PCB Printed Circuit Boards
PCM Powertrain Control Module
PID Proportional Integral Differential
PSCM Power Steering Control Module
RIB Relay Interface Board
RNDF Route Network Definition File
SpAM Speed-based Acceleration Maps
SUV Sport Utility Vehicle
UAV Unmanned Aerial Vehicles
UDP User Datagram Protocol
UGV Unmanned Ground Vehicles
UPS Uninterruptable Power Supply
VI Virtual Instrument
VTUC Victor Tango Urban Challenge
ix
Chapter 1
Introduction
Autonomous vehicle technology is a rapidly evolving field and the subject of a large
number of research programs around the world. Autonomy holds the promise of enabling
unmanned vehicles to perform tasks that are undesirable to humans due to either the
tedious nature or the dangerous conditions involved.
1.1
Background
Until recently, military environments have been the primary habitat of autonomous systems. Many military operations, such as driving convoys along unsecured roads, expose
vehicle operators to high risk situations in order to accomplish relatively simple tasks.
The need for unmanned systems is such that US Congress has mandated that:
“It shall be a goal of the Armed Forces to achieve the fielding of unmanned,
remotely controlled technology such that by 2015, one-third of the opera1
1.1. BACKGROUND
CHAPTER 1. INTRODUCTION
tional ground combat vehicles of the Armed Forces are unmanned.” [1]
Autonomy is an obvious solution, but the technology has not yet been up to the challenges
posed.
The civilian world also poses less acknowledged but equally important problems that
appear to be excellent places for application of autonomous technologies. Autonomy may
be able to improve efficiency on congested highways, reduce accidents, and ultimately
make the roads safer for human passengers by eventually supplanting human drivers entirely. Although it may be some time before fully autonomous vehicles enter the civilian
market, derivatives of the technology are already appearing. Systems such as active cruise
control, lane departure warning, and automatic parking are available now as driver aids
and use sensor and processing technology to improve road safety.
The promise of autonomy has begun to be fulfilled in the air as Unmanned Aerial
Vehicles (UAV) rapidly increase in capability, especially in military environments. Unmanned
Ground Vehicles (UGV) have, however, tended to lag behind their aerial brethren due to
the greater complexities of the environment in which they operate. The single largest
effort to push the advancement of UGV technology over the last half-decade has been
the Defense Advanced Research Projects Agency (DARPA) Grand Challenge series. The
Grand Challenges were posed as competitions open to any organization that was willing to attempt to achieve their ambitious goals and were highly successful at mobilizing
highly motivated teams of researchers to devote their efforts to the development of UGV
technology.
The first two Grand Challenges focused on off-road driving as the vehicles were tasked
to complete a 130-140 mile desert course. The desert courses featured only static obstacles and were a test of the vehicle’s abilities to navigate and drive for long distances. The
first challenge, held in March 2004, showed that the vehicles were not prepared as every
vehicle had suffered a failure before the eight mile mark. The second challenge, held in
2
1.2. LITERATURE REVIEW
CHAPTER 1. INTRODUCTION
November 2005, was contested by a much improved cast of vehicles. Twenty-three vehicles were able to qualify for the final event and five vehicles successfully completed the
130+ mile course.
The next challenge was the DARPA Urban Challenge, held in November 2007. The
Urban Challenge moved the competition to a city environment. This time the vehicles
would have to deal with moving traffic and follow the rules of the road. The goal was
to complete a 60 mile course in less than six hours. Thirty-five teams qualified for the
National Qualification Event, but only 11 were deemed safe enough to compete in the final. Those 11 vehicles along with approximately 30 human driven vehicles were released
onto a suburban closed course in Victorville, CA. Six vehicles managed to complete the
course, four of them without committing any serious traffic violations, proving that UGV
technology had advanced to the point where urban navigation is feasible.
To compete in the Urban Challenge, Virginia Tech and TORC Technologies, LLC.,
formed team VictorTango. The team developed Odin, a modified Ford Escape in a little
more than one year to compete in the challenge. Odin was equipped with the necessities
for autonomous operations: Drive-by-Wire (DBW) systems, sensors, computers, and advanced software modules. The detailed description of the solution to the complete Urban
Challenge problem is so large as to be beyond the scope of any one paper. The goal of
this work is to outline in detail the development and validation of the vehicle platform
that formed the basis for Odin.
1.2
Literature Review
The literature contains a number of examples of autonomous ground vehicle platforms
that have been developed. Particularly prominent are those developed for the DARPA
challenges. Actuation and control approaches vary, but most systems involved adding
3
1.2. LITERATURE REVIEW
CHAPTER 1. INTRODUCTION
actuators to each system to achieve the basic requirements for DBW control. Basic requirements for DBW control are discussed by Bertoluzzo and require control methods
for throttle, brake, steering, and shifting systems [2]. Some groups, such as the Grey
Team, chose commercial products such as the AEVIT system to enable rapid conversion and ensure reliability [3]. Others, particularly those who had Original Equipment
Manufacturer (OEM) support, were able to control systems such as throttle and braking through use of the integrated controls while adding actuators to steering and shifting
controls [4] [5]. Other organizations, including Red Team, Autonosys, and Autonomous
Vehicle Systems, chose to implement fully custom actuator based solutions [6] [7] [8].
A variety of approaches have been applied for longitudinal and lateral control of autonomous ground vehicles. Urmson, et al. implemented a proportional derivative based
longitudinal speed control algorithm on Sandstorm with good results [9]. This approach
operated on the assumption that the correct operating point for the throttle or brake would
likely be near the current and used the controller to generate a relative motion [9]. This
approach was capable of maintaining speed within 0.5 m/s, but suffered from a 0.1 Hz oscillation [9]. T.A. Johansen developed an off-equilibrium based gain-scheduled approach
to vehicle speed control. This approach used gain scheduling to account for the variation
in dynamic response of the vehicle, yielding acceptable results for speed throttle only
control of a large truck [10]. Popular methods of lateral control tend to use a two-degree
of freedom bicycle model to represent the vehicle dynamics as shown by Fenton, Feng,
and Sotelo [11] [12] [13].
One particularly relevant paper discusses the conversion and state estimation of a
Ford Escape for the DARPA Urban Challenge [14]. The team at Princeton converted
the vehicle for autonomous operations by electronically controlling the throttle, brake,
and steering systems while adding a servo motor to the shifter [14]. Proportional Integral
Differential (PID) controls were used to control the speed and steering actuation. Per-
4
1.3. MOTIVATION AND OBJECTIVES
CHAPTER 1. INTRODUCTION
sonal communication with members of the Princeton team have revealed, however, that
the electronic control of the braking system was never reliable and that they are planning
to switch to mechanical control [15]. Interestingly, Franken and Glass find that a similarity based vehicle model predicts the curvature response of the vehicle better than the
standard bicycle model [14].
1.3
Motivation and Objectives
Autonomy is at heart a software and sensing domain. However without a reliable hardware platform, the best software in the world is only good in simulation. Autonomy
cannot be created by hardware, but it can be lost by it. The goal of this research is to
create a highly integrated, flexible, and reliable autonomous ground vehicle platform capable of operating in an urban environment. The vehicle platform should be a standalone
capable of operating safely across the range of conditions common to the environment.
To enhance real-world usability, it is also desired that the conversion for autonomy have
minimal impact on the passenger and cargo capacity; it should also be easily convertible to human operation. Once developed such a platform provides the essential base
for developments in autonomous capability, particularly in this case the DARPA Urban
Challenge.
1.4
Overview
Conversion of a stock vehicle for autonomous operations requires installation of a DBW
system to enable computer control, power systems for the sensors and computers, and a
vast amount of wiring to connect all of the systems. In most vehicles, a DBW conversion requires the addition of a large number of actuators. Due to the advanced nature of
the Ford Escape Hybrid, the DBW conversion was completed with the addition of only a
5
1.4. OVERVIEW
CHAPTER 1. INTRODUCTION
single actuator. The rest of the systems controlled by tapping into the OEM systems electrically. Power for the sensing and computing systems was drawn from the Hybrid power
system, providing a huge amount of available power with no mechanical modifications.
The power is stepped down to usable levels using a DC-DC converter and is converted
to AC and backed up by an Uninterruptable Power Supply (UPS). The wiring to control
all of these systems was minimized by heavy use of digital communications, but still required half a mile of wiring to be installed. This wiring, along with the DBW system, was
concealed under the floor of the vehicle, protecting it and maintaining the stock look and
usability of the vehicle. The end result is Odin, a reliable, high performance autonomous
ground vehicle platform.
6
Chapter 2
Hardware Systems
2.1
Ford Escape Hybrid
The base platform chosen for Odin is a 2005 Ford Escape Hybrid (Figure 2.1). This
platform was chosen in part due to a generous donation from Ford Motor Company of two
vehicles to Virginia Tech, but it proved to be an excellent selection. The Escape Hybrid
contains a large amount of advanced automotive technology that eases the conversion to
an autonomous vehicle in a package that provides reasonable dynamic performance.
At its core, the Ford Escape is a compact, unibody Sport Utility Vehicle (SUV) that
features a four-wheel independent suspension, front or four-wheel drive, car-like handling
characteristics and space for 5 passengers and cargo. The Escape Hybrid is parallel hybrid
that is propelled by a 2.3L 100kW Atkinson-cycle four-cylinder gasoline engine coupled
to a 70kW electric motor and a 36kW generator through a proprietary transmission known
as an Electronic Continuously Variable Transmission (eCVT). The eCVT system uses a
7
2.1. FORD ESCAPE HYBRID
CHAPTER 2. HARDWARE SYSTEMS
single planetary gear set with each of the main components coupled to a part of the gear
set to enable forward drive one either gas power, electric power, or a combination of
gas and electric power. The system, which is similar to but developed independently of
Toyota’s hybrid system, can also use the engine, motor, and generator to vary the effective
gear ratios for each of the components and to regulate the power flow to the wheels and
the battery storage system. One unique feature of the system is that the vehicle can travel
in reverse only on electric power.
Figure 2.1: 2005 Ford Escape Hybrid [16]
The high-voltage electrical system is built around a 330V, 5.5Ah Nickel Metal Hydride
(NiMH) battery pack located under the rear cargo floor. This battery pack is used to store
power from the regenerative braking system and to provide propulsive power when required. The high-voltage system is also used to charge the standard 12V accessory battery through a liquid-cooled, underhood, 90amp DC-DC converter. The 12V bus is used
to power all of the standard automotive accessories, such as lights, signals, and windshield
wipers. Due to the inherent danger of high-voltage DC power, the high-voltage system
8
2.2. ARCHITECTURE
CHAPTER 2. HARDWARE SYSTEMS
is electrically isolated from the chassis and contains sensors that will disable the system
in the event of a ground fault or collision. The Escape Hybrid is capable of operating at
up to 25-mph on electric power only and can attain accelerations on par with the models equipped with larger V6 gasoline power plants. All regulation of the propulsion and
power systems in handled by Ford’s proprietary automatic control system.
Due to its hybrid powertrain, the Escape Hybrid’s driver control systems are significantly different from those of more conventional automobiles. Traditionally, power assist
for steering and braking systems has been provided by drawing power from the gasoline
engine, either in the form of hydraulic fluid or stored engine vacuum. Since the gasoline engine in a hybrid vehicle is not running at all times during driving, power assist
must be obtained from the always powered electrical system. The Escape Hybrid thus
features electric steering and brake assist. Since the eCVT system regulates the flow of
power through the transmission system via electronic means, the throttle and shifting systems must also be controlled electronically. These features of the Escape Hybrid greatly
facilitated its conversion to an autonomous platform.
2.2
Architecture
Autonomous operation of an automobile requires converting the throttle, shifting, steering, and brake systems to Drive-by-Wire control. Two major approaches were considered
for the conversion: installation of actuators and utilization of the OEM systems.
The first possible approach is to install mechanical actuators to physically move the
driver controls. Commercial systems have been developed for this purpose, most notably
the AEVIT system developed by Electronic Mobility Controls, LLC. (EMC) [17]. The
AEVIT system is a Commercial, Off-the-Shelf (COTS) solution designed as a retrofit
DBW solution for physically disabled human drivers. It consists of a set of bolt-in ac-
9
2.2. ARCHITECTURE
CHAPTER 2. HARDWARE SYSTEMS
tuators that operate the stock controls and an electronic control box; it can be fitted into
almost any standard vehicle. The main disadvantages to the system are its relatively high
cost ($40-50,000), the large physical size of the control box, and an interface that is not
designed for autonomous operation. Use of the AEVIT for Odin would have obstructed
the use of at least one passenger seat and would also have required an additional computing unit to translate between the AEVIT interface and the required Joint Architecture
for Unmanned Systems (JAUS) external interface. Other available COTS solutions would
yield similar advantages and drawbacks.
Another option was to develop a custom actuator based DBW system. This approach
would have required a large amount of mechanical design and fabrication to implement.
It would have been necessary to fit actuators to actuate each of the control systems as
well as an electronic control unit to manage communications and power to the actuators.
While it is potentially feasible, this system is also inherently inefficient when used on
a heavily native DBW vehicle like an Escape as it is, in most cases, using actuators to
move physical controls that are themselves merely generating electrical signals. Due to
this inefficiency, the power requirements for an actuator based system will be higher than
those of a system that does not rely on physical movement. Custom development also
has the disadvantage of requiring significant amounts of engineering effort and having a
much longer development time than a COTS type solution.
The solution chosen for Odin’s DBW interface was designed to maximize use of the
OEM systems. Since the Escape Hybrid already contains a large amount of by-wire technology, it is not necessary to physically move the manual controls to control many of
the systems. The throttle and shifting systems are fully by-wire, the braking system is a
by-wire system with a physical back-up, and the steering system is electrically assisted.
It was thus possible, as described in the following sections, to control the throttle, shifting, and steering systems through direct application of the electronic signals. It had been
10
2.3. THROTTLE
CHAPTER 2. HARDWARE SYSTEMS
intended to control the brakes electronically, but this proved difficult and an actuator was
ultimately installed (see Section 2.6). The system was designed to be controlled from a
single embedded computer that handled communications, control, and signal generation;
a National Instruments (NI) CompactRIO system for this purpose. This approach allowed
the system to be developed for a relatively low hardware cost ($15,000) and to achieve
high dynamic performance while using minimal power. The highly integrated approach
also enabled the conversion to be almost transparent to a human operator, a desirable
side-effect that aids human operation and greatly improves the interior aesthetics.
AUTHOR’S NOTE: Due to the necessity of protecting proprietary information provided
by Ford, system operating parameters presented in subsequent sections will be shown in
qualitative form only, even if the systems were reverse engineered in part or in whole.
2.3
Throttle
Throttle control on Odin was achieved by tapping into the OEM electronic throttle control. The Escape Hybrid features a fully electronic throttle system. The throttle pedal
actuated by the driver is an electronic transducer that signals the driver’s intentions to the
Powertrain Control Module (PCM). The PCM interprets these signals and generates an
appropriate output from the eCVT.
A general description of the operation of the system was provided in the Ford Escape
Service Manual (FESM), and the system was reverse engineered based on this information. Examination of wiring diagrams in the FESM showed that the throttle pedal transducer was connected to the PCM by a wiring harness consisting of two reference voltages,
three signal wires, and two return wires [18]. Prior experience in dealing with automotive
throttle-by-wire systems indicated that the system was likely constructed of three linear
potentiometers that return voltages in a linear proportion to pedal displacement.
11
2.3. THROTTLE
CHAPTER 2. HARDWARE SYSTEMS
To test this hypothesis, a connector was inserted into the wiring harness, and a measurement insert was constructed that mated with the new connectors to allow measurement
of the signals in operation. The measurement shunts were connected to a NI USB-6008
Data Acquisition unit (DAQ) and the voltages measured at 100Hz with the car running.
The pedal was actuated through the full range of motion and the measurements were
logged to a file. The results, as shown in Figure 2.2, indicate that the three voltages vary
linearly with pedal position in fixed ratios scaled to the reference voltages. Two of the
voltages have a positive slope with a fixed offset between them and the third voltage has
a negative slope. Abnormal operation testing also showed that the system will function
with only two in-range signal voltages, but that an error will be triggered by the PCM.
Figure 2.2: Qualitative relationship of throttle voltages.
For autonomous use, a linear function was derived to map each of the three voltages to
12
2.4. SHIFTER
CHAPTER 2. HARDWARE SYSTEMS
an integer command space allowing throttle commands between 0 and 100 percent. The
command space was chosen to correspond to the JAUS standard wrench effort message
(see Section 3.5). These functions were implemented on the controller’s FPGA to dynamically generate the required signal voltages scaled to the measured reference voltage on
command (see Section 2.7).
2.4
Shifter
Due to its hybrid powertrain, the Escape Hybrid does not use a mechanical linkage to
control the gear selection in the eCVT. The shifter lever inside the vehicle actually uses
a set of potentiometers almost identical to the throttle pedal to indicate the selected gear
to the PCM. Due to this unique configuration, it is not necessary to physically move the
shift lever in order to change gears. The only exception to this is Park, where a cableoperated linkage engages a parking pawl to prevent the vehicle from rolling. Once the
vehicle is manually shifted out of Park, any other gear state can be commanded using
electronic signals. To make use of this unique feature, the team had to accept the lack of
ability to shift into and out of Park. This was actually viewed as a safety feature, as it
can be guaranteed that the vehicle cannot move in autonomous mode when the shifter is
physically in Park.
The shifter interface was reverse engineered in a manner similar to the throttle interface. The three control voltages vary linearly with lever position similarly to what was
found with the throttle. For the shifter, each gear corresponds to a range of values of the
three voltages, as shown qualitatively in Figure 2.3, and the shifter will function with one
of the three control lines disabled.
Implementation of the shift control consisted of determining the center point of the
voltage range for each gear and implementing a finite state machine on the controller
13
2.4. SHIFTER
CHAPTER 2. HARDWARE SYSTEMS
Figure 2.3: Qualitative relationship of shifter voltages.
FPGA to provide enumerated gear outputs (see Section 2.7). The physical position of
the shifter was determined by monitoring one of the control voltages and mapping it the
resulting gear. The shifter position was used as a safety lock-out; the controller is required
to verify that the shift lever is physically in Neutral for 2 seconds before autonomous mode
can be engaged. Further, any movement of the shifter out of Neutral disables autonomous
mode and returns the vehicle to full manual control. This feature proved very popular
with the safety drivers as it allowed for a very simple and natural movement to engage
manual override.
One unusual aspect of the Escape Hybrid is the implementation of Drive and Low
gears with the eCVT. As the eCVT only has one physical set of gears, both gears behave
identically when the vehicle is accelerating and allow access to the full range of vehicle
14
2.5. STEERING
CHAPTER 2. HARDWARE SYSTEMS
speed. The difference occurs under deceleration. In Drive, the transmission does not
apply drag from the gasoline engine or electric generator to the drive train, improving fuel
mileage by coasting but requiring application of the brake pedal to significantly reduce
speed. In Low, the regenerative brake system and the gasoline engine are used to apply
drag to the drive train and slow the vehicle without application of the brake. Since the
full speed range is available under either gear, the DBW system always uses Low gear to
reduce the need for actuation of the brake.
2.5
Steering
Control of the steering system required a steering position sensor to be installed in addition to actuation. Actuation is provided by electronically controlling the stock electric
power-steering system.
2.5.1
Steering Sensor
A sensor to indicate the position of the steering system is a requirement for closed-loop
steering control. Since the 2005-2007 Ford Escape Hybrids do not feature a steering
sensor as standard equipment, it was necessary to add an external sensor. Several options
were investigated, with the preferred option being an OEM part that could be retrofitted
without modification. Unfortunately, such a part could not be found and sourced in the
limited time available.
A steering sensor was constructed from two Celesco SP2-25 string potentiometers
(Figure 2.4). A string potentiometer uses a wire under tension to turn an internal rotary
potentiometer and output a voltage proportional to the extension of the string. The strings
from the potentiometer were wound around a 1.75 in diameter collar that was fitted to the
steering shaft. Rotation of the shaft caused the strings to either extend or retract depend-
15
2.5. STEERING
CHAPTER 2. HARDWARE SYSTEMS
ing on the direction of rotation, producing a voltage signal. The 1.75 in diameter collar
combined with the 0.25% error of the string pots yields a theoretical angular resolution of
0.25 deg. One advantage of the potentiometers is that, despite the multiple rotations of the
steering shaft (3.4 turns lock-lock), each potentiometer is capable of acting as an absolute
encoder as each absolute position of the steering shaft maps to only a single string extension length. Fitting of two potentiometers therefore, produces a completely redundant
sensor; in normal use the readings from the two sensors are arithmatically averaged to
provide an output reading.
Figure 2.4: Celesco string potentiometers installed in Odin with steering collar.
Potentiometer output is proportional to the supply voltage as well as to string length.
To eliminate of the effects of supply voltage variation, an extremely high-precision Ana16
2.5. STEERING
CHAPTER 2. HARDWARE SYSTEMS
log Devices 5V AD586M IC Reference Voltage was used to power the string potentiometers. This supply guarantees a voltage tolerance of ±2mV across the entire operating
range, enabling the effects of supply voltage fluctuations to be neglected.
The analog outputs of the potentiometers were read in by the CompactRIO system, a
fourth-order 10Hz digital IIR low-pass filter was applied to reduce noise, and the steering
angle was calculated. No suitable measurement rig was available to provide accurate
correlations of the potentiometers to the angle of the front wheels, so the relationship
was estimated by scribing lines parallel to the wheels on the shop floor and measuring
the angles with a protractor. Within the error bounds of the rather crude measurement
technique, the Escape was found to exhibit nearly parallel steer characteristics and the
relationship between the potentiometers and the wheel angles was roughly linear. The
relationship was therefore assumed to be linear and the wheel angle is calculated by a
linear scaling between the left-lock and right-lock readings. Error detection is built in to
the calculation routine such that if one sensor produces an out-of-range value, the output
will default to the other sensor. This allows the vehicle to operate safely on only one
sensor in event of a failure. If both sensors are out of range, a fault is triggered and pause
mode is activated.
The use of steering potentiometers enabled rapid installation and calibration of a steering sensor, but due to the mechanical action, concerns exist about the long-term reliability.
Two potentiometers broke in testing after a relatively short period of use (<50 hrs). Although these failures were determined to have been caused by improper installation causing a stress concentration in the string, and other potentiometers have survived hundreds
of hours of testing, it is difficult to justify claims of long-term reliability. An OEM type
sensor with validated reliability data would probably be a better choice for future work.
17
2.5. STEERING
2.5.2
CHAPTER 2. HARDWARE SYSTEMS
Steering Actuation
The steering system on the Escape Hybrid, while not a true DBW system, is electrically
assisted. Electric power assist is growing in popularity among OEMs due to its higher
energy efficiency compared to hydraulic assist; electric assist is also a necessity on hybrids
where hydraulic power may not be available due to the gasoline engine being deactivated.
The power assisted rack on the Escape consists of a rack-and-pinion with a powerful DC
electric motor geared to the pinion via a worm gear. The amount of assist required is
determined by a torque sensor that measures the twist in the steering shaft caused by the
driver. Assist provided is determined by a Power Steering Control Module (PSCM) and
is based on the magnitude of the torque and the speed of the vehicle.
The approach taken to control the steering system on Odin is to replace the signals
from the torque sensor to the PSCM with signals that will cause the motor to actuate the
steering as required. From the FESM it was determined that there are two signals generated by the torque sensor that are correlated to reference voltage [18]. The signals vary
in direct opposition to each other, such that an increase in one signal coincides directly
with a decrease in the other, as shown in Figure 2.5. The direction of the torque can be
determined by evaluated which signal is increasing and which is decreasing.
After much experimentation, it was discovered that the PSCM is very sensitive to the
relative magnitudes of the reference voltage and the signal voltages. When these are not
properly matched, the PSCM will trigger a fault and disable the power assist, especially
when turning to the left. The reason for the increased number of faults when turning left
is unknown, but may be related to the asymmetrical construction of the rack. To solve
this problem, the FPGA on the controller was used to digitally scale to voltage outputs at
a high rate.
The steering motor is very powerful, momentary current draws of 80 amps were measured using a clamp meter, and is capable of moving the wheels from lock-to-lock in
18
2.5. STEERING
CHAPTER 2. HARDWARE SYSTEMS
Figure 2.5: Qualitative representation of torque sensor voltage patterns as the steering
wheel is manually turned.
approximately two seconds under most conditions. However, cases were found in which
the steering motor was incapable of turning the wheels. These cases occurred only at zero
or near zero velocity and only on high friction road surfaces such as rough asphalt. No
hardware solution to this problem is possible except adding an additional source of steering torque such as an auxiliary motor. The workaround for this condition was to have
the software allow the vehicle to roll slowly, thus reducing the load on the wheels and
enabling the motor to actuate the rack.
The steering sensor and actuation control were combined in software to produce a
system capable of closed loop steering angle control, as described in Section 3.4.
19
2.6. BRAKES
2.6
CHAPTER 2. HARDWARE SYSTEMS
Brakes
The brake system on the 2005 Escape Hybrid proved to be extremely difficult to reverse
engineer, leading to the ultimate selection of an actuator-based approach.
2.6.1
Electrical Approach
The braking system on the Escape Hybrid is a DBW system, due to the requirement for
regenerative braking. The human-actuated brake pedal is connected to a master cylinder,
as in most cars, but the primary braking force does not come from the hydraulic pressure
that this generates. A brake pedal position sensor that sends a pair of PWM signals to the
Brake System Control Module (BSCM), which determines the brake force requested. The
BSCM coordinates with the PCM via CAN to determine the proportion of the brake force
to be generated by the regenerative system versus the hydraulic brakes. The hydraulic
pressure to actuate the brakes is generated by an electric pump internal to the BSCM,
stored in an accumulator, and distributed to the wheel calipers via a system of solenoid
valves. The BSCM also controls the Anti-lock Brake System (ABS). As a backup to the
electronic systems, there is a physical hydraulic connection between the master cylinder
and the BSCM. In the event of a BSCM failure, a valve opens and connects the master
cylinder hydraulic lines directly to the wheel calipers.
The team’s original design was to control the brake system by reverse engineering and
duplicating the the brake pedal position sensor signals. Reverse engineering proved to be
difficult due to unusual features of the signals. An initialization sequence of unknown
content appears at startup that must be passed through to the BSCM or a fault is triggered.
The signal also displays a drift over time; due to this drift applications of the same signal
lead to increased brake drag over time. The BSCM’s internal compensation algorithm
for this drift is unknown. The system also features a feasibility check that is performed
20
2.6. BRAKES
CHAPTER 2. HARDWARE SYSTEMS
between the pressure in the hydraulic pressure generated by the master cylinder and the
electrical signal. If this check fails, the system will fault and default an emergency mode
in which it will only respond to hydraulic commands.
After consulting with Ford and contacting the manufacturer of the brake system (Continental Automotive), who declined to assist, the team decided that it would be extremely
difficult to ensure reliability with electrical control. Therefore, the decision was made to
fit an actuator to the brake pedal. Although the actuator solution was not as clean and
efficient as desired, it proved to be reliable in service. Personal communications with
several other groups who have attempted to control the 2005-2007 Escape Hybrid brake
system electrically revealed that these groups have suffered from reliability problems with
their electrical brake control implementations. It is likely that a reliable electrical interface can be developed, but without manufacturer support, and given the restrictive time
scale, choosing to switch to an actuator-based approach appears to have been the correct
decision.
2.6.2
Actuator Approach
Once the decision had been made to switch the brake system to an actuator, mechanical
design began on an actuation system. The force required to actuate the pedal was measured using a strain-gauge based load cell. The load cell was affixed to the pedal using
velcro and the pedal was actuated manually at different rates. The rate of actuation was
not measured, as all that was required was an average maximum force. A target full-brake
actuation time was chosen based on an estimated human actuation time of 0.5 seconds.
Several actuator layouts were considered including: cable-operated, rotary, hydraulic,
and linear. After sketching up several designs, the team decided that a linear actuator
pushing directly on the pedal, as shown in Figure 2.6, was the simplest and most efficient
design. The Ultramotion Bug DC423 12 linear actuator was selected as it was capable
21
2.6. BRAKES
CHAPTER 2. HARDWARE SYSTEMS
Figure 2.6: Diagram of brake actuator installed under steering column and top view of
fork linkage.
of meeting the force, speed, and packaging requirements. The Bug DC423 12 actuator,
illustrated in Figure 2.7, is a ball-screw type linear actuator powered by a 12V brushed DC
motor with an integrated linear potentiometer. One other useful feature of this actuator
is the optional add-on normally-applied solenoid brake. Since Odin is not capable of
shifting into Park autonomously, long-term stop situations can require the brake to be
applied continuously for hours. With the solenoid brake, the brake pedal can be applied
and the solenoid brake released to hold the position, thus requiring zero power draw to
hold a brake position. This feature also led to the selection of a DC motor over the optional
SmartMotor, which would require a continuous power draw to hold a position.
The brake actuator is controlled by a Roboteq AX1500 dual-channel DC motor controller operating in single channel mode, which is capable of powering the actuator without active cooling. The Roboteq controller operates the actuator in closed-loop position control mode, using the Ultramotion linear potentiometer for feedback, and triggers
22
2.6. BRAKES
CHAPTER 2. HARDWARE SYSTEMS
Figure 2.7: Cutaway picture of Ultramotion Bug actuator showing internal parts [19]
.
the solenoid brake. Since the Roboteq controller uses RS-232 serial native communications, a daughter board was built to convert the signals to CAN for communication
to the main controller. The daughter board consists a PIC microcontroller and serial
and CAN transceivers. The daughter board reads the desired brake percentage from the
CAN bus and generates the serial commands necessary to operate the Roboteq controller.
The solenoid brake is automatically released when a new movement command is issued
and is reapplied after two seconds of inactivity. The daughter board also monitors the
Emergency Stop (E-stop) circuit; if an E-stop is detected, the brake is automatically applied, regardless of external commands.
The brake system met performance goals, although some steady-state error is present
because the internal PID controller integral gain is set to zero. Due to noise in the analog
position sensor, the actuator tends to exhibit low-magnitude oscillation around the set
point if the integral gain is non-zero. As a small magnitude error in the brake position
23
2.7. CONTROLLER
CHAPTER 2. HARDWARE SYSTEMS
has little impact on the dynamic response of the vehicle, this configuration was chosen to
prevent the integral gain term from trying to overpower the solenoid brake to achieve the
desired position exactly. A feature exists on the Roboteq controller to disable the output
MOSFETs when the solenoid brake is engaged, but this feature does not appear to work
in the firmware revision available.
2.7
Controller
The primary vehicle controller is a National Instruments CompactRIO system that interfaces with the OEM systems through a series of Relay Interface Boards.
2.7.1
CompactRIO
Odin’s DBW system is designed to be controlled from a single system that can provide
the necessary analog and digital I/O, perform control tasks, and communicate with external systems. The system chosen for this task is a NI CompactRIO. The CompactRIO
is a low-cost, reconfigurable I/O-centric platform designed to be used with NI’s LabVIEW software. The CompactRIO configuration used for Odin consists of a cRIO-9012
real-time controller with a 400MHz PowerPC processor running LabVIEW Real-Time,
a cRIO-9004 8-slot chassis with an integrated 3-million gate Field Programmable Gate
Array (FPGA), and seven NI R-series I/O modules to provide CAN, digital I/O, and analog I/O.
The CompactRIO is configured such that the Real-Time processor handles the communications and higher level-control loops while the FPGA controls the DBW system.
An FPGA is essentially a chip containing a very large number of logic gates connected by
software-configurable interconnects. FPGAs excel at tasks that require high degrees of
parallelism and are capable of executing complex instructions at high loop rates. They are
24
2.7. CONTROLLER
CHAPTER 2. HARDWARE SYSTEMS
Figure 2.8: NI CompactRIO controller as installed in Odin.
also very stable as the software is effectively translated into silicon, so they are much less
likely to exhibit unexpected behavior than traditional processors. All FPGA programming
used NI’s Labview FPGA module that allows for graphical FPGA programming, greatly
reducing the development time.
The FPGA was used to monitor and control the DBW systems and is configured so that
each system runs independently in parallel. In the case of the throttle and shifting systems,
the FPGA, gets the desired state from the Real-Time processor, calculates the required
outputs, reads in the reference voltages, scales the outputs to the measured reference
voltages, and then commands the appropriate I/O module to output the proper voltages.
Each of these loops runs at 100Hz, far faster than the frequency response rate of the
vehicle systems, ensuring that the transitions are smooth and that the reference voltages
are tracked accurately. For the steering control, the high rate capabilities of the FPGA are
used to emulate analog circuitry. As noted previously, the PSCM is very sensitive to the
relationship between the reference voltage and the signal voltages, so the FPGA performs
this scaling at a rate of 100kHz, the maximum capability of the I/O modules. Closed loop
25
2.7. CONTROLLER
CHAPTER 2. HARDWARE SYSTEMS
steering position control is also handled on the FPGA, as discussed in Section 3.4.
The FPGA also handles all Controller Area Network (CAN) communications, both
reading data from the Ford CAN bus and transmitting commands over the secondary CAN
port to the brakes and accessory devices. Possibly the most important use of the FPGA is
safety. All manual overrides, software lockouts, and E-stop functions are implemented on
the FPGA. These safety checks are therefore executed on the last stage of the processing
system and cannot be overridden or bypassed by higher processing levels.
A discussion of the software and algorithms used on the Real-Time processor can be
found in Chapter 3.
2.7.2
Relay Interface Board
A Relay Interface Board (RIB), pictured in Figure 2.9, was designed to allow switching of
the electrical interface between manual and autonomous mode. The board has connectors
to interface with the input and output side of the OEM wiring harness as well as the
controller output. The main functionality of the RIB is contained in an Omron G6A-434P
four-pole double-throw relay. This relay is configured to switch up to four analog voltage
outputs from the physical control to DBW control when triggered by a 12V digital signal.
The relay trigger is also configured such that the relay is defaults to manual mode in the
event of an E-stop, ensuring that the controller is physically isolated from the vehicle
systems.
Testing showed that the CompactRIO analog output modules were incapable supplying the driving current necessary to overcome the internal resistance of the command
circuits. To solve this problem, the RIB was equipped with a Texas Instruments OPA4350 four-channel Operational Amplifier (OP-AMP) configured as a unity gain voltage
follower to boost the current on the signals generated by the controller outputs. This solution only increased the cost of the relay board by about $15 and proved to be an efficient
26
2.7. CONTROLLER
CHAPTER 2. HARDWARE SYSTEMS
Figure 2.9: Relay Interface Board inside enclosure.
and reliable solution to amplify the signal current.
Previous experience interfacing OEM voltage signals had indicated that faults could
occur due to step changes in output when control was switched from manual to autonomous mode. The RIBs were thus designed with provisions for a RC low-pass filter
across the analog outputs. Testing under worst case conditions (minimum to maximum
control switching) showed that the Escape’s systems were insensitive to this step change
and that the filters were not needed. The filters were bypassed using 0-ohm resistors
and not mounting the capacitors to the boards. This feature could be deleted from future
designs.
To increase long term reliability, the RIBs were laid out using CadSoft Eagle 4.15
Light and were generously manufactured for free by Advanced Circuits as industrial quality Printed Circuit Boards (PCB). All components except for the relays and connectors
used surface mount packages. Standard DB-9 connectors were used to interface with the
OEM wiring harness; these were chosen because of the easy availability of male and female versions of board and wire mount sides. The connectors were configured so that the
input side was female on the board and the output was male. This layout prevented in-
27
2.8. ACCESSORIES
CHAPTER 2. HARDWARE SYSTEMS
correct installation and enabled the wiring harness to be reconnected to itself in the event
of removal of the RIB. A DB-15 connector provided the interface to the CompactRIO
and a vehicle-wide standard 3-pin Switchcraft connector interfaced with the E-stop system. The boards were enclosed in cut-to-length Hammond aluminum enclosures to provide EMI shielding and physical protection. The one RIB mounted outside the passenger
compartment (steering) was sealed with silicone and fitted with weather tight shrouds on
the connectors.
2.8
Accessories
In addition to the primary control systems, a number of accessory systems were enabled
as part of the DBW system. These systems included headlights, turn signals, horn, and
door locks. All of these systems were controlled by a custom developed CAN enabled
board that was installed under the steering column. The board contains a PIC microprocessor and analog and digital outputs that operate in parallel with the human controls to
activate these systems. The accessory control board is commanded via CAN from the
main controller.
2.9
Emergency Systems
As full-size autonomous vehicle work is inherently dangerous, extensive emergency systems were required both by DARPA and by common sense. Odin is equipped with a
failsafe emergency stop circuit consisting of one internal and two external emergency
stop buttons and a wireless emergency stop system all wired in series such that activation
of any of the triggers will cause the circuit to drop to ground. The loss of voltage on the
E-stop circuit causes a relay to cut the vehicle ignition circuit, the CompactRIO system
to command full brake, the brake controller to automatically apply full brake, and the
28
2.9. EMERGENCY SYSTEMS
CHAPTER 2. HARDWARE SYSTEMS
emergency brake to activate. These methods of stopping the vehicle are redundant and
the ignition relay and emergency brake do not require external power or action from any
type of programmable device, ensuring that the vehicle can be stopped even in the event
of total power failure.
The emergency brake consists of two 25lb gas springs connected to the cable actuated
handbrake. The brake is held in place by an electromagnet connected to the E-stop circuit.
When the circuit drops low, the electromagnet releases and the gas springs force the hand
lever up, setting the parking brake. Resetting the system requires manually pushing down
on the parking brake lever to engage the electromagnet, a simple procedure but one that
ensures that the vehicle does not self recover from an E-stop state. One disadvantage to
this system is that it only applies the rear brakes, potentially causing a loss of directional
stability. In normal E-stop operation, however, the main brake will override the parking
brake applying braking forces to all four wheels. The risk of loss of directional stability
and potential rollover must be accepted for the E-stop system as it is considered as the
system is designed to be used only in emergency situations where stopping the vehicle is
considered more imperative than preserving it. Overall, the emergency brake system is
very simple and is failsafe in that its lowest energy state occurs when the brake is applied.
The wireless emergency stop system normally used in Odin is the TORC Technologies
ES-220. This system consists of a hand-held transmitter and a small footprint receiver that
are connected by a radio modem. The system provides run/pause and kill functionalities
at ranges of up to 6 miles and has been found to be extremely reliable in testing. On Odin,
the kill function is wired to the E-stop circuit, triggering the systems previously described.
The run/pause output is wired to the CompactRIO and causes the desired speed command
to be overridden and a speed of 0m/s with a high acceleration to be executed.
29
2.10. AUXILIARY SYSTEMS
CHAPTER 2. HARDWARE SYSTEMS
Figure 2.10: TORC Technologies SafeStop ES-220 wireless emergency stop system.
(Photo courtesy of TORC Technologies) [20]
2.10
Auxiliary Systems
To enable full autonomy, it was necessary to equip Odin with a large number of systems that can be considered auxiliary to the focus of this work. These systems are not
required for a basic ground vehicle platform, but are required in some form in any fully
autonomous vehicle so they are discussed here for completeness. This section describes
Odin as equipped for the 2008 DARPA Urban Challenge.
30
2.10. AUXILIARY SYSTEMS
2.10.1
CHAPTER 2. HARDWARE SYSTEMS
Power
The autonomous systems installed on Odin required a total of approximately 1.5kW of
electrical power at 12VDC, 24VDC, and 120VAC. The Escape Hybrid contains two native
power buses: a standard automotive 12VDC system and a high-voltage 330VDC bus
for the hybrid system. The installed power system converted the native voltages to the
required forms, as shown in 2.11, a task that would have been much simpler had time and
resources permitted a reduction in the number of required voltages.
Figure 2.11: Diagram of power system architecture.
The majority of the required power is sourced from the 330VDC hybrid bus and converted to 120VAC. A commercial solution for 330VDC to 120VAC conversion solution
31
2.10. AUXILIARY SYSTEMS
CHAPTER 2. HARDWARE SYSTEMS
could not be found; a V-Infinity VTZ2000-D300-S48 330-52V DC-DC converter is thus
used to step the voltage down for the external battery input to a a Tripp-Lite SMART
3000RM2U UPS. The Tripp-Lite system operates as if it was connected to an infinitely
large external battery pack, inverting the 52VDC power to 120VAC and providing a maximum capacity of 3000VA. The UPS also provides emergency backup power from its own
internal battery pack, necessary when the high-voltage bus is deactivated during E-stop
conditions, and allows for connection of the AC power systems to and external 120V
outlet via use of the built in power cable.
The DC power requirements for Odin are considerably less than the AC, only 100W
at 12V and 200W at 24V. Power for the 12V systems was initially provided directly from
the automotive 12V bus, which in the Escape Hybrid is itself charged by a 90A DC-DC
converter from the high-voltage bus. It had been anticipated that, due to the lack of a
traditional alternator, the voltage on this bus would be stable enough to power sensors.
Eventually it was discovered that during zero-velocity wheel movements on high-friction
surfaces the steering motor could draw 70A, enough to draw down the voltage on the bus
and potentially cause problems with sensitive sensing equipment such as the GPS/IMU
and IBEOs. To solve this problem, a 150W AC-DC converter was installed shortly before
the Urban Challenge to draw power from the UPS and provide a more stable bus voltage. This also had the side benefit of providing backup power to the GPS/IMU system,
reducing the chance of a power loss requiring a realignment. Power for the 24V system
is drawn from the 52V bus and down converted to 24V by a Dehner SD-350C-24 DC-DC
converter.
Power distribution is handled by a pair of custom CAN enabled power distribution
boxes. These boxes have manual switches, but can also be controlled by the vehicle
controller over the auxiliary CAN bus to enable automatic switching of systems. This
capability is used to turn on the warning light and siren in autonomous mode and also to
32
2.10. AUXILIARY SYSTEMS
CHAPTER 2. HARDWARE SYSTEMS
cycle power to the IBEO systems when a failure is detected.
2.10.2
Wiring
Wiring as a system is often overlooked in studies of autonomous vehicle platforms as it
is not typically the topic of research. However, while exact statistics are not available,
experience has shown that wiring failures are one of the most common failure modes associated with autonomous vehicles and can lead to mission failure or loss of the vehicle.
In the design of Odin, therefore, a great deal of attention was paid to design and implementation of wiring systems. An estimated 2500 feet of wiring were added to Odin during
the conversion. Before any wiring was installed, the entire system was diagrammed out
and a labeling system was devised. This preparatory work vastly improved the efficiency
of final connection and future repair work.
To reduce Electromagnetic Interference (EMI) effects, the wiring was segregated between power and signal lines and primary wiring runs were separated with power and
signal on the right and left sides of the car, respectively. To further reduce the chances
EMI disruptions, only digital communications were used and all communication lines
were shielded with some also being twisted-pair. Physical damage to the wiring was prevented by enclosing all wires in nylon or plastic conduit and locating primary wiring runs
underneath the vehicle’s trim panels.
All connectors used on Odin are strain-relieved and either positive lock or soldered in
place to prevent accidental or vibrational disconnection. As much as possible connectors
were standardized, enabling easy repairs and exchanging of equipment. The primary
connector for all power wiring is the Switchcraft EN-3 series plastic-bodied, multi-pin,
positive lock connector. The EN-3 connectors are inexpensive, easy to assemble and
available in a range of pin configurations and mounting styles. Power wires were colorcoded by voltage and the connectors were configured such that components could not be
33
2.10. AUXILIARY SYSTEMS
CHAPTER 2. HARDWARE SYSTEMS
improperly connected to the wrong power bus. Data connections used either Switchcraft,
D-subminiature, or Ethernet RJ-45 connectors.
2.10.3
Computing
Powerful computing systems are an essential part of all autonomous vehicles. Odin is
equipped with a standard 19” rack with 3U of space allocated for computing systems
as shown in 2.12. The rack also holds the UPS, a 24-port Gigabit Ethernet switch, and
a 4-port Keyboard, Video, Mouse (KVM) switch connected to the front monitor. For
the Urban Challenge, Odin was equipped with 2 1U HP DL-140 servers each fitted with
dual Intel Xeon Quad-core processors. Communication to the computers is exclusively
through dual Gigabit Ethernet ports, except for IEEE-1394 Firewire connections to the
top mounted cameras. Two Moxa N-Port 6450 serial-to-Ethernet converters enable either
computer to communicate with serial devices. Other computing configurations could be
fitted as necessary for future operations; the use of the standard-size rack makes reconfiguration very easy.
2.10.4
Sensors
Odin is equipped with an extensive sensor suite as shown in 2.13. For the Urban Challenge, Odin was equipped with a Novatel Propack LB+ GPS/IMU system, 4 SICK LMS291 laser range finders and 2 Imaging Source cameras mounted to a custom built roof
rack. The roof mounted sensors were augmented by two front and one rear bumper
mounted IBEO ALASCA multi-plane laser scanners. To provide physical protection to
the sensors, each is enclosed in a heavy-gage steel cage. The mounts are designed to
break away from the vehicle in the event of a high-speed collision, hopefully preventing
damage to the sensors. Although designed for this sensor suite, the roof rack and bumper
mounts could be reconfigured to fit other combinations of sensors.
34
2.10. AUXILIARY SYSTEMS
CHAPTER 2. HARDWARE SYSTEMS
Figure 2.12: Odin’s rear rack showing current computing configuration with 2 HP servers.
Figure 2.13: Odin’s Urban Challenge sensor suite with sensors labeled.
35
Chapter 3
Control Systems
3.1
Software Overview
The Drive-by-Wire, low-level control software, and communications on the Escape platform make up the Vehicle Interface running on the CompactRIO. The responsibilities
of the vehicle interface include: DBW systems, mode select, speed control, directional
control, and JAUS communications. As previously discussed, the DBW systems are implemented in LabVIEW FPGA. The remainder of the vehicle interface is implemented in
LabVIEW Realtime and runs on the PowerPC processor in the CompactRIO controller.
The realtime components make use of the inherently parallel nature of LabVIEW to run
in asynchronous parallel loops. Mode select is executed at 20 Hz, speed and directional
control at 50 Hz, and JAUS communications at 100 Hz. Data transfer between loops is
handled using LabVIEW Shared Variables. The Vehicle Interface boots automatically on
vehicle start and is ready for autonomous operations approximately 45 seconds after the
36
3.2. OPERATIONAL MODES
CHAPTER 3. CONTROL SYSTEMS
key is turned on. It accepts commands via JAUS over Ethernet and is capable of operating in either open or closed loop modes, although closed loop is the primary operational
mode.
3.2
Operational Modes
As the lowest level of the autonomous system, the Vehicle Interface is responsible for
determining the operating mode of the vehicle. For safety, the Vehicle Interface must also
override the commanded vehicle mode if errors are detected or if manual overrides are
engaged. The allowable vehicle modes include: manual control, full autonomous control,
partial autonomous control, and several emergency modes, as shown in Figure 3.1. The
modes are arranged in a hierarchy with the manual and emergency modes able to override
the autonomous modes as necessary. The emergency modes can be triggered via either the
remote emergency stop system or on board error checking. Important parameters such as
brake actuator communications and vehicle speed feedback are monitored continuously
and automatically trigger Software Pause mode in the event of a failure.
3.3
Speed Control
The requirement for the speed control on the Escape platform is to achieve a desired speed
of up to 13 m/s using a specified rate of acceleration and to maintain that speed over varying terrain until a new speed is commanded. Properly implemented, a system meeting this
requirement would enable upper level autonomous control systems to command desired
longitudinal speeds and predict the vehicle response with a reasonable degree of accuracy.
37
3.3. SPEED CONTROL
CHAPTER 3. CONTROL SYSTEMS
Figure 3.1: Diagram showing hierarchy of vehicle modes.
3.3.1
Implementation
Three control inputs are available on any automotive platform to regulate speed, the throttle, the brakes, and the shifter. On a vehicle such as the Escape Hybrid that is equipped
with a Continuously Variable Transmission (CVT), the shifter purely controls the direction of travel, leaving only the throttle and brake for speed control. The CVT does,
however simplify the task of speed control by eliminating the step changes in vehicle
response caused by gear shifts in a traditional transmission. As noted in Chapter 2, the
DBW system allows specification of the positions of the throttle and brake over a range
from 0-100% in increments of 1%.
38
3.3. SPEED CONTROL
CHAPTER 3. CONTROL SYSTEMS
Alternate Approaches
Several speed control implementations were tested during the development of the Escape
platform: a simple PID controller, a SpAM-based controller [21], and two forms of a
modified PID controller. All of these techniques included a version of a PID controller,
which uses a set of gains based on the error signal, the difference between the setpoint
and the actual process variable value. The proportional term applies a gain to error signal to generate a control effort that tends to drive the error toward zero, however a pure
proportional controller will exhibit a small amount of steady state offset in the process
variable. The integral term of the controller eliminates steady-state error by applying a
gain to the integral of the error signal, ensuring that the process variable is eventually
driven to the setpoint. The derivative term is used to control the system based on the slope
of the response and is usually used to reduce undesired overshoot; derivative control is
very sensitive to measurement noise, however, and can drive the system unstable if the
process variable measurements are too noisy. PID controllers have been found to work
well for linear systems, but can provide suboptimal responses for nonlinear systems.
Initially, a simple PID controller was implemented to provide basic speed control.
Testing quickly revealed that the vehicle responded differently to throttle and brake inputs,
causing the overall longitudinal acceleration control to be nonlinear. As a result of these
nonlinearities, satisfactory response characteristics over the full range of operations were
difficult to obtain without a highly complex gain scheduling scheme. The approach also
offered no method for closed loop acceleration control, thus making acceleration response
highly responsive to vehicle pitch inclination.
An early version of the Speed-based Acceleration Maps (SpAM) scheme developed
by David Anderson was also tested [21]. This scheme uses maps of vehicle performance
to fit a match speed response to a splined acceleration curve. While promising in theory,
the version used for initial testing was incomplete and yielded poor results. The scheme
39
3.3. SPEED CONTROL
CHAPTER 3. CONTROL SYSTEMS
was later further developed but, as noted by Anderson, the SpAM approach requires very
accurate vehicle performance maps and does not contain sufficient feedback to correct for
all terrain effects [21].
The final approach tested for speed control used a PID controller mated with a function
designed to correct for the nonlinearities present in the system. The first implementation
of this approach was based on work done by Gothing and Hurdus to control speed on the
Virginia Tech Autonomous Cadillac SRX [22]. This implementation used a PID operating on the vehicle speed with the output fed into a splining function that mapped the PID
output to a commanded throttle or brake setting. The spline function fits a cubic spline
to basic vehicle performance parameters to linearize the throttle and brake response. Acceleration is controlled by adjusting the parameters of the spline. This method yielded
reasonable results, but proved to be difficult to tune as the spline parameters are nonintuitive and was computationally inefficient due to the need to continuously recalculate
the splines. Accurate acceleration control was also difficult to achieve over a range of
pitch angles. This approach was modified to produce the final implementation.
Final Implementation
The final implementation of the speed control fused aspects of the SpAM performance
maps and SRX PID with closed loop acceleration control to create a robust, accurate, and
computationally simple speed controller. The approach, as shown in Figure 3.2, is based
on a PID operating on the vehicle speed. The output of this controller is interpreted as a
requested acceleration effort. To control the acceleration, the PID output is band-limited
by the commanded acceleration, ensuring that the desired acceleration is not exceeded
while allowing the acceleration to decrease as the setpoint is approached. The bandlimited acceleration output is then input into a map lookup function and converted to a
throttle and brake output.
40
3.3. SPEED CONTROL
CHAPTER 3. CONTROL SYSTEMS
Figure 3.2: Block diagram showing implementation of speed controller.
The lookup function is based on a simple map of vehicle performance containing a
full-throttle acceleration curve, a full brake acceleration curve, and a zero throttle acceleration curve derived from experimental data. The vehicle was accelerated at full throttle
on nearly flat ground from zero to 15 m/s and then stopped using full brake. The test was
repeated allowing the vehicle to decelerate with zero throttle and zero brake in Low gear.
The Escape Hybrid exhibits a zero-throttle, zero-brake creep speed of approximately 2
m/s; to complete the map, the zero throttle acceleration from zero to 2 m/s was also measured. The vehicle speed for each test was obtained from the vehicle CAN bus and logged
to a file at 50 Hz. Each test was repeated in the opposite direction along to road to correct for bias due to road pitch. The data from each of the two runs was averaged and the
acceleration at each point was calculated using a two-point backwards difference. The
data was plotted as acceleration versus speed for each condition and a high order curve
fit was performed to provide smooth curves. The result, shown in Figure 3.3, is a map
approximating the acceleration performance at speeds up to 15 m/s. Higher speeds were
not tested due to test space limitations, but were not required for this application as the
maximum required autonomous speed required is 13 m/s. The performance data is not
exact, but does provide a reasonable estimate of the vehicle’s capabilities.
The map lookup function performs a linear interpolation on the map at the current
speed to output the required throttle or brake to produce the desired acceleration. The
41
3.3. SPEED CONTROL
CHAPTER 3. CONTROL SYSTEMS
Figure 3.3: Speed control map showing approximate vehicle performance at full throttle,
zero throttle, and full brake.
representation of the map as implemented is a table of the acceleration produced at each of
the three tested conditions at each integer value of speed up to 15 m/s. Higher granularity
in speed produces little change in the interpolated result, so only integer values of speed
are used to reduce memory requirements. Testing later showed that raising the result of
the interpolation to a power yielded better results for low and intermediate control ranges.
The experimentally determined exponent values used are 2.2 for the throttle and 0.5 for
the brake. The result of applying the map lookup function is to linearize the response of
the system with respect to acceleration, allowing the PID controller to efficiently control
the speed. Test results are shown in Section 3.3.2.
The map used to represent vehicle performance can only be considered accurate on
42
3.3. SPEED CONTROL
CHAPTER 3. CONTROL SYSTEMS
level ground. In order to accurately control acceleration over varying terrain, a mechanism
is needed to compensate for the effects of acceleration due to gravity, variations in vehicle
load, or errors in the acceleration map. Due to the linearization of the system with respect
to acceleration, the effects of these accelerations can be linearly superimposed with the
desired acceleration output of the PID before application of the map function. A simple proportional controller is used to estimate the auxiliary accelerations. The difference
between the acceleration requested by the PID and the current measured acceleration is
calculated, multiplied by a gain, and then added to the current estimate of the auxiliary acceleration. This method closes the loop on the acceleration control, rendering the vehicle
much more insensitive to terrain variations than the other methods tested.
The speed controller gains were tuned experimentally, but one undesirable effect was
discovered. When gains that yielded fast response were used, the process variable exhibited low-amplitude oscillations about the setpoint. To eliminate this problem, an eightpoint moving average filter was applied to the the PID output when the process variable
remained in a deadband around the setpoint (typically 0.2 m/s). This filter effectively
increased the damping in the system and eliminated the oscillations. To ensure that the
vehicle remains stopped when commanded and that the brake is not excessively actuated,
a further feature of the implementation is the provision of a fixed brake output when the
commanded and actual speeds are both below 0.2 m/s.
3.3.2
Test Results
The speed controller was tested extensively during autonomous operations, mostly in uneven terrain due to the test sites available. Data from a public demonstration at the Virginia
Tech Corporate Research Center is shown as representative response data in Figure 3.4.
Data sets from other test sites show similar results. It can be seen that the acceleration response of the controller generally follows the commanded acceleration. One problem that
43
3.3. SPEED CONTROL
CHAPTER 3. CONTROL SYSTEMS
does exist is a lag of up to several seconds that occurs when the vehicle accelerates from a
stop. This lag is due to the auxiliary acceleration estimation growing without bound when
the vehicle is at rest. This issue could be solved by holding the acceleration estimate static
when the vehicle is at rest and a zero velocity is being commanded.
Figure 3.4: Speed control response to autonomous commands in hilly terrain.
It should also be noted that the speed signal, which is derived from the vehicle speed
sensor, can be very noisy. The apparent oscillations in the speed that occur between
320-325 seconds cannot represent the actual vehicle speed. These fluctuations have a
frequency of approximately 5 Hz, much faster than the actual frequency response capability of the vehicle and must therefore be attributed to noise. The source of this noise
is unknown as the sensor providing the data is an OEM part for which specifications are
not available. The noise in the signal could be attenuated by applying a low-pass filter
44
3.4. DIRECTIONAL CONTROL
CHAPTER 3. CONTROL SYSTEMS
to the signal if desired, however, the noise does not actually significantly affect vehicle
performance. A more significant source of error is the effect of terrain inclination. Unfortunately, terrain inclination data synchronized to speed control data is not available. It is
theorized, however, that terrain inclination is responsible for several of the anomalies in
the response, such as the oscillation present between 335-345 seconds.
The overall average speed error for the entire data set (only a portion of which is
shown for clarity) is 0.3 m/s. This is slightly higher than the desired 0.2 m/s, but is
heavily influenced by the excessive lag when accelerating from rest. It is anticipated that
fixing the lag problem would result in a significantly better mean error as the median for
the data set is only 0.12 m/s. The result of this implementation is a robust and reasonably
accurate controller that is capable of controlling speed and acceleration. The controller is
relatively computationally efficient and capable of being implemented extremely quickly
and performs sufficiently for autonomous urban operations.
3.4
Directional Control
Directional control on an automotive type vehicle is provided primarily by the steering
system, especially in the low-speed, on-road conditions for which the Escape platform
was developed. Autonomous navigation requires control over the path on which the vehicle will travel. For the Escape, this path is specified by a path curvature and a rate
of change of path curvature. For a known initial state, these two variables are capable
of precisely delimiting the path of travel. Directional control on the Escape is provided
by modeling the vehicle to determine the appropriate steering input to apply in order to
achieve the desired curvature state and then controlling the steering system to execute this
command.
45
3.4. DIRECTIONAL CONTROL
3.4.1
CHAPTER 3. CONTROL SYSTEMS
Vehicle Model
The vehicle model used to calculate the steering response of the Escape is known as
the bicycle model. The bicycle model compresses the four wheel vehicle into a much
simpler two wheel “bicycle,” as shown in Figure 3.5, by neglecting lateral effects such
as weight transfer and body roll. This assumption is generally considered valid for lowspeed road maneuvers and examples of use of the bicycle model can be found in the
literature [12] [13]. The version of the bicycle model used is derived by Milliken and
includes the further assumptions that the vehicle exhibits understeer response and that
the tires are operating in the linear range [23]. For a full derivation of the model, the
reader is referred to the excellent discussion in Chapter 5 of Milliken’s Race Car Vehicle
Dynamics [23].
The steady state response of the path curvature to steering angle can be expressed as
κ=
δ /`
1 + KV 2
where κ is the path curvature, V is the forward velocity, ` is the wheelbase, δ is the steering angle, and K is termed the stability factor [23]. The stability factor is related of the
variation of curvature with forward velocity and is a measure of the oversteer/understeer
characteristics of the vehicle. For the given set of assumptions, K can be expressed as

K=

m 
a+b
−a ∗C f
−a∗C f +b∗Cr
C f +Cr

f +b∗Cr
+C f ∗ ( −a∗C
C f +Cr
where m is the vehicle mass, a and b are the distances from the CG to the front and rear
axles, and Cf and Cr are the front and rear cornering coefficients [23]. As test equipment
was not available to measure each of the parameters, the value of K was calculated using
the best available data: the published vehicle curb mass of 1720 kg, the published vehi-
46
3.4. DIRECTIONAL CONTROL
CHAPTER 3. CONTROL SYSTEMS
Figure 3.5: Diagram of the bicycle model representation of the vehicle.
cle CG location of a=1.12m and b=1.494m, and a typical cornering coefficient obtained
2
from Milliken of 10000N/rad [23]. The resulting value, K=0.001 rad∗s
indicates underm2
steer behavior, implying that the vehicle will tend to increase its path curvature as speed
increases. This effect would be expected for a passenger vehicle such as an Escape. From
the curvature response equations, it can be seen that the two primary variables affecting
path curvature are steer angle, δ , and forward velocity, V, and that the steer angle is the
primary contributor.
To obtain the curvature rate response, it is necessary to take the derivative of the curvature response equation with respect to time. Performing this differentiation symbolically
47
3.4. DIRECTIONAL CONTROL
CHAPTER 3. CONTROL SYSTEMS
yields
κ̇ =
δ̇
δ̇
−
3
2
V ∗ ` + ` ∗ K ∗V
(` + ` ∗ K ∗V )(2 ∗ κ ∗ ` ∗ K ∗V ∗ V̇ )
which represents the instantaneous curvature rate response. The curvature rate is dependent on the curvature, the velocity, the acceleration, and the rate of change of the steering
angle.
3.4.2
Implementation
The vehicle model is implemented in quasi-static form on the realtime processor of the
CompactRIO. For each iteration, the velocity is considered to be constant and acceleration
terms are neglected. To prevent singularities, the minimum velocity used for calculations
is 0.01 m/s. The equations are then rearranged to solve for the steering angle and steering
rate required to achieve the desired curvature and curvature rate. On Odin, the steering
rate is further modified by multiplying the calculated value by the ratio of the current
velocity to the commanded velocity. This modification was necessary due to the method
of curvature calculation used in the Urban Challenge path planning software. As the
steering system can have difficulty moving the wheels at very low rates, the steering rate
is coerced to a minimum value of 0.03 rad/s.
The target steering position and rate are used as inputs to ramp function that provides
rate control. The output from the ramp function is transmitted to the FPGA. The actual
steering position is controlled by a PID controller executing on the FPGA at a high rate.
The controller attempts to drive the steering to the desired angle and is tuned specifically to provide very rapid responses to commands at medium to low steering rates. Due
to some nonlinearities present in the steering system, the controller tends to overshoot
commands at very high rates; however, commands are rarely issued at these rates in autonomous situations. A more desirable result could be obtained by implementing a more
48
3.4. DIRECTIONAL CONTROL
CHAPTER 3. CONTROL SYSTEMS
sophisticated control law; this was not done due to time limitations and the acceptable
response under normal autonomous conditions.
3.4.3
Test Results
The bicycle model used to predict curvature was validated by driving the vehicle in circles
and measuring the actual path curvature. The curvature was measured by setting the
vehicle to drive in a circle at a fixed steering angle and a fixed speed under DBW control
on relatively flat ground. Position was obtained from a Novatel Propack LB+ system with
Omnistar HP corrections and was logged at 10Hz. Tests were conducted at a variety of
steering angles and speeds up to 8 m/s. It would be desirable to conduct tests at higher
speeds, but a test location of suitable size was not available. The data from the GPS was
analyzed and an average radius of curvature from each test was calculated.
Figure 3.6: Response of path curvature to variations in speed at a fixed steering angle.
The results of the testing are very similar to those found by Franken and Glass on an
identical vehicle [14]. Path curvature shows a slight dependence on speed, as shown in
49
3.4. DIRECTIONAL CONTROL
CHAPTER 3. CONTROL SYSTEMS
Figure 3.6. The effective understeer coefficient for each test can be back calculated from
the data and demonstrates a significant variation with speed, as shown in Figure 3.7. This
same effect was found by Franken and Glass, and they concluded that the bicycle model
was invalid for curvature prediction [14]. While they appear to be correct about the bicycle model neglecting some of the physics of vehicle dynamics, they neglected to calculate
the path curvature error actually produced by the parameter variation. Calculating the
error between the actual curvature and the curvature predicted using an understeer coef2
produces a mean error of only 3%, which is less than the likely
ficient of K=0.001 rad∗s
m2
measurement error. Therefore, it can be concluded that while the bicycle model simplifies
the vehicle dynamics, it produces results accurate enough for use in autonomous driving.
Figure 3.7: Effect of speed on effective understeer coefficient.
Test results for the steering controller are shown in Figure 3.8. These results were
obtained under the same test conditions as the speed control results: fully autonomous
maneuvers in the Corporate Research Center. It can be seen that the steering controller
tracks the desired steer angle very closely. The largest anomalies occur when the steering
50
3.4. DIRECTIONAL CONTROL
CHAPTER 3. CONTROL SYSTEMS
motor is unable to turn the wheels to full lock when the vehicle is at rest. This is a known
issue and was solved by allowing the vehicle to move at a low rate of speed when the
problem was detected.
Figure 3.8: Steering controller response to autonomous steering commands in urban driving.
After removing the error induced during full turn situations, the mean offset between
the desired and actual steering angle of the data set is 0.006 rad or 0.4 deg. The median
of the corrected error set is 0.003 rad or 0.2 deg. Overall, the performance of the steering
control is adequate to follow the rates and steering angles actually commanded in autonomous driving. The controller could possibly be improved by implementing a model
based controller, but significant performance improvement is not expected.
51
3.5. COMMUNICATIONS
Identifier
0xE22D
0xE22E
0xE22F
0xE239
0xE322
0xE325
0xE328
3.5
CHAPTER 3. CONTROL SYSTEMS
Table 3.1: Experimental JAUS messages implemented on Odin
Message
Data
Report Steering Angle
Steering Angle
Report Wheel Speeds
Individual Wheel Speeds
Report Vehicle Mode Actual
Actual Vehicle Mode
Report Vehicle Mode Commanded Commanded Vehicle Mode
Set Signals
Turn Signal and Light Command
Set Vehicle Mode
Commanded Vehicle Mode
Set Motion Profile
Commanded Motion Profile Array
Communications
All external communications to the Escape use the TORC Technologies implementation
of the AS-4 JAUS standard. JAUS was developed to enable interoperability between
robotic systems by establishing a common communication framework. Ideally, any system implementing JAUS should be able to communicate with any other system using the
standard. The JAUS framework provides a set of standard messages for autonomous vehicle control [24]. These messages, however, were originally designed for teleoperation
and are not always ideal for autonomy. One example of this is the standard movement
message known as the wrench effort message. Wrench efforts are specified as a percent
of available effort along a given axis. In order to predict the response of a vehicle to a
wrench effort message, it is necessary for the higher level autonomous software to have
a vehicle specific model. To solve this problem, the primary movement communication
message on Odin is the motion profile message. This message provides a series of movement commands in vehicle independent parameters: path curvature, curvature rate, speed,
and acceleration. The message also specifies a time to execute each command, ensuring
that the lower level systems will be able to detect a loss of communications and stop the
vehicle safely if necessary. A list of experimental messages used is provided in Table 3.1.
The use of JAUS increase the flexibility and interoperability of the Escape platform.
52
Chapter 4
Conclusions
4.1
Conclusions
The result of this research is the development of a reliable autonomous vehicle platform
for urban operations. The Ford Escape Hybrid proved to be an excellent choice of platforms as it features OEM systems that can be accessed for both DBW control and electrical power. The Escape also provides sufficient cargo capacity for the computing and
sensor equipment necessary for full autonomy. The Escape platform was able to be developed extremely quickly and proved to be reliable in testing, enabling developers to focus
on other aspects of autonomy.
The control systems developed for the vehicle proved to be adequate to the requirements of autonomy. The speed control method developed is simple and accurate, capable
of maintaining speeds to within 0.2 m/s under most conditions. Due to the map based
approach, the speed controller could be applied to another vehicle with a minimum of
53
4.2. RECOMMENDATIONS AND FUTURE WORK CHAPTER 4. CONCLUSIONS
effort; only a few simple tests would be needed to map the vehicle performance.
The directional control method applies a simple vehicle model to enable the vehicle
to follow desired paths by tracking curvatures and curvature rates. The model has been
shown to be valid for the designed operational range of the vehicle. Due to the assumptions made in the formulation of the model, however, directional control may become
unstable under abnormal road conditions such as snow, ice, or mud. Under these conditions, the model would no longer yield accurate results and could lead to a loss of control.
Although testing has not been conducted, a more detailed vehicle model is most likely
necessary to enable operations under these types of conditions.
Ultimately, the proof of any system is its performance in the environment for which it
was designed. Odin was designed for the DARPA Urban Challenge proved to be highly
successful, as shown in Figure 4.1. Odin completed the approximately 60 mile course in
4.5 hours under full autonomous control, placing third overall and validating the team’s
approach.
4.2
Recommendations and Future Work
If reliable hardware platforms are available, the future of work in autonomous systems is
the continued enhancement of sensors, decision making, and sensor fusion. To enable this
work, the future of platform development should be the further development and commercialization of the hardware and control algorithms necessary for autonomy. The market
for fully custom autonomous vehicles will likely remain small in the near future (with
the exception of a small number of extremely high-cost military systems), so the most
feasible approach would likely be a retrofit system to enable commercial vehicles to be
rapidly outfitted. Such systems exist in the form of the AEVIT, Pronto4, and other similar
systems. These have the disadvantage of being expensive, bulky, and often difficult to
54
4.2. RECOMMENDATIONS AND FUTURE WORK CHAPTER 4. CONCLUSIONS
Figure 4.1: Odin taking the checkered flag at the end of the 60 mile DARPA Urban
Challenge [25]
interface.
It appears to be possible to develop an inexpensive retrofit kit that makes use of OEM
systems for vehicle control and implements low-level vehicle control and standard communication algorithms. While effective in low volumes, the centralized controller architecture used in Odin is likely not the optimal choice for a production system. The most
difficult part of the installation of any DBW system is the installation of the hardware and
especially the wiring. From both a cost and a reliability standpoint, it would be desirable
to reduce the number of components and wires to a minimum.
It is recommended that a distributed controller system be developed. This approach
could make use of “smart” RIBs equipped with either microprocessors or Complex Programmable Logic Devices (CPLD) to handle the generation of the control signals at points
local to each of the systems. These smart RIBs could be linked by a digital network,
55
4.2. RECOMMENDATIONS AND FUTURE WORK CHAPTER 4. CONCLUSIONS
preferably CAN, requiring that only a single cable be routed through the vehicle to connect the system. These boxes would preferably be equipped with OEM connectors to
enable installation without need for installation of secondary connectors. The DBW system could then be controlled directly in open loop mode via CAN or linked to an auxiliary
controller that would contain implementations of the control algorithms and higher level
communications such as JAUS. If a method can be found to control the braking system
on the Escape without an actuator, the result would be a high performance, extremely
low cost DBW system that could be installed in a matter of hours. Such a system could
possibly be applied to other vehicles with similar OEM systems and would dramatically
lower one of the barriers to entry into autonomous vehicle research.
Future work is also needed to develop a method for effectively modeling the directional response of autonomous vehicles, particularly in adverse terrain conditions. More
significantly, a method for integrating the data from such a model into control and motion
planning algorithms must be developed. Without such work, it will be extremely difficult
to guarantee safe operation of autonomous vehicles in adverse conditions.
56
References
[1] National Defense Authorization Act for Fiscal Year 2001. S. 2549.
[2] Bertoluzzo, M., et al. (2004). Drive-by-Wire Systems for Ground Vehicles. 2004
IEEE International Symposium on Industrial Electronics. Vol. 1: 711-716.
[3] Trepagnier, P. G., et al. (2005). ”Team Grey Technical Paper DARPA Grand Challenge 2005.” Retrieved Dec. 31, 2007, from http://www.darpa.mil/grandchallenge05/.
[4] Thrun, S., et al. (2006). ”Stanley: The Robot that Won the DARPA Grand Challenge.”
Journal of Field Robotics 23(9).
[5] Klarquist, W., et al. (2005). ”Intelligent Vehicle Safety Technologies 1 Technical Description.” Retrieved Dec. 31, 2007, from http://www.darpa.mil/grandchallenge05/.
[6] Whittaker, W., et al. (2005). ”Red Team DARPA Grand Challenge 2005 Technical
Paper.” Retrieved Dec. 31, 2007, from http://www.darpa.mil/grandchallenge05/.
[7] Moore, W. T., et al. (2005). ”Autonosys Technical Paper DARPA Grand Challenge
2005 Technical Paper.” Retrieved Dec. 31, 2007, from
http://www.darpa.mil/grandchallenge05/.
[8] Vest, M., et al. (2005). ”DARPA Grand Challenge 2005 Technical Paper.” Retrieved
Dec. 31, 2007, from http://www.darpa.mil/grandchallenge05/.
[9] Urmson, C., et al. (2004). “High Speed Navigation of Unrehearsed Terrain: Red Team
Technology for Grand Challenge 2004.” Pittsburgh, PA, Robotics Institute, Carnegie
Mellon University.
[10] Johansen, T. A., et al. (1998). ”Off-equilibrium linearisation and design of gainscheduled control with application to vehicle speed control.” Control Engineering
Practice Vol. 6(2): 167-180.
[11] Fenton, R. E., et al. (1976). “On the Steering of Automated Vehicles: Theory and
Experiment.” IEEE Transactions of Automatic Control. Vol. AC-21.
[12] Feng, D. and B. Krogh. (1990). “Dynamic Steering Control of ConventionallySteered Mobile Robots.” 1990 IEEE International Conference on Robotics and Automation, Cincinnati, OH.
57
[13] Sotelo, M. A. (2003). “Lateral control strategy for autonomous steering of
Ackerman-like vehicles.” Robotics and Autonomous Systems Vol. 45(3): 223-233.
[14] Franken, G. and Z. Glass. (2007). “Advanced State Estimation and Control of an Autonomous Ground Vehicle using a priori Knowledge of Ground Vehicle Dynamics,”
Princeton University.
[15] Ferguson, Ian. Personal Communication. December, 2007.
[16] MSNBC, Inc. (2008). Retrieved April, 2008, from
http://www.msnbc.msn.com/id/9664955/
[17] Electronic Mobility Controls, LLC. (2008). Retrieved April, 2008, from
http://www.emc-digi.com/
[18] Ford Motor Company, Inc. Service Information, 2005 Escape Hybrid. September,
2004. Electronic Version.
[19] Ultramotion, LLC. (2008). Retrieved April, 2008, from
http://www.ultramotion.com/
[20] TORC Technologies, LLC. (2008). Retrieved April, 2008, from
http://www.torctech.com
[21] Anderson, D. P. (2008). Splined speed control using SpAM (Speed-based Acceleration Maps) for an autonomous ground vehicle. Master of Science in Mechanical
Engineering. Blacksburg, VA, Virginia Tech.
[22] Gothing, G. and J. Hurdus (2006). “Implementation of JAUS on a 2004 Cadillac
SRX Using a Potential Fields Architecture.” AUVSI’s Unmanned Systems North
America 2006. Orlando, FL.
[23] Milliken, W. F. and D. L. (1995). Race Car Vehicle Dynamics. Warrendale, PA, SAE
International.
[24] Faruque, R. R. (2006). A JAUS Toolkit for LabVIEW, and a Series of Implementation
Case Studies with Recommendations to the SAE AS-4 Standards Committee. Master
of Science in Mechanical Engineering. Blacksburg, VA, Virginia Tech.
[25] Defense Advanced Research Projects Agency. (2007). Official Government Photograph. Retrieved April, 2008, from http://www.darpa.mil/grandchallenge/gallery.asp
58