Handle out-of-range motor params without wraparound

[tlbtlbtlb]

Description

Avoid wraparound when converting floating point values to fixed-point. Previously, a value for Kp (the position feedback term) just above 5.0 would wrap around to 0 when converted to uint16_t. Now it gets clamped at the minimum & maximum representable value. All the control params (Kp, Kd, i_sat, current_ref, velocity_ref, position_ref) are handled similarly.

Also add tests for the above, using the catch2 test harness. make test will run them.

How I Tested

sdk/master_board_sdk/tests/test_protocol.cpp covers many cases

I fulfilled the following requirements

• [x] All new code is formatted according to our style guide (for C++ run clang-format, for Python, run flake8 and fix all warnings).
• [x] All new functions/classes are documented and existing documentation is updated according to changes.
• [x] No commented code from testing/debugging is kept (unless there is a good reason to keep it).

[nim65s]

This looks good for me, thanks ! Could you just remove this last commit ? I think it is not supposed to get in this PR.

Also, I think we should add some CMake for catch2. (i didn't even notice that we had a Makefile here…) ; but I can handle this if you want.

[tlbtlbtlb]

Sorry, I'm still learning how to do PRs properly. The branch this PR references now only contains the changes relevant to FP overflow.

[nim65s]

yes, PR are opened on a particular base branch, and while the PR is open, all interactions with that branch will update the PR.

To deal with this, a common usage is to create a branch specific for a PR in your fork : this way you'll be able to continue other tasks on the main branch.

Anyway this looks OK now, I'll squash all those commits and merge, thanks !

[nim65s]

Well, I should have run the tests before merging… Here are the results on my system:

[0/1] Running tests...
Test project /tmp/master-board/sdk/master_board_sdk/build
1/1 Test #1: sdk_tests1/1 Test #1: sdk_tests.........................***Failed    0.00 sec
Randomness seeded to: 2038158713

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sdk_tests is a Catch2 v3.1.0 host application.
Run with -? for options

-------------------------------------------------------------------------------
FLOAT_TO_D32QN and friends work
-------------------------------------------------------------------------------
../tests/test_protocol.cpp:5
...............................................................................

../tests/test_protocol.cpp:27: FAILED:
  CHECK( ((int32_t) std::min(std::max(((std::numeric_limits<double>::quiet_NaN()) * (1<<(24))), -2147483647.0), 2147483647.0)) == int32_t(0) )
with expansion:
  -2147483648 == 0

===============================================================================
test cases:  1 |  0 passed | 1 failed
assertions: 28 | 27 passed | 1 failed

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.01 sec

The following tests FAILED:
     1 - sdk_tests (Failed)
Errors while running CTest
FAILED: CMakeFiles/test.util 

[tlbtlbtlb]

I put that test in thinking "I wonder what the behavior even is for converting NaNs?" Both x64/Linux and ARM/Apple give 0, so I left the test in. Probably better to remote the test, since it's not worth master-board trying to guarantee any particular behavior in this case.