Hi, I have some confusion over the UAV and its actual altitude source. I have been using AHRS2 as the “true” value of the UAV’s altitude, but it doesn’t necessarily seem to fuse the Barometer and GPS altitudes? The logs of our flight are attached as such: Flight 1, Flight 2
What is the most accurate parameter to determine the UAV’s altitude?
Does EK3_SRCX_POSZ all have to be set to 3(GPS), and in that case would altitude control still failover to BARO in case the GPS is deemed unreliable
Is there a way to check which EK3 lane is being used?
Sorry for being all over the place, but the more I try to dive deeper into this issue the more questions seems to sprout out. Thanks to anybody willing to pick this up!
What is the most accurate parameter to determine the UAV’s altitude?
I prefer the EKF’s “up-down position” which is one of its essential estimated states. You’ll find it in the .bin logs as XKF1.PD.
Is there a way to check which EK3 lane is being used?
XKF4.PI. But also, when the lane switches, a notification is sent via telemetry to the GCS. All info sent via telemetry is available in the .bin under MSG. (Notice also, this means that notification will be in the .tlog if that’s ever useful to you.)
I have been using AHRS2 as the “true” value of the UAV’s altitude, but
Assuming you mean AHR2 in the bin file, that’s the backup kalman filter. Not the main one. That would explain why you are seeing somewhat-reasonable altitude-looking things which also don’t match observed uses of “altitude”.
Does EK3_SRCX_POSZ all have to be set to 3(GPS), and in that case would altitude control still failover to BARO in case the GPS is deemed unreliable
In the light of info above, do you still desired to mess with the EK3 SRC parameters? I’m hoping that the root cause was mistaking AHR2’s altitude as “the altitude (estimate)” and you can reset those to default values to achieve desired results. If not, please post back (explaining what you’re seeing/hope to accomplish using them) and we’ll keep helping about them.
A final note: Your post seems like you might be on the precipice of analyzing logs yourself. I love helping self-motivated folks learn to solve their own issues & start diving into the source. Feel free to DM me here in the forums or on discord (hunt0r).
Thanks for taking the time to reply! Yes you are right, I had confused AHR2 as being the primary altitude source. I was seeing how the NavEKF libraries were referring to AHRS as the primary filtered output, but since I couldn’t find AHRS on the dataflash files, stupidly assumed that AHR2 referred to the AHRS output .
I’ll probably keep the EK3 SRC parameters unchanged, and refer to the PosD output instead (I’m assuming its the same as the XKF1.PD output based on AP_NavEKF3).
However, just to cleanly tie up this train of confusion: could I ask how does the setting of different EKF sources function? According to the default settings, SRC1 has all its POSZ,XY,VELZ,YAW and so on populated, but SRC2 and 3 only have POSZ set to a value, while all the other parameters are set to 0. How then does the ardupilot determine its velocities and attitudes for lanes 2 and 3? Also correct me if I’m wrong, but I’m assuming that XKF1[0] refers to lane 1 and EKF SRC1, and XKF1[1] refers to lanes 2 and 3, as well as EKF_SRC1 and 2, according to the default settings.
I will definitely be checking out the Discord server, but I do feel that asking questions on the forum would be better for the general sharing of knowledge. Thank you!
Did you already find the advanced EKF info in the documentation? (Copter → Advanced Configuration → ~3 EKF-related pages, one of which is linked below.)
I’m happy to keep helping in the context of that, but wanted to check first.
You are right that XKF1[0] and XKF1[1] and so on are for distinct ekf lanes.
By my reading, you seem to imply that “lane 1” (which has XKF1[i] index == 0) corresponds to the 1 in “EK3_SRC1_xxx”. Notice that is generally not true: lanes are not 1-1 with EK3_SRCx’s. But it might be specifically true, depending on the value of a different parameter: EK3_SRC_OPTIONS.
My understanding is that we can configure which sensors are used in each lane for each pos/vel/acc measurement, through the affinity configuration. What I can’t figure out is how that can be done using the 4 bit EK3_AFFINITY bitmask.
Admittedly, I have not tried tinkering about with this param, as I didn’t want to risk crashing. But I would really appreciate some guidance into how the EKF lanes tie in with the EKF sources, affinities and maybe some tips on analyzing the logs for relevant information.
As always, thanks so much for your time of the day!
I did some source diving. IMO, the exact truth is “quite complicated”. I will make an effort to improve it, but that could take some time & collaboration with the devs.
Here’s a simplification that’s “pretty accurate”:
For the IMU “sensor type”, each lane is 1-1 with the corresponding IMU instance.
For each other “sensor type” (Airspeed, Barometer, GPS, Magnetometer), if affinity is disabled, use the system-wide “primary” instance-selection logic. (“primary” switches sensors in case of failure, but not merely for high-noise.)
If affinity is enabled for a sensor type (e.g. Airspeed), each lane’s “primary” instance is the corresponding sensor of that type (e.g. lane X’s primary airspeed sensor is X, for X in 1, 2, 3, …). In this way, lane-switching becomes like sensor-switching for sensors with affinity enabled. And since lane-switching does examine aggregated noise magnitude(s), that might happily switch away from using a noisy-but-not-faulted sensor.
While the affinity logic for each sensor-type is independent (the “independent” bits of the affinity param value), with more than one affinity bit enabled, that effectively “ties together” pairs of otherwise independent sensors. (e.g. if Airspeed and Baro affinity are both enabled, it is rare that the system will ever use airspeed1+baro2. Much more likely to use whichever pair of airspeed1+baro1 OR airspeed2+baro2 is performing better.)
Does that help? Happy to answer follow-up questions, I want to match the level of detail to your level of need.
.