Autonomous Vehicles Project

Department of Mechanical Engineering and Mechanics
MEM 380: Autonomous Vehicles
Instructor: Dr. Harry Kwatny
Date: June 4, 2015
Team Members: Jon Affleck
Tyler Darrah
Elliot Farquhar
Jeff Fuller
Robert Stricek
Abstract
The design team had been tasked with developing an autonomously functioning vehicle,
converted from a Traxxas E-Maxx Remote Control Truck, capable of navigating hallways and
avoiding obstacles along the way. Such obstacles included small doorways, water fountains, conduit,
and corners. The team had performed slight modifications to the vehicle’s pre-existing electrical
configuration in order to alleviate performance issues, and then focused primarily on delivering the
software from which the vehicle would perform its intended task. This had been done using the
Arduino IDE (Integrated Development Environment) in conjunction with the Arduino UNO
controller board. The group developed two core functionalities for the vehicle to perform its intended
task, namely a wall following PID integrated controller and obstacle avoidance software.

1 | P a g e
Table of Contents
I. Introduction ............................................................................................................................................ 3
1.1 Problem Statement .......................................................................................................................... 3
1.2 Applications ..................................................................................................................................... 3
II. Car Setup ............................................................................................................................................... 3
2.1 Hardware Specifications ................................................................................................................. ?
2.2 Modifications ................................................................................................................................... ?
2.2.A Electrical............................................................................................................................... ?
2.2.B Mechanical............................................................................................................................ ?
III. Logic Design ......................................................................................................................................... ?
3.1 Following Along Walls .................................................................................................................. ?
3.2 Obstacle Avoidance ........................................................................................................................ ?
3.2.A Doorways .............................................................................................................................. ?
3.2.B Obstacle In Front ................................................................................................................. ?
3.2.C Dead Ends and Right Hand Turns ..................................................................................... ?
3.2.D Left Hand Turns .................................................................................................................. ?
IV. Software Development ........................................................................................................................ ?
4.1 General Process............................................................................................................................... ?
4.2 Function Development ................................................................................................................... ?
4.3 PID Library Modifications ............................................................................................................ ?
V. Performance .......................................................................................................................................... ?
VI. Conclusion ............................................................................................................................................ ?
VII. Future Work ....................................................................................................................................... ?
VIII. References ......................................................................................................................................... ?
Appendix IX: Component Pictures .......................................................................................................... ?
Appendix X: Final Vehicle Pictures ......................................................................................................... ?
Appendix XI: Final Arduino Code ........................................................................................................... ?

2 | P a g e
List of Figures
Figure 1: Original E-Maxx Factory Configuration…………..…..……………………………………………..……..4
Figure 2: Modified E-Maxx Configuration ...…………………………………………………………………..……..4
Figure 3: Ultrasonic Limiting Sensing Angle …………………………………………………………………....…...7
Figure 4: (Left) sensing field given a flat object (Right) sensing field given a round object …….…………………..7
Figure 5: Top down view of vehicle layout …………..…..………………………………………..…………..……..8
Figure 6: Wiring Diagram of the Control System …………..…..………………..…………………………………..9
Figure 7: PID Functional Block Diagram …………..…..…………………………………………………….……..10
Figure 8: Device Path as it Passes a Small Doorway …………..…..…………………………..………………..…..12
Figure 9: (Left to Right) Increasing Doorway Width Causing Sensor 1 to Reach its Limiting Angle ……….……..12
Figure 10: Sensor Limitations as the Device Becomes too Close to a Doorframe ………….………………………13
Figure 11: Device Response Given Full or Partially Path Obstruction …………..…..……………..…………..…..14
Figure 12: Device Obstacle Avoidance Routine …………..…..………………………………………….…..……..14
Figure 13: Device Path Given a Dead End or Right Hand Turn …………..…..……………..………………….…..15
Figure 14: Device Response Given a Left Hand Turn ………………………………………………………..……..16
Figure 15: PID Library Source Code, PID_compute() Method …………..…………………………………..……..18
Figure 16: Servo Turn Conditionals …………..…..………………………...………………………………..……..19
Figure 17: Obstacle Avoidance Code …………..…..………………………………….……………………..……..20
Figure 18: Parallax Ultrasonic Sensor …………..…..……………………………………………..………………..24
Figure 19: Arduino Uno Microcontroller …………..…..…………………………………………………….……..24
Figure 20: Victor 884 Motor Controller …………..…..……………………………………………………...……..24
Figure 21: Futaba S9402 Servo …………..…..……………………………………………..…………………….....24
Figure 22: Titan 550 Electric Motor …………..…..………………………………………………………….……..24
Figure 23: Tower Hobbies 7.2V 1500 mA Battery …………..…..…………………………………….……..……..24
Figure 24: Turnigy 7.4V 5000mA Battery …………..…..……………………….…………………………..……..25
Figure 25: Front View of Vehicle …………..…..……………………………………………………...……..……..25
Figure 26: Side View of Vehicle …………..…..……………………………………………..……………………..26
List of Tables
Table 1: Victor 884 Factory Specifications …….………………………………………………….......……………..4
Table 2: Futaba S9402 Factory Specifications ……………………………………………………………………….5
Table 3: Arduino Uno Factory Specifications ………………………………………………………………………..6
Table 4: Ultrasonic Sensor Factory Specifications.……………………………………………………….…………..6
Table 5: PI/ Servo Relationship..…………………………………………………………………………...………..19

