Altitude overshoot on ascent & descent, tuning help please

I’ve got stabilize mode flying well, but my alt-hold/loiter vertical behavior needs a bit more work. On ascent and descent, the copter overshoots by a few meters, consistently, in both directions (after a vertical ascent, it settles a few meters lower; after a vertical descent, it settles a few meters higher). Do I need to mess with the PSC_VELZ_P,I,IMAX,D params? And if so, what should I do with them?
In my log file, I think it’s easiest to see the behavior in the loiter region after my acro portion, at the peaks and troughs.

here are my current parameters

here’s an example of overshoot at the top:

and overshoot at the bottom:

If there’s already an answer elsewhere, please direct me, but I’m surprised that my searches didn’t immediately yield similar issues, I figured this should be a pretty straightforward fix. I can start messing with the rates on my own, but it’s probably more efficient to get good advice.

no suggestions? I took some video in the hope that it will elicit some comment action.

Hi @CBwintertime,

Sorry, I don’t know how I missed this post.

So the issue is definitely related to the use of the lidar for altitude hold (aka “surface tracking”). I’m sure if you disabled the rangefinder by setting RNGFND1_TYPE = 0 you’d find it would behave much better. I’m not saying that’s the solution of course, just that the issue is related to surface tracking and tuning the altitude hold controller won’t help I think.

It looks like you’ve got a lightware serial rangefinder which is a decent quality lidar so it shouldn’t be a hardware problem.

Have you ever tested this setup with 4.0? I’m just wondering if we’ve had a change in behaviour somehow or if this is the first time you’ve tried surface tracking with this vehicle.

I’m confused, doesn’t the LIDAR data look fine? If the LIDAR data is good, isn’t it an issue with the PID loop that attempts to track the rangefinder data? Agreed it’s using lidar for the altitude measurement, but isn’t it the response to the data that is not working out properly, regardless whether it came from the rangefinder or the barometer?

You’re right, I have the LW20 Lightware lidar and it seems to work well.

I did disable surface tracking, incidentally (actually, I tied it to a switch) for better SAR usefulness over a forest (trees make for a roller-coaster ride when surface tracking is on). It didn’t seem to make a difference in the up/down behavior. I will double-check that however and report back, to be sure.

I don’t think I’ve tried this with 4.0. I can try that also. Probably won’t have a chance to get to that bit until saturday morning however. I’ll record a log with the surface tracking disabled first, to see what we get.

Hi Matt,
If you are sure the altitude problem is not what Randy says you could try changing PSC_JERK_Z,5 to 10 and see what effect that has.

I noticed motor outputs generally getting higher and higher during that flight, as the battery voltage goes down - that’s expected, but you are getting near maximum motor output. Could be a bit under powered, or over weight.
The motor output is quite noisy and so is the attitude control (less so). I think there might be benefit in running another Autotune and see if attitude control improves a bit. I’m not saying attitude control is bad, I just think it could be a little better. It wouldn’t surprise me if that helps the altitude control somewhat.
Any reason not to use SERVO_BLH_AUTO ?
And I thought MOT_PWM_MAX/MIN would be automatically set to 2000/1000
GPS update rate is a bit all over the place, try GPS_GNSS_MODE,65 to see if that cuts down on the GPS Glitch messages and gives a more uniform update rate.

@rmackay9 in messages there’s nothing about servo outputs, which are PWM or BLH - did that message drop out of some betas or am I just missing it?

I have looked at this and I think I understand the problem. I will work on this with Randy later and give you something to test.


Okay I misspoke; disabling surface tracking did indeed solve the up/down overshoot. Apologies to @rmackay9 who nailed it. As you said, it isn’t the solution, as it would be great to be able to use surface tracking without the overshoot, but in any event tuning has nothing to do with it.

@Leonardthall and I have spent some time on this and hopefully we can come up with something in the next week or so. It’s a little tricky…

I think we have a fix:

When we finish reviewing it would you be willing to test it for us?

I am facing a similar issue with my TeraBee equipped aircraft on 4.0.7 - so I am following along.

yes of course, is it ready to try now or should I wait for your go-ahead?

I would like to get Randy to check it over before it goes onto your aircraft. Ideally I would like you to be testing what we consider the final version.

Thanks for your willingness to help us get this sorted!!


We’re wondering if you could give this modified version of Copter-4.1.0-beta8 a try? This binary is for a MatekH743 board and the only change is the addition of these surface tracking fixes.

The changes are significant though so please be careful and be ready to retake control in Stabilize mode.

will do tomorrow morning

Okay, flew with your modified version 4.1.0-beta8. Logs and parameters.

No instabilities whatsoever with the flight that were worrisome in any way, to get that out of the way.

It felt better. Maybe halfway between what it was before, and how it performs with the surface tracking turned off. I went back and forth, enabling/disabling the surface tracking, so there should be side-by-side comparisons of the overshoots with/without. Definitely a step in the right direction, thank you to both of you for working on it.

