First and IMO the main - sticks scaling change when PIDs are adjusted. Do everyone agree? All the other mini-drawbacks I find insignificant and I wouldn't start my implementation if this issue wasn't present.
2.
Theory: D = (error - previous_error)/dT
Totally agree! But in current (v2.2) code, the D term is calculated not from error, like it should, but from gyro alone. Let me cite the code to ensure proper understanding:
delta = gyroData[axis] - lastGyro[axis]; // 16 bits is ok here, the dif between 2 consecutive gyro reads is limited to 800
lastGyro[axis] = gyroData[axis];
deltaSum = delta1[axis]+delta2[axis]+delta;
delta2[axis] = delta1[axis];
delta1[axis] = delta;
DTerm = ((int32_t)deltaSum*dynD8[axis])>>5; // 32 bits is needed for calculation
I hope now it's obvious (let me focus the issue once again), that there's no rcCommand variable in D calculation at all, so D is calculated only based on gyro output and tries to dampen ANY changes of angle rates, including these induced by moving the sticks.
it should look like this:
Code: Select all
delta = error - lastError[axis];
lastError[axis] = error;
3. I agree, that I control alone may introduce overshoot. But combined with limiting the I value (it is already present in code! but to some unadjustable 16000 values) and presence of P and D this would be insignificant. I component really helps in extreme controls on bad quads like one of my multirotors - the P just can not be set high enough to have good control. I agree - for good systems where influence of ESCs, motors etc are far on the high frequencies this doesn't matter, but these systems fly well with almost any control - I think that main focus should be on making the bad frames fly as good.
4. I hope everyone agree, that current implementation has RATE impacts the stick scaling and that's why the control seem more sharp when RATE is increased?
Last remark. To increase the quality of control, we should provide as small error as possible. Current approach with reducing the gain doesn't look good, IMO. I don't think, that it significantly impacts anything though.
I've tested my implementation. P and I work really well, also I don't see any overshoot even without limiting I value at all. There's no obvious improvement over current version (which was obvious from the beginning), but now I'm really comfortable with swapping the battery and retuning - all the sticks scaling is still the same. D needs tweaking still. Nonlinear control didn't have a good test yet. Also, I've found plenty of scientific articles on multirotor advanced control algorithms (who could think that these are being made at all!). Trying to figure out what can be applied to ACRO mode. Most of them are on navigation, but that's another topic.