3 | P a g e
I. Introduction
1.1 Problem Statement
The main objective of this project was to explore the possible scenarios and solutions that
an autonomous vehicle could encounter in real world application. The team determined, from
instructor suggestion and our own personal goals, that the vehicle should be able to follow a wall
at a set distance, avoid obstacles, and maneuver corners. All of these challenges are based
indoors and on relatively level ground to allow the team to understand the fundamentals of
autonomous navigation.
1.2 Applications
As technology continues to improve the possibility of automated vehicles continues to
grow. For example, in today’s market there are a few vehicles which can parallel park without
the guidance of the driver. These vehicles rely on exterior sensors to relay proximity values to
microprocessors which then calculate the needed vehicle trajectory. These sensor values are
monitored by controllers which adjust the steering angle and speed as the car completes this task.
In more recent news, the first autonomous car drove itself across the country, from San Francisco
to New York City. No incidents were reported and no user was required except intricate city
maneuvering.
These examples and many others show the growing importance and possibilities of
autonomous driving. In such a busy world, every minute is precious. One day it will be possible
to read a book, sleep, or get dressed on your way to work instead of wasting that time dealing
with traffic. Though the vehicle the team is developing is a simpler version of the car which
drove across the country, the principles are still the same and the lessons learned could be
applied to your next car.
II. Car Setup
2.1 Hardware and Specifications
To start the project the design team was given a modified Traxxas E-Maxx Model 3906
Battery-Powered All-Terrain Truck. As seen in Figure 2 below, the modified truck utilized two
Titan 550 brushless motors, a Victor 884 motor controller, two Futaba S9402 steering servos,
heavier springs, and various Traxxas gears which lowered the differential speed. Some hardware,

4 | P a g e
such as the radio receiver and the shifting servo, were removed due to their irrelevance to the
project. More detailed pictures of these individual components can be found in Appendix X.
Figure 1: Original E-Maxx Factory Configuration [1]
Figure 2: Modified E-Maxx Configuration
Of the mentioned truck components, the motor controller and the steering servos affect
the wall following capabilities of the device the most. Thus, in order for the microprocessor to
precisely maneuver the vehicle, the limitation of these components needed to be taken into
consideration. The specifications and limitations of each component are shown below.
Table 1: Victor 884 Factory Specifications [2]

5 | P a g e
Table 2: Futaba S9402 Factory Specifications [3]
The team, for instance, needed to make sure that the proper operating voltage was
supplied to both the controller and the cooling fan. This was done through a new wiring setup
which will be explained in section 2.2A. Another concern was limiting the amount of current
sent to the motor controller. The batteries and microprocessor used in this project are well within
these component’s limits. As for moving the vehicle, the team wanted to keep the device at a
relatively slow pace. However, the team did have to maintain a speed greater than 5.4% of the
controller’s maximum value. This pace was determined through trial and error of analog values,
which will be explained in section 4.1.
Moving onto the control system, the main components consisted of an Arduino Uno and
three ping ultrasonic distance sensors from Parallax. The Arduino Uno is a fairly inexpensive
microprocessor which has some great features that can be seen in the table below. From a design
standpoint, the team was mainly concerned with the operating voltage, input voltage limits, and
the DC current output to the pins. As shown in Tables 3 and 4, the output voltages or currents do
not interfere with any of the other parts. The Arduino Uno also has the capability of sending
analog signals required by the servos. One feature which the team did not get to utilize was the
Arduino’s interrupts which were originally going to be used for the obstacle avoidance routine
explained in section 3.2.
Parameter Value
Nominal Voltage 12V
Min/Max Voltage 6V - 15V
Continous Current 60 A
Surge Current 150 A
Nominal PWMInput Pulse (high time) 1-2 miliseconds
Min/Max PWMInput Pulse (high time) .87-2.14 miliseconds
PWMInput Rate (period) 2.1 - 500 miliseconds
PWMOutput Chop Rate 1 KHz
Minimum Throttle 5.40%
Fan Voltage Range 6V - 16V
Parameter Value
Input Signal Analog
Nominal Voltage 6V
Maximum Torque 111 oz-in

6 | P a g e
Table 3: Arduino Uno Factory Specifications [4]
Table 4: Ultrasonic Sensor Factory Specifications [5]
The second component of the control system was the ultrasonic sensors. These sensors
work by recording the time it takes a sound wave to hit an object and then return to the sensor.
Given the sensors pulse speed, the distance between the object and the sensor can be calculated
via D = V*(T/2). Some important limitations of these sensors include the minimum and
maximum sensing distances, the field pattern, and the maximum reading angle of 45. As shown
in Figure 3, at angles greater than 45 the sound waves bounce off of oncoming objects and travel
further away from the sensor. This returns an inaccurate distance value that is equal to the
sensors maximum, three meters. Considering the distance limits of the sensor, the team chose a
wall following distance well within this range of 18 inches.
Parameter Value
Operating Voltage 5V
Nominal Input Voltage 7V - 12V
Input Voltage (limits) 6V - 20V
# Digital I/O Pins 14
# Digital Pins w/ PWMOutput 6
# Interupt Pins 2
# Analog Input Pins 6
DC Current I/O Pins 40 mA
DC Current 3.3V Pin 50 mA
Flash Memory 32 KB
SRAM 2 KB
EEPROM 1 KB
Clock Speed 16 MHz
Parameter Value
Sensing Range 2cm - 3m
Operating Voltage 5V
Nominal Operating Current 30 mA
Maximum Operating Current 35 mA
Nominal PWMInput Pulse (high time) 2 miliseconds
Maximum PWMInput Pulse (high time) 5 miliseconds

