a car that can track its own location and calculate the direction and distance needed to get to a...

7/27/2019 A Car That Can Track Its Own Location and Calculate the Direction and Distance Needed to Get to a Final Destinati

1/14

"A car that can track its own location and calculate the direction and distance

needed to get to a final destination given by user inputs."

Elevator Pitch

For our final project, we built a self-driving car that takes in inputs for a final destination and

drives itself from its initial location to the final destination. The idea for this final project requires

an LCD to display the location that the car is already at and allows a user to input coordinates for

where he or she would like the car to drive itself to. By using a GPS receiver, the car can track its

initial location and use the compass to direct where it should go, constantly updating its GPS

location. This idea was chosen because of an interest in GPS and because we both wanted to try

something different from our usual lab assignments and something new outside our scope of

knowledge.

High Level Design

Goal


2/14

The goal of our project was to design and fabricate a low cost self-driving toy car. The rationale

behind this project was to utilize every day materials for a low cost self-driving car that could be

used to help take a person from point A to B. Since commercial GPS units are relatively

straightforward devices, the main goal for this was to use its data and be able to extract needed

information from it.

This self-driving toy car was done by having the central unit connected to a GPS receiver and

compass send information to the microcontroller to determine where the car is and continue to

send coordinates in order to see whether or not it is making progress towards the final destination.

With the central unit receiving information, the compass will have its data also read by the MCU to

see the direction the car is facing and to help determine which turns the car needs in order to

arrive at its final destination.

Societal Impact

There are always alternatives to ease a persons drive from here to there. Starting with cruise

control, which only monitors ones speed, and then leading to recent self parking cars or Roombas

or self driving cars, there has been a growing field and research into self operating systems. This

societal impact also had an affect on what led us to this idea of a project.

Background Math

Background math required geometry to figure out the angle and also which direction the car

should move towards. In addition to this, there was additional arithmetic needed to understand

the movement of the car and the algorithms used to find the angle and using that to move the car

closer to its final destination.

Block Diagram

The logical structure of this car can be seen in the block diagram below. This displays the main set

up of the core control of the toy car.


3/14

The microcontroller used was the ATMEGA1284. This acted as the main source to handle the

compass, GPS, LCD and car motor. The arrows point to the direction that is being used. The

microcontroller uses the GPS coordinates and compass angle from the respective devices as input

and then outputs to the motor and LCD the results. However, in order to do obstacle avoidance,

we added an additional board, the Raspberry Pi Board.

Tradeoffs and Issues

Issues that arose were the powering supplies and the electromagnetic interference that could be

caused inside certain buildings and the lack of signal for the GPS receiver. The powering supplies,

if not maintained at a certain voltage or above, would prove to not provide enough power to the

motor to give it enough thrust to continue movement. In addition to that, by calling several

components off the three 1.5 V batteries, the batteries quickly deteriorated or were not distributed

correctly. In order to remedy this, we used the Raspberry Pi Board voltage sources to pull the GPS

off the 3.0 V from the three 1.5 V batteries below that was also connected to the motor and

compass. This alleviated the stress on those batteries and provided smoother route movements in

the code.

Another tradeoff was that because the GPS needed a 3.3 V supply at its optimal value and the

Raspberry Pi Board provided exactly that, we decided to add that extra weight for the Raspberry Pi

Board battery in order to have this source. In addition to having this extra component, this leads


4/14

us to having more applications be built upon this system onto the Raspberry Pi Board specifically

such as obstacle avoidance.

Lastly another issue that arose while testing was the compass angle. Since the compass needs to

be on a flat surface or an evenly inclined surface, any bumps that the car runs over may alter the

compass angle temporarily. By having the LCD refresh and since the compass is running in a while

loop, this should be fixed within milliseconds.

Patents/Copyrights/Trademarks

No existing patent or copyrights or trademarks exist that are relevant to our project currently.

Program & Hardware Design

Software

The code was broken up into several portions. The software coding needed was used to extract the

GPS coordinates (latitude, longitude), compass direction, and motor instructions. In addition to

this, other portions of the code included displaying the current location and wanted destination on

the LCD screen and also code to take the Raspberry Pi Board details of obstacle avoidances.

The purpose of the compass was to retrieve the angle in respect to north in order to determine the

way the car was pointed and which way it should start to move in order to achieve its desired

location. We went through a series of case statements to be switched around depending on the

