GPS Running Watch

High Level Design    top

Rationale

The idea for this project came from a brainstorm of different applications for GPS. GPS receivers are everywhere in the modern world, and are small and simple enough to use with a microcontroller to a reasonable degree of accuracy. There are many websites and smartphone apps that can help runners find and create routes but what they don't do is guide runners while running those routes. There is no feedback to indicate where the next turn is, or in which direction to turn. A smartphone app could interrupt music that may be playing to indicate when and how to turn, but that would remove the user from the general peace of the run and force the user to think about the next turn. All those interruptions could get very irritating. A better solution would be to indicate the next turn through haptic feedback. A vibration on a user's left arm would naturally indicate a turn to the left, and a vibration on the right arm would naturally indicate a turn to the right. We use this method of feedback to seamlessly guide the user along a route without interrupting the run.

Logical Structure

Our device provides basic route navigation guidance and waypoint logging using GPS. An ATMega1284 microcontroller unit (MCU) receives GPS data from a receiver module, and user selections from four 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 two vibration motors. The MCU retrieves waypoints from routes saved in text files on an SD card. For waypoint logging, the MCU only uses the LCD display and not the vibration motors. The MCU saves waypoints to a text file on the SD card.

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. These sentences give the receiver’s latitude, longitude, altitude, speed, and bearing, the current UTC time, and the state of the GPS satellite fix. We use all this information for the route navigation function, and all except the speed and bearing for the waypoint logging function.

The SD card stores routes as a list of comma-separated latitude/longitude waypoints in text files. The first line in these text files is a header with no useful information to the MCU. Each subsequent line contains a waypoint starting with a ‘T’ followed by a latitude, a longitude, a waypoint name (not necessary), and a description (also not necessary). As mentioned before, each of these five values are separated by commas to make it easy for the MCU to parse them. The MCU only extracts the latitude and longitude from each line and stores them in two arrays: one for latitudes, and one for longitudes. It moves through these arrays as the user runs the route. In the waypoint logging function, the MCU stores waypoints in the exact same format. We use this format because it is used by the website we use to convert between text files and Google Earth KML files (www.gpsvisualizer.com).

The GPS Visualizer website makes it much easier to use Google Earth to create and view routes. While a user could create a text file with our format by entering each latitude and longitude, a less tedious solution, which we recommend, is the following:

1. Create a path in Google Earth
2. Save the path as a KMZ file
3. Upload the KMZ file to the GPS Visualizer website and output a comma-separated text file
4. Copy the output to a text file and save this text file to the SD card

A user can view his saved waypoints from the waypoint logging function in a similar manner:

1. Upload the text file to the GPS Visualizer website and output a KML file
2. Use Google Earth to open the KML file
3. The path should appear as a series of red lines as shown below

The LCD displays certain information to the user depending on the current function. In route navigation, it displays the current waypoint number, the elapsed time since the start of the run, the distance in meters to the next waypoint, and the runner’s current speed in kilometers per hour. When the user completes the run, it displays the total completed distance of the run and the total time. During waypoint logging, the LCD displays the current local time, and the user’s latitude, longitude, and altitude. Outside of these two functions, it displays different menus.

Hardware and Software Tradeoffs

Hardware

There were four major hardware tradeoffs in this project: wired vs. wireless communication, board size, battery size, and LCD type. Since our hardware is split into three groups situated on three different parts of the user's body, there has to be some way for all the hardware to communicate. The simplest solution is to run wires between the different groups. Wires and pin headers are cheap, relatively compact, and do not require additional software. On the other hand, wires can restrict the user's movement, which is not ideal for runners. Another solution is to use short-range wireless RF communication, such as Bluetooth. Bluetooth would not restrict the user's movement. However, it can be difficult to use with microcontrollers, requires more hardware and software to run, adds more weight than wires, and is significantly more expensive than wires. Considering our time and budget constraints, we chose to use wires even though wires impede the user experience to some degree.