7 | P a g e
Figure 3: Ultrasonic Limiting Sensing Angle [5]
Though this cannot be avoided, another issue is the sensors inability to read certain
objects. As seen in Figure 4, the sensor has the ability to read flat objects, parallel to the sensor,
better than round objects. This is because the sound waves bounce off of round objects in
varying directions. Thus the field of sensing becomes wider but the maximum distance the
sensor can read is lessened. Most of the testing performed utilized flat objects such as walls,
boxes, doors, etc.
Figure 4: (Left) sensing field given a flat object (Right) sensing field given a round object [5]
Lastly, the batteries used for this project were 7.2V 6-cell rechargeable NiCd batteries
and Turnigy 5000mAh 2SIP 7.4V 30C batteries. The NiCd batteries were used to power the
Arduino and the servos while the more powerful Turnigy batteries were used to power the
motors.

8 | P a g e
2.2 Modifications
2.2.A Mechanical Modifications
Figure 5 shows some of the other modifications which were previously made on the
Traxxas E-Maxx. Most notably, a clear acrylic platform was cut and mounted to the body struts
of the vehicle. This platform housed the ultrasonic sensors, Arduino Uno, and the battery supply
for the Arduino Uno and the servos. From this platform, the design team went on to change the
location of the ultrasonic sensors, power supply, and breadboard. The sensors were moves to the
front left of the platform with one facing forward, one on a 45 angle, and one facing left. For the
sake of this report the front facing sensor will be considered as sensor 1, the 45 angle sensor will
be considered as sensor 2, and the left facing sensor will be considered as sensor 3. Slight
modifications were also made to the suspension to level out the platform.
Figure 5: Top down view of vehicle layout
2.2B Electrical Modifications
Again, most of the original modified layout was left the same, but a few crucial changes
were made. The existing AA battery pack used to power the Arduino and servos, for example,
was removed and replaced by 2 NiCad batteries wired in parallel. This provided these
components with more current, allowing the vehicle to operate for longer, within the specified
ranges mentioned earlier.

9 | P a g e
Another big change was commonly grounding the Arduino, servos, sensors, and motor
controller. In order for current to flow, there needs to be a positive and negative source to create
a potential difference. This difference is voltage. By commonly grounding these components to
the 5V ground, only 5V of electricity could flow to these components. Well within the specified
limitations of these components.
Lastly, a switch was added in-between the parallel Turnigy batteries and the motor
controller. This was so the design team could quickly cut power to the vehicle in case of
emergency. This also helped to conserve battery life and kept the vehicle from driving away
while programming was being performed. All of these electronic modifications can be seen in
the wiring diagram shown by Figure 6.
Figure 6: Wiring Diagram of the Control System.
III. Logic Design
3.1 Wall Following
The wall following function of the autonomous vehicle had been the primary objective
for the project. This required a means of the system being aware of its distance away from the
wall, reacting to inconsistencies over the course of its path and maintaining trajectory to the best
of its ability. An ultrasonic sensor had been utilized to pull distance data values into the
controller. These values were then handled by a software implemented PI controller algorithm.
The PI controller would perform the task of smoothing the vehicles trajectory and controlling its
reaction to inconsistencies such as small doorways, water fountains and conduit.

10 | P a g e
Simply stated, a PI controller, a variation of the PID controller, calculates the error
between a measured process variable and a defined setpoint, and then attempts to minimize the
error by adjusting the process variable via a feedback loop. The controller utilizes 3 unique
constant parameters to perform the aforementioned task, namely the proportional, integral, and
derivative gains. In layman’s terms, the proportional component is calculated based on present
error, the integral component is based on the accumulation of past errors, and the derivative
component is based on the prediction of future errors [6]. A block diagram schematic is shown
below to illustrate the feedback and process.
Figure 7: PID Functional Block Diagram [6]
There a variety of ways to tune the parameters of PID controller to obtain a desired
response. Several involve mathematical calculations as per the equations shown in the above
figure. For this project, the design team had opted to use a manual tuning method via software
implementation. Following correct setup of the code, to be explained later, each parameter had
been tuned individually, first starting with the proportional gain. This value was increased from
its default value of 0 by increments of 1 until the team began to see oscillations in the vehicles
trajectory at a proportional gain of 4. From here, the integral component had been adjusted in a
similar fashion beginning with 1. This however produced a response that appeared to “ignore”
almost all inconsistencies in the wall that the vehicle had been using to gauge its distance,
rending the vehicle highly unresponsive. Values lower than 1 had been implemented in the
software controller, achieving more and more immediate results to variations in the walls of the
hallway. A value of 0.5 for the integral component had been used in conjunction with

