Quadplane/Tailsitter: Q_TRIM it creates integral accumulation problems and causes flip in takeoff!

[robustini]

At the takeoff in QStab I saw that the elevons were starting to move a lot for no reason at the ground, and I was wrong to want to take off, the tailsitter went flip. Angle Pitch P it is at an off-scale value (3<->12), and in this log I was just calibrating it. I detected a value of over 47 with a good attitude, but being exaggerated i land and I put it at 24, at the next takeoff it is precisely flipped in pitch. From the image you can clearly see my throttle command and the pwm of the two elevons moving for no reason as the tailsitter is still on the ground. It could be a land detector problem, I ask @rmackay9 and @tridge to evaluate this. On the SITL with Realflight I've never had this problem, even using an exaggerated Angle P value.

00000002_crash.zip

Platform [ ] All [ ] AntennaTracker [ ] Copter [ x ] Plane [ ] Rover [ ] Submarine

Airframe type Tailsitter non-vectored.

[robustini]

I found the problem, also replicated to the simulator. In my VTOL I had the need to enter a value of Q_TRIM because the wing profile caused a slight pitch shift in copter, which caused the problem. In all the previous test flights in fact I had left it at 0, yesterday after having inserted it there was a crash. In fact, in the image on the sim you can see the elevons in an anomalous position, and from the log that you place you notice the same error. Instead, bringing the value of Q_TRIM to 0 the problem is non-existent, in this log generated with the SITL it is initially at 0 and everything is fine, then I insert -3 and adios amigo.

[Uploading qtrim_issue.zip…]()

[robustini]

Once again I placed the SITL log because today GitHub is a little angry...

qtrim_issue.zip

[robustini]

A video showing the problem: https://youtu.be/pppEs_EGInE

[IamPete1]

This is basically a conflict between vectored and none tail-sitters, We purposely don't relax so belly takeoffs work, but if you dont need that then its bad.

[robustini]

Belly takeoffs with a non-vectored are a little tricky! :P On the sim it does not flip because the tailsitter tends to slip, but I assure you that nothing slips on the grass if it has no wheels underneath... :-) This problem needs to be solved.

[kd0aij]

What happens with a real tailsitter if Q_TRIM_PITCH is zero, but the ground is not level? If I understand you correctly the result would be a crash on takeoff, but I've never had a problem with that, as long as I use sufficient throttle to get off the ground promptly.

[robustini]

@kd0aij usually I always do it too, but it was enough once where the elevons were too tilted and he was unable to correct the angle. It is also a known problem of copters, when attempting to take off from an inclined plane only some motors rotate if the spin arm is at 0. For this reason, to avoid strange behaviors, I always takeoff with big copter from a boat in Acro, end of the problem.

[kd0aij]

@robustini BTW, have you tried the body-frame roll control option for qstab/qhover with q_angle_max=9000? q_tailsit_input=3 for "plane" mode controls: aileron is body-frame roll and rudder is body-frame yaw

[robustini]

@kd0aij yes Mark, and in fact it is more instinctive for a plane pilot, but by now I'm already used to controlling it the other way, changing now I should reset the brain! :p

[kd0aij]

Have you tried q_tailsit_input=2 then? That's body-frame roll with multicopter style controls in hover.

[kd0aij]

So the remaining problem would not be solved by ignoring q_trim_pitch on takeoff; instead the attitude controller would need to be smart enough to maintain the current attitude until the vehicle was airborne. Unfortunately, I don't believe there is currently any 100% reliable method to determine whether the vehicle is airborne. Perhaps the only practical solution is to implement a "jump" takeoff state which would use throttle and attitude control to attempt a clean takeoff. I'm not sure how that could be properly integrated though.

[IamPete1]

So long as there is no I build up it should be fine no matter the angle. With just P and D we have 'instant' response so it should cope.

[robustini]

