Improved management of Crazyflies in crazyflies.yaml

[williamleong]

To make experiments and demonstrations more flexible and reliable, is it possible to have the Crazyflies defined, but do a scan in the constructor of CrazyflieServer to determine which Crazyflies are active before trying to initialize them, instead of relying on the "enabled" flag? This way, if a Crazyflie is not deployed, or is not responding due to a technical problem, it does not block the constructor and the experiment can proceed.

Currently, if a single Crazyflie cannot be connected, say 1 out of 20, the constructor blocks. We also use the Crazyflies in a competition context and often have to reset if the deployed Crazyflies do not exactly match what is defined in crazyflies.yaml or are not responding due to some other issue.

Maybe one way is to allow the "enabled" flag to be set to "scan" instead of just true/false.

My thinking is that the concept of "swarm" means that we want to build and demonstrate a reliable and robust system. In such a system, the failure or absence of a few agents/Crazyflies should not affect or change the emergent outcome or behaviour that we want to demonstrate using the Crazyflies.

[whoenig]

Thanks for the suggestion! I agree that this is important and I share the concern that robustness is important; we do have that "robustness" if a communication failure occurs after connecting, but not during.

To prioritize/assign: are you using the cpp or cflib backend?

[williamleong]

Thanks for considering it! I am using the cpp backend.

Maybe one way to do this is to have a timeout and skip the current Crazyflie if it is not responding.