11 | P a g e
proportional gain of 4 selected previously. The vehicle had then been responsive enough to
navigate obscurities in the wall while also being able to quickly achieve steady-state at the
desired setpoint of 21 inches. The derivative component had been experimented with briefly
however yielded worse results than the PI controller alone, and was thus set aside for remaining
duration of the project. The performance of the controller can be viewed in the video file
packaged with this report.
3.2 Obstacle Avoidance
3.2.A Doorway Avoidance
The main function of the vehicle was to maintain a straight line, but a strict PI controller
was not a viable option due to inherent obstacles along the walls. Thus the group began by
developing a logic step to deal with doorways. Tests showed that as the vehicle rolled past a
doorway the ultrasonic readings would spike, especially if the door was open. If these higher
values were used in the PI controller the controller would then try to compensate by drastically
altering course and crashing the device. After looking at the vehicle geometry, the team decided
to add the values from sensor 2 into the PI controller. It is important to note that these other
ultrasonic sensor values would only be plugged into the controller if sensor 2 was reading closer
to an object than the sensor 3. Figure 8 depicts the vehicle traveling past a standard doorway.
Once sensor 3 reads a doorway the vehicle takes roughly a foot of linear travel to respond to the
spike in readings. This slow response corresponds to the tuned parameters of KP and KI
mentioned in the previous section. As the vehicle turns it gets not only closer to the wall but also
closer to the sensing range of sensor 2. Towards the end of the doorway the vehicle implements
values from sensor 2 causing the device to turn away from the wall.

12 | P a g e
Figure 8: Device Path as it Passes a Small Doorway
In some cases this conditional statement worked to avoid doorways, but it strongly
depended upon the width of the doorway and the device’s distance from the wall as it passed the
doorway. These issues can be attributed to the inherent blind spots and sensor limitations of the
system. For example, if the doorway was much wider than 30 inches the vehicle would not be
able to use the values from sensor 2 to correct the vehicles path. For some doorways, however,
the front sensor would be able to see the doorframe. At a certain width even this sensor reaches
its limiting sensing angle, approximately 45 degrees. At this point the controller will treat this as
a large deviation from the set value causing the device to continue turning left until the set value
is reached again. This scenario can be seen in Figure 9 below. For doorways which the front
sensor can detect, an obstacle avoidance routine was implemented that will be explained shortly.
Figure 9: (Left to Right) Increasing Doorway Width Causing Sensor 1 to Reach its Limiting Angle
Blind Spot
Sensing Area

13 | P a g e
If the device is too close to the doorway then another scenario arises where both sensor 2
and sensor 3 are not capable of seeing the oncoming door frame. In Figure 10, below, the vehicle
has reached the limiting angle of sensor 2 and the blind spot is preventing quick acquisition of
the doorframe by sensor 1. Thus, the vehicle must turn even more until the sensor 1 is within the
reading limits. At this point, even if the sensor 1 value was implemented into the PI controller
via another conditional statement, the device is too close to the door frame to correct. For both
scenarios, a conditional statement was introduced to the code which would only trigger if sensor
2 read less than 10 inches or if sensor 1 read less than 15 inches. If either of these conditions is
satisfied the vehicle will use the obstacle avoidance routine which will be explained next.
Figure 10: Sensor Limitations as the Device Becomes too Close to a Doorframe
3.2.B Obstruction Out Front
In order to identify an obstruction located in front of the device it uses both the 45 and the
0 sensor as described in the previous section. Figure 11 depicts two common scenarios that the
vehicle could encounter as it drives along the wall. The first is an obstruction completely in front
of the vehicle and the other is an obstruction that is only slightly in the path of the vehicle. If the
object is completely in front of the vehicle, sensor 1 will trip the conditional statement before
sensor 2. On the other hand, if the obstruction is only partially in front of the device sensor 2 will
trip the conditional since the sensor 1 will continuously read greater than 15 inches.

14 | P a g e
Figure 11: Device Response Given Full or Partially Path Obstruction
As briefly described in the previous section, once the obstacle avoidance routine is
tripped the device will begin taking evasive maneuvers. First, the ultrasonic readings and the PI
controller are suppressed. Next, the device backs up for so many seconds while the wheels are
turned at an angle of 135 degrees. The device then drives forward while the wheels are turned at
an angle of 45 degrees. Once this is completed the ultrasonic values and the PI controller are then
turned back on and the device continues to correct and follow the wall. This process can be seen
in Figure 12 below.
Figure 12: Device Obstacle Avoidance Routine
3.2.C Dead Ends and Right Hand Turns

15 | P a g e
In these scenarios, the vehicle treats the walls as set of obstacles located directly in front
of it. The vehicle will continue to perform the obstacle avoidance routine until the device is
heading in the same direction as it came or it makes the right hand turn of a hallway as seen in
Figure 13.
Figure 13: Device Path Given a Dead End or Right Hand Turn
3.2.D Left Hand Turns
The vehicle experiences left hand turns when the hallway it is driving down turns into a
hallway intersection or a large object is protruding from the wall. In this case, the main
correction comes from the PI controller. After repeated tests, it was apparent that the larger KI
was hurting the devices ability to make these turns fast enough as to stay 18 inches from the
wall. The further past the intersecting wall the vehicle traveled before beginning the turn the
harsher the impact angle of the device. Implementing the 45 sensor values into the PI controller
helped to alleviate this issue but did not completely solve it. The other scenarios were solved
after inserting the obstacle avoidance routine. Figure 14, below, depicts these two scenarios the
vehicle encountered after making the left hand turn. The first scenario uses the PI controller to
bring the device back to 18 inches from the wall while the second uses the obstacle avoidance
routine to back up turn and then use the PI controller to settle the device.

