max sustained yaw rate possible?

[mrmks]

When I fly my crazyflie 2 (and crazyflie 1), I can't seem to get sustained yaw rates above 500 degrees / second.
Somewhere the yaw rate is being effectively limited. Does anyone know what causes this?

Here's what I did:
in crazyflie-clients-python/src/cfclient/utils/input/__init__.py :

Code: Select all

change (near line 360):
               if data.toggled.alt1:
                    try:
                        logger.warning("alt1 toggled: toggling rot yaw")
                        self.rot_yaw = 1
                        logger.warning("rot_yaw: " + str(self.rot_yaw))

and near line 402:

Code: Select all

self.input_updated.call(data.roll + self.trim_roll,
                                        data.pitch + self.trim_pitch,
                                        data.yaw + self.rot_yaw * 1000,
                                        data.thrust)

so I'm sending in a yaw rate of 1000 deg/sec everytime read_input() is called, I think.

What I see when I fly is 'surging' where the crazyflie yaws faster, then slows down, then the cycle repeats. I'll post if I find what the cause is.

[tobias]

My guess is that you are saturating the yaw output but it could also be something else. You could log the output to see if that is the case by adding a log variable for yawOutput.

[mrmks]

Thank you for the suggestion Tobias!

I am even more confused now, because yesterday I captured the first picture of yawOutput and today I captured the second picture, without changing the code.

yesterday: seem to show a maximum value being help for yawrate, then tapering off.

today: no evidence of yawOutput maintaining a maximum value. yawOutput is covered by unlmitedpidUpdate.

I tried setting KI and KD to 0.0 for both the pid_attitude and pid_rate parameter sections. Got some promising 3 second spins but nothing repeatable yet.

[arnaud]

The strange oscillation effect you are seing comes from the way the yaw rate is handled together with the yaw rate control capping.

To make the yaw control more exact I hacked it a while ago to always control the yaw in absolute angle, not in rate. If you are asking for a yaw rate, the internal yaw angle setpoint is moved following the requested rate. The code that calculates the yaw setpoint form the rate is here: https://github.com/bitcraze/crazyflie-f ... .c#L43-L48

From your graph I can guess that the yaw setpoint is first running in front of the current yaw, the crazyflie cannot follow until the setpoint error passes 180degree and the crazyflie then breaks to reach the setpoint on the back, until the setpoint passes again and it accelerate again.

You can modify the controller_pid.c file to pass the yaw rate setpoint directly in the attitudeControllerCorrectRatePID function. This way you will at least turn at the maximum rate allowed by the control capping. Then the capping can be removed go even faster.

If the PID parameter where better tuned we could certainly remove this way of handling the yaw rate.