The main board in our project is much bigger than it could be because we are using a PDIP-package ATMega1284. If we had designed our own printed circuit board (PCB) and used a TQFP-package ATMega1284, the main microcontroller board could be half its current size (just the size of the green PCB in the picture). A smaller board would be better for the user who has to wear it on his arm, and could better incorporate the battery pack. Although a PCB has benefits, it is also more expensive, more time-consuming in design work and fabrication, and harder to fix if we made an error in the design. Since time and budget are our two main constraints and we already had a microcontroller carrier board from the lab, we decided to use the carrier board and a protoboard to connect the other hardware.

Our choice to use 3 AA batteries to power the project was a little unintended. Since one of us already had a battery holder for 3 AA batteries, it was a quick and easy solution for powering the hardware for outside tests. The voltage from the AA batteries starts around 4.7V and drops to around 4.5V over time, which is still acceptable for 5V devices, and doesn't require a voltage regulator. The ATMega1284 will run at 16 MHz with at least 4.5V, so the AA batteries work. A better solution may have been to use a two-cell lithium battery with a small voltage regulator. A lithium battery would have been much smaller and lighter than the AA batteries, and could have been recharged with an on-board recharging circuit. Since the AA batteries worked just fine and were readily available, we forgot to consider lithium batteries any further. In retrospect, lithium batteries would have been better for weight and size, but they have more safety problems and require more on-board hardware for charging or an external charger. A compromise on size and weight may have been to use AAA batteries instead of AA batteries, but we did not consider this change worthwhile as we already had a AA battery holder.

The last hardware tradeoff was the LCD. The LCD is the main visual interface, and the only user interface during the waypoint-logging function. A larger character LCD would allow us to display more information to the user, but would also be bulkier and heavier. Since the LCD is sitting on the user's forearm, the size and weight should be as small as possible to reduce fatigue. A 16x2 character LCD, like the one we use, is a good tradeoff for these criteria. However, a graphic LCD might be able to display more information, albeit in a smaller font, with a smaller board size. We chose to not use this type of display because it is often more expensive, requires more software, and would display information in a smaller size, which would not be ideal for some users.

Software

The main software tradeoff was whether or not a real-time kernel would be used. A real-time kernel has the advantage of easy timing of multiple tasks that need to be run simultaneously. A custom scheduler on the other hand allows for more precise timing of time-sensitive tasks and the ability to ensure the MCU is never overloaded. Because the project does not require many simultaneous processes, a real-time kernel is not required. Additionally, two tasks, including the clock for the SD card, and the GPS update signal needed to be called at certain intervals. Therefore, a custom scheduler was used that was run off of TIMER0 with a 1ms time-base.

Background Math

One part of our design is to calculate the distance remaining between the user and the next waypoint, which involves finding the difference between two latitude/longitude points on a sphere. An exact calculation of this distance requires the haversine formula, which is shown in equation 1. $\varphi$ is latitude, and $\lambda$ is longitude, and all angles are in radians.

$a = \sin^2(\frac{\varphi_2-\varphi_1}{2})+\cos(\varphi_1)\cos(\varphi_2)\sin^2(\frac{\lambda_2-\lambda_1}{2})$    (1)

Equation 2 uses the haversine result above to find the distance on the Earth's surface. $R_E$ is the Earth's radius approximated to be a constant 6371000 meters.

$d = 2R_E*atan2(\sqrt{a},\sqrt{1-a})$    (2)

Computing these two equations on a computer is trivial, but it is not trivial on an 8-bit microcontroller such as the ATMega1284. It involves 7 trig functions, 2 square roots, and 6 multiplications of double-type variables (to be reasonably accurate). This amount of computation takes a long time. To decrease computation time, the distance can be approximated using en equirectangular projection. An equirectangular projection is a way to map the Earth onto a 2-D surface in which the lines of latitude and longitude are straight with equal spacing. This projection greatly deforms Earth's actual surface, but gives a reasonable approximation for the distance between two points as long as those points are closer than about 100 km and not near the poles. Since this project deals with waypoints that are no more than a couple kilometers apart, and there are very few, if any, people running near the poles, the equirectangular projection approximation works well. In our testing, it gave exactly the same integer answer as the haversine method, at least to a 200 meter distance. The formula is shown in equation 3.

$d = R_E\sqrt{(\lambda_2-\lambda_1)^2*\cos^2(\frac{\varphi_2+\varphi_1}{2})+(\varphi_2-\varphi_1)^2}$    (3)

This equation only requires one trig function, one square root, and three multiplications; a big increase in performance for no loss in accuracy (for our application).

The other major calculation in our project is the bearing from one latitude/longitude point to another. As with the haversine formula, it requires a lot of trig functions. Unlike the haversine formula, it is only applicable within a certain distance along the great circle path since the bearing changes. However, since our project only deals with the bearing between points that are at most a couple kilometers apart, the change in bearing over distance is not a concern. The formula for the bearing calculation in radians is shown in equation 4.

$b = atan2(\sin(\lambda_2-\lambda_1)\cos(\varphi_2), \cos(\varphi_1)\sin(\varphi_2)-\sin(\varphi_1)\cos(\varphi_2)\cos(\lambda_2-\lambda_1))$    (4)

This equation requires 8 trig functions and 4 multiplications, making it very slow. We tried an approximation but it did not give correct values. Hhowever, equation 4 was fast enough in testing, so we kept it.

Standards

Three commonly used standards were followed in this project. The first is the SD card interface. It uses a SPI connection, so the hardware and software needed to communicate with the card over this bus. Additionally, the SD card uses the FAT data format. SPI or Serial Peripheral Interface is a four pin connection. There is a clock pin which synchronizes the logic between the master and the slave, a master out slave in pin (MOSI), a master in slave out pin (MISO), and a chip select pin. Chip select is used to signal that a particular peripheral is being accessed via the master. Data can then flow across the MISO and MOSI pins simultaneously. Fortunately, communication with an SD card is fairly simple thanks to a library created by “ChaN”. His FatFs module was “ported” to the ATMega644P MCU, which is somewhat compatible with the ATMega1284, in several earlier 4760 projects, most recently the TrckrX Onboard-data-logger. The pins for SPI were simply defined in the FatFs library and the code takes care of the rest.

The second standard is the National Marine Electronics Association (NMEA) protocol for GPS serial communication. In this standard, data is sent over an ASCII serial connection such as UART at a constant rate chosen by the developer. Each cycle, a “sentence” is sent from the “talker” (the GPS module) to the “listener” (the MCU). The sentence always begins with a dollar sign “$” and is then followed by two characters to identify the broadcaster, three characters to determine the type of message, then a series of comma-delimited data. Following the data is the “*” character and a checksum followed by a carriage return and line feed. In the case of GPS data, the data section can contain information such as, latitude, longitude, heading, speed, and current time.

The final standard is the Hitachi HD4470 LCD controller interface. The HD4470 is commonly used to drive a variety of ASCII LCD displays. The interface simply consists of a command/data select pin, a read/write pin and 4 or 8 data pins. Again, the LCD library used in earlier projects was very useful in making the LCD interface easy to use.

Intellectual Property

We did not find any relevant copyrights or trademarks for products similar to ours. We did find research from the Intelligent Systems Lab at the University of Amsterdam for a vibrating belt for cyclists. This belt performs a similar navigation function to our project but strictly for cyclists. It also uses different hardware, such as an Android phone and Arduino Mega microcontroller to interface with the vibration motors. We did not find this research until after we had arrived at the idea for our project, so it did not provide inspiration or motivation for us.

We also found a patent for a haptic feedback navigation device for automobile steering wheels. This patent (U.S. 8,554,410) covers a steering wheel device that connects to a car-based GPS navigation unit and vibrates different parts of the steering wheel to indication directions to waypoints. It only covers using haptic feedback in a steering wheel with a connection to a car-based GPS navigation unit, so it does not apply to our project.