FW overshoot when changing altitude

#1

I’ve been fiddling around on the X-Plane simulator and in real life with all parameters (especially TECS), reading documentation and all that, and I just can’t accomplish to have no overshoot on altitude change.

Does anyone have any tips on the issue?
Is there any more documentation on TECS, like the math and algorithms behind it? It just seems that many parameters don’t do what they are supposed to and I would like anderstand why and what am I doing wrong.

Thanks.

#2

You aren’t the only one. I tend to get large overshoots on my descents and am also wondering what could be changed to correct this.

#3

Unfortunately we don’t have any documentation for TECS. I don’t believe it’s based on a particular paper, but total energy control is a general technique.

One possibly unrelated thing to note is that in FW altitude or position control mode the altitude is set once you let the pitch stick go back to neutral. So you’re going to overshoot after climbing or descending.

#4

Good to know it’s not just me not handling the parameters properly. I guess it’s up to me to tinker with the code to overcome this…

#5

I found the solution if anyone is interested. It’s this little line in tecs.cpp
_hgt_dem_adj = 0.1f * _hgt_dem + 0.9f * _hgt_dem_adj_last;
Adjusting more weight to _hgt_dem_adj_last will make transitions in altitude smoother and decreasing will make it more discrete.

There are a few tweaks to think about when changing the value, for example, do we want it smooth on both ends? But I will just make a parameter for it for now and see how it goes.

With this setting smoother you can also set your TECS time constant a bit lower.

Is this pull request worthy? @dagar?

#6

Did you try adjusting the height rate feed forward? FW_T_HRATE_FF

#7

I did and it seems to effects only descending overshoot. I even tried to go stupidly high like 1500 to see what happens but it seems have no more effect after 10-100. Still not sure what it is supposed to do though…

#8

I’m not sure what’s appropriate for the first order lag in this case, but if you want to do an initial PR including a couple logs to compare I’ll try to get the right people looking at it.

#9

I’ll make my first test flight with my implementation tomorrow and I’ll send logs before and after.

#10

Here is the log from todays flight. I am not proud of it at all, and should be shouldn’t be showing it to public at all, but I since I said yesterday I would, I keep my word. Anyways, it was a test flight, not production material. Altitude is very unstable, but it isn’t because of the new feature, but because of the TECS time constant. But you can clearly see how the altitude SP changes from almost discrete to smooth when changing the parameter. Thats what is supposed to reduce overshoot.

It was so ridiculously cold that I didn’t bother to make another flight and went home to look at the logs.

full log: http://review.px4.io/plot_app?log=a5e4b8a7-69b5-4890-ba44-e962bba4c325

#11

I can’t make out the actual param changes.
Likely doesn’t matter here, but you could plot the setpoints against the altitude, and airspeed in TECS status. TECS has its own filters.

#12

I’ll make a better flight next time. Here are the best results I could achieve on the simulator:

file:///home/vid/Pictures/pasted_image_at_2017_02_09_02_51_pm_1024.png

And with my tweak:

with my tfile:///home/vid/Pictures/pasted_image_at_2017_02_09_02_52_pm_1024.png

As you can see, all thats being done, is I limit the rate of altitude change, thus eliminating overshoot.

#13

A bug was found in TECS that caused the height rate feedforward to be ignored.

#14

Nice, thanks! It’s weird I haven’t found the second bug, as I’ve been fiddelig a lot around that peace of code a lot lately. Anyway, great find!

#15

Hi,
Do you tuned FW_T_HRATE_FF and FW_T_HRATE_P or just FW_T_HRATE_FF ?