16 | P a g e
Figure 14: Device Response Given a Left Hand Turn
IV. Software Development
Note: All unique and modified code is included in the appendices of the report, fully
commented for convenience. Below is a more detailed walkthrough of the program execution
and developmental process.
For sensing distance from the wall, a Ping))) Ultrasonic sensor had been mounted to the
left-hand side of the vehicle which would transmit and receive high frequency sound waves.
Example code had been modified from the NewPing library page of Arduino’s open source
website to trigger an emission pulse from the ultrasonic sensor and then change the sensors status
from an output to an input in which it would, in most cases, receive the sound pulse previously
emitted. The program was then designed to store the time value of the duration from which the
pulse had travelled and returned in the variable duration, accomplished through the use of a pre-
defined NewPing library method. From this point, another function had been called within the
sensor read function, which simply converts the stored duration to an inch value according to
pre-defined hardware specifications. Returning to the function, an inch value is now stored in the
variable inches, and returned upon exiting the function. This code had been placed in a custom
function to enable the design team to pull accurate distance data from any Ping sensor linked to
the controller board at any point during in the program. This also eliminated the need for lengthy
and messy sections of code. The function properties had also been modified to return a data type

17 | P a g e
of double instead of the default integer value. This gave the readings much higher resolution with
distance values and thus, the vehicle could be more responsive.
The team knew that there had been a desired setpoint of 18 inches away from the wall,
established on the first day of the class. The ultrasonic used to gauge distance from the wall had
been offset into the vehicle body, thus 3 inches had been added to the setpoint of 18 making it
21. The team understood that the vehicle was required to maintain a certain distance from the
wall, and the team also knew that the vehicle must adapt reactively to changes in distance as it
travelled. The solution to this problem had been a PID controller, or PI because the Derivative
component had been set to 0, mentioned earlier in the report. Research had been conducted, and
it was found that the Arduino website also had an open source PID library available for
download. This code was implemented in the project to return a modified output value which is
adjusted based on the input from a ping sensor and the desired setpoint of 21. An example of the
PID input function is shown below.
PID PID1(&In1, &Out1, &Set1, 4.00, 0.5, 0.00, DIRECT);
The parameters accepted by the method are the input, output, desired setpoint, controller
parameters, and on-off state respectively. The sampling time for the controller had been set to the
smallest possible time of 1 millisecond via a method from the PID library. During testing with
the vehicle, it had been found that the PID computation algorithm in the PID library functioned
similarly to an Arduino PWM output. How this works, is that the Arduino can supply a voltage
to a load anywhere between 0 and 5V on a pre-defined scale of 0 to 255. 0 corresponds to 0
Volts and 255 corresponds to 5 Volts, with fractional values lying between. The PID code was
developed to restrict the integral gain and total output gain to the same range as the Arduino
PWM output, 0 to 255 respectively. This proved to be problematic for the team because the PI
controller output was used to position the steering servos appropriately. The servos work on an
angular scale, with 0 degrees on the positive x-axis corresponding to a complete rightward
position, and a maximum of 180 degrees corresponding to a complete leftward position. 90
degrees would therefore position the wheels of the vehicle straight forward. As a side note, the
wheels had been restricted to turning between the angles of 45 degrees and 135 degrees because
of the mechanical limitations of the vehicle. Any angles beyond these points would cause strain

18 | P a g e
on the components and cause jittering. The problem encountered however was that it was unclear
how to mathematically turn the servos in either the left or right directions using only the
Arduino’s and PI’s 0 to 255 scale.
The challenge was address by modification of the PID libraries source code, shown in
Figure 15 below.
Figure 15: PID Library Source Code, PID_compute() Method
The modifications had been dated for appropriate documentation. There had been two sets of
conditionals limiting the maximum and minimum values that the integral and total outputs could
achieve. These conditionals had simply been commented out whereas the code would now be
able to return a full spectrum of both positive and negative values on an uneven scale, which had
then been utilized for even positioning of the servos. Now that an even output scale from the PI
had been achieved, it had been necessary to translate this mathematically to a scale that the servo
driving function could use. This had been accomplished by taking the PI controller output and
finding the percent difference between it and the desired setpoint. The percent difference can
then be used to compute a percent deviation on the restricted, 45-135, degree scale from which
the servos would be positioned. The conditionals below represent the aforementioned
mathematical process and a sample table of controller inputs, outputs, and servo angles are

19 | P a g e
displayed below according to that conditional. Recall that the input is a distance value pulled
from the ultrasonic sensor #3 on the left-hand side of the vehicle.
Table 5: PI/ Servo Relationship
Figure 16: Servo Turn Conditionals
Looking at the above table, the green illustrates when the wheels are straight and the vehicle is
travelling on its intended course. The yellow marks where the vehicle achieves its maximum
turning angles with 45 being the sharpest right turn it can possibly make and 135 the sharpest left
turn it could possibly make. The calculations are accurate up to 2 decimal places as per the
modification to the Ping distance return function. The Servo.write() function will only accept
integer values however so some accuracy is lost. The wheel turning is as smooth as possible
through the given hardware components and programming methods.
At the end of the repeated loop in the microcontroller, the vehicles drive servos are
instructed to turn 12 degrees (value of 102) in the positive direction, achieving a moderate
forward speed. Faster speeds are possible however the PI controller becomes less and less
accurate, and thus the vehicle cannot react quick enough to adapt to distance changes along the
wall. It should be noted that there had been complications with the drive servos. They did not
turn according to Arduino Servo library’s description. Some angles did not produce movement at
all when they indeed should have. This is likely attributed to a faulty electrical setup, but
troubleshooting did not yield any solutions.
Once the wall following component of the project had been completed, the team noticed
that the vehicle still retained issues with avoiding larger obstacles and navigating corners. An
obstacle avoidance section had been added to the program allowing the vehicle to use 2
additional ultrasonic sensors, namely sensor 2 (45 degrees) and sensor 3 (forward facing). This
Setpoint Input Output Servo Angle
21 15.67 24 45
21 16.33 21 45
21 17.89 14 60
21 21 0 90
21 24.11 -14 120
21 25.67 -21 135
21 26.33 -24 135

