Bug in NMEA parsing code for ArduPilot and ArduIMU (it's been there since the beginning)

As a fan of inexpensive GPS units I've always been interested in keeping NMEA GPS's compatible with ArduPilot and ArduIMU. So last night and today, while I was incorporating Remzibi's OSD code into the AP2.7.1 source I did some testing with my new GPS Emulator navigation logic. During this test, I had problems with the plane waffling back and forth around 0 degrees (due north). I have seen this before during testing with AP2.6 and my old Emulator. For a while, I attributed this to an error in my program and spent a good 2 hours searching for the cause. Finally, I tried the same exact test using uBlox for my GPS_PROTOCOL... and what do you know? It worked like a dream!?!? So I went back to NMEA and upped the Hz. I tried everything from 5-30Hz and nothing made it any better.

Any time the plane approached or passed 0 degrees the AP would tell my emulator to turn hard left, then hard right, then hard left and sometimes would get stuck in this cycle (not the sine wave I posted yesterday) but a very tight sine wave only varying about 10 to 40 degrees before snapping back hard the other direction.

Finally, I started looking at the NMEA parsing code in the AP source. It turns out, there are 2 atoi() function calls for ground_speed and ground_course in the GPRMC parsing routine. Simply changing atoi to atof completely solves the problem. I assume it's a rounding issue and since the GPS sends one decimal place after the degrees, this decimal place was getting rounded to an integer and then multiplied by 100. I believe this bug has been there since the very beginning when the NMEA parsing routine was first written. I wouldn't have guessed that one decimal point would make such a difference!

Howdy Gents,

I have been working the NMEA issues with ArduPilot. Troy, you can find the Venus Binary command set here:

http://www.sparkfun.com/datasheets/GPS/Modules/AN0003_v1.4.14_Flash...

The Venus is a nice GPS chip, I am using it as well. If you have a look at the binary protocol you will find that SOG and COG is not included, it is instead ECEF Velocity information and ECEF location information. Also, as you so aptly pointed out, the GPS is operating in a slightly more complex coordinate frame than a plane. The use of RMC is probably a good idea.

Also note that the binary protocol is 59 bytes per packet, not much larger than the NMEA sentence itself. So from a size perspective there is little advantage to using it over the NMEA equivalent. There is additional accuracy information that could be really useful but for practical purposes it is not.

Juampa, note that the maximum size of the NMEA sentence is 82 bytes with the payload a maximum of 79 bytes. So the buffer should be two more bytes larger to ensure compliance with the standard. Multipart sentences have a smaller size.

I also found that the VTG parsing was not correct. The NMEA standard does not mandage spaces after the comma delimited value and this will cause parsing errors.

Logan

You need to be a member of diydrones to add comments!

Join diydrones

Comments

Troy October 20, 2010 at 12:50pm

THANKS!!
I had found a earlier rev of this document but the command set but did not have info on "Navigation data message" thats when I gave up and started playing with NMEA.
I hate to abandon the idea of streamlining NMEA parsing to only GPGGA messages but the binary protocol is likely the better choice.
Not sure if it will be any easer to get from ECEF domain to SOG, COG. Will have to ponder that a bit. Cant get away from doing trig can I :)
Thanks again.

Troy
Logan Greenlee October 15, 2010 at 8:10pm

Howdy Gents,

I have been working the NMEA issues with ArduPilot. Troy, you can find the Venus Binary command set here:

http://www.sparkfun.com/datasheets/GPS/Modules/AN0003_v1.4.14_Flash...

The Venus is a nice GPS chip, I am using it as well. If you have a look at the binary protocol you will find that SOG and COG is not included, it is instead ECEF Velocity information and ECEF location information. Also, as you so aptly pointed out, the GPS is operating in a slightly more complex coordinate frame than a plane. The use of RMC is probably a good idea.

Also note that the binary protocol is 59 bytes per packet, not much larger than the NMEA sentence itself. So from a size perspective there is little advantage to using it over the NMEA equivalent. There is additional accuracy information that could be really useful but for practical purposes it is not.

Juampa, note that the maximum size of the NMEA sentence is 82 bytes with the payload a maximum of 79 bytes. So the buffer should be two more bytes larger to ensure compliance with the standard. Multipart sentences have a smaller size.

I also found that the VTG parsing was not correct. The NMEA standard does not mandage spaces after the comma delimited value and this will cause parsing errors.

Logan
Paul Mather October 12, 2010 at 5:19pm

Very nice Juampa!!!

Troy, try googling Arduino lat long heading
I'm sure there's some pretty simple math to calculate heading.
Juampa October 12, 2010 at 4:55pm

A couple of RTL from different directions, very windy day. Easy Star with ailerons, default PID gains, GPS Locosys LS20033 at 5Hz, AP 2.7.1, no shield, thermopiles.
http://www.vimeo.com/15788869
Troy October 12, 2010 at 2:11pm

I just realized (or remembered) something. The math for speed and direction is trivial on a flat world. Getting it from Lat and Long data is a little tougher (trig slows down a uP ).
I could probably set some scaling factors for longitude and latitude when the GPS first gets a lock and then use a flat rectangle earth assumption from then on. Most flights in local area wouldn't get far off. Can only make short flights in Greenland :) .
Any way I will still log some NIMA data and play with replacing GPRMC with calculated values from GPGGA.
Troy October 12, 2010 at 1:49pm

I'll capture some NMEA data log files and do a post processing comparison of speed dir calculated from CPGGA and vs that reported in GPRMC.
Paul Mather October 12, 2010 at 1:38pm

For some reason, NMEA has been largely abandoned for ArduPilot use. I was glad to see Jordi stocking the MediaTek GPS unit until I found out they have a custom binary message instead of NMEA. My next interest is in writing a ground control station. I've got 2 different brand NMEA GPS's, a uBlox, a Sirf and a MediaTek here on my desk. Once I get my GCS up and running, I'm going to do my own testing on the accuracy of all of these units.
Juampa October 12, 2010 at 1:35pm

It's great to see more people working on NMEA mode, widely used around here.
I'm using BUF_LEN 80, more than enough.
I just put this code on the end of fast_loop() to get 5Hz without drops. medium_loop is not fast enough.
#if GPS_PROTOCOL == 0
update_GPS();
#endif
I'll upload a video to show it working on my Easy Star with ailerons mod.
Paul Mather October 12, 2010 at 1:34pm

I don't think it does. I think it's just comparing it to the last data point. Yes, I think both could be calculated on the fly which might eliminate the need for GPRMC.... That's an interesting idea.
Troy October 12, 2010 at 1:32pm

I am playing with NMEA because I can not find documentation for the binary spoken by my SUP500f (which uses a Skytraq Venus chip). If someone has come across documentation of there protocol please point me in that direction.

of 3

This reply was deleted.