Yesterday, I had a first test-flight using the “GPS for Yaw” feature of ArduCopter 4.1.0-beta1. Hardware setup uses two ublox ZED F9P chips with helical antennas mounted with 70 cm distance.
Before going into the air, I noticed that a single board computer (with a CPU working in the range of 1.5 Ghz to 2.5 GHz) mounted also on the frame seems to interfere with GPS. It takes longer to get “RTK fixed” status (status = 6) on GPS2 (as required for a stable GPS based heading) and quite often it went down to “rtk float” (status = 5) or even 3dgps (status = 4). So I decided to shutdown this computer and now the GPS fix status was most of the time stable on “RTK fixed” level (status = 6).
I was also using RTK correction data via NTRIP from a local service, so most of the time also first GPS was on “RTK fixed” status (status = 6):
The flight was good, I noticed no issues. Position was held very stable and when I moved the sticks, all reactions were as expected. There was no yaw drift during that flight.
Number of satellites was between 24 and 27 and hdop was between 1.2 and 0.8 on GPS1 and between 0.6 and 0.4 on GPS2. Nevertheless, I got quite often “Unhealthy GPS” warnings spoken on Mission Planner and I did not see a reason for that. There are over 6000 GPS messages in the log, for about 10 minutes flight, this means 5 Hz for each GPS, so there should not be a communication problem.
Also, when you look into the log file, there are a lot of events of type “GPS_PRIMARY_CHANGED” (82 events in 10 minutes flight).
When you look at the GPS track on the map, it also looks quite astounding:
You can see a zigzag track but it was not the way, like the drone was flying. It was flying very smooth, so I assume, that this zigzag is just an issue with the way, how Mission Planners log analyzer interprets a track when you have two GPS mounted in a significant distance.
I guess, this is not intended?
EDIT: You can download the onboard log here: https://kopterkraft.com/downloads-static/2021-05-15%2012-10-29.bin