actuator: Delay compensation via Smith predictor. #2044
Conversation
flight/Modules/Actuator/actuator.c
Outdated
| 1); | ||
|
|
||
| for (int i = 0; i < MIXERSETTINGS_MIXER1VECTOR_NUMELEM; i++) { | ||
| desired_vect[i] += m->mix * (inv[i] - desired_vect[i]); |
There was a problem hiding this comment.
I'm hoping this one is the right way. I had the terms of the subtraction switched earlier and it made things audibly worse.
|
Tried autotuning with this, it makes the yaw readings way worse. |
|
False alarm, I changed to a pristine set of props, issue went away. |
glowtape
force-pushed
the
glowtape-delaycomp
branch
from
a21943b
to
b2469cc
Compare
|
This is targeted at post-wired right? P.S. Any ideas for post-wired name? :) |
|
Wasabi. --edit: Wait, no, this also starts with W. |
|
The predictor currently also mixes thrust into command, since that's also part of the inverse. Do we even want that? |
|
I think we do-- if know we're underperforming on thrust, we want to fix it right? |
|
god damn wrong button. |
flight/targets/sprf3e/fw/Makefile
Outdated
| OPTMODULES += Battery | ||
| OPTMODULES += ComUsbBridge | ||
| OPTMODULES += Airspeed | ||
| OPTMODULES += UAVOHoTTBridge | ||
| #OPTMODULES += UAVOHoTTBridge | ||
| OPTMODULES += UAVOFrSKYSensorHubBridge |
There was a problem hiding this comment.
Will want to remove all these from HwSprf3e too https://github.com/d-ronin/dRonin/blob/next/shared/uavobjectdefinition/hwsprf3e.xml
|
On which config page should I stick the UI for this? |
|
Let's prove it's good before adding UI |
|
Seems like I need to get cracking on this. The other guys have implemented sorta Smith prediction on their throttle control. |
|
So the loose idea I had anyway was an optionally purely filter based time delay (not in particular a fan of adding more noise than necessary :), as alternative to the sample based delay plus weak IIR. Separate values for throttle may be worth an experiment? |
Hm, I'm not really a fan. 1-- PID can effectively compensate for either pure-delay or exponential decay, but not both simultaneously.... the sample delay is what makes the smith predictor actually do something useful that doesn't mostly just commute with PID, the IIR is just to clean it up. 2-- throttle shaping, etc... how's this different from what smoothcontrol does? We already put in maximal effort to deliver requested throttle with the clip management. |
glowtape
force-pushed
the
glowtape-delaycomp
branch
from
b928da4
to
241d738
Compare
|
Yeah, was just a bunch of random ideas. Rebased to fix conflicts. Added some minor massaging of the throttle signal, after noticing some motor grinding when on the ground with hangtime or very low throttle (took me a while to figure that one out). |
|
What about a second order lowpass? The step response of one is kinda delay+IIR-ish, given the desired delays (4-7ms), if you squint your eyes. If it's remotely applicable, we could keep the noise down, which in turn would allow cranking up the contribution to the control signal. |
|
Put back into inconceivable for now, just for consideration. |
|
@ufoDziner These are the Smith predictor artifacts. |
|
Artifacts built, by request of @glowtape |
|
@ufoDziner I nearly forgot. You should probably set ActuatorSettings.SmithPredictorMix to 0.3 to start (lower than the default in this PR) after installing. |
flight/Modules/Actuator/actuator.c
Outdated
| float r = t+v; | ||
|
|
||
| /* Don't cross zero via prediction. Also bound throttle. */ | ||
| if (sign(t) == sign(r)) |
There was a problem hiding this comment.
THis isn't quite what we want, because if you overperform significantly and throttle is 10%, and it wants to lower it to -2%... we should still lower it to throttle epsilon.
glowtape
force-pushed
the
glowtape-delaycomp
branch
from
a19fac6
to
40f37f3
Compare
|
Is this something we want to try and merge for inconceivable? If so, it should lose the WIP tag and go through review. |
|
We have the anti-windup changes in PID and then the LQG. It would be interesting to get people flying these changes before adding another influencer on control. IMO we should shove it off to Ludicrous. I'd probably want to run another round of logs eventually, to check its behavior at low and high end of throttle. |
|
I've ported some of this over to EmuFlight, but instead did the smith predictor on the gyro data and have had great results with it. |
Hope I did it right. Doesn't have any ill-effect at least in the living room. Can't test it outside yet, so I'm not sure what I'm supposed to be looking for.
Default delay is 3.2ms (for Seppuku x1.6 + 0.5, then rounded = 6 samples), the IIR has a default coefficient of 0.5, which creates a group delay of 1.4 samples. Should get in the ballpark of the 4ms mentioned before in IRC.