instruction the compass is sending. By hardwiring the compass to determine the direction of

specific ports (i.e. CLK is an input), we had to send a series of commands so that the MEGA1284

would know whether or not the data was valid. Following the data sheet, we set up different

statements that would send a COMPASS_RESET command, COMPASS_START_M command, and

COMPASS_READ_M command. The compass requires an input of 30 bits with the first 4 bits being

command and the second 4 bits being a response to check the status and the last 22 being the x

and y values to be used to find the angle. The last 22 bits with the first 11 being x and the last 11

being y were then used to find the angle with arctan. Modifications were made to the angle to

make it read 0 degrees north, 90 degrees when facing east, 180 degrees facing south, and 270

degrees facing west. By combining this with the LCD, our results are then posted to the LCD to see

where the angle is and is consistently updated.

In order to obtain a current location, a GPS receiver was used. However, the GPS receiver retained

its details in NMEA format. Therefore a NMEA parser was needed to only extract the needed details

such as latitude and longitude for the purpose of this project. This parser was borrowed from Chris

Anderson and Jordi Munoz with the information foundhere.
http://diydrones.com/profiles/blogs/using-the-5hz-locosys-gps-withhttp://diydrones.com/profiles/blogs/using-the-5hz-locosys-gps-withhttp://diydrones.com/profiles/blogs/using-the-5hz-locosys-gps-withhttp://diydrones.com/profiles/blogs/using-the-5hz-locosys-gps-with


5/14

By using the parser, this only gave us an output of

$GPGGA,053740.000,2503.6319,N,12136.0099,E,1,08,1.1,63.8,M,15.2,M,,0000*64 and

therefore the parser had to be modified to only extract the needed data. Therefore we had to

thoroughly understand the parser code in order to retrieve the needed data. After this, we wrote

additional code in the GPS to display onto the LCD and also implemented UART to help debug.

The motor code used an algorithm that can be best seen visually. Essentially, our idea was to have

two angles, the current angle and the destination angle. The first angle is the current angle which

is found from the compass as a data input and tells the car whether or not it is facing in the right

direction or if it should be turning. The second angle, the destination angle, computes where the

car should be facing. For example, if the car were facing the engineering quad in the Sage parking

lot, but was trying to go towards Sage, it would need to turn and face towards the south.

Therefore, depending on how it was facing north (at what angle) it would need to turn itself

around. Using the difference of the current angle and the destination angle and with some simple

arithmetic, this determined whether the car should turn left or right.

In the LCD, the first step was to initialize the LCD and to configure the pull up resistors, and to

determine what resistor value would be needed to help with the contrasting. This is later seen in

the references and also is mentioned in the hardware of the LCD settings.

In addition to having these features, another additional feature that we added was a camera

controlled by the Raspberry Pi Board. This is currently a developing work that could lead to furtherexpansions of Willy such as obstacle avoidance.

Hardware

For the hardware, it was rather tough to fit everything completely on the board with all of our

components. By very careful planning, we managed to fit everything on the board and avoided

throwing off the magnetic field for the compass. Most of the wiring occurred underneath the perf-

board that was screwed onto the top of the car and its motor.

The hardware design for our project was fairly complex to set up. The general idea is separated

into components. The LCD was connected to PORTC, the GPS connected to PORTD, the motor

connected to PORTA, and the compass connected to PORTB. Additional things connected to the

ports were the output for the Raspberry Pi Board, which used leftover ports from PORTB. Both the

compass and GPS used serial data. And resistors were used to avoid any short-circuiting. However,

handling the power became slightly more complicated since the MCU ran off 9 V, the cars remote

control ran off 3 V, and the GPS receiver ran off 3.3 Volts. Power supplies that were already

hooked up were the motors power supply, which came with the store bought toy car, and the

Raspberry Pi Board, which we already had a battery pack for at 4.5 V. Originally the remote

control with the store bought car came with a battery pack, but in order to condense the size and


6/14

make this car more portable we removed that battery pack and had to find other means of

achieving 3 V. To resolve this, the motors battery pack also used to help power the 3 V for the

remote control transmitter. The Raspberry Pi Board has a 3.3 V output, which we used instead of

using a linear regulator, which would be powered by the MCU.

What we tried that didn't work (software and hardware)

In the GPS, something that we initially tried were attempting to parse the GPS NMEA format