In fact the problem of Q_TRIM does not occur at the takeoff in Q_ACRO, I also tried with a value of -10, the elevons remain in the neutral position regardless, always and in any case. The wrong position of the elevons due to hesitation with the throttle in Q_Stab as in my video is reset by switching to Q_Acro or Manual and then back to Q_Stab, so where the stabilization intervenes that problem is generated. I have also ascertained this several times at the airfield, often I was in Q_Stab with the elevons in absurd positions before take-off, switching to Manual and returning to Q_Stab they returned to axis.

[robustini]

So the remaining problem would not be solved by ignoring q_trim_pitch on takeoff; instead the attitude controller would need to be smart enough to maintain the current attitude until the vehicle was airborne. Unfortunately, I don't believe there is currently any 100% reliable method to determine whether the vehicle is airborne. Perhaps the only practical solution is to implement a "jump" takeoff state which would use throttle and attitude control to attempt a clean takeoff. I'm not sure how that could be properly integrated though.

Yes Mark, this is a Copter problem forever. In fact, the skilled pilots in particular situations all take off in Acro as you are guaranteed to take off safely and without strange behaviors, then once in the air they switch into other desired flight modes.

[robustini]

Q_TRIM_PITCH now acts on the body frame. For example, if it is set to 5° when a Copter flight mode is activated the artificial horizon in the hud moves of 5°, this causes the integral accumulation problem. Instead, it would be enough to apply a trim value on the elevons leaving the body frame alone, leaving it unchanged referred to the Plane, the problem of the integral would be solved. Practical example:

SERVO5_TRIM, 1500 SERVO5_MAX, 2000 SERVO5_MIN, 1000 SERVO6_TRIM, 1500 SERVO6_MAX, 2000 SERVO6_MIN, 1000

With Q_TRIM_PITCH at 10% you will have (if they act in the opposite direction):

SERVO5_TRIM, 1600 SERVO6_TRIM, 1400

So Q_TRIM_PITCH should act on the servo trim with a percentage (only in the Copter flight mode), not degrees on the body frame trim. Now Q_TRIM_PITCH it works as if in Copter we virtually tilt the flight control on the pitch, it is not conceptually correct. With my concept imho everything related to the integral accumulation would be resolved.

[kd0aij]

I think by "body frame" you mean "attitude" or Euler pitch angle (which is relative to earth frame). I don't think changing elevon trim would work for the intended purpose of Q_TRIM_PITCH, since it would be cancelled by the pitch PID integrator. Also, we don't want any elevon deflection prior to takeoff, as that is what causes a tipover in the first place, right?

[robustini]

I think by "body frame" you mean "attitude" or Euler pitch angle (which is relative to earth frame). I don't think changing elevon trim would work for the intended purpose of Q_TRIM_PITCH, since it would be cancelled by the pitch PID integrator. Also, we don't want any elevon deflection prior to takeoff, as that is what causes a tipover in the first place, right?

Yes, I mean attitude. True, if i change the trims manually they are then canceled by the pitch PID integrator, damn. Yes, we don't want any elevon deflection prior to takeoff, as that is what causes a tipover in the first place.

[kd0aij]

I'm afraid that nothing short of a weight-on-wheels sensor could completely fix this issue. At present, we're OK when we first arm, but you need to disarm immediately on landing to avoid the integrator windup.

[IamPete1]

In copter land I think it also zeros integrator at 0 throttle, not sure if we do that on plane or not.

[kd0aij]

Is that a flight mode in copter?

[IamPete1]

Not the flight mode, expressing myself badly again, sorry. Try this: In ArduCopter I think it also zeros integrator at 0 throttle, not sure if we do that on plane or not.

[IamPete1]

I fact in that case I think it hits the lower throttle limit flag in AP_Motors, might not zero the integrator but 'pause' them.

[kd0aij]

I see, it calls reset_rate_controller_I_terms() if in GROUND_IDLE state Seems like we could do that in tailsitter.cpp when throttle is low, although there may be some unfortunate interactions with air_mode...

[robustini]

I'm afraid that nothing short of a weight-on-wheels sensor could completely fix this issue. At present, we're OK when we first arm, but you need to disarm immediately on landing to avoid the integrator windup.

