ECE497 Project GPS Tracker
Embedded Linux Class by Mark A. Yoder
I'm using the following template to grade. Each slot is 10 points. 0 = Missing, 5=OK, 10=Wow!
00 Executive Summary 00 Installation Instructions 00 User Instructions 00 Highlights 00 Theory of Operation 00 Work Breakdown 00 Future Work 00 Conclusions 00 Demo 00 Late Comments: I'm looking forward to seeing this. Score: 10/100
Chris Hopwood and Robert Fendricks will be working on a way to interface the Beaglebone Black with a GPS tracker using UART. We plan on using this data to track the Bone's location on a map via a web interface.
If you have hardware, consider Small Build, Big Execuition for ideas on the final packaging.
The user instructions are based off of the assumption that you have already followed the installation instructions and have ran into no issues.
First change your directory to gps-tracker/webpage. This directory holds all of the information for displaying the webpage associated with our project. Run MapServer.js to start up the server. By browsing to :8080, the server will display map.html, which is our user interface for the project.
Now change your directory to gps-tracker/bin. Run load_uart_overlay.sh to make sure that the Beaglebone can read from the UART. Now run gps_tracker.py. This will start up the communication with the GPS Tracker, which should have already been installed by this point.
Now browse to the web interface. From here, you should be able to see a map centered on Rose-Hulman. At the top you will see two modes, live and search. Selecting live will let you see what GPS data you're receiving in realtime. If no satelites have been acquired or a fix hasn't been established, no data will be displayed. In search mode, new data acquired from the GPS won't be shown. Instead, you can specify a time range you'd like to display on the map. By setting the Start Time, the End time, and then hitting go, you can display any GPS data acquired during this time.
Whether you're in live mode or search mode, the time of the most recently plotted information will be displayed just above the map.
The color of the path changes depending on the Horizontal Dilution of Precision (HDP) received from the GPS tracker. Green indicates a good HDP, red indicates a less optimal HDP.
Here is where you brag about what your project can do.
Include a YouTube demo.
Theory of Operation
Give a high level overview of the structure of your software. Are you using GStreamer? Show a diagram of the pipeline. Are you running multiple tasks? Show what they do and how they interact.
We first attempted to connect to the Beaglebone via the included FTDI cable. Here is a link to the FTDI cable's ref. sheet: http://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_TTL-232R_CABLES.pdf. To connect the
List the major tasks in your project and who did what.
Also list here what doesn't work yet and when you think it will be finished and who is finishing it.
The GPS we are using is MTK3339
To load the device tree overlay on the beaglebone:
This should connect UART4-rx onto P9_11.
To confirm which tty the UART is exposed as, run:
root@beaglebone# dmesg | tail
On our beagle it outputted:
[ 50.991396] bone-capemgr bone_capemgr.8: slot #8: 'Override Board Name,00A0,Override Manuf,BB-UART4' [ 50.991495] bone-capemgr bone_capemgr.8: slot #8: Requesting part number/version based 'BB-UART4-00A0.dtbo [ 50.991514] bone-capemgr bone_capemgr.8: slot #8: Requesting firmware 'BB-UART4-00A0.dtbo' for board-name 'Override Board Name', version '00A0' [ 50.991542] bone-capemgr bone_capemgr.8: slot #8: dtbo 'BB-UART4-00A0.dtbo' loaded; converting to live tree [ 50.991860] bone-capemgr bone_capemgr.8: slot #8: #2 overlays [ 50.995484] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is a OMAP UART4 [ 50.996082] bone-capemgr bone_capemgr.8: slot #8: Applied #2 overlays. [ 51.171271] [drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status updated from 2 to 2 [ 61.202485] [drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status updated from 2 to 2 [ 71.233751] [drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status updated from 2 to 2
According to [ 50.995484] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is a OMAP UART4 our port is mapped to ttyO4.
To test if the GPS is connected correctly, run:
root@beaglebone# screen /dev/ttyO4 9200
replacing ttyO4 with whatever device dmesg reported earlier.
To disconnect from the screen session correctly, press <ctrl>+<shift>+<:>, then type ":quit"
First, install pip, python's package manager:
root@beaglebone# opkg install python-pip
After that finishes, downgrade pip using easy_install (which should be installed now) because the latest pip uses ssl, and complains about certificates.
root@beaglebone# easy_install pip=1.2.1
Now instal pyserial
root@beaglebone# pip install pyserial
pyserial should now be installed! Load it in python by doing:
Google Maps Webpage
Robert started work on this, first using Dr. Yoder's Boneserver script to create a simple server. A new webpage was added that just had map on it. Google provides free documentation for their API, and it turns out it's fairly straight forward to use. One of the many features that Google offers with this API is the ability to draw on the map, such as placing markers and drawing lines. By using the marker class in conjunction with actionlisteners, I was able to create a button that would place a marker on coordinates specified by the user. The next step will be to have a script that will read from a file and place markers or lines on the map given a time range.
Ad Hoc Networking
For this project, we felt that being able to connect to the Beaglebone directly to access the web interface would be beneficial. To do this, we looked into setting up an ad-hoc wireless network.
To do this, first make sure that you have a wireless interface installed an configured on the Bone. We used Adafruit's RTL8192CU wireless adapter on our bone.
Once your wireless adapter has been configured, you are now ready to set up the Ad Hoc network. The following commands must be run on both the Beaglebone and the computer you want to connect to the Beaglebone. Note that this will utilize the wireless adapter on your computer, so you won't be able to use it for connecting to the internet. These commands are:
bash# ip link set <interface> down #This will bring your wireless interface down bash# iw <interface> set type ibss #This sets your interface to act as an Ad Hoc Network bash# ip link set <interface> up #Bring your interface back up bash# iw <interface> ibss join <SSID> <frequency> #This sets up an SSID for your ad hoc network.
Once these commands have been run on both machines, you now want to assign an IP address to both. The most straight forward way is to use a static IP for both, making sure they are on the same subnetwork. Running the following command on each will accomplish this:
bash# ip addr add <IP address>/<subnet mask> dev <interface> #e.g.: ip addr add 192.168.5.1/24 dev wlan0 #This should go without saying, but make sure the IP address is different on the two machines
Now you should be able to ping the IP of the opposite machine and get a response. If you get it, you're done! In our experience, it can take a while of pinging before we get a response back. We will have to look into what the cause of this is.
For our project, we compiled these changes into a easy to use script, called "ad-hoc_setup.sh". The script works as follows:
ad-hoc_setup.sh <interface> <IP_Address> <SSID>
This script must be run on both the Bone and the host that you want to add to the ad-hoc network. Keep in mind that the IP_Address must be different (but on the same subnet, /24) and the SSID must be the same.
Adding the ability to hover over lines to get data would be a good feature. For example, hovering over a line and seeing that it was tracked at at certain time and being able to see the exact longitude and latitude associated with it would be a nice feature.
Another feature that may be harder is adding algorithms that would analyze the GPS data and attempt to fix it or give a better sense of the accuracy of the reading. While we were using our tracker, we found that it often would stray a few meters from where we actually were, especially if we were moving fast. Given more time, we may have been able to find a way to rectify the accuracy issues.
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.
Server Side Events info: http://www.html5rocks.com/en/tutorials/eventsource/basics/
GPS NMEA Sentences: http://www.gpsinformation.org/dale/nmea.htm
Embedded Linux Class by Mark A. Yoder