Rover: CONDITION_YAW command to skid-steering Rover
Related to #29416 Added initial handling logic for the CONDITION_YAW command. An associated autotest was created to validate the new functionality. However, the test currently fails, indicating that further debugging and refinement of the yaw control logic are needed.
Will need to cope with that problem in the autotest, you can add a parameter to wait_heading to send the attitude request through until the condition is met (or the the call fails....)
I don't really understand what I have to do for this, as I was not able to find anything similiar. Am I supposed to create a new parameter for this function? I couldn't really find a way to achieve the intended behaviour with the existing ones.
Will need to cope with that problem in the autotest, you can add a parameter to wait_heading to send the attitude request through until the condition is met (or the the call fails....)
I don't really understand what I have to do for this, as I was not able to find anything similiar. Am I supposed to create a new parameter for this function? I couldn't really find a way to achieve the intended behaviour with the existing ones.
OK, you need to continuously send through or guided thinks you've given up and gone home for the day - that takes 3 seconds. See SET_ATTITUDE_TARGET_heading_test_target - you want to pass in called_function
Okay, nice I can do that. The support to specify cw and ccw movement isn't implemented yet though. I need to do that part and improve the autotest to try all types of parameters for the command.
Should I still add this to this PR and then, when everything's fine, squash everything, or is it better to close this as it is and open a new PR for that part?
I've implemented support for specifying clockwise or counter-clockwise movement and made a simple test that expects the vehicle to turn to 60º counter-clockwise (performing a -300º rotation)
The test fails and I've tracked with gdb the problem. Further down the intruction flow, in the AR_AttitudeControl library, the function get_turn_rate_from_heading is called.
This function turns the received angle in radians to an angle in range [-PI, PI] at the beginning, which impossibilitates rotations over 180 degrees, no matter what I do.
In order to get this to work, I would have to alter this function to instead turn the angle received into an angle in range [-2PI, 2PI]. I've tested this and it worked. However, this modification could break other code that relied on this function.
So, essentially I'm asking what to do? Do I modify it, nonetheless? Do I create an identical function in the library to use in this scenario only and leave the existing one alone?
So, essentially I'm asking what to do? Do I modify it, nonetheless? Do I create an identical function in the library to use in this scenario only and leave the existing one alone?
We have a function to do the conversion for you wrap_2PI. It will take the -Pi to Pi and return 0 to 2Pi.
@rmackay9 Friendly reminder of this PR :)
@rmackay9 Is there anything else to change?