Maximum Number of Crazyflie 2.1 for Synchronized Light Shows - Data Limitations?

[jeremweb]

Hello there,

I'm currently working on a project to create light shows. For now, I have two Crazyflie 2.1 drones for my research and development.

I'm reaching out to ask how many Crazyflie 2.1 drones I can fly simultaneously in a synchronized manner using the Python library. I'm using the Lighthouse system for positioning.

In terms of data, I send position commands and LED Ring color settings. In return, I receive battery levels and their positions in the real world.

Will I quickly hit a limitation in terms of data exchange? Or possibly face stability issues? At the moment, controlling two drones is easy, but I can't yet assess the situation with a larger number.

Thanks in advance for your help!

[ataffanel]

Hi,

Using the python lib we usually advise 3 Crazyflies per Crazyradio. There is limitations in the radio bandwidth (about 500 packets per seconds both ways) but also with the way python handles multithreading. So to keep the latency low it is best to limit the number of Crazyflie per radio.

We are currently adding communication statistics to the lib in order to be able to observe and analyse the link quality, this will contain at least link contention and lantency which will be two very important metric for you.

@gemenerik will host a dev meeting this afternoon on the subject and it will be published on Youtube later. This is something that might be interesting for you.

[jeremweb]

Ok, but technically, if I want to do a show with 50, 100 drones, or more, aside from the hardware question (having 34 radios for 100 drones probably isn't trivial), can the Python library handle all of that? Would you recommend using ROS2?

Thanks for the link, I'll watch the replay.

[ataffanel]

OK, yes at this scale I would recommend Crazyswarm (based on ROS2) with the CPP link backend. The original Crazyswarm paper described a swarm of 49 Crazyflies flying in MOCAP using only 3 radios. So Crazyswarm has been optimized for these kind of use-case. Python is a bit problem at this king of scale unfortunately, in the future we are planning at making a Rust backend that should solve scalability and will be usable by python/ros/rust/....