Drone won't climb above 1m altitude when using optical flow

I have an MTF-02 (max range: 2m) and have tried setting the primary altitude source to both rangefinder and baro with no luck. Can someone please check my params and tell me if it is some setting that is causing this or is it due to EKF?

drone.param (16.7 KB)

1 Like

Please post a log of that flight as well.

Flight log: https://drive.google.com/file/d/1ipaJlQqofVRa-1Td9FGhRlZ7ZyJyoCOs/view?usp=drive_link

Thanks for posting the log. From the data, the vehicle appears to be underpowered. The log shows thrust loss along with a battery failsafe triggering while airborne, which causes the vehicle to enter LAND mode.

This points to an insufficient thrust-to-weight ratio rather than an EKF or rangefinder configuration issue. I’d recommend rechecking your thrust-to-weight calculations and overall power system (motors, props, ESCs). Fully charging the battery is unlikely to resolve the issue on its own.

Nope, that thrust loss was towards the end of the flight due to low voltage and I was yawing if I remember correctly. My TWR is more than 2. This is definitely a configuration issue as it can go above that without optical flow. If this was a underpower case, the drone should still be rising at a slow enough rate and should not be having a hard 1m ceiling.

Set EK3_SRC1_POSZ = 1 (Barometer only).
Connect the rangefinder, which will be used for altitude estimation up to 70% of the configured height, after which the system will smoothly switch to the barometer.

I tried that too. Also tried setting “optflow may use terrain altitude”along with this

Hi @StrikeEagle,

Yes, this is a built-in safety feature to stop users from climbing above the max range of the rangefinder because the rangefinder is required in order for the EKF to consume the optical flow data. So if this limitation was removed the pilot could climb out of range of the rangefinder, the EKF would lose its position estimate and an EKF failsafe would be triggered and the vehicle would switch to Land mode.

The easiest solution is to use a rangefinder with a longer range

1 Like

Okay but even if I increase the max range in the params and also doable the rng_hgt param, it still doesn’t try to climb above.

What’s funny is that I can actually Takeoff to more than 1m (max I have done indoors is 2m) and it hold position well. I don’t remember if I had used my roll/pitch sticks but I guess it can definitely move in Guided. But if I climb to above 1m initially, and i manually try to increase altitude from the RC, then it will decrease in altitude.

Is there a method to switch to baro above 1m?

@StrikeEagle,

Increasing the RNGFND1_MAX parameter should definitely increase the maximum range that the vehicle can climb to although I suppose it’s possible that there is a hard-coded limit somewhere in the driver for the rangefinder being used (sorry, I haven’t looked at the log file yet).

AP may be enforcing slightly different safety features depending upon the mode. So for semi-autonomous modes (e.g. Loiter) it likely limits the altitude because the pilot could easily push the sticks so that the vehicle climbs above the rangefinder limit and thus cause an EKF failsafe.

In Guided mode however we trust the caller more because they would have specifically requested a higher altitude and so it’s less likely that it is pilot error.

These safety features are often applied before the actual limit.. e.g. an additional safety margin is added

2 Likes

Can you share with us what are your EK3_SRCn_POSZ values? Have you give it a try suggested by @Anup_Ahlawat ? Maybe you take a look at these parameters too. EK3_RNG_USE_HGT and EK3_RNG_USE_SPD.

Hi @rmackay9

Was the requesting tester project similar to the user query?

Hi @Jai.GAY,

Yes, AP-4.7 does allow the estimated altitude above terrain to be used once the vehicle is out-of-range of the rangefinder by setting EK3_OPTIONS = 4 (Optflow may use terrain alt) but I suspect it won’t work well in this case because the baro noise will be a large part of the alttitude estimate. e.g. baro noise of 1m when the vehicle is only flying at 2m will have a huge impact on the optical flow sensor scaling. When the vehicle is flying at 50m or 100m that baro noise will have a much smaller impact.

I’m also unsure whether we disable the altitude limiting in Loiter when this option is enabled, I’d need to check..

1 Like

Okay the baro noise makes sense but if I remember correctly to the days I flew before the flow sensor, I saw that the EKF altitude estimate with just the barometer and IMU fusion was pretty good

1 Like

Good as in “smooth” or “smooth and matching attitude compensated rangefinder data”?

Only the later provides useable data for optical flow, former can mess up EKG attitude estimate and you really don’t want to have your indoor copter thinking horizon is 30° down :sweat_smile:.

Well, yeah admittedly, it’s not smooth but the average is almost correct. Anyway I don’t really have to raise it above 1m but just asked what the procedure is. I don’t necessarily want to use Loiter but the thing is, even Alt hold has this 1m restriction now

Hello guys. I solved this issue. There is a parameter in QGC’s Application Settings → Plan View → Default Mission Altitude. I must have changed it to 1m for safety during initial testing sometime. Or this corresponds to some ArduCopter parameter bur recently I also tried flying with no GCS connected and just using the RC but even then it had this limit of 1m even in AltHold. Anyway now I changed this parameter to 1.5m and now I can apparently climb to atleast 2m (maybe more but I didn’t try because I’m using an MTF-02) in Loiter. I also changed WP_NAVALT_MIN to 1.7m from 1.2m but this parameter alone didn’t solve it before I changed that QGC parameter.

I have given other relevant parameters as follows:

EK3_SRC1_POSZ = Baro

EK3_RNG_USE_HGT = 70%

EK3_OPTIONS = 4 (Optflow may use terrain alt)

RNGFND_MAX_CM = 200 cm

(Note: This limit was only for manual flying. The copter could still climb to atleast 2m in Guided if commanded to do so)

1 Like