"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
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 person’s drive from here to there. Starting with cruise control, which only monitors one’s 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.
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 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 found here.
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 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 car’s remote control ran off 3 V, and the GPS receiver ran off 3.3 Volts. Power supplies that were already hooked up were the motor’s 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 motor’s 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 job just as well. Therefore through the complexity of building one’s 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.
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 people’s 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 people’s 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, we’ve 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, we’ve 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.
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 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 user’s 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
MEGA 1284 Connection (Ports)
Tri-state Connection
References
- GPS Data Sheet
- MEGA 1284 Data Sheet
- Compass Data Sheet
- Tri-State Buffer Data Sheet
- LCD Data Sheet
- NMEA Parser
Parts and Cost List
| 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 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.