information ourselves. This proved to be very tedious and not worthwhile. Since the NMEA code is

so lengthy and one of the popular forms of GPS data, we found from the sparkfun website, a good

resource to refer to for a parsing code.

n the compass, initially we tried to use SPI handling and since the MEGA1284 expected more bits

than the compass data really required, modifying this to make sure there were empty bits that

would not affect the compass reading but would also suffice the MEGA1284 seemed to be much

more than SPI slave and master. Therefore, we simply manually toggled the clock and also ran the

data with delays so that it would be delayed 40 ms+ since the data sheet specified after 40 ms

that the data was good.

Something we attempted in the hardware was building a H bridge to control the motor and

organize which direction applied to which. However, we found that a tri-state buffer could suffice

and do the jobjust as well. Therefore through the complexity of building ones own H Bridge, we

decided against purchasing an H bridge to limit our budget and make this most cost efficient and

instead used a tri-state buffer at a cheaper cost.

Other hardware attempts that we tried but did not work was connecting several things to the 4.5 V

source (the three 1.5 V batteries) which drained the power too quickly and therefore made the car

inefficient and also cost some of the components to not function completely or at all. This was

modified by adding more voltage sources to ease the stress on the 4.5 V source.

Results

Execution

The execution of this design is running within seconds. The LCD updates about eight times a

second while the compass is set to update every 50 milliseconds. The GPS collects data about 2 to

3 times a second. This helps keep the car up to date since the GPS coordinates threshold, which is

0.00005 leads the car to be within 5 meters of an exact location. Changing the threshold in the

code would bring the car closer to one exact point but for purposes of this project we just wanted

to bring it to the general location of a point based off of a latitude longitude point. By having a

fairly updated compass, LCD, and GPS, this gives us a good accuracy.


7/14

Accuracy

Accuracy outdoors shows that the GPS is accurate to the 0.00005 degree difference causing a 1.5

meter difference in longitude and 5 meter difference in latitude points as long as the signal is clear

and there is a fix of four GPS satellites. The compass outdoors is also very accurate based off of

readings on a compass app and shows that it is within +10 degrees. Indoors however, the

accuracy starts to falter due to metals in the building that may alter the compass reading and the

inability to receiver a clear signal on the GPS receiver.

Safety

Enforcing safety in this design was by adding a kill switch on the car. Attached by a leash, the

user has control over when to stop the car immediately or to let it continue running. There is no

delay in this switch and it immediately stops the car. Another safety consideration could be the

exposed power sources but two out of three are hidden under the circuitry while the 9 V battery

source could also be placed under but it placed currently to help balance the car. There are no

other safety issues that warrant consideration because the car runs at a fairly slow rate.

Other Issues or Interferences

Since our toy car includes radio control, there is some RF interference that may interfere with

other peoples designs. Those that may be on the same frequency as the radio control will be

affected and may also affect our communication between the motor and the tri-state buffer that

connects to the transceiver sending messages to the motor. Other issues of interfering with other

peoples design would be due to magnets or metals or any electromagnetic interference which

would affect the compass in our design and possibly lead to a bias in the angle calculations.

Usability

Anyone and everyone can use this self-driving toy car. It even has a leash to help those that

may be disabled in vision in helping to lead it to point B. Safety issues should be noted and

followed though.

Conclusions

Our results met our expectations with the exception of the car motor being unable to sustain the

load and get enough torque to move unless it is on an incline. The results we attained from the

GPS is accurate to the meter and the compass has an error of less than 10%. Therefore our design

in terms of the results exceed our expectations since originally we thought we would be within 10-

15 meters based off GPS L1 C/A but with a better GPS receiver, weve managed to cut down to

within a meter of accuracy or less for the current destination and within less than 5 meters within


8/14

the destination point but this can be changed depending on what we want our threshold to be.

Since the LCD has a limited character display, weve decided to go to the 1000th decimal place for

both longitude and latitude.

Things that we would do differently would be to have a better car motor that could carry such a

load and have a higher torque in order to go uphill. Luckily, the board on top of the car connecting

to the motor of the car is easily disconnected and can be transferred over to a stronger car motor.

In addition to this change, other things that would be done differently would be to have a better

testing set up for the GPS. Since the GPS receiver only receives a fix and a good signal outdoors,

having a mobile testing method would have been better to test the GPS. In lab, testing the GPS

was unreasonable and therefore most of this setting up the GPS parser and making sure it was

