Unresponsive Altitude - Drone Drifts Upwards

Hey everyone, today while flying, the drone started steadily increasing in altitude and was not responding to pilot command to come down in altitude. By looking at the log can anyone tell what went wrong? Note: there is a sonar sensor on the drone for altitude tracking. https://drive.google.com/file/d/1DFEiVSgASioV_GV5pjjPaz28hFr4lEng/view?usp=sharing

The sonar does not give any useful indication. You can test it easily indoors without arming. If that works, it may not work on sunlight.

Compensate battery:

Those Maxbotic Sonar units are not worth the cheap price they cost. Suggest upgrading to better technology.

Thanks for the feedback @dkemxr . Is there a specific, higher-end sonar you have worked with in the past that you would recommend?

Thank you for your response. Could you please explain what you mean by compensate battery? For reference, we are using a 12S battery.

I know for sure those Sonar units are not worth using, tried them several years ago. Today the Benewake Lidar (time of flight sensor really) units are popular although I don’t have one currently flying. The TFmini Plus are popular and priced right.

1 Like

Probably you are having high vibrations.
Please follow the arducopter tuning instructions , retest and post a .bin log file.

Battery Voltage Compensation
Convenient but a remote reason. Probably your problem is that altitude data come from barometer and GPS, and not from sonar.

Nop. See this video (4K). That can’t be done with barometer and GPS alone.

It is not sufficiently documented that outdoors sonars may not work, and particularily over dry grass as on the video. Possibly having two sonars helps: if one fails at some point perhaps the other works there (probability theory).

Note ROI waypoint forgotten after hitting grass.

Your vibrations are good, low with no clipping.
The problem appears to be some tuning, plus the barometers are uncovered and affected badly by light and/or prop wash.

or are you taking off from a high place, flying below “ground” level and landing somewhere even higher? Maybe crashed in a tree :frowning:

There’s a few key items missing from the log, set LOG_BITMASK,141310
The pitch and roll are following desired fairly well, but could be slightly better. I highly recommend setting these first:

I would disable the rangefinder and retest and see how that goes. If everything is OK set these and check logs, maybe run another Autotune.

Once all the tuning is spot-on and the craft is flying reliably, enable the range finder and work on that.

Tuning guide:
Reference spreadsheet:

Thanks, @xfacta. Are barometers are actually covered from light, so that shouldn’t be the issue. Yes, we took off from a lower place and landed in a higher place :confused:

We have PSC_ACCZ_I set to 0.92, but PSC_ACCZ_P at default value. Why should we change it to 0.38? Thank you for your help.

Read through the tuning guide and use that spread sheet to help

Ok, we found something interesting. The plot shows the two instances of the EKF. NKF1.PD is the altitude estimation of the primary EKF, and NKF6.PD of the second instance. At about 97 seconds, The parameter SP (the one used for determining the healthier estimation) started growing indefinitely in the primary instance, while in the second it is not perfect but at 117 seconds its value is lower than in the primary instance. Why did the controller never switch to the healthier estimation of altitude? Also, why did the Fail safe never report anything? We did not see any error message in the log. our FS_EKF_THRESH value is 0.8 and our action is land. Can any developers explain what went wrong? @rmackay9

I wanted to circle back and see if anyone has an idea as to what went wrong. It looks like a failsafe should have been triggered when one of the EKFs failed for altitude, but it didn’t.