You’ll see all this in the log, but I went vertically up and down a few times in a cautious way, then I flew slowly laterally over a ~2m high mound of dirt to check the surface tracking behavior–I didn’t notice any difference from nominal, with regard to the responsiveness as I got over the lump (though admittedly I have less of an intuitive feel for the horizontal behavior than with the vertical overshoots). Then I moved to a slightly new location and spent time going vertically up/down in earnest, with surface tracking on/off, in loiter and alt-hold.

Note I also used this flight to check out the performance of my new 6,000mah li-ion, so that’s why I dragged it out so long and to such a low voltage, so I could see just what I could get before my thrust/weight wasn’t quite enough for comfort. [EDIT: on reviewing the logs, I see that the voltage I was viewing via telemetry is NOT the same as that in the logs. I was seeing ~19.5-20V when I landed, and I’m seeing 17.8 in the logs, and it only recovered to ~18.8. Lucky I was still in the air. I think the capacity may be a bit overstated on this battery! And I need to figure out why I’m seeing the wrong voltage on the taranis telemetry–that’s pretty important.]

Is it worth messing about with the RNGFND_GAIN? I have it at the 0.8 default (at least I think that’s default, I don’t remember changing it). Maybe next time I can throw that onto a knob and play around with it. I suspect that my overhead on thrust:weight is not high enough with this drone for increased ST responsiveness to make much of a difference (i.e. I’m limited by my thrust not the ST responsiveness I believe) in terms of the actual surface tracking functionality, but would that make a difference in the vertical overshoot?

Here’s an overshoot with surface tracking turned on:

And the same scale with surface tracking turned off:

Sorry I should have lingered longer in the final position each time to make the actual achieved altitude more evident.

Great, thanks for testing.

I am interested to see why we see any difference between the surface tracking on and off. Could I give you a custom build with some extra logging for you to do a flight with? The ideal test would be series climb and descent over a flat piece of ground.

No, this parameter is no longer used. We use the same limits as Alt_Hold when following terrain. This is why there should be no difference with or without surface tracking when over flat ground. A delay between measured lidar and the real range may cause a slight overshoot. But until I see the data I won’t know.

You only got 4.6 Ah out of the battery. The battery started at 24.3 V or 4.05 V/c so that is unusually low. Maybe you didn’t charge it fully (hard to imagine but something is wrong). You may also be out on your calibration of your battery monitor. But your starting voltage is very low and only getting 4.6 Ah out of a 6Ah battery all the way down to 3V/c is a sign something is not right.

1 Like

@Leonardthall yes send whatever build you want my way. I need to fix my txmodv2 before I can fly but I should be able to get to it mid-week. What do you mean by “series climb and descent” – on flat ground ascend straight up, wait at the apex for a bit, then descend straight down, wait at the bottom, repeat a few times?

Where do you see 24.3 V for the starting voltage of the battery? EDIT: I see you are looking at the estimated resting voltage a few seconds in—I take it that’s the best voltage to go off of.

Note I’m using Li-Ion not Lipo, 6S2P 18650 cells for 6000mAh rating

Wow I just took a 30 minute interlude to dig deeper into the Li-Ion research than I had previously, and messed about with my charger. I’m using the GEPRC brand VTC6 battery. This wonderful report shows some discharge curves for that SONY VTC6 18650 cell.

They are supposed to be charged at 4.2 V to a 100-125 mA cutoff. Then soon after coming off the charger they are supposed to have a resting voltage of 4.10–4.19 V? Which would be 24.60–25.14 V? (That number wasn’t as easy to find–it’s not in the datasheet and different sources on the web disagree slightly.)

I have been using my charger on the “Li-Ion” mode. Turns out that charges them to 4.1 V rather than 4.2 V. I am annoyed that I did not catch that discrepancy until now, but better late then never. I just upped the charging condition to 4.2 V and got another 638 mAh into it. @Leonardthall your inquiries just increased my battery capacity, no new purchases needed!

Also I just checked and fixed the battery cal; it was off by 0.3 V which is something but not huge. Between undercharging the battery, and that 0.3 V, maybe it accounts for the discrepancy. The issue with the voltage I see on the screen of the taranis being different than what the FC knows is a separate thing and still a problem; hopefully I can resolve that on my separate txmod question thread. Whatever the voltage really is, it does me no good if the telemetry shows me old/wrong numbers.

I know my current cal is real close because the reported consumption is within a few percent of the amount that goes back in.

1 Like

Sorry for the delay!

This just has some extra logging on top of Master. All I need is some climbs and descents in the same spot like you did before.

Thanks for your help!


I was wondering if you had an opinion on surface tracking in 4.1 (with these latest fixes) vs 4.0? We’re getting close to the Copter-4.1 release and I’m wondering if you think it is acceptable for a final release. In particular do you think it performs as well as 4.0?

@rmackay9 unfortunately I didn’t get enough of a feel for the 4.0 surface tracking in order to be able to offer an opinion. I could revert to 4.0 to give it a workout, see if I can notice the differences, if you want