Yaw rate reference in firmware PID controller

[mwlock]

Hey!

I am attempting to use the crazyflie_controller_py_firmware_pid controller for simulating the crazyflie onboard controllers.

Unfortunately, I am struggling a little bit with Yaw/Yaw rate regulation and have noticed that in the example, the desired yaw rate is set:

yawDesired = 8
...
degrees(yawDesired)

https://github.com/bitcraze/crazyflie-simulation/blob/9fc77d2967be7f1aad0c2af608d729433e2880b7/simulator_files/webots/controllers/crazyflie_controller_py_firmware_pid/crazyflie_controller_py_firmware_pid.py#L139

https://github.com/bitcraze/crazyflie-simulation/blob/9fc77d2967be7f1aad0c2af608d729433e2880b7/simulator_files/webots/controllers/crazyflie_controller_py_firmware_pid/crazyflie_controller_py_firmware_pid.py#L141

Is there a reason one has to give such a large setpoint? This makes absolute yaw tracking a little tricky...

[knmcguire]

yeah, that is probably due that the python bindings have a bit of a timing issue. Perhaps if you noticed, we fix the ticks now to a 100

https://github.com/bitcraze/crazyflie-simulation/blob/9fc77d2967be7f1aad0c2af608d729433e2880b7/simulator_files/webots/controllers/crazyflie_controller_py_firmware_pid/crazyflie_controller_py_firmware_pid.py#L163

But this is not the same as the actual rate of the simulator. However, if we uses the real time of the simulator, the crazyflie is hardly able to fly.

There are currently quite some timing and intergration issues with the python bindings that we need to fix. However this needs to be on the crazyflie firmware side of things. We don't have time to quickly have a fix for this but I've made an issue so that we are reminded to look at this once we have more time https://github.com/bitcraze/crazyflie-firmware/issues/1320

[mwlock]

I see ! Does this relate to this part of the firmware?

https://github.com/bitcraze/crazyflie-firmware/blob/cd3f3dfb668261f4461f972be8116d996aa7256e/src/modules/src/controller/controller_pid.c#L63

Additionally, I am wondering if this would also affect the thrust control for the legacy (manual) thrust control

https://github.com/bitcraze/crazyflie-firmware/blob/cd3f3dfb668261f4461f972be8116d996aa7256e/src/modules/src/controller/controller_pid.c#L97

[knmcguire]

Yeah probably everything is affected by it that is depended on that rate control 😅 . It is not ideal for now. The control works pretty good okay but then you can't really call it software in the loop anymore, which is the initial purpose of it.

Anyway, hopefully we will have some time to look at it in the future.

[mwlock]

Could I potentially create a timer to call the controller at the same rate it would be called on the Crazyflie itself ?

If so, then I would have two follow-up questions:

1. Where could I find what rate the controller is called in hardware?
2. In the Crazyswarm2 package, I can see that the sim backend calls the controller with a timer similar to what I am suggesting. Although I can see by default that max_dt = 0.0. What would the actual execution rate of the timer then be?

Thanks!

[mwlock]

Could I potentially create a timer to call the controller at the same rate it would be called on the Crazyflie itself ?

If so, then I would have two follow-up questions:

1. Where could I find what rate the controller is called in hardware?
2. In the Crazyswarm2 package, I can see that the sim backend calls the controller with a timer similar to what I am suggesting. Although I can see by default that max_dt = 0.0. What would the actual execution rate of the timer then be?

Thanks!

I can see in the firmware how the tick is increased when calling the controller https://github.com/bitcraze/crazyflie-firmware/blob/cd3f3dfb668261f4461f972be8116d996aa7256e/src/modules/src/stabilizer.c#L342, but it isn't clear the rate at which this loop runs

[knmcguire]

ahhh... yeah it should be at a 1000 hz I think. but this is perhaps a bit dangerous as there are many factors that might delay that rate in the stabilizer loop these days, so it might not be as true anymore as it used to.... I feel that a revamping might be necessary 😓. I'll mention this in the previous issue I started, since there are a lot of assumptions placed on this very simple increase I think. If this is the case, we will need to make the controller and estimators not rely on this tick anymore but on the actual time and that is not a change in the Python bindings but an actual change in the firmware.

The timer thingy in crazyswarm2, you should start a discussion at their discussion page: https://github.com/IMRCLab/crazyswarm2/discussions. I am a co-maintainer there but I didn't implement this part of the code.

[mwlock]

I see 🙈 I tried my hand at setting the simulation rate of Webots to 1 ms (the fastest rate possible) and incrementing the tick of the controller with the simulation tick, but the behaviour seems to be a little unstable...

[knmcguire]

yeah that is not working indeed.

I see that you posted a question on crazyswarm2 about webots: https://github.com/IMRCLab/crazyswarm2/discussions/290

Just mind, that the python bindings timing issue is completely unrelated to the simulator ;) this is not a webots issue