Today, I found out that to do fast debugging for the GPS module I will need a cheap LCD display. More than likely, I will use old code from 319k and use the same cheap module. NEED TO TELL JOHN THIS. NOT SURE IF IT IS ON THE BOM.
Valvano has his EE345J, graduate class, students design and evaluate a battery-powered GPS and IMU system (lab document link here:
http://users.ece.utexas.edu/~valvano/EE385J/Lab5_GPS_IMU_PaineCao.pdf). This design integrates data form multiple sensors in order to enhance accuracy of measured data. I need to email him to get more info on this class project.
SOFTWARE
How the students designed it is as follows, the program is divided in to 5 major functions. An infinite loop in the main which uses a foreground task that controls the GPS, which continuously reads from the SCI and preprocessing TSIP report packets as they arrive. The report packet as a structer as follows:
<DLE><ID><data bytes><DLE><ETX>
The <DLE> byte is 0x10. Data bytes 0x10 are padded with an extra <DLE> byte. The foreground loop continuously reads in data from the GPS module. When a new report packet is detected, it saves the data
bytes, stripping any padding bytes, in a global byte array buffer. Once it detects the end of a report packet, procCmd() is called and is passed the <ID> of the report packet.
The procCmd() function processes the data bytes in the buffer according to what packet ID it received. The two main packets have IDs 0x46, health of receiver, and 0x84, LLA position in doubleprecision. The health of receiver packet reports if the GPS module is functioning correctly and how many satellites it has locked on to. This is stored in a global byte variable, gpsState, which can be output on the LCD for debug purposes. The 0x84 packets give latitude and longitude in radians in 8-byte double-precision floating point format. They get stored in a global latitude and longitude variable that tracks position, and converted into positions on the map and stored in global unsigned char variables.
Here is the software flow chart found below.
Of course, the GPS will be on the robot, so this flow chart will not be entirely accurate. I will modify this to incorporate reading control information from the controller (hooked up to the PC/host).
HARDWARE
------------------------------------------------------
- Performance Concerns
- Start Time-
- How quickly the module can lock- when a lock is made the module can receive the GPS signal from satellites to calculate position. The amount of time required is referred to as, START TIME.
- Positional Accuracy of the module-
- How well it gets and holds the lock in the presence of obstacles (urban setting, canyon areas, etc)
- Dependencies for performance:
- Number of Satellite Channels- the module can simultaneously receive is an important specification. GPS modules today can receive up to 20 channels. More channels mean more places for the modules to look for a signal, corresponding to faster locking times and better locking in urban settings.
- Onboard processing of the GPS signal- new chipsets such as the SiRF III provide faster and more robust locking than previous SiRF II based designs. Ne featers such as wide area augmentation system (WAAS), or differential GPS (DGPS) provide better positional accuracy by correcting GPS signals using other sources (such as ground stations).
- Interface
- Easy to use!
- NMEA 0831 compatable
- can oubout standard NMEA messages every second
- reporting speed
- 3D position
- number of stallites in view
- GPS time
- and more...
- NMEA output- is the default, so all the user needs to do is apply power and the module begins spitting out NMEA data.
- protocol differs from module to module
- check data sheet to see what commands and protocols are available
- Batteries and Antennas
IN PROGRESS!!!
