I use 2 downward facing range finders that can operate in different distance-intervals. I want to use them for the EKF (ideally both according to the current height). In case we somehow get out of the range of both, the barometer should be used. The way I understand the description of EK3_RNG_USE_HGT, I should keep EK3_SRC1_POSZ = 1 (Baro).
According to the logs, it seems to not use the rangefinders at all. Since the EKF’s height estimation doesn’t converge to the range finders’ measurements at all (see plot below), I assume it’s not about the RMS of the noise.
As a result, it’s sometimes hard to get the drone to go ascend. Once it is at a normal height for a few seconds, everything behaves fine.
Setup:
ArduCopter v4.6.2
Mission planner 1.3.83
RNGFND1: TeraBee TOF EVO 60m
RNGFND2: onboard lidar of HereFlow Optical Flow Sensor
GPS is turned off, since we are currently flying indoors.
Parameters:
EK3_SRC1_POSZ = 1 (Baro)
EK3_RNG_USE_HGT = 70 (70% of maximum distance)
EK3_RNG_USE_SPD = 2 (m/s)
RNGFND1_MIN_CM = 65
RNGFND1_MAX_CM = 6000
RNGFND2_MIN_CM = 0
RNGFND2_MAX_CM = 70
Questions regarding EKF3:
Why did the EKF not use the range finders?
Is EK3_RNG_USE_HGT = 70 (% of maximum distance) multiplied with the first range finder or with the range finder, that is supposed to be used.
Does the EKF use both range finders depending on which one is within its operating range?
Can I see in the logs, when (and which of) the range finder or barometer was used when?
Can I see in the logs, whether the innovation consistency check of a sensor failed? (regarding EK3_RNG_I_GATE)
Further questions:
Since I fly indoors, I disabled GPS (as recommended in documentation). To get log files with meaningful names, I set the system_time using mavproxy at every start of the drone. Is there a better way? Could I activate GPS and just not use it in the EKF?
in the “tuning”-window of ardupilot: What’s the difference between flow_x and flow_comp_m_x and what is the exact meaning and unit of them?
Is there a documentation about the entries of this tuning window and the entries in the log file?
What happens in case of failsafe scenarios while in Guided mode? Are the commands of the companion controller ignored or do I have to catch these scenarios on my own? Could I somehow still overwrite the commands with the companion computer, if I wanted?
I am currently trying different combinations of settings and noticed a few mistakes on my side:
In the previous figure, I plotted VD instead of PD. The correct plot is below. Ideally, the green graph (PD) should be mirrored in comparison to the red line with a small offset of 0.17m). It deviates from that, especially at the beginning and at the end (at low altitudes). That and the minimum range of range finder 1 being 65cm makes it plausible, that actually only the first range finder is used (like some of you told me too). It would be unfortunate to have the hardware to cover the whole range from 0m to 60m and being limited by ardupilot. I will do some more testing…
By default, surface tracking was activated (SURFTRAK_MODE was 1) which is not recommended to be used together with fusing the range finder into the EKF (according to the warning here). I am not sure, whether it actually helped in the situation at the end of the plot, where the height estimate was so bad. But that would mean, that the surface tracking used the second range finder, which seems unlikely to me. Does someone have an explanation, why the drone kept the height so well (in PosHold) at the end, despite the height estimation being bad.
If I use 2 IMUs (and the EK3_IMU_MASK = 3), I should also take care of EK3_SRC2. (To my understanding SRC2 should correspond to the second EKF-core/-lane/-instance, which in this case uses the second IMU, right?) If I set SRC1 and SRC2 the same, I only get robustness regarding IMU failures. Does someone have a better idea for this sensor setup?
Sorry for not directly answering your question but can I ask why you’d like to use the rangefinder as the altitude source? It sounds like the vehicle is flying outdoors and it’s not recommended to use the rangefinder as the EKF’s alt source unless the vehicle is indoors and flying over a completely flat floor with no “ground clutter” (e.g. no tables, chairs, boxes, etc)
I’m sure it’s probably already clear but terrain following and surface tracking do not require setting the EKF’s altitude source as rangefinder
at least for now, most testing has to be done indoors, since we are too close to an airport. Later, we will have to test everything outdoors somewhere else. So I would like to use the rangefinder as altitude source (indoors), since otherwise the altitude control during launch and landing is quite bad (despite GND_EFFECT_COMP=1).
I just noticed EK3_GND_EFF_DZ (currently set to 4). Regarding the following plot: At about time = 6 sec the estimated negative height (XKF1[0].PD blue line) increases. Shouldn’t EK3_GND_EFF_DZ = 4 prevent that, since both barometer altitudes (red and yellow) don’t exceed -4m?
I tried to look up in the code whether 2 rangefinders can be used for height estimation. The EKF3-code is a bit larger than expected, but at least a comment claims that 2 rangefinders should be supported in Copter 4.6.2 So why did it not work in my case? I would like to use both rangefinders, since they can only combined cover the whole range starting from 0m.
Here are the log files (This time the file should be public). The param file is uploaded in another message above.
Yesterday I set the EKF to use only the short distance rangefinder (which was RNGFND2 previously) as SRC1_POSZ (without barometer). Since then I can not fly higher than about 1.2m in PosHold mode. Is that somehow a fixed percentage of the maximum range? I tried setting EK3_RNG_USE_HGT=85 and RNGFND1_MAX_CM=195, but I am far away from reaching 0.85*195cm=165.75cm.
Yesterday, I also found out that surface tracking was on by default and deactivated it. If I understand terrain following right, it is only used if I define a goal position (e.g. in a mission) with an altitude above ground. So I should not be able to accidentally use it in PosHold, right?
If I use 2 IMUs (and the EK3_IMU_MASK = 3), I should also take care of EK3_SRC2. (To my understanding SRC2 should correspond to the second EKF-core/-lane/-instance, which in this case uses the second IMU, right?) If I set SRC1 and SRC2 the same, I only get robustness regarding IMU failures. Does someone have a better idea for this sensor setup?
Out curiosity where did you read this? My understanding is that SRC1, SRC2, and SRC3 are there so the end user can switch between different sources using a switch or a script, like when transitioning between GPS and non GPS environments. Maybe I have been misunderstanding this so I’m genuinely curious!
hi,
after reading the documentation again, I think you are right.
First I read about the existence of multiple EKF-lanes and the example table showed that different lanes use different sensors. I was wondering how one defines which lane uses which sensor and EK3_SRCx_y seemed intuitive to me.
What I didn’t notice was that in the table (mentioned above), the different sensors were just different instances of the same type of sensor. So I assume now, that all lanes use the same type of sensor and EK3_AFFINITY defines if all lanes use the primary sensor instance (of a specific type) or different lanes use different instances of that sensor type. (I previously was also wondering how you could compare the lane error score for lane switching, if you compare completely different sensor combinations. With the same sensor type on all lanes, that makes more sense.)
Since the number of lanes is defined by the number of IMUs, I assume that the IMU’s sensor affinity is always on.
Looking at the documentation again, it seems like if you set EK3_SRC_OPTIONS appropriately, then what you were saying could happen.
EKF Source Options. Bit 0: Fuse all velocity sources present in EK3_SRCx_VEL_. Bit 1: Align external navigation position when using optical flow. Bit 3: Use SRC per core. By default, EKF source selection is controlled via the EK3_SRC parameters, allowing only one source to be active at a time across all cores (switchable via MAVLink, Lua, or RC). Enabling this bit maps EKF core 1 to SRC1, core 2 to SRC2, etc., allowing each core to run independently with a dedicated source.
