Professional Documents
Culture Documents
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.
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.
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.
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.
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 further expansions 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 perfboard 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
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.
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.
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.
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 1015 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
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 found here. 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.
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
Tri-state Connection
References
GPS Data Sheet MEGA 1284 Data Sheet Compass Data Sheet Tri-State Buffer Data Sheet LCD Data Sheet NMEA Parser
Part
Quantity
Total Cost
LCD Display Remote Car Mega1284 Digitial Compass GPS Small Solder Board (2 inches) Raspberry Pi (Model B) 9V and 1.5V Batteries Sip or Header Socket/Plug DIP Socket
Already Owned $25.00 $5.00 Already Owned Already Owned $2.00 Already Owned $2.00 and $0.50 each $0.05 / pin $0.50
1 1 1 1 1 1 1 1*2+0.50*3 34*3+30*3+16*2 2
Total
$0.00 $25.00 $5.00 $0.00 $0.00 $2.00 $0.00 $3.50 $11.20 $1.00 $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 Halberg
For 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
Source
Headers