That's right, this is also an unfortunate situation. I often land and if I don't disarm immediately the elevons start moving brutally, and if it stays inside enough throttle there is a risk of flip there too. In this video I made a few days ago the problem is also evident in RF9.

https://youtu.be/K3JgxrJs7ac?t=4848

[andyp1per]

Sounds like the issue Leonard fixed for me on copter - it used to be that if you spooled up the motors slowly but did not take off and were not on a perfectly level surface the integrator was active and when you finally left the ground you would lurch to one side.

[kd0aij]

@andyp1per Thanks, I see that was https://github.com/ArduPilot/ardupilot/pull/12759 but it only affects altitude controlled modes, right?

[andyp1per]

@kd0aij pretty sure I was getting this in stabilize - the crash I experienced was in my office 😄

[robustini]

Sounds like the issue Leonard fixed for me on copter - it used to be that if you spooled up the motors slowly but did not take off and were not on a perfectly level surface the integrator was active and when you finally left the ground you would lurch to one side.

More or less the same thing, but here it does even if the drone is perfectly level. Many of these copter fixes should also be pushed into the quadplane code. But looking at this @lthall's fix it seems to me that this has been fixed only for AltHold.

[robustini]

@kd0aij @andyp1per yeah, i can confirm, the fix of @lthall it seems to work well with the tailsitter too, tested now on the sim. Why wasn't it included in the quadplane.cpp too ??? And he would like to insert in all of the Copter flight modes, even in the SHUT_DOWN condition ("on ground state during landing" in case of tailsitter of course)!

[andyp1per]

Actually my bad - it doesn't apply to stab, you are right @kd0aij

[robustini]

Actually my bad - it doesn't apply to stab, you are right @kd0aij

In the quadplane code I obviously also applied it to QStab, because the problem is there too.

[andyp1per]

Cool - I've asked @lthall whether that is what we should do.

[robustini]

I was looking at the quadplane.cpp right now, in my opinion with the throttle at minimum i-term should always be reset, under any conditions, but it is not. Or even better i-term should be ignored/reset below the throttle hover point threshold, many problems would be solved. This happens for example in MicroPilot, there is a throttle threshold below which i-term are completely ignored on the ground, before takeoff and after landing.

[robustini]

@lthall when you have time remember this, thanks! :p The problem of the integral accumulation obviously also exists when it lands on the ground.

[IamPete1]

Would be interested in seeing a log of this with this patch, https://github.com/ArduPilot/ardupilot/pull/16204

We should be setting the control saturation flags such that the I term is frozen at zero throttle (in Q modes except Qacro at least)

[robustini]

@IamPete1 here the log, I hope everything has been logged.

00000008.ZIP

[IamPete1]

@robustini Sorry new field is not in that logs. Not sure what branch your on, GitHub cant find the commit hash.

[robustini]

@robustini Sorry new field is not in that logs. Not sure what branch your on, GitHub cant find the commit hash.

I see your PR is on master now, so this is the log.

2021-01-05 14-05-43.zip

[IamPete1]

@robustini sorry, just had a look at that log. It looks like were doing the correct thing by freezing the I term.

Here you can see the limit flag getting set when throttle is 0 (or 1)

We are not however zeroing the I term, this is I and the limit flag, you can see the I term flat lines when the limit flag is set.

We could reset the I to 0 is not flying, this would help but the landing detector cannot be a quick as it is on copter. This is the is flying flag with I term.

So I think this issue should be fixed for the first take off after arming, but might not be on subsequent takeoffs because you will keep whatever I you had from the landing.

Does that sound like what your seeing?

[robustini]

Does that sound like what your seeing?

Yes!

[IamPete1]

I think we should look into running the full copter landing detector for tailsitters, or at least a step towards copter, tailsitters are never going to hover with zero vertical throttle as a 'normal' quadplane can. This would allow us to clear I terms more usefully on landing.

[robustini]

No news about that?