AP_TECS: Fix Regression of TKOFF_IGAIN

[menschel]

The referenced commit below did remove an is_zero() check which in my case made a belly landing out of an auto takeoff because the parameter TECS_TKOFF_IGAIN is 0 (default) and pitch error is not corrected.

fixes: b163e13 (AP_TECS: Fixes to reset state )

[menschel]

The referenced commit relates to issue #27147 which surprisingly is still open.
Please comment on the reason why someone wants an I-Gain of 0 basically leaving the constant error uncorrected forever.

[menschel]

I just learned that the last item in the AP_GROUPINFO tupple is the default value,
so alternatively it can be fixed by just changing the default value to non-zero.

AP_GROUPINFO("TKOFF_IGAIN", 25, AP_TECS, _integGain_takeoff, 0.3f),

Anyway the code and the default parameter must not stay this way.

[menschel]

Ok, that's the NO_CODE_CHANGE version, only update parameter to 0.3f .

[tridge]

@menschel can you post a link to the log which shows the problem on your aircraft? A log with the older code before this changed would be good too

[peterbarker]

@menschel also note this should be a single commit to fix that line - assuming that's the correct fix :-)

[menschel]

@menschel can you post a link to the log which shows the problem on your aircraft? A log with the older code before this changed would be good too

I can share the belly landing but honestly it was the first attempt to auto takeoff the plane and there was much to improve. I found the "suspected" TECS_TKOFF_IGAIN issue by accident.

I made a follow-up flight with minor improvements where I managed to prevent ground contact with stick mixing but in auto even with stick mixing the elevator did hardly move nose-up while it moved the complete way nose-down.

That's where I started looking into TECS and experimented with TECS_TKOFF_IGAIN and voila. If not zero, elevator does move nose-up the complete way and goes to neutral when 15deg pitch are reached.
An hour of reverse engineering and a git blame lead me to the mentioned commit and that's how I ended up with this PR.

EDIT:
Please ignore the wind indicator, there was no wind at that moment.

EDIT2:
Removed attachments.

[Georacer]

Hi @menschel,

The log you uploaded is a flight with ArduPlane 4.5.6. This is a stable version where the changes of #27174 are not applied yet.

Also, in this log, TECS was commanding a positive pitch up, but the attitude controller didn't manage to serve it:

Perhaps because your airspeed was still quite low?

Could you please double-check your logs and try to explain better why this change of TECS_TKOFF_IGAIN is helpful?

[menschel]

Hello,
the plane is a ZOHD Drift, sub 250g and the stall speed is 6-7m/s or 18-22km/h, depending on how far the flaperons are down.
I see in logs that rc4 elevator dials in to some value around 1300 instead of 1000.
This is typically an indicator for an I-Gain issue. Constant Error is not corrected. Then it hits ground with 42km/h, pitch down.

The parameter description in Missionplanner corresponds to the current text in master, so I expected the change to be present. If it's not, I have to do more test flights to iterate on the reason.

All I can say for now is that dry running the whole thing on the bench, elevator moves completely nose-up when I have a non-zero value in TECS_TKOFF_IGAIN.

I'm waiting for good weather because the plane is vulnerable to strong inconsistent wind.

[Georacer]

@menschel

The code you're running currently is this, for Plane 4.5.6: https://github.com/ArduPilot/ardupilot/blob/Plane-4.5.6/libraries/AP_TECS/AP_TECS.cpp#L838

In this version, during a takeoff, when TECS_TKOFF_IGAIN=0, the value of TECS_INTEG_GAIN is used instead.
It is possible that the other values you tried for TECS_TKOFF_IGAIN=0 were better suited, but I think loss of pitch control was the real issue, not TECS parameters.

By the way, I notice that you don't use an airspeed sensor. Instead, here's a plot of your GPS speed.
If there was no headwind, you might have been pretty close to stall before your pusher managed to gain you some airspeed:

[menschel]

Hello,

If I falsely accused your commit, I'm sorry.

I do have a BIN file of the follow up test where I managed to avoid ground contact with stick mixing in auto but it's too big for upload. Is there a way to cut the BIN files to only have the relevant takeoff? I'm struggling with file sizes to upload.