20 | P a g e
section of code is executed before the computation of the PI controller because the controller was
adapted to handle the smallest input between the left side sensor 1 and the 45 degree sensor 2.
The vehicle had now been able to begin turning away from the wall earlier if it found itself
entering the wall at too sharp an angle for the left-side sensor to pick up accurately. This is the
pre-emptive section of obstacle avoidance because the vehicle tries to preserve its forward travel,
however there is another more complicated section of obstacle avoidance that acts as a last
resort. A conditional checks the front facing sensor and 45 degree sensor for how close an
incoming object is, and once an object meets certain threshold values, a second obstacle
avoidance technique is triggered. At this point, the vehicle has moved beyond a point where it
will successfully be able to move forward around an object. Instead of collision, the vehicle stops
for ½ second and turns the steering servos 135 degrees to the left and backs up for 1.25 seconds.
The steering servos then adjust to 45 degrees rightward and continue driving forward.
Figure 17: Obstacle Avoidance Code
Obstacle avoidance had been the final addition to the code and concluded the development of the
vehicle for the Spring 2015 Term.
V. Performance

21 | P a g e
The performance of the vehicle (as can be seen in the attached video) was as expected; all
major performance objectives were achieved. The vehicle was able to autonomously follow a
wall, avoid various obstacles on the left side (including doorways), and make turns to both the
left and right as the setup of the hallway dictated. Left turns were made smoothly and in one
motion, while 90 degree right turns required one or several reversals in order to successfully
complete. Making a 90 degree right turn in one motion would require beginning the turn at 21”
from the wall, based on the physical turning radius of the vehicle, which would not be feasible.
The performance involving reversals to make a 90 degree right turn is acceptable for this
application, even if not ideal.
In some cases, the vehicle will come across an object on the right side that is not
detected, and is not able to avoid it. This is why in figure 1 a front-facing camera was installed
on the right side. This would help alleviate blind spots in front and avoid this issue, but logic for
handling objects detected by this sensor was not implemented in the code due to time constraints.
Future work would include implementing this sensor or some similar orientation to take account
of other more complicated object avoidance scenarios.
The wall following was relatively smooth, even in the presence of various obstacles.
However, some more detailed PI parameter tuning may be advantageous. Including a derivative
term could have been useful as well. Although the smoothness of the performance was good in
general, there was still room for further improvement if more time was available for parameter
tuning.
VI. Conclusion
At the end of this project the main objectives were met. A vehicle was created that
followed a wall and was able to avoid obstacles. The objectives were accomplished by using
sonar distance sensors to obtain real time data. This data was then fed into the Arduino controller
to control the steering servos. This data was in a constant feedback to a PI controller was
programmed into the Arduino controller. This was done so that the following of the wall would
be smooth straight line and not in a jerky motion. The PI control program filtered out the noise
from the sensors and adjusted the turning rate based from how far the truck was from the wall
and obstacles. Any future work that is recommended to be performed can be found in the next
section.

22 | P a g e
VII. Future Recommendations
This project has endless possibilities for improvements to many different components and
systems of the vehicle. One possibility is to change the sensor layout or type. Currently there are
three ultrasonic sensors oriented at various angles in the front left corner of the vehicle. This
sensor grouping can be replicated in the other corners of the vehicle in order to eliminate blind
spots and allow the vehicle to perform more complicated tasks such as following a wall on the
right side of the vehicle or detecting more complicated obstacles that require specialized
maneuvering. An alternative to this setup would be to use a range-finding sensor (either
ultrasonic or laser) that can rotate 360 degrees and allow the vehicle to map its surroundings and
perform precise movements. Improvements can be made to the programing as well. Currently
backing up to allow for a turn in obstacle avoidance relies on a time constant which is imprecise
and the addition of a rear sensor can allow for more accurate movement.
A situation the group ran into various times during testing was when individuals in the
hallway moved in the way of the vehicle and caused a false object detection. A possible solution
would be to create a sensor array that is mounted on servo-motors that would allow the vehicle to
track moving objects and determine if they are going to be in the way of the vehicle. This motion
tracking and intercept capability would be a large undertaking for the group and would have
required more time and resources, but this tool is entirely possible to create and would allow for
the vehicle to have better obstacle avoidance capabilities.

