Drone flipping while swarming

[jonasdn]

In preparations for BAM days demos we noticed buggy behaviors that we would like to fix. One of those was the tendency for drones to flip over, sometimes directly at take-off.

A post on the forum seem to see the same thing and the poster has created a video of the phenomenom: https://www.youtube.com/watch?v=XbePpd3uS0c

We have observed this while using the Lighthouse positioning system.

Next steps(?):

• Try to find a stable reproducer and start to isolate the problem
• Check if this happens with other controllers
• Check if this happens with other positioning systems than Lighthouse

[ntamas]

FYI, we have seen similar flyaways with the Lighthouse system every now and then, but no flips. No similar flyaways were observed with the UWB system, not even after flying 8-10 drones several times over a course of several days. I'd cautiously say that it's probably related to the Lighthouse system, but we weren't able to reproduce it deliberately.

[krichardsson]

Thanks for the input @ntamas , I also saw your post in the forum. Our prime suspect (at the moment) is the communication stack on the PC side, but I also have a sneaky suspicion there might be some sort of buffer/stack over flowor bug in the CF. Remind me, how do you talk to the Crazyradio in Skybrush, do you use any Bitcraze code or have you re-written all of it? You are still using python, right?

We recently increased the stack size for the lighthouse task as there was a stack overflow, but I think this only happened during initialization (reading persistent storage) and not during flight.

[ntamas]

Remind me, how do you talk to the Crazyradio in Skybrush, do you use any Bitcraze code or have you re-written all of it?

We've rewritten all of it to use async-await instead of callbacks because the host app (Skybrush's own server) is also async-based. But otherwise it's all Python, yes. We handle the takeoff differently, though; the server broadcasts a countdown signal to all Crazyflies in range with the Crazyradio PA, and the drones issue the takeoff command on their own when the time comes.

[krichardsson]

Ah yes, thanks! The threading in the Bitcraze lib is one possible candidate (especially in the Swarm class that runs one thread per CF)

[knmcguire]

Just for reference, the async library made by @skybrush-io can be found here: https://github.com/skybrush-io/aiocflib.

[knmcguire]

This is an difficult thing properly and we don't know exactly if indeed turning everything to async will solve it either.

Anyway, this will mean that the most of the library needs to be rewritten which is quite an big task to do... so this will need an actual quartely focus perhaps. So still up for discussion

[ntamas]

Another complication with switching to async is that async Python code usually does not play nicely together with high-level GUI frameworks like Qt - the async scheduler would need to tie itself into the top-level event loop of the GUI framework if you want GUI code and async code to run on the same thread. Trio has a guest mode, but it is not part of the Python standard library and it seems like a big hack anyway. So, the official Crazyflie client will probably still need to utilize sync code or it has to be rewritten as well to run async code on a separate thread.

[knmcguire]

Ah yes... ofcourse. That will make it more complicated as well.

[knmcguire]

We need to double check this for the new release. Let's try to fly 5 with the swarm class and see if it still happens

[krichardsson]

Can not reproduce