Changes were no motor startup delay, 15m/s² threshold and no flaps. It basically denied pulling the nose up the whole takeoff and I had to yaw off to the side to avoid the trees. I still suspect TECS.
In FBWA, it pulls up the nose immediately after the first "bump" and takes roughly 10s to 50m altitude.

If wind calms down at 17:00CET, I'll be out flying again.

[Georacer]

If I falsely accused your commit, I'm sorry.

You don't have to apologize. We need to get to the facts, and see how we can find a solution from there :)

You can paste a Google Drive link or similar. It won't be live forever, but it will be available for long enough.

[menschel]

Hello,

I have to waive the flag here. Even after manipulating on the TECS I-Gain Values, the behavior remains. I will try flashing "Latest" Firmware, just to see if there is any change.

All I can say is that it's like flying a complete different plane in FBWA and Auto.

The down-slope after throwing seems to be air-frame specific but it's tame in FBWA while significant in Auto.

FBWA

Auto

I doubt it's the motor start delay.

Anyways, when I find out what it is, I'll create new Issue or PR.

Thanks for bearing with me.

[menschel]

Just for info, I'm onto something. I have a negative hdem in auto takeoff and found a comment towards that behavior.

https://github.com/ArduPilot/ardupilot/blob/Plane-4.5.6/libraries/AP_TECS/AP_TECS.cpp#L556

In my case it even drops the nose to negative pitch.

The reason seems to be that I throw the plane with up to 20deg pitch which is higher then the 15deg in takeoff mission item.

I will verify that during next flight and eventually push PR to limit hdem to positive values during takeoff.
It seems the most logical way to do.

[Georacer]

Before you dive too deep into TECS, I suggest you verify that your have good pitch control. Compare the ATT.Pitch and ATT.DesPitch.
If ATT.DesPitch is indeed wrong, then you might be onto something. But if it looks right and your actual pitch diverges, then you probably have PID issues.

[menschel]

Tying some loose ends here.
I have it running in Autotune Level 8, a slighly moved backwards CG and 1mm reflex on the elevator.
Factory information sheet forgot to tell about the reflex and autotrim did not reach that trim point due to the 20% limit.

Additionally SCALING_SPEED was at 15 while it should have been around 10 and my ignorance got the better of me by disabling speed scaling for auto takeoff in FLIGHT_OPTIONS because I don't have an airspeed sensor.

After getting rid of this concatenation of unfavorable conditions and setting TECS_TKOFF_IGAIN=0.4, the Drift does auto takeoff without even wagging the tail regardless of what pitch I throw it.
Thanks again.

[Georacer]

Nice to hear!
Do you know how it behaves when you leave TECS_TKOFF_IGAIN to the default 0?
Does it crash? Does it climb less well?

[menschel]

I will check with 0.02 because I'm still using AP4.5.7.

The main issue has been the reflex on the elevator. ZOHD designed the plane to be very nose heavy for beginners and counter with reflex on the elevator.

From my analysis, a high TECS_TKOFF_IGAIN helps fixing the TRIM issues when the plane's nose dips down initially after throw.
I expect it does almost nothing on my setup now.

I currently takeoff at 12° pitch because I fly a configuration with a DIY 1400mAh Li-Ion Pack, 249g weight, and performance limitation to 3A (5A Burst for 10 seconds). Flight time almost 40 minutes with battery failsafe at 6,2V and 1000mAh.

[menschel]

I tested with current 4.7.0-dev because I wanted the mavlink connection via ELRS,
I believe it was the nightly from Thursday morning.

I did not notice any difference in the climb ability or the initial pitch correction but the plane did seem to not reach the target altitude for TKOFF, it kept flying at 48m, 2m below at almost horizontal pitch. I'm not sure about the course either, seemed to be shifted by crosswind and was not corrected.

I returned in FBWA.

There was also some other issue on the GCS messages, I get the initial (board,version,rc-out config) tuple repeatedly, so I assume I should not fly latest software. And I was seeing a 2nd vehicle in APM Planner. This did not happen in 4.5.7 .

To sum it up, I still vote for a TECS_TKOFF_IGAIN default of 0.3.