23 | P a g e
VIII. References
[1] Traxxas.com, 'E-Maxx: 1/10 Scale Electric 4WD Monster Truck with TQi Traxxas Link
Enabled 2.4GHz Radio System | Traxxas', 2015. [Online]. Available:
https://traxxas.com/products/models/electric/39036emaxx?t=specs. [Accessed: 05- Jun- 2015].
[2] Vexrobotics.com, 'Victor 888 Motor Controller - VEX Robotics', 2015. [Online]. Available:
http://www.vexrobotics.com/217-2769.html. [Accessed: 05- Jun- 2015].
[3] Servodatabase.com, 'Futaba S9402 Servo Specifications and Reviews', 2015. [Online].
Available: http://www.servodatabase.com/servo/futaba/s9402. [Accessed: 05- Jun- 2015].
[4] Arduino.cc, 'Arduino - ArduinoBoardUno', 2015. [Online]. Available:
http://www.arduino.cc/en/Main/ArduinoBoardUno. [Accessed: 05- Jun- 2015].
[5] Parallax.com, 'PING))) Ultrasonic Distance Sensor | 28015 | Parallax Inc', 2015. [Online].
Available: https://www.parallax.com/product/28015. [Accessed: 05- Jun- 2015].
[6] Wikipedia, 'PID controller', 2015. [Online]. Available:
http://en.wikipedia.org/wiki/PID_controller. [Accessed: 05- Jun- 2015].
[7] Traxxas.com, 'Motor, Titan 12T (12-Turn, 550 size) | Traxxas', 2015. [Online]. Available:
https://traxxas.com/products/parts/motors/titan12T. [Accessed: 05- Jun- 2015].
[8] www3.towerhobbies.com, 'TowerHobbies.com |Tower Hobbies NiCd 6-Cell 7.2V 1500mAh
Stick Standard', 2015. [Online]. Available: http://www3.towerhobbies.com/cgi-
bin/wti0001p?I=LXJA83. [Accessed: 05- Jun- 2015].
[9] HobbyKing Store, 'Turnigy 5000mAh 2S1P 7.4v 30C Hardcase Pack (ROAR APPROVED)',
2015. [Online]. Available:
http://www.hobbyking.com/hobbyking/store/__21005__Turnigy_5000mAh_2S1P_7_4v_30C_H
ardcase_Pack_ROAR_APPROVED_.html. [Accessed: 05- Jun- 2015].

24 | P a g e
[10] T. Eckel, 'Arduino Playground - NewPing Library', Playground.arduino.cc, 2015. [Online].
Available: http://playground.arduino.cc/Code/NewPing. [Accessed: 06- Jun- 2015].
[11] B. Beauregard, 'Arduino Playground - PIDLibrary', Playground.arduino.cc, 2015. [Online].
Available: http://playground.arduino.cc/Code/PIDLibrary. [Accessed: 06- Jun- 2015].
Appendix IX: Component Pictures
Figure 18: Parallax Ultrasonic Sensor [5] Figure 19: Arduino Uno Microcontroller [4]
Figure 20: Victor 884 Motor Controller [2] Figure 21: Futaba S9402 Servo [3]
Figure 22: Titan 550 Electric Motor [7] Figure 23: Tower Hobbies 7.2V 1500 mA Battery [8]

25 | P a g e
Figure 24: Turnigy 7.4V 5000mA Battery [9]
Appendix X: Final Vehicle Pictures
Figure 25: Front View of Vehicle

26 | P a g e
Figure 26: Side View of Vehicle
Appendix XI: Final Arduino Code
NewPing Library Credit [10]
PID Library Credit [11]
Sketch Code (Modified to Fit Word Document):
//----------------------------------------------------------------------------------------------------------------------------//
// Sketch: MEM380 ST Automated Vehicles
// Date: 6 June 2015
// Author: Tyler Darrah
// Contributors: Jon Affleck, Elliot Farquhar, Jeff Fuller, Robert Stricek
//
// Purpose: This program had been developed for an autonomous vehicle to navigate Drexel
// University hallways, with the additional functionality of avoiding obstacles such as
// small doorways, water fountains, and conduit.
//----------------------------------------------------------------------------------------------------------------------------//
//------------------------------------------------------Libraries-----------------------------------------------------------//
#include <PID_v1.h>
#include <NewPing.h>
#include <Servo.h>
Servo drive;
Servo steer;
//------------------------------------------------Variable Declarations-------------------------------------------------//
const int ping1 = 11; // Front Left sensor pin //
const int ping2 = 8; // 45 degree angled sensor pin //

