Dear DIYDrones,
I have been following the ArduPlane Group here for quite a few month, and your discussions were truly helpful in solving my Ardu related problems. However, recently I've stumbled upon this NMEA/AHRS interference topic and it seems that I am unable to overcome it by myself. So, here is the summary:
I am trying to compare the navigation performance of my ArduPilot 2.6 with latest SW release (2.76) with various GPS units using:
1. 3DR GPS LEA6 (v1.1)
2. 3DR MTK (V2.0)
3. Ashtech MB100 (configured for NMEA output)
The only way in which I can connect the last GPS is via NMEA only protocol and it does communicate with APM (providing the GPGGA and GPVTG datasets). The problem is that there is a fairly serious side effect: APM's AHRS pitch output starts to oscillate by as much as +/- 3 deg around the real pitch attitude. I have rechecked that the same situation occurs when I use MTK gps with ArduPilot compiled with GPS_PROTOCOL_NMEA defined. i am positive that, there are no such oscillations when I use the default GPS_PROTOCOL_AUTO option either with LEA or MTK (well maybe a +/- 1 deg but this is totally acceptable). The most curious thing is that the problem is present even without any GPS sats in range (confirmed on both MB100 and MTK in NMEA only).
Initially, I assumed that this may happen due to too high computational load of the NMEA protocol parser, but it seems unlikely as the APM scheduler debug does not indicate any GPS related overruns (average G_dt_max execution time for both MTK binary and NMEA GPS is somewhere in the range of 20,2ms). Also, I tried compiling without any camera mount support to make the Ardu code less computationally intensive but this didn't seem to have any effect on the pitch oscillations.
So my question is if it is an APM bug related to the NMEA implementation? Did anybody else experienced something similar? Any suggestions on how to proceed with this?
Thanks in advance for your help!
Cheers,
Przemek
Replies