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 PWM Input Pulse (high time) 1-2 miliseconds

Min/Max PWM Input Pulse (high time) .87-2.14 miliseconds

PWM Input Rate (period) 2.1 - 500 miliseconds

PWM Output 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/ PWM Output 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 PWM Input Pulse (high time) 2 miliseconds

Maximum PWM Input 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 SpotSensing 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; }