AP_Baro: Do not cache EAS2TAS conversions #26783
Conversation
libraries/AP_Baro/AP_Baro.cpp
Outdated
| const float _EAS2TAS = sqrtf(eas2tas_squared); | ||
| return _EAS2TAS; |
There was a problem hiding this comment.
| const float _EAS2TAS = sqrtf(eas2tas_squared); | |
| return _EAS2TAS; | |
| return sqrtf(eas2tas_squared); |
There was a problem hiding this comment.
Ha! Yeah, I definitely should have just done that. Fixed.
|
That change in spdem demand seems to be having an out-sized impact on that throttle demand. |
Caching this introduces discontinuities in TECS, as the step change modifies the target speed demand.
WickedShell
force-pushed
the
wickedshell/recalculate-tecs
branch
from
4ef362a to
207665e
Compare
I think it's because it's a step change, that we take the derivative of, so the rate of change is suddenly high. After that it just ripples straight into the throttle feed forward. It's definitely more then I expected it to be. |
|
Flew it, looks fine, I can't find the regular large throttle spikes anymore, and is smoother. |
|
How about moving the calculation to the update call? This would mean that we only do the calculation once per loop rather than on each call. It would also give the possibility of getting the value from a secondary sensor. Currently EKF baro affinity always uses the EAS2TAS from the primary baro even if the rest of the core is using the second sensor. |
|
@WickedShell we should also fix the few places that are not using the ahrs.get_EAS2TAS() function which is memoised |
Caching this introduces discontinuities in TECS, as the step change modifies the target speed demand.
The graph of speed demand steps are from EAS2TAS recalculating every 25 meters in the climb, these changes then ripple into the throttle feed forward for throttle as a throttle spike, that makes it all the way out to the motor.
My understanding of the reason for this cache is this was very expensive for us back in the APM2 days, but the world has moved on since then and has a lot more processing power available then we used to. We could try to limit this to faster boards, but I think we can probably afford this on all our currently supported boards. (Side benefit, saves memory :) )
Will be test flying this on a backport to 4.4 tomorrow.