"A GPS system for navigation through GPS Visualizer waypoint with audio and temperature feature."
The basic idea of this 4760 final project is to build a GPS navigator for runners who are new to
their neighborhood. For example, if someone is new to Cornell University, College of Engineering, and wants to run around the engineering quad every day, this runner Navigation system have the following functions to ensure that he would not get lost or encounter some undesirable situations:
1.Navigation: Let the user choose the destination, then navigates him to the destination by telling the user to turn left or turn right at each waypoint, or even with accurate turning angle. This part is the core of the project.
2.Temperature: This part would tell the user the temperature outside and make an evaluation of suitableness for running outdoors.
3.Location: This part would tell the user the exact latitude and longitude of his current location, with the landmark nearby.
As for the user interface, we built a menu shown on the TFT screen. The user could interface with the system using two buttons: ‘next’ and ‘confirm’. The user can switch between submenus and enter them by pressing these two buttons. Moreover, a human voice would be displayed to tell the user whether he should turn left or right so that he would not have to keep an eye on the screen when running
High Level Design top
Overview
Our device provides basic route navigation guidance using GPS. A PIC32 microcontroller unit (MCU) receives GPS data from a receiver module, and user could interface with the system using two pushbuttons. The pushbuttons allow the user to move through different menus, make selections, and return to previous menus or exit the current function. During route navigation, the MCU displays route information on an LCD display and gives turn indications through the audio output as well as the message printed on the TFT screen. The routes are saved in the microcontroller memory in advance in the format of a sequence of way points.
The GPS module sends NMEA strings containing certain GPS data over a serial communication line. The MCU can control the speed of the data connection, the update rate, and the type of information that the module provides. We chose a 9600 baud rate with a 1 Hz update rate for new information, which is fast enough for our application. The GPS module provides the GPGGA and GPRMC NMEA sentences to the MCU. We only use the GPGGA sentence in our project, which pretty much includes all the information we need, such as the receiver’s latitude, longitude, altitude, speed, and bearing, the current UTC time, and the state of the GPS satellite fix.
The temperature sensor would measure the temperature outside and help runners make an evaluation of the outdoor environment and avoid running in extreme weather.
Block Diagram
Hardware and Software Tradeoffs
There were several tradeoffs for the hardware and software used in the project.
For hardware, we tried to minimize the amount of peripherals and the space they take. At first we wanted to use a speaker to output the human voice, but it turns out the only speaker available in the lab take too much space while requires a higher power supply. Accordingly we decide to use an earbud to output the human voice. By doing so, we were able to remove the large speaker. By minimizing the amount of hardware, we streamline the amount of extra hardware and extra inputs onto the microcontroller.
For software, because of the limited power of the microcontroller, rather than using the distance formula of two multiplications, and summation, and a square root to calculate distance, we instead use a comparison to thresholds of latitude and longitude independently in order to minimize the number of cycles used. Additionally, we used the basic mathematic method to calculate the turning angles in 2-demensional coordinates, but it turns out that the approximated angles are quite reasonable.
Background Math
Formulas for calculating the turning angles are shown below.
Existing Work
There are numerous existing works for microcontroller GPS Navigation system. One is example is Cornell ECE4760 project by Jason Setter and Jeff Setter, that uses similar ideas to guide people. However, existing works are mainly based on AVR. Our system is PIC32-based, and provide audio features and calculate exact turning angles to avoid ambiguity in navigation, which has not been found in previous works.
Hardware top
Hardware Design
GPS Unit
The core of navigation device is the GPS unit. The GPS module we use is the Adafruit Ultimate GPS Breakout v3. It can run on 5V-3.3V with a 20mA current draw, and outputs NMEA 0183 standard data strings at 1, 5, or 10 Hz. Since it outputs serial data, we connected the transmit (TX) lines to the UART2 RX (pin22) on the MCU. It starts sending data to the MCU immediately after power-on, although the data is not meaningful until the receiver gets a position fix from the GPS satellites. In our tests, the cold-start (time until a position fix) was usually less than two minutes. Using this GPS module, we are able to gather location data, compare locations, and determine how the user should proceed in their movements.
Audio Output
We used DMA channel to output a human voice that could tell the user which direction to turn to. We recorded Bruce’s voice saying ‘turn left’ and ‘turn right’ and adapted a Matlab Program to convert the wav files to two 4-bit arrays and store them in the PIC32 memory. We play the voice with the DMA channel when we are close enough to a way point. We used an 4-bit internal DAC and CVref (pin25) as the output of audio signal. Converted array could be found in the header file Left_Right_sound.h . To hear the audio clearly, the waveform must be amplified, and to suppress noise, the waveform also must go through a low pass filter. We set the cutoff frequency of low pass filter as 10kHz. The schematic for the amplifier we designed is shown below.
Temperature Sensor
The temperature sensor being used was DS18S20. It is a digital temperature sensor, which communicates with MCU with one-wire communication protocol. The RA0 (pin2) on MCU and pin2 on temperature sensor was connected and used as one-wire bus. The one wire bus was hooked to Vcc through a pull-up resistor. Since the Vcc we were using was 3.3V instead of 5V, correspondingly, we used 3K pull-up resistor instead of 4.7K . Timing diagram of DS18S20 could be found at page 13 and 14 in DS18S20 Datasheet.
The initialization timing slot and writing “0x44” timing slot waveform on oscilloscope are shown below.
We added a median filter for the temperature sensor. We selected the median of every 3 measurement as the result. Noise does occur in some frames, and a mean filter with a size of 3 is capable enough to deal with that based on our experiment.
User Interface: TFT Output
The user interface is through a TFT output that prints statistics and menus for the user. There are three options: weather, location and navigation.
In the weather mode, it displays the temperature for you, both temperature in Celsius and Fahrenheit. If the temperature sensor is removed, it would display “No Temp Sensor” for you.
In the location mode, if there is no GPS signal, it would tell you. If there is GPS signal, it would show you the longitude, latitude, and EST time on the screen. Also, if you are in Engineering Quad, it would tell you which building you are near to. Demo pictures are shown below.
In the navigation mode, The first screen tell allows you to select which area you want to go, the second screen is which building in that area you want to go, and if you have selected a building, it would navigate you. When you are close to a way point, it would tell you to turn left or turn right for what degree, and after a while tell you to keep going. When you arrive the destination, it would tell you arrived, then jump back to the second screen. Key frame pictures for demo navigation from Duffield to Carpenter lib were recorded. All demo pictures for TFT LCD could be found here.
User Interface: Pushbutton
The cursor on the TFT screen is manipulated by two push buttons. One is “next” to move the cursor up and down, another is ”confirm” to enter the next or previous page.
The software detects the state of the push button. If one button is pushed, the software would debounce that first, then change the corresponding state machine. Details for state machine would be covered in the software design part. The schematic for our system is shown in the appendices.
Software top
Software Flowchart
The Flowchart of the software part is given below.
NMEA Sentences Receiving & Parsing
The first thing to do with the software is to read the NMEA sentences and decode it. We used the function ‘PT_GetSerialBuffer(struct pt *pt)’ to read the output of GPS receiver character by character. At the very beginning of this function it tests whether there is a frame error when PIC32 communicating with GPS module using UART. If so, it would clear all errors and throw the whole sentence away and wait until next valid data arrives. Since all NMEA sentences ends with ‘\n’, this function would check if the incoming character is ‘\n’ and save all the characters into the array ‘PT_term_buffer’ if so.
This function parses all the NMEA sentences start with ‘GPGGA’, which is one type of NMEA sentences that contains all the information we want, like UTC, latitude and longitude. In more detail, it uses ‘sscanf’ to parse and save useful information into the following variables: GPS_type, GPS_time, GPS_curLat, GPS_NS, GPS_curLon, GPS_WE, GPS_quality.
Menu Hierarchy
The user interface was implemented by a huge state machine. The hierarchy of the menu is shown below.
- Weather: (displays the outdoor temperature)
- Location: (displays the UTC, current latitude and longitude, and the landmark nearby)
- Navigation:(choose the destination and start navigation)
Engineering Quad
o Philips Hall
o Duffield Hall
o Kimball Hall
o Hollister Hall
o Thurston Hall
o Carpenter Hall
College of Management
Hoy & Sch Field
Again, all demo pictures for TFT LCD could be found here.
The menu hierarchy is setup by a relatively complicated state machine. For details about this state machine, please refer to the file "menu.h" in our source file below.
Navigation & Heading Calculation
We used GPSvisuallizer.com to create and plot all possible routes of which the start point is either Philips hall or Duffield Hall and the destination is one of the main buildings within Engineering Quad. All routes are saved as gpx files. Then we converted the gpx files into text head files which is readable by the microcontroller and saved all the routes in the format of waypoint arrays by using a Python program. In the head file routes.h, all way points are presented by its latitude and longitude. Upon the user chose the destination, the program would load the array corresponding to his current location (start point) and the destination. The flow chart of the navigation mode has been shown before. As we can see from the diagram, in the navigation mode, the microcontroller keeps compare the user’s current location with the next waypoint. When the user gets close enough to the next waypoint, the audio output would generate a human voice to tell him turn left or right at the waypoint and the TFT screen would simultaneously display the heading information for the user.
Under the file GPS_Navigation, the function ‘get_leftright’ returns either 0 (stands for right) or 1 (stands for left) at each point to tell whether the user should turn left or right. This is basically implemented by computing the cross product of two vectors, one starts at last waypoint and ends at current location, one starts at current location and ends at next waypoint;
The function ‘waypoint_close’ returns true if current location is close enough to the waypoint;
The function ‘get_angle’ returns a float number of degrees that the user should turn at each waypoint.
Results top
Program Parameters
With Protothreads, concurrency is guaranteed in our system. The key scanning is executed every 1 ms, the screen updates every 1 second. The temperature sensor updates every 750ms. UART communication between GPS module and MCU , navigation calculation , these two threads yields at the beginning, therefore periods for executing these two threads are typically less than 1 ms.
To make the navigation reliable, we define 10m close to way point as “close”. Instead of using Sphere coordinate for calculation, we approximate the coordinate system as 2-dimensional coordinate, because longitude and latitude does not change much within engineering quad, it could be thought piecewise planar. If we stand still in a fixed position, the error for the GPS module we measured is 0.000023 degree for longitude, 0.000017 degree for latitude, and in meters, that is approximately 2m.
Accuracy
The accuracy of our project depends on the accuracy of the GPS receiver we use. Most GPS receivers are accurate to within 5 meters most of the time. In our testing, we found that the accuracy of our receiver was usually well within 2 meters. However, the reliability of the system is subject to the location and weather condition. The system is not reliable in extreme weather condition, or working indoors.
Usability
The current device requires that one look at screen to know the turning direction. If the user has impaired sight, he could listen to the audio to follow the guidance.
Conclusions top
Final Results
At the conclusion of this project, we have a GPS device that is able to take inputs from a site, similar to plotting points on Google Maps, upload these points onto the GPS, and then follow these points using the GPS to tell which direction to turn once we are close to the waypoint, in addition to telling useful information about heading, distance to waypoint, and GPS location that are useful for knowing how far one is to the waypoint. Additionally, in the explorer mode, we can add waypoints at the press of a button, download these coordinates to the computer using UART, and then display the path that was recorded on a site similar to Google Maps.
In our project, it would have been nice to add vibration motors as a means of haptic feedback. This would allow the user to receive navigation without looking at the screen or the LEDs. Also, the packaging of the project could have been smaller so that it would have been a more usable device.
Standards
NMEA
NMEA is a combined electrical and data specification for communication between marine electronics, which in this project GPS receiver, and other types of instruments. This standard uses ASCII, serial communication to define how data are transmitted from a base to several receivers. This standard also defines the contents of each message type, and receivers can parse messages accurately. (Adapted from Wikipedia, https://en.wikipedia.org/wiki/NMEA_0183).
GPX
GPX, or GPS Exchange Format, is an XML schema designed as a common GPS data format for software applications. In our project, we use gpx to specify the order and waypoint latitudes and longitudes. The coordinates are drew in GPS Visualizer and then converted to a text file in which routes are stored as a list of comma-separated latitude/longitude waypoints in text files. The conversion can be done on the gpsvisualizer website. Then we could save the text file into our microcontroller PIC32 or its extended memory.
UART
In our project, we need to download GPS data from website in the laptop, then convert the data then send them into the microcontroller. While a runner is running, the microcontroller should receive data from GPS receiver and do some calculation. The communication between laptop, microcontroller, and GPS receiver is by a UART system. All UART communication would transmit and receive messages on the same protocol format.
Social Impact
- Safety Considerations
The main safety risk with this project is electric shock since the user is wearing it on his body. All of the hardware runs on less than 3.3V at low current. These power levels will not harm a user, even if he touched the exposed solder joints. Also, our system evaluates the temperature level and would discourage users to run in extreme harsh weather conditions. Since this project is just a navigator system that provides information for the runner, there are no risk factors otherwise.
- Human Factors and Usability
The main purpose of our project is to help runners when they are not familiar with the route, or in some special weather conditions, like in the dark night, or extreme foggy days. Also, sometimes runners would run in complicated traffic situations, so it is not convenient for them to look down on the TFT screen all the time. Accordingly, our system would generate some sound to remind the runner when he gets near to a waypoint, so they only have to check the navigator at these point of time, then they would know whether they should turn left or right, and how many degree they should turn exactly.
- Interface Design Considerations for People with Special Needs
Sometimes, when the runner gets to a fork in the road, just telling the runner to either left or right is not enough, because there may be several branch roads in his left or right. In these case, we would display the exact turning degree on the screen to point out the exact direction.
- Intellectual Property Considerations
We found several previous ECE4760 final projects also making use of runner GPS navigators. We appreciate the great example of the previous group, Jason Setter & Jeff Setter set for us. The main difference of our project is that when runner gets near to a waypoint, we would generate a sound to inform the runner to check the TFT screen. Also, the system we built is wearable, with a better user interface, and we stored data locally in advance so the user don't need to set up routes manually before departure. In addition to GPS part, our project referred or adapted the protothread written by Adam Dunkels , and extended version by Bruce Land, TFT library and DS18S20 program on PIC32 written by Tahmid Syed Mahbub.
We have acknowledged all use of code and have abided by all copyright statements on both code and hardware. We have given credit to all hardware devices that were used in this project, as well as the code that was referenced in our final program.
Appendices top
A. Program Listing
All source files could be downloaded here . The file final.c serves as main.c .
B. System Schematic
C. Parts List
| Part | Vendor | Cost/Unit | Quantity | Total Cost |
|---|---|---|---|---|
| Microstick II | Microchip (Lab) | $10 | 1 | $10 |
| GPS receiver (WAAS) | Adafruit | $40 | 1 | $40 |
| Solder Board (6 inch) | Lab | $2.5 | 1 | $2.5 |
| Solder Board (2 inch) | Lab | $1.0 | 1 | $1.0 |
| TFT LCD | Adafruit (Lab) | $10 | 1 | $10 |
| PIC32MX250F128B | Microchip (Lab) | $5 | 1 | $5 |
| DS18S20 | Maxim (free sample) | $0 | 2 | $0 |
| Header Pins | Lab | $0.05 | 40 | $2.00 |
| Jumper Cables | Lab | $0.20 | 1 | $0.20 |
| Miscellaneous (wires, resistors, etc) | Lab | $0 | 1 | $0 |
| TOTAL: | $70.7 |
D. Division of Labor
Almost all of the project was done together. However, there was more focus for Junyin of writing the TFT LCD User Menu and DS18S20 code, and for Haonan to work on writing navigation helper functions and soldering circuits. But in general, most tasks were done together.
References top
This section provides links to external reference documents, code, and websites used throughout the project.
References
Acknowledgements top
We would like to give Special Acknowledgement to Bruce Land for building an amazingly rewarding class and his spider sense for helping us debug. Also, we would like to thank the TAs, especially Tahmid, for creating the library for us, and keeping the lab open for so many hours.