EDIT: I also do not seem to have a bin log for that flight on the sd card.

[Georacer]

Okay. My biggest concern with TECS_TKOFF_IGAIN=0 is in making some frames nose down right after launch. I'm not saying this is what happens now. I'm saying I can imagine a world where this happens.

But alas I'd need a .bin log to comment on your altitude issue.

Thanks for reporting back!

[menschel]

I'll check again with

https://github.com/ArduPilot/ardupilot/tree/ArduPilot-4.6

Not sure what the issue was with 4.7.0-dev.

[menschel]

No issues with AP 4.6.0-Beta1 yet. I made one takeoff into ~15-20km/h Headwind and did not see anything unusual with TECS_TKOFF_IGAIN=0. Leveled out at 50m, course correction or better the attempt to was visible.

I'll do another flight when there is less wind.

[Georacer]

That's good to hear. Thanks a lot for reporting back, I really appreciate it!

[menschel]

Bad news, I have a tkoff with 4.6.0-beta1 and it leveld out below target altitude again. I went on to stash things into an existing repo, so I don't have to ask Seve to delete it afterwards.

24-11-18_12-43-12.bin

[Georacer]

Thanks for the log.
For the following graphs, I've placed the cursor at the point where the mission switches from the takeoff waypoint to the next waypoint.

Indeed the aircraft coats around 48m for a few seconds before the switch.

During that whole time, the throttle was wide open, as expected:

You did raise your throttle stick, but that was not the reason that the takeoff was complete (at least as far as I can tell).

It is more likely that the last 2 meters were gained by an accidental pitch-up:

I think what is going on here is that you have a plane that does not gain altitude when it flies pitched up at ~5deg and at full throttle. This breaks the assumption that a plane flying at 0deg pitch and full throttle would eventually climb to altitude, during the last few meters of climb.
That's of course not a reason for TECS not doing its job, so I'll see how we this can be improved.

Thanks again for the report!

[menschel]

I got the wrong switch when trying to switch to FBWA and moved flaps 50% instead. The stick action after that was intended because I wanted to turn. Then I realized I was still in auto and flipped the correct switch to FBWA.

The 100% THR is not normal. It should have reduced to ~75% because 12deg (TKOFF angle) / 18deg (TECS pitch max) results in that value in 4.5.7.

The flaperons are quite effective, I just need some feed-forward to pitch control.

That flight also had ~25km/h wind which is more then the minimum speed for the plane. It's a bumpy ride for a sub 250g 880mm wingspan plane.

[Georacer]

It should have reduced to ~75% because 12deg (TKOFF angle) / 18deg (TECS pitch max) results in that value in 4.5.7.

Where are you basing this off of? I don't recall such a feature. Especially in TAKEOFF mode with TKOFF_OPTIONS=0, the throttle is 100% open by default.

See the documentation for the refactor ArduPilot/ardupilot_wiki#6149

[menschel]

I run throttle controlled without airspeed sensor and TECS is setup according to guide. Means TECS_CLIMB_MAX corresponds to TECS_PITCH_MAX at 100% THR. Less Pitch scales throttle down in 4.5.7.
This is a battery duration test that required 3A max.
24-11-12_11-00-04.bin

[Georacer]

See my updated comment above.

[menschel]

Was that an intended change?

Because in 4.5.7 it drops down when the time has exceeded and does not care about altitude.

In this configuration, right after takeoff the throttle is set to :ref:TKOFF_THR_MAX<TKOFF_THR_MAX> for :ref:TKOFF_THR_MAX_T<TKOFF_THR_MAX_T> or until :ref:TKOFF_LVL_ALT<TKOFF_LVL_ALT> (whichever lasts longer).

As I wrote, I have constraints on the discharge curve and the maximum speed of the airframe which ZOHD names as 50km/h although it can do ~60km/h horizontally.

[Georacer]

Because in 4.5.7 it drops down when the time has exceeded and does not care about altitude.

The change in behaviour is intentional because the behaviour in 4.5 was buggy.
The intended behaviour is, during a takeoff without an airspeed sensor, for the throttle to be at TKOFF_THR_MAX (or THR_MAX) and the pitch to be fixed up until you get close to the target altitude, where it starts to level off.

