ardupilot icon indicating copy to clipboard operation
ardupilot copied to clipboard

Rover: CONDITION_YAW command to skid-steering Rover

Open jrcacador opened this issue 9 months ago • 7 comments

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.

jrcacador avatar May 24 '25 13:05 jrcacador

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.

jrcacador avatar May 26 '25 18:05 jrcacador

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

peterbarker avatar May 27 '25 12:05 peterbarker

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?

jrcacador avatar May 30 '25 08:05 jrcacador

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?

jrcacador avatar Jun 02 '25 15:06 jrcacador

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.

IamPete1 avatar Jun 02 '25 20:06 IamPete1

@rmackay9 Friendly reminder of this PR :)

jrcacador avatar Jun 09 '25 19:06 jrcacador

@rmackay9 Is there anything else to change?

jrcacador avatar Jun 15 '25 21:06 jrcacador