I’m running Copter 4.5 on a HolyBro PixHawk6x to fly my HolyBro X-650. I have GPS-RTK from a Holybro H-RTK F9P Base Station, an F9P Rover on the drone, and SiK telemetry radio data link.
The autopilot is supposed to have the drone loiter at the waypoints for 3 seconds. Looking at the GPS data I extracted from the ground control telemetry log, the latitude and longitude positioning looks good, but the altitude positioning looks like there is significant error.
In the plots, the blue circles are the actual GPS coordinates recorded by the ground station telemetry log while the drone is loitering. The asterisk’s are the waypoints. The top down view shows the lat/lon alignment. The side view shows the altitude errors. For reference, the top down view shows a circle with a radius of 50 meters.
I’m not sure where to start to address this issue. Are there specific parameters that I could have missed for the flight controller? Does this mean that I will need Lidar for accurate altitude position holding and loitering?
I don’t have Lidar, and the ground is covered with patches of brush and other vegetation. Is it possible that the drone is using the barometer instead of GPS for elevation? Is there a parameter that I can check for that? I couldn’t find one in the documentation.
Set AHRS_GPS_USE to 2 (Use GPS for DCM position and height). EK2_ENABLE, EK3_ENABLE: set to “1” to enable the EKF2 and/or EKF3 respectively.
EK2_IMU_MASK, EK3_IMU_MASK: a bitmask specifying which IMUs (i.e. accelerometer/gyro) to use. An EKF “core” (i.e. a single EKF instance) will be started for each IMU specified.
1: starts a single EKF core using the first IMU
2: starts a single EKF core using only the second IMU
3: starts two separate EKF cores using the first and second IMUs respectively
EK3_PRIMARY: selects which “core” or “lane” is used as the primary. A value of 0 selects the first IMU lane in the EK3_IMU_MASK, 1 the second, etc. Be sure that the selected primary lane exists. See Affinity and Lane Switching below.
I have done this before. I set EK3_SRC2_POSZ to 3 (and set the other SRC2 to the same as SRC1) and put the source selection on an RC switch. I didn’t fiddle with lanes or EKF types or IMU masks, those should all be set up correctly already.
I was able to safely conduct a mission maybe 1m above the ground safely. Be sure to switch back to baro if you lose RTK fix!
I fly with an F9P, using GPS as my main altitude source.
You only have to use EK3_SRC1_POSZ and set it to 3. No need to touch EK3_SCR2_ and EK3_SCR3_. I didn’t set AHRS_GPS_USE to 2.
DO NOT enable both EK2 and EK3. Only EK3.
Leave EK3_PRIMARY to 0.
I don’t think the issue is the GPS precision. With your data, Ardupilot knows it is not at the correct altitude, yet it is not going to the correct altitude. Most likely, that is because the EK3 is not using your GPS, but your barometer ( EK3_SRC1_POSZ was set to 1 instead of 3.
Take a look at your log. Compare GPS.Alt (GPS altitude) and POS.Alt (Altitude estimated by the EKF). And you can also look at BARO.Alt, and compare if it looks more like what POS.Alt looks like, to confirm that the Altitude source is indeed the Baro, not the GPS.
But the Flight Controller must have been using the barometer. The flight controller altitude and barometer altitude agree, but not the GPS data. I’ll prove it when we can get out to fly again!
To clarify, in these plots:
Barometer Data = BARO Alt
GPS Data = GPS Alt
Flight Controller Data = CTUN Alt
Sorry about the non standard legend, the plots were made so that I could explain the altitude error to a professor who does not use ArduPilot.
There is a MATLAB function called “ardupilotreader” that imports the Dataflash logs from a .bin file.
There is also a MATLAB function called “mavlinktlog” that imports the telemetry .tlog files that are saved by the ground control station.
It’s pretty handy, thanks MATLAB! I haven’t tried using python yet, but I’ll have to do that after I leave the university and my MATLAB license expires.