In this configuration, right after takeoff the throttle is set to :ref:TKOFF_THR_MAX<TKOFF_THR_MAX> for :ref:TKOFF_THR_MAX_T<TKOFF_THR_MAX_T> or until :ref:TKOFF_LVL_ALT<TKOFF_LVL_ALT> (whichever lasts longer).

What you quoted here is true when you set TKOFF_OPTIONS=1 and use an airspeed sensor.

I have constraints on the discharge curve and the maximum speed of the airframe which ZOHD names as 50km/h although it can do ~60km/h horizontally.

That's OK, it shouldn't prevent you from completing a takeoff and I'm looking onto writing a patch.

[menschel]

I have a suspicion. TKOFF_ALT and TKOFF_LVL_ALT copy paste error somewhere.

[menschel]

OK, so what I take as expected behavior is the bug mentioned here.
I'll try working with TKOFF_THR_MIN and MAX respectively.

[Georacer]

I'll try working with TKOFF_THR_MIN and MAX respectively.

I'm afraid for now they won't really help you. These parameters won't have a beneficial effect in your configuration.

What you can do, as a mitigation, is to set TKOFF_PLIM_SEC=0. This will disable the taper-off of the pitch angle at the end of the climb. It will result in altitude overshoot, but at least you will complete the climb.

[menschel]

I'll check what I can fix by using TECS_TKOFF_IGAIN=0,4.

But honestly, why is Airspeed Sensor Presence evaluated here?

If TECS is setup correctly the resulting throttle value would yield cruise speed regardless what takeoff angle is. It works in 4.5.7 even though labeled a bug.
Now the user has to experiment with both angle and TKOFF_THR_MAX and can choose to overspeed or stall in worst case.

[Georacer]

If TECS is setup correctly the resulting throttle value would yield cruise speed regardless what takeoff angle is. It works in 4.5.7 even though labeled a bug.
Now the user has to experiment with both angle and TKOFF_THR_MAX and can choose to overspeed or stall in worst case.

That was a pre-existing design decision, not done by me, in order to make 100% sure that you won't stall your plane during takeoff, especially in absence of an airspeed sensor.

We could amend it, but that's for another discussion.

By the way, I have a proposed fix for your climb failure here.
Would you like to test it? Can you compile it for yourself or should I build you a binary?

[menschel]

Thanks, I'll cherry-pick onto 4.6.0 branch and build.

[Georacer]

I have just updated the description there, in case you want to read more about it.

[menschel]

Thanks, just for the record, it's this plane, second revision.
https://www.zohd.net/zohd-drift

Another interesting thing what I noticed in my FPV footage, the level-off already starts at 8m instead of 3m previously. I assume that's the initial cause for the altitude undershoot.

I'll test tomorrow if I find a free slot and the wind is <20km/h.

[Georacer]

@menschel I'm sorry to report that that PR was flawed. Feel free to have another look at the code, but I think I'm double dipping on the pitch trim parameter.

I guess I'll have to write some sort of other controller, but for now I have no other solution for you other than setting TKOFF_PLIM_SEC=0 thus disabling the pitch taper-off.

[menschel]

Ok, then I'll test TKOFF_THR_MAX=75% and TECS_TKOFF_IGAIN=0,4 instead. The IGAIN should make it reach target altitude.

[Georacer]

Ok, then I'll test TKOFF_THR_MAX=75% and TECS_TKOFF_IGAIN=0,4 instead. The IGAIN should make it reach target altitude.

It will probably make no difference, because the TECS pitch is not taken into account when you don't have an airspeed sensor. You get the fixed takeoff pitch, as set in the mission item.

[menschel]

for reference ap460beta1_tkoff_issue.mp4

EDIT: I also notice another thing here. The plane does not keep the original course but turns roughly 30degrees clockwise after the throw.
It took the target yaw based on IMU while yaw reset from GPS was not done. Then it turns onto the same numerical heading.
I consider this dangerous.

[Georacer]

@menschel I've created a PR fix here: #28707

It's against master. Are you able and willing to do a flight test?
Do you know how to cherry pick the commit over 4.6 beta and build it, or would you like me to build you a binary?