Looking for fixed wing D-gain tune results

[avsaase]

I'm opening this issue to collect PIDFFs that use the new D-term on fixed wing (#6669). The goal is to find defaults that will work on most planes and to incorporate the D-gain in the autotune procedure.

If you want to test this, first make sure the rates are set correctly for your airplane and FF is tuned accordingly, for example by autotune. The airplane should also be well-trimmed to avoid excessive I-terms. Set dterm_lpf_hz = 10 to reduce the strain on the servos. The easiest way to experiment is to use the inflight adjustments.

I am following the following tuning procedure adapted from here:

1. Set the P, I and D gains to zero. Do not change FF.
2. Increase the P gain until the response to a disturbance is steady oscillation.
3. Increase the D gain until the oscillations go away (i.e. it's critically damped).
4. Repeat steps 2 and 3 until increasing the D gain does not stop the oscillations.
5. Set P and D to the last stable values.
6. Increase the I gain until the plane no longer drifts and keeps its attitude.

On my Dart 250, I had success with P set 5-10 times higher than what autotune gave, and D set equal to P.

Once you're done, land, save and reboot, go into the CLI, type diff, and copy-paste the part under the active profile. Please also report the plane model and the flying conditions. DVR and blackbox logs are also more than welcome. I am not looking for the "perfect" tune, which probably doesn't exist anyway, I just want to see if there are patterns to what people feel is a good tune.

Development builds for the most popular targets can be found here, and the configurator here.

Testing is at your own risk. If you have very cheap servos then you probably don't want to try this. Thanks a lot!

[rts18]

@avsaase I have concluded that D-term settings are going to vary greatly from model to model. Even for the same air-frames, using different servo's. I use Savox, Hyperion, Emax and Futaba. They all have different speed and torque ratings.

I would not be confident to give any of my tunes for a base line. Because none of my models are stock PNP.

I settled for P values between 8 to 30 and D values between 6 and 17, depending on many variables.
I also set D-boost factor to 1.0 (off), because its an MR setting.

Its easy to tune tightly at low speeds with little wind. But when flying in higher winds at higher speeds; the P and D values have to be reduced considerably. But its still way better than it used to be without D-term.

I imagine that the last component that would be tuned in a PIDFF autotune. Would be the Derivative. And it being set only after the model is pushed to its maximum flight speed.

I'm trying to think of a way using the Programming parameters, to implement a speed base dynamic PID attenuation or PID rate selector that would reduce the PID's based on GPS speed, rather than TPA.

[avsaase]

You could be right that it's not possible to find a decent tune that will work for most planes. So we would have to keep the low P and leave D at zero in autotune.

The problem with using the gps speed for scaling PIDs is that it doesn't reflect airspeed, especially at high winds. The throttle level is proportional to airspeed so I think it makes sense to use that for PID scaling.

[rts18]

Air speed is the ideal way to do it. The main problem, is that Pitot's aren't totally reliable either. And not used by the majority of fliers.

GPS speed is still better than throttle based PID attenuation. Because it will wait until the speed is lowered before the gains are increased.
While at present with TPA. The throttle can be lowered at any speed, thus increasing the gains at high speed's (air or ground). Which most certainly will induce oscillations and aileron flutter.

[avsaase]

There is fw_tpa_time_constant to take into account the delay between throttle and airspeed changes.

[rts18]

@avsaase I used to have fw_tpa_time_constant = 1000 on my past tunes. Now I have it set between 2.5 and 3 seconds with D-term tunes.
It makes a difference on faster planes. Especially during deceleration after quickly dropping the throttle back. I am also using a tpa_rate > 50 on all the planes.

The more I tune with the D-term addition, the better I get a feel for the P-term and D-term limits.

I was able to get the P-term around 10x higher, as you did with your Dart250G. It was very rock solid on one of my builds. But this only applied to flying slow and with constant wind (no gusts).
While in reality. I have found that setting P-term between 3 to 4x greater than what was set with PIFF. Is a viable figure for most planes under most wind conditions, with D-term damping.

Another thing I found, was not reducing fw_iterm_limit_stick_position below 0.5. This helps to keep the roll axis smoother in turns.
While it gets more jumpy when I-term is reduced in turns if fw_iterm_limit_stick_position is implemented to close to center stick.
This seems to indicate that D-term is also acting on the I-term in a noticeable way, compared to the way I-term used to work before PIDFF.

[rts18]

@avsaase As we spoke of earlier. TPA_rate seems to have little effect on FW PID tuning. If it did, a fixed wing P and D could be tuned much tighter, over a wider speed range.
I always assumed TPA stood for - Throttle PID Attenuation. But from the CLI documents. That's only part of the story.

Throttle PID attenuation reduces influence of P
on ROLL and PITCH as throttle increases. For
every 1% throttle after the TPA breakpoint, P is
reduced by the TPA rate.

It only works on Proportional. This was all well and good, when iNav used a P I controller.
But now that iNav has fixed wing D-term. Present TPA_rate is not of much use, because the Derivative also acts on the Integral.

We need a Throttle P D Attenuation. With a speed reference, that supplements the change.
What do you think?

[avsaase]

That documentation must not apply to FW, or it is just incorrect. On FW, TPA scales down (and up) all PIDFF gains proportionally:

inav/src/main/flight/pid.c

Lines 545 to 551 in 27373fb

	// Airplanes - scale all PIDs according to TPA
	pidState[axis].kP = pidBank()->pid[axis].P / FP_PID_RATE_P_MULTIPLIER * tpaFactor;
	pidState[axis].kI = pidBank()->pid[axis].I / FP_PID_RATE_I_MULTIPLIER * tpaFactor;
	pidState[axis].kD = pidBank()->pid[axis].D / FP_PID_RATE_D_MULTIPLIER * tpaFactor;
	pidState[axis].kFF = pidBank()->pid[axis].FF / FP_PID_RATE_FF_MULTIPLIER * tpaFactor;
	pidState[axis].kCD = 0.0f;
	pidState[axis].kT = 0.0f;

IMO, this makes sense. With higher throttle, which serves as a proxy for airspeed, the control surfaces are more effective, so to get the same response we need smaller deflections and all parts of the stabilization should be reduced.

Interestingly, on MR the I-gain is not affected by TPA, but the D-gain is:

inav/src/main/flight/pid.c

Lines 554 to 559 in 27373fb

	const float axisTPA = (axis == FD_YAW) ? 1.0f : tpaFactor;
	pidState[axis].kP = pidBank()->pid[axis].P / FP_PID_RATE_P_MULTIPLIER * axisTPA;
	pidState[axis].kI = pidBank()->pid[axis].I / FP_PID_RATE_I_MULTIPLIER;
	pidState[axis].kD = pidBank()->pid[axis].D / FP_PID_RATE_D_MULTIPLIER * axisTPA;
	pidState[axis].kCD = pidBank()->pid[axis].FF / FP_PID_RATE_D_FF_MULTIPLIER * axisTPA;
	pidState[axis].kFF = 0.0f;

I'm not sure I understand what you mean by that D acts on I.

[rts18]

I'm not sure I understand what you mean by that D acts on I.

@avsaase I don't know the code. But I always felt the roll axis wobble experienced with the PIFF controller, was due to the Integral not being able to respond fast enough to perturbations. Causing the I-term to wind-up a little, and make oscillations worse for a few corrections, after the initial response.

I have tested the D-term, by turning P to nothing. And it feels like the D-term is giving some dampening of the I-terms inability to correct fast roll axis drift.

Interestingly, on MR the I-gain is not affected by TPA, but the D-gain is:

That makes sense. I-term is needed to keep Air mode active at all throttle set points.

[CertainBot]

@avsaase and @rts18, I am going to sum my findings on PID FW controller 3.0-RC1 on a by default quite nervous AR Mini wing. Unfortunately Matek 411 wing does not have a BB log so I only "test by feel" First of all PID work quite well... for one speed! The further away from that speed in any direction the worse the behaviour, either because PIDs result to be too low or too high in my case going into crazy oscillations. And dives at low throttle are a big problem that I didn't have with PIFFs. Oscillations are uavoidable with no active TPA so I am building the habit to switch to manual prior to a dive.

So TPA should be set to kick in at that 'tuned' throttle which most typicaly is the cruising throttle, in my case 38%, and gradualy decrease PID strength from that point on. For tunning TPA ramp initialy should be steep so that on higher throttle produces too much PID relaxing and during tunning should be decreased until PID hold equal on any throttle above cruise throttle. A built in small delay is ok to compensate for acceleration.

As you have mentioned real air speed IAS is THE value that should attenuate PID not throttle but 99.9% do not use a pitot. GPS ground speed GS is more or less meaningless depending on winds and plane attitude but 3D speed which mixes GPS and baro can substitute to some extent IAS specially for the vertical component.

So I think one possible solution for the total PID attenuation can be a mix of TPA and 3D speed in a proportion, like GPS and baro for altitude. Hopefuly this mix will mantain PID effect inside a window where the plane flies OK and never letting the PIDs be excessive or too low.

Currently in 3.0-RC1 I have some problems on autolaunch with some big slow rolls and unstable pitch control due to low speed and high throttle, aka big PID attenuation in a critical moment. And two more things I don't feel any effect from FF and stabilized Rates are no longer rates in deg/sec but act like a % of the total aileron through wich is kinda wierd. I had to bump from 230 to 750 to have the same control (this can be seen on aileron movement on the ground) and 750 is more like 75% of total through. Maybe I missed something here.

[avsaase]

I just found (and fixed) a bug that disabled the D-term in the fixed-wing control loop. The bug was introduced in #6681 and thus made it into 3.0-RC1.

[CertainBot]

I just found (and fixed) a bug that disabled the D-term in the fixed-wing control loop. The bug was introduced in #6681 and thus made it into 3.0-RC1.

You mean it was never active or just in certain occasions?

[avsaase]

It was never active in builds from the master branch from the last 16 days.

[stale]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help.
This issue / pull request will be closed if no further activity occurs within two weeks.