functioning correctly had to be done at another location.

Code that was reused was the NMEA parser. This parser was borrowed from Chris Anderson and

Jordi Munoz with the information foundhere.

There was no need to sign a non-disclosure to get a sample part since we did not have to deal with

retrieving parts from companies. In our design, we somewhat reverse engineer a cheap RC car

that was bought at Walmart. However, by disassemblying this car, we voided any warranty to it

and also added our own additional components to it, altering some of what it originally was

anticipated to do. We also did not have to deal with patent or trademark issues.

IEEE and Ethical Standards

We tried our best to adhere to all the IEEE standards and the IEEE Code of Ethics when designing

this project. None of them create any constraints on our project. However, for the safety of users

that while our self-driving car does not pose a threat to humans, it is advised to keep children

away from the circuitry since there is no covering over the electronics and therefore leaves a lot of

this exposed. Packaging is something that should be considered for future implementations of this

kind of product. Also since our product is so small, if it were to be used in larger devices or in a

real vehicle and the speed was increased, this could harm people and therefore more safety

features should definitely be implemented in addition to a kill switch. For the purposes of our

vehicle and its sizing scale, a kill switch is enough to satisfy safety constraints.

The self-driving car functions only as well as the weather is and functions best outdoors with a

good signal reception. If the weather permits, then the self-driving car should have no issues.

However, if there is inclement weather, this may alter the GPS reading due to the dilution of

precision being thrown off by its fix on the number of satellites (as long as there are four satellites,

it will find a fix but the more satellites it finds in the air, the better the precision). In addition to

this, it may affect the compass and also affect how the car operates. Also since the car currently

has no obstacle avoidance, this is all under the assumption that the path from its current location
http://diydrones.com/profiles/blogs/using-the-5hz-locosys-gps-withhttp://diydrones.com/profiles/blogs/using-the-5hz-locosys-gps-withhttp://diydrones.com/profiles/blogs/using-the-5hz-locosys-gps-withhttp://diydrones.com/profiles/blogs/using-the-5hz-locosys-gps-with


9/14

to its desired destination is a clear path. Further additions that could be added onto this could be

obstacle avoidance so it stops in front of a wall or will remain on a sidewalk and avoid grassy

areas. By stating these claims about how well our car runs, we have adhered to the IEEE Code of

Ethics.

By following the IEEE Code of Ethics to the best of our ability, this also solves ethical standards.

However an obvious ethical standard that comes into play is the issue of privacy. Since we are

using a GPS tracking device, user privacy is an obvious issue. This is resolved since our device

does not store the location data or do any location data logging that larger companies presently do

and is subject to debate among user privacy. Since our GPS receiver only jots down the last

location and current, and then constantly updates and overrides the previous information, no

logging is taken and therefore this resolves users privacy issues.

Legal Considerations

We made sure to follow any legal restrictions that we found that may have applied to our project.

Legal considerations in this project would include the use of a transmitter which was already from

the RC car bought from Walmart. This should presumably follow the appropriate FCC legal

restrictions already since it was a product bought off the shelves in a public store. We did not alter

the job of the transmitter and the receiver, but merely connected it to logic and the tri-state buffer

to ensure the movement of the car.

Appendix

Acknowledgements

We would like to thank our instructor, Bruce Land, for the support provided in this assignment and

for the opportunity to design a product to expand our own personal interests. In addition to this,

we would like to thank Michael Kilzer and Daniel Lo for helping to debug our code and give

suggestions as to what could possibly have been going awry during our testing simulations.

Schematics

Power


10/14

MEGA 1284 Connection (Ports)


11/14

Tri-state Connection


12/14

References

GPS Data Sheet MEGA 1284 Data Sheet Compass Data Sheet Tri-State Buffer Data Sheet LCD Data Sheet NMEA ParserParts and Cost List

