I would like to know how I can, using an external GPS that provides me with NMEA sentences of position and heading (GGA and HDT), pass them to Ardupilot so that it uses this heading (HDT) and disable the compasses, which give me a lot of magnetic problems.
It is a GPS that has two antennas, but I don’t want to send the GGA position of each one and have Ardupilot calculate the heading; I want to send the HDT sentence and have Ardupilot take that heading directly.
I have been following this thread and it seems that the question is similar to mine, but I think the solution given is to use the position of each of the 2 antennas. I don’t want that; I want to use the heading that comes from the GPS in the HDT sentence:
We believe it was because they took the boat to test that the course was correct and they turned it between two people, and when they picked it up, since they covered the antennas, it gave some incorrect value.
In any case, I understand that GPS[0].Yaw is the heading that comes directly from the HDT sentence. But what is the actual heading value that the AP uses to steer the boat?
Looking at a previous log where the course (HDT) didn’t give zeros, I think that seeing how ATT.Yaw behaves, it seems to me that it is the actual course the boat takes. Is that right?
It’s just that when I see the one that gives zeros, I don’t understand why it started to change before GPS[0].Yaw changed abruptly. Then I see that in other areas it has a hard time recovering because it must be a somewhat slow filter. Is there any way to make it respond more quickly?
I missed a key point in this log. It appears your test began before the EKF reported yaw alignment complete (that only happens in the last few seconds of the log, likely upon disarm and state reset). So this test was basically just invalid. Wait for the initialization sequence to complete before moving the vehicle.
Also, if you’re going to push the vehicle around, wait for EKF alignment and do your testing disarmed (with LOG_DISARMED,1 configured for analysis). Arming the vehicle likely places some kinematic constraints on EKF state management that won’t be met with zero throttle input.
To answer your above question regarding AHR2 vs ATT - the ATT values are primary in the control loop. AHR2 is secondary/backup.
Another thing, today we tested in navigation and heading, and since it’s not covered, it works much better, but I notice that sometimes 1 or 2 zeros in HDT still come through every few minutes… is there a way to filter that data when it reaches the ArduPilot?
Those messages are entirely irrelevant to Rover (and happen after arming anyway).
The key indicator for you should be AHRS: EKF3 Active, but there is a better way to determine ready for arming.
Enable the GPS bit for ARMING_CHECK (or just leave the default of 1 for all!) and select a position-dependent mode like LOITER. If you can arm, all is well. Alternatively, you can enable fences with FENCE_ENABLE (even if you don’t want to use them), and prearm checks will fail until the system is healthy enough for navigation.
As for filtering erroneous HDT data - that’s what the “F” in EKF does.
One question, I am investigating each of the parameters so that this sails as well as possible…
If I no longer use compasses, my antennas are aligned with the bow, and the HDT goes from 0º to 360º, fluctuating the value when looking North between 359º and 1º, could this cause problems?
And the parameter “AHRS_ORIENTATION” is set to “Roll180”, does this affect me in any way?
Another thing I wanted to ask about the filter is that I would like to prevent certain GGA and HDT strings from reaching the AP and being processed—can’t that be avoided?
These strings, for example, are normal examples of good data:
But these others, either because the value is 0.0 (almost impossible to get a course or position like that), or because they are blank, I wouldn’t want it to process them. Can’t it just discard them?
