-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TPA optimisations #12721
TPA optimisations #12721
Conversation
This comment has been minimized.
This comment has been minimized.
AUTOMERGE: (FAIL)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it really worth touching this code? It's some obscure heuristic that probably works.
This PR does only shave few cycles (at the cost of more state variables), but code is still poorly documented and hard to read.
ae5a293
to
813bc20
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I do think that saving those cycles is important. Future work for more precise attitude control will consume more cycles, and an F411 overclocked to 120Mhz with a 4k PID loop is using 71% CPU in Angle mode already. I measured the whole primary PID loop in Angle mode as consuming at baseline 1,657 cycles. I'm not sure where the remaining 19,000 cycles get consumed :-) This PR saves 55 of those cycles, a non-trivial proportion of the total, and the maths is no more difficult to follow than before. This graphic shows the measured cycleCount for the main |
Sorry, I thought that TPA runs at RC update rate, not PID one. In that case saving is more important. |
@KarateBrot @ledvinap would appreciate review again... I hope I addressed the comments appropriately? |
This comment has been minimized.
This comment has been minimized.
a15a0a6
to
761e8b0
Compare
Do you want to test this code? Here you have an automated build: |
* TPA optimisations * improvement, thanks @ledvinap * update following review comments, thanks karatebrot and ledvinap * include rx.h in pid_init.c to get PWM_RANGE_MIN * review suggestion
* TPA optimisations * improvement, thanks @ledvinap * update following review comments, thanks karatebrot and ledvinap * include rx.h in pid_init.c to get PWM_RANGE_MIN * review suggestion
* TPA optimisations * improvement, thanks @ledvinap * update following review comments, thanks karatebrot and ledvinap * include rx.h in pid_init.c to get PWM_RANGE_MIN * review suggestion
* TPA optimisations * improvement, thanks @ledvinap * update following review comments, thanks karatebrot and ledvinap * include rx.h in pid_init.c to get PWM_RANGE_MIN * review suggestion
* TPA optimisations * improvement, thanks @ledvinap * update following review comments, thanks karatebrot and ledvinap * include rx.h in pid_init.c to get PWM_RANGE_MIN * review suggestion
Code optimisation for the TPA calculation.
Master code requires 26 cycles while throttle < TPA breakpoint, and 63 cycles while sticks are above breakpoint.
This PR reduces that to only 8 cycles, regardless of the throttle position, and returns the same result. This is achieved by doing most of the computation in pid_init.c and avoiding conditional statements.
I'm not sure that throttle can be > 1.0 at this point in the code, but kept that check in place, just in case, since if it was > 1.0 then P and D could be pushed higher than intended.