High Level Design
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.
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 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.
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.
No existing patent or copyrights or trademarks exist that are relevant to our project currently.
Program & Hardware Design
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.
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.
Parts and Cost List
|Part||Cost per Unit||Quantity||Total Cost|
|LCD Display||Already Owned||1||$0.00|
|Digitial Compass||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|
For more detail: Willy the Self-Driving Toy Car