27 | P a g e
const int ping3 = 9; // Left-side forward mounted sensor pin //
const int ping4 = 10; // Front Right sensor pin // [UNUSED]
int SampleTime = 1; // Controller sampling time //
double FLread; // Create variable to store values for front left sensor //
double F45read; // Create variable to store values for 45 angled sensor //
//----------------------------------------------PID Controller Definition----------------------------------------------//
// Define PID variables // In1 will store values for the left-mounted Ping sensor //
double In1, Out1, Set1, In2, Out2, Set2;
// PID #1 parameters // Format (Input, Output, Setpoint, Kp, Ki, Kd, Mode) //
// Mode(DIRECT, MANUAL)// DIRECT = Controller on // MANUAL = Controller off //
PID PID1(&In1, &Out1, &Set1, 4.00, 0.5, 0.00, DIRECT);
//------------------------------------------------Function Prototypes---------------------------------------------------//
// Ping time-to-distance conversion function prototype //
// Modified to return variable type double //
double microsecondsToInches(double microseconds);
//Function prototype for reading a Ping sensor on any pin //
double Ping_Read(int sensor);
//--------------------------------------------Program Setup (to run once)---------------------------------------------//
void setup() {
// initialize serial communication:
Serial.begin(9600); // Serial window set, 9600 bit/s //
PID1.SetSampleTime(SampleTime); // Decrease sampling time for controller to 1ms //
steer.attach(4); // Attach steering servo to pin #4 //
drive.attach(6); // Attach driving servo to pin #6 //
Set1 = 21.0; // Setpoint 21 inches //
In1 = Ping_Read(ping3); // Read Ping sensor pin #9 (Left Front) and set to Input 1 //
PID1.SetMode(AUTOMATIC); // Set controller to function continuously //
}
//------------------------------------------Program Setup (to run continuously)--------------------------------------//
void loop()
{
In1 = Ping_Read(ping3); //Read-in a value from the PID sensor
FLread = Ping_Read(ping1); //Read-in a value from the front mounted sensor
F45read = Ping_Read(ping2); //Read-in a value from the 45 deg angled sensor
//---------------------------Avoidance--------------------------------//
/* The first section is a preliminary attempt
at avoiding the wall but still maintaining

28 | P a g e
forward travel. This uses the 45 degree
angled sensor to first detect an incoming
obstacle and begin steering away from it.
This changes the PID input to the 45 sensor
which produces a smaller value and sharpens
the turning angle. */
if (F45read < In1)
In1 = F45read;
/* This section of obstacle avoidance can be
considered as a last ditch effort. The
vehicle is at a point where it will no
longer be able to maintain forward travel
and steer around the obstacle. The vehicle
must execute a reverse maneuver backing away
from the wall and turning right. */
if (F45read < 10 || FLread < 15)
{
drive.write(90); // Stop the vehicle //
delay(500); // Delay 1/2 second until vehicle stopped //
steer.write(135); // Turn wheels complete left //
drive.write(85); // Reverse moderate speed //
delay(1250); // Delay program, reverse for 1.25 seconds //
steer.write(45); // Turn wheels complete right //
drive.write(102); // Forward at normal speed //
delay(1250); // Delay program, forward for 1.25 seconds //
In1 = FLread; // Assign the smallest value to PID input //
}
//---------------------------Steering Algorithm----------------------//
/* This stores the output value of the PID
controller in the variable val according
to Out1's value. Negative Values correspond
to a left turn and positive value are right
turns. Values in between are handled by the
equation below to compute fractional turning
angles according to the controller output. */
PID1.Compute();
double val;
if (Out1 > 21)
val = 45;
else if (Out1 < -21)
val = 135;
else

29 | P a g e
val = ((21 - Out1)/42)*90 + 45;
steer.write(val);
//------------------------------Drive--------------------------------//
/* A value of 102 is written to the Drive Servo
This value is not accurate to angular
displacement but works well enough to
accomplish the intended task. Troubleshooting
of system should be performed. */
drive.write(102);
}
//--------------------------------------Modified Ping Sensor Return Function---------------------------------------//
double Ping_Read(int sensor)
{
double duration, inches;
// The PING))) is triggered by a HIGH pulse of 2 or more microseconds.
// Give a short LOW pulse beforehand to ensure a clean HIGH pulse:
pinMode(sensor, OUTPUT);
digitalWrite(sensor, LOW);
delayMicroseconds(2);
digitalWrite(sensor, HIGH);
delayMicroseconds(5);
digitalWrite(sensor, LOW);
// The same pin is used to read the signal from the PING))): a HIGH
pinMode(sensor, INPUT);
duration = pulseIn(sensor, HIGH);
// pulse whose duration is the time (in microseconds) from the sending
// of the ping to the reception of its echo off of an object.
inches = microsecondsToInches(duration); // convert the time into a distance
return inches;
}
//--------------------------------------Ping Time to Distance Pre-defined Function--------------------------------//
double microsecondsToInches(double microseconds)
{
// According to Parallax's datasheet for the PING))), there are
// 73.746 microseconds per inch (i.e. sound travels at 1130 feet per
// second). This gives the distance travelled by the ping, outbound
// and return, so we divide by 2 to get the distance of the obstacle.
// See: http://www.parallax.com/dl/docs/prod/acc/28015-PING-v1.3.pdf
return microseconds / 74 / 2;
}

30 | P a g e
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Arduino PID Library Source Code (After Modification) :
/* Compute() **********************************************************************
* This, as they say, is where the magic happens. this function should be called
* every time "void loop()" executes. the function will decide for itself whether a
new
* pid Output needs to be computed. returns true when the output is computed,
* false when nothing has been done.
**********************************************************************************/
bool PID::Compute()
{
if(!inAuto) return false;
unsigned long now = millis();
unsigned long timeChange = (now - lastTime);
if(timeChange>=SampleTime)
{
/*Compute all the working error variables*/
double input = *myInput;
double error = *mySetpoint - input;
ITerm+= (ki * error);
//---------- EDIT: 4/30/2015 ---------------//
//if(ITerm > outMax) ITerm= outMax;
//else if(ITerm < outMin) ITerm= outMin;
//------------------------------------------//
double dInput = (input - lastInput);
/*Compute PID Output*/
double output = kp * error + ITerm- kd * dInput;
//---------- EDIT: 4/30/2015 ---------------//
//if(output > outMax) output = outMax;
//else if(output < outMin) output = outMin;
//------------------------------------------//
*myOutput = output;
/*Remember some variables for next time*/
lastInput = input;
lastTime = now;
return true;
}
else return false;
}

Autonomous Vehicles Project

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (17)

Similar to Autonomous Vehicles Project

Similar to Autonomous Vehicles Project (20)

Autonomous Vehicles Project