I wanted to set up altitude hold using optical flow sensor + rangefinder (MTF02)
I understand that the height value for the drone is determined by the XKF PD parameter. I was recording logs while holding the drone in my hands and I don’t understand what’s going on. the XKF value.PD’s are very strange, as I understand it, ideally they should be mirrored to the rangefinder. I also noticed a strange thing that errors often appear (EKF3 IMU0 fusing optical flow, EKF3 IMU0 stopped aiding) But if I first turn on the flight controller from USB and then connect the battery, then there are practically no errors.
Can you look at my logs and tell me why this is happening ?
move_h.bin - moved the drone with his hands
static_h.bin - moved objects under the drone
I took a look at your logs. Here’s what I think might be going on.
EK3_ALT_M_NSE = 100 is likely the main issue. This effectively tells the EKF to disregard the barometer. Combined with EK3_SRC1_VELZ = None, there’s no vertical velocity reference and no baro constraint — the rangefinder alone can’t hold PD stable. In move_h.bin, by ~57s the EKF appears to estimate ~120m altitude, reaching ~321m by t=77s, while the rangefinder reads 1.1–1.5m. XKF4.SH (height innovation) spikes to ±321 where it should normally be <1.0. This looks like unconstrained IMU integration drift.
Rangefinder seems intermittent in static_h.bin. The MTF02 shows Stat=1 (No Data) for long stretches — it appears to only produce valid readings for ~100s total. This could be a wiring/power issue, or it may need more boot time. BRD_BOOT_DELAY = 0 might not be giving it enough time to initialize.
Hand-held testing (move_h.bin) likely explains the 30+ “started/stopped aiding” cycles. OF quality itself looks fine (91–127), but chaotic hand motion probably creates flow patterns the EKF can’t reconcile with IMU data. Your static test approach is more appropriate.
What I’d suggest trying:
EK3_ALT_M_NSE → 2.0 (default) — baro provides essential vertical damping even with rangefinder
EK3_SRC1_VELZ → 0 (default) instead of None
BRD_BOOT_DELAY → 3000
RNGFND1_MIN_CM → 10 (0 isn’t realistic for MTF02)
I believe the core problem is that both vertical constraints were removed simultaneously, leaving the EKF with nothing to prevent drift. Hope this helps!
Thanks for trying to help. I tried to set EK3_SRC1_VELZ = 0, but it is automatically set to None. I set the other parameters as you said, but unfortunately it didn’t help.
I have recorded three new logs. They are available on G.Disk in new_logs folder
new_log1 - As far as I understand, everything is working as it should before 00:39? Does XKF1.PD show the height relative to the drone’s power point ? If you look at the rangefinder, the height has changed relative to the inclusion by 0.6m (0.9 - 0.3) and XKF1.PD shows -6 ?
new_log2 - Turned on the drone in the sequence I mentioned, first from usb, then from the battery. As a result, there were no error messages, but the XKF1.PD graph is very strange again. You can see how the slope of the straight line changes when the height changes.
new_log3 is a normal battery power-on, just like when recording new_log1, but this time I don’t see anything XKF1.PD has in common with the rangefinder.
I have a very similar issue with optical flow fusion where my flow gets rejected mid flight during fast motion as you see in the log it goes into ekf failsafe and then exits repeatedly
Also i have another issue where the flow correction is abrupt and not continuous like it takes some error buildup for it to get corrected with is overdone and then there is more error buildup. It manages to hover but its not as perfect as gps and has a lot of drifting and delayed corrections
I have attached the link of the most stable flight ive had till now after trying to reduce camera delays and the failsafe issue still exist.. please help me out too
i have done the same setting as OP except i set barometer for EKF3 pos_z because it was suggested to do so instead of rangefinder(and rangefinder wasnt even being fused into ekf properly).
The radio failsafe in the end was me turning of the remote and not any speific issue
In another run my flow inovation was spiking excessively, the small blue line is the actual flow and it follows t
I managed to achieve the same values for XKF1.PD and Rangfinder.Dist
Now I have made the following parameters:
EK3_SRC1_VELXY = NONE
EK3_SRC1_POSZ = Range finder
It turns out that I have some kind of conflict between opticflow and rangefinder.
I looked at your log. I think the root cause of your issues is that your rangefinder stops working once you’re airborne.
Here’s what I see in the data:
Your rangefinder is essentially dead in flight. From about t=116s onward (shortly after takeoff), it bounces between Stat=2 (no data) and brief Stat=4 flickers showing 0.05m — while the barometer puts you at 1.5-2m altitude. Only 502 out of 1761 rangefinder readings are valid, and most of those are from before takeoff. RNGFND1_TYPE=20 (DroneCAN), MAX=1200cm — so it’s not a range limit issue. The sensor either isn’t pointing straight down, has a wiring/power problem, or is malfunctioning.
This explains all your symptoms:
Flow innovation spikes (FIY up to ±3494) — Optical flow gives angular rates, which the EKF multiplies by height (HAGL) to get velocity. With HAGL stuck at ~0.22m (last good reading) while the drone is at 1.5m, the velocity calculation is off by roughly 7x. Every small movement creates a massive innovation mismatch.
Abrupt corrections, not continuous — The EKF rejects flow data when innovation is too high, then re-accepts it when the drone is momentarily stable. This creates the “error buildup → overcorrection” pattern you described.
EKF failsafe cycling — Same cause. The EKF can’t maintain a stable position estimate with corrupted flow scaling.
Your graphs confirm this — FIX (green) spikes to ±3000 while HAGL (red) stays flat near zero.
Your OF sensor itself is fine. Quality is 240-255 throughout the flight, which is excellent.
Two things to fix:
Fix the rangefinder first. Check mounting orientation, wiring, power supply. Test on the bench — does it give stable readings at various heights? It needs to work reliably up to at least your flight altitude.
Calibrate optical flow. FLOW_FXSCALER and FLOW_FYSCALER are both 0, which means no calibration has been done. Once the rangefinder is working, do the in-flight calibration procedure described in the ArduPilot docs.
Until the rangefinder is fixed, optical flow will never work properly — it fundamentally needs height data to convert angular flow rates into velocity.
I am using a benewake tfmini s as rangefinder throught uart and also my optical flow data is sent throught mavlink calculated on my companiom computer that is why there is no scaling.
I thought the tfmini was a fair enough rangefinder for the job why is its data so messy then, the drone doesnt even tilt to much of move too fast either during the entire flight sequence
Good point about the MAVLink flow – you’re right, if the flow is calculated on the companion computer and sent via OPTICAL_FLOW_RAD, then FLOW_FXSCALER/FYSCALER don’t apply. My mistake on that one.
Regarding the TFmini S – the sensor itself is capable, but something is clearly going wrong in flight. In your log, after takeoff (~t=116s), it repeatedly shows Stat=3 with Dist=13.00m (out of range) or Stat=2 with Dist=0.01-0.05m, while the baro puts you at 1.5-2m. A working TFmini S should have no trouble reading 1.5m — its range is up to 12m.
A few things that could cause this:
Propellers in the field of view – TFmini S has a ~2.3° beam angle. If it’s mounted near the props or at an angle, the blades can intermittently block or reflect the beam.
IR interference from propellers – spinning props can modulate ambient light in ways that confuse IR-based lidars.
Mounting angle – even a few degrees off vertical can cause the beam to miss the ground or hit a leg/arm of the frame at certain attitudes.
Vibration – if the sensor isn’t firmly mounted, vibration in flight could be causing connector issues or affecting the optics.
I’d suggest a simple test: hold the drone by hand at about 1m height (motors off), tilt it gently to different angles, and watch the rangefinder readings in Mission Planner. If they’re stable, then try with motors spinning (props on, but held down or on a test stand) to see if prop wash or prop interference causes dropouts.
Once the rangefinder gives clean data in flight, the flow scaling issue should resolve itself – HAGL will track actual height and your flow innovations should come down to reasonable levels.
My rangfinder is mounted in the bottom most layer with a stiff mount and theres nothing blocking it..while holding it with my hand the reading on sonarange is stable and doesnt drop to zero at all i will try testing if vibration of the floor tile pattern is causing the issues
This is utter nonsense. The rangefinder seems to be providing data. Check the orientation param. I can’t review the log right now, but the screenshot makes it look like a config problem and not any of that LLM generated drivel.