Part Cost per Unit Quantity Total Cost
http://www.sparkfun.com/datasheets/GPS/Modules/LS20030~3_datasheet_v1.2.pdfhttp://www.sparkfun.com/datasheets/GPS/Modules/LS20030~3_datasheet_v1.2.pdfhttp://people.ece.cornell.edu/land/courses/ece4760/AtmelStuff/mega1284full.pdfhttp://people.ece.cornell.edu/land/courses/ece4760/AtmelStuff/mega1284full.pdfhttp://www.mouser.com/ProductDetail/Parallax/29123/?qs=%2Fha2pyFaduhYMMfmMD2zP4EO6mnEOcZYbp0zCgoUR4s%3Dhttp://www.mouser.com/ProductDetail/Parallax/29123/?qs=%2Fha2pyFaduhYMMfmMD2zP4EO6mnEOcZYbp0zCgoUR4s%3Dhttp://pdf1.alldatasheet.com/datasheet-pdf/view/51030/FAIRCHILD/DM74LS125AN.htmlhttp://pdf1.alldatasheet.com/datasheet-pdf/view/51030/FAIRCHILD/DM74LS125AN.htmlhttp://cdn.shopify.com/s/files/1/0038/9582/files/MD_Blue16x2LCD_1602A.pdf?1260727644http://cdn.shopify.com/s/files/1/0038/9582/files/MD_Blue16x2LCD_1602A.pdf?1260727644http://diydrones.com/profiles/blogs/using-the-5hz-locosys-gps-withhttp://diydrones.com/profiles/blogs/using-the-5hz-locosys-gps-withhttp://diydrones.com/profiles/blogs/using-the-5hz-locosys-gps-withhttp://cdn.shopify.com/s/files/1/0038/9582/files/MD_Blue16x2LCD_1602A.pdf?1260727644http://pdf1.alldatasheet.com/datasheet-pdf/view/51030/FAIRCHILD/DM74LS125AN.htmlhttp://www.mouser.com/ProductDetail/Parallax/29123/?qs=%2Fha2pyFaduhYMMfmMD2zP4EO6mnEOcZYbp0zCgoUR4s%3Dhttp://people.ece.cornell.edu/land/courses/ece4760/AtmelStuff/mega1284full.pdfhttp://www.sparkfun.com/datasheets/GPS/Modules/LS20030~3_datasheet_v1.2.pdf


13/14

Part Cost per Unit Quantity Total Cost

LCD Display Already Owned 1 $0.00

Remote Car $25.00 1 $25.00

Mega1284 $5.00 1 $5.00

Digitial Compass Already Owned 1 $0.00

GPS Already Owned 1 $0.00

Small Solder Board (2 inches) $2.00 1 $2.00

Raspberry Pi (Model B) Already Owned 1 $0.00

9V and 1.5V Batteries $2.00 and $0.50 each 1*2+0.50*3 $3.50

Sip or Header Socket/Plug $0.05 / pin 34*3+30*3+16*2 $11.20

DIP Socket $0.50 2 $1.00

Total $46.20

Separation of Tasks

GPS (Hardware and Software) Crystal Lu Compass (Software) Erik Halberg and Crystal Lu Compass (Hardware) Erik Halberg LCD (Software) Crystal Lu LCD (Hardware) Erik Halberg UART Crystal Lu MEGA 1284 Crystal Lu and Erik Halberg Motor Control (Software) Erik Halberg Motor Control (Hardware) - Erik Halberg and Crystal Lu Write up Crystal Lu Web page Erik HalbergFor the most part, as a team, we tried to incorporate one another in each aspect of the project so

that each of us understood the product to its full capability when breaking it down into its

subsystems. However, some portions of this project, one individual became a stronger expert

overtime. For the most part since we tried to schedule times to meet in lab and outside of lab,

both of us played a key part in designing all portions of the code.

Code


14/14

Source

Lab5.c trtkernel_1284.c uart.c trtUart.c lcd_lib.c

Headers

trtSettings.h uart.h trtUart.h lcd_lib.h
http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/Lab5.chttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/Lab5.chttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/trtkernel_1284.chttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/trtkernel_1284.chttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/uart.chttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/uart.chttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/trtUart.chttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/trtUart.chttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/lcd_lib.chttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/lcd_lib.chttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/trtSettings.hhttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/trtSettings.hhttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/uart.hhttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/uart.hhttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/trtUart.hhttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/trtUart.hhttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/lcd_lib.hhttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/lcd_lib.hhttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/lcd_lib.hhttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/trtUart.hhttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/uart.hhttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/trtSettings.hhttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/lcd_lib.chttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/trtUart.chttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/uart.chttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/trtkernel_1284.chttp://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2012/esh64_csl84/esh64_csl84/extras/code/Lab5.c

a car that can track its own location and calculate the direction and distance needed to get to a...

Documents