Cornell Explorer 10

[Carmen Kalua]

Theidea of the the project is to create a useful device for being able to get directions with any specified path by use of waypoints rather than a path chosen by a GPS as well as being able to follow a path that is offroad. The basis of this project was to provide a way to ski down an unfamiliar mountain without making a wrong turn by loading the path on the device, as well as plotting a new path to be able to view the path later. Note that this also works very well for biking where one may want to choose their own path and ride specific roads rather than going on the shortest path. A normal GPS is able to provide functionality on roads, but not off-road where the paths are not already mapped, so this device is quite beneficial for skiing and snowboarding in particular.

For logging, rather than inputting a path, the device will save the GPS locations every time the user presses a button. The device will store all this information in the microcontroller. Later, at a computer, one can connect the device to the computer using UART and send the coordinates to the computer where it is copied from UART to a text file. Then, after parsing the output, you can upload the file to GPS Visualizer to view the path.

To transfer GPS coordinate data between the GPS module and the microcontroller, the standard NMEA messaging system is used. The most pertinent of these message types is GPRMC. When this message type is received by the MCU, the data fields in this message can be used to extract the current GPS coordinates.

To communicate between the computer, microcontroller, and the GPS module, a UART system is used. Messages are sent and received based on the protocol timings and behavior that is required of all UART communication.

After the project conception and execution, numerous projects were found that used microcontrollers to provide navigation. One such example is the Cornell ECE4760 project by J. Heck and K. Kulas, that uses similar ideas to guide people using vibration. However, our method of inputting headings has not been found to be used by any other project.

There are three LEDs on the device board that provide information to the user. Two of these LEDs are used notify the user when to take a turn during navigation mode. The LED on the microcontroller board is used for debugging information: the LED toggles when the button is pushed in exploration mode, and the LED toggles when a minimum distance has been walked during navigation mode. Each LED is powered when on by an output pin on the MCU. The circuit starts from the MCU output pin, through a limiting resistor, through the LED, and to circuit ground.

The user interface is through an LCD output that prints statistics and menus for the user. There are two modes: exploration mode and navigation mode. In the exploration mode, there are three screens that may be accessed: a mode-select screen to change to navigation mode, a screen showing the current GPS coordinates, and a screen where the captured waypoints can be transmitted to the computer.

There are two pieces of hardware provided to the user to interface with the navigation device: a pushbutton and a potentiometer. The potentiometer is turned in order to change between the screens shown on the LCD. The potentiometer outputs varying voltage (from 0V to 5V) based on how much the device is turned. This value is read through an internal ADC on the MCU, and then the MCU translates the potentiometer voltage to which screen should be shown.

Depending on which screen is currently being shown on the LCD, when the button is depressed, some functionality occurs. The MCU responds to a button press on the mode-select screen, coordinate screen in exploratory mode, and the transmission screen. A button press on the coordinate screen in exploratory mode results in the current location being captured as a waypoint. Any button press on this screen after 100 presses will results in no action, due to a limit of 100 waypoints allowed on the MCU at time. On the transmission screen, a button press results in all of the captured waypoints to be sent over UART to the connected computer. The waypoints are then cleared from the MCU.

The pushbutton physically is connected to an input pin on the MCU. The input pin is connected to 5V through an external 10k resistor when the pushbutton is open. When the button is pressed, the button completes a circuit between the input pin and ground. This causes the input pin from reading a high voltage to a low voltage. Therefore, the software detects that the button is pushed using polling and finding that the voltage has changed from high to low.

To plot the path, one plots the waypoint in the website gpsvisualizer.com or any other website that outputs GPS output files (gpx). Each waypoint is described by two markers, one for the location and a second for the waypoint heading. Once all the waypoints are plotted, one can download the path. This gives a standardized output file of type .gpx. From this file, we need to somehow take the output file and convert it to a format that is useable by the microcontroller. To do this, we take advantage of the structure gpx file and parse the waypoints using a python script. This reads in every waypoint, which are tagged in a .gpx file, and then creates an array of points in a heading file. When the code is flashed onto the microcontroller, it includes the heading file and reads the coordinate array to be used by the program in the navigator mode.

For GPS communication, we receive our GPS NMEA message using UART. The GPS unit passively sends coordinates every second over the UART channel, where the MCU reads the message. We look for the $GPRMC tag, which is the message that tells the current latitude and longitude of the current coordinates. The entire sentence is then parsed, and the latitude and longitude are extracted from the message. These coordinates are sent using degreesminutes.minutes, so these coordinates must first be converted to degrees.degrees to be consistent with gpx standard format.

For data communication between the microcontroller and the computer, the same UART channel is used. When the button on the board is pressed, the MCU responds by sending a message over the UART, which is captured by the UART channel on computer. The points that are sent to the computer screen can be placed in a text file and then converted to gpx format using our data parsing script.

In order to calculate heading, every time a GPS coordinate is received, we first check the distance traveled since the last time we have recorded a coordinate. This is because there are many coordinates acquired by the microcontroller, and if we calculate headings from every small distance, the headings will be widely off due inaccuracies in the GPS coordinates. Instead, we only update the heading once there has been a sufficient distance traveled. Since this exact distance is not important, rather than calculating the square root of the sum of the square differences in position (as in an actual distance calculation), we simply check if the distance changed in the latitude or longitude is over a certain threshold. Once it is determined that sufficient distance has been made, we calculate the heading, change to degrees, and convert from mathematical angles to navigation degrees (north is 0 degrees, and goes clockwise).

For the LCD, before the LCD is printed, it samples the last GPS sentence sent and calculates the current latitude and longitude if the GPS data is valid and of the form that sends latitude and longitude information. Next, it updates the heading, which also determines information of whether the user is close to the waypoint. Finally, it displays the information on the LCD based on the ADC value (determining the menu) and whether the user is close to a waypoint.

In order to prevent too many waypoints being collected on the MCU, we limited the array that holds captured waypoints to 100, but this number can be easily modified, since we were not close to the space constraints of the microcontroller.

There were several distances that were used by the program to specify how often the GPS data was polled. Due to the inaccuracies that can be seen in the data, it was necessary to make sure that we were sufficiently far from the original point to calculate another heading. We chose this distance empirically to be 0.000025 degrees to balance out the accuracy of the heading and how often the heading is calculated. Another distance that was programmed was the minimum distance before the turn is notified to the user. We chose this distance as 0.00015 degrees, so that there is sufficient time to notify the users. At higher speeds, it may be advisable to increase this distance.

The device was generally accurate to around 3 to 5 meters, though these distances can vary based on the current weather conditions, especially activity in the ionosphere. We also noticed that there was some drift in the coordinates, where the readings were slightly off from what was put as coordinates, biased slightly to the east. This may be a concern for some applications, but since we have some slack in terms of how close one needs to be to the waypoint, this slight error does not detract from the device. Note that this accuracy is due to using a WAAS GPS that increases accuracy from 10 meters to 3 to 5 meters. Though pricer, this makes the device much more useable and worth the investment.

In order to avoid the necessity of looking at the LEDs to notice when one has reached a waypoint, heptic feedback can be utilized. By replacing the LEDs with small coin vibration motors, one can get the turn information using their tactile senses.

The current device requires that one look at the LEDs in order to get information on when to turn. In a case that the user has impaired sight, we could replace the LEDs with vibration motors. While using the device, there would be no need to look at the LEDs or read LCD screen. Instead, the turn information is gathered using the vibration motors.

3a8082e126