Refactor pulse width calculation for kick into its own function #3351
Conversation
DimitriK24
requested review from
itsarune,
williamckha and
sauravbanna
as code owners
| * @param speed Speed of the desired kick in m/s | ||
| * @return Width of pulse | ||
| */ | ||
| uint32_t calculateChickerPulseWidth(int kick_constant, double kick_coefficient, |
There was a problem hiding this comment.
You'll need to mark this function as inline. Functions defined in header files need to be marked as inline to avoid violating the One Definition Rule
| * @param kick_constant | ||
| * @param kick_coefficient |
There was a problem hiding this comment.
These params should have descriptions. e.g. "the constant to use in the kick speed to pulse width conversion"
There was a problem hiding this comment.
Also, if you take a look at other functions where calculateChickerPulseWidth is called, you'll see that kick_constant, kick_coefficient, chip_constant, etc. are undocumented in the function docs. This is outside the scope of this PR, but it might be worth updating those function docs with descriptions for those params
…alculateChickerPulseWidth to be inline
…into duplicate_power_kick
DimitriK24
force-pushed
the
duplicate_power_kick
branch
from
7717838
to
7eaf4ce
Compare
|
The last software test (//software/embedded/ansible:requirements_test) timed out after 60 seconds, all others passed. I'm not sure why the auto-fixes failed. |
You can just rerun them if they fail for those reasons. //software/embedded/ansible:requirements_test is flaky on CI for some reason and the auto fixes check often fails after formatting. |
someone2060
requested review from
a team,
Mr-Anyone and
AadityaSuri
and removed request for
a team
Please fill out the following before requesting review on this PR
Description
Combines duplicate calculations for the chipper's kick pulse width
Testing Done
Built and tested file using bazel
Resolved Issues
resolves #3193
Length Justification and Key Files to Review
Software/src/proto/message_translation/power_frame_msg.hpp
Review Checklist
It is the reviewers responsibility to also make sure every item here has been covered
.hfile) should have a javadoc style comment at the start of them. For examples, see the functions defined inthunderbots/software/geom. Similarly, all classes should have an associated Javadoc comment explaining the purpose of the class.TODO(or similar) statements should either be completed or associated with a github issue