open-sourcing provably safe distributed crazyflie swarm on-board controller

[bconvens]

Hello crazyswarm developers,

In one of my latest research projects I have worked on provably safe on-board distributed feedback control for aerial swarms (this paper, video with method explained and hardware experiments).
The method is an Invariant Set Distributed Explicit Reference Governor (D-ERG) law which runs on-board the crazyflie firmware. The overall control law (i.e. a navigation and control layer) is very computationally efficient (runs at 500Hz) and ensures asymptotic stability and safety for higher order quadrotor dynamics under the presence of input saturation on each of the motors and collision avoidance constraints with static obstacles and dynamic agents (i.e. the other Crazyflies). For the collision avoidance the crazyflies share their position or applied reference position to coordinate safely. For more details, check out the paper and video. If you got inspired or if you plan to use it, please cite the paper.

If there is sufficient interest from the community I would like to open source the software for others to use and extend it further.
I developed and tested the software mid 2019 when I was on a research stay in the ROCC lab of University of Colorado Boulder. Unfortunately, I did not have the opportunity afterwards to access a sufficiently large vicon system to continue this project on the Crazyflies? Covid pushed me to work on bigger outdoor drone swarms now :-).

Back then, my software requested changes in:

• The crazyflie firmware. Basically the D-ERG navigation layer was programmed in the top part of the Mellinger controller file (before the actual control law). This is most of the code. I did not change the Mellinger controller itself.
• I have edited some launch files and created my own task scripts.
• I changed some publishers and subscribers in the main crazyswarm_server.cpp to allow the agents to send the required information (i.e. the drone applied reference position vectors, basically the set-point position send to the Mellinger controller, note that this is not just the goal position sent from the ground station) with each other. Since back then I remember this feature was not there. I would like to know if this high-rate inter-crazyflie communication of signals computed in the firmware is available at this moment?

So according to your documentation, you would propose me to go for option 2 where I make my own ROS package (since I also have changes in the firmware and that seems cumbersome with option 1)? What is the main difficulty if I would use option 1? I would like to have a solution to keep easily up to date with the original Crazyswarm, while I can still add other variants of my D-ERG to compare with.

Thanks in advance for the interest and suggestions!
I am open for future collaborations so you can always contact me. ;-)

Best,
Bryan Convens

[whoenig]

This looks exciting and contributions are of course always welcome! I think adding this would benefit many other researchers to compare different methods fairly.

The Crazyswarm switched completely to the official firmware. So the first & biggest step would be to get your firmware changes accepted upstream. The "closest" example might be an collision avoidance mode that @jpreiss contributed, see bitcraze/crazyflie-firmware#628. This also already includes the infrastructure to receive other robots' relative state (position and velocity). I don't think we have support for the goal position, yet. Note that the Crazyflies do have a peer-to-peer communication feature now as well, which might be suitable in your case. This can be used with the Crazyswarm of course, although it does make debugging harder, since the Crazyradio PA cannot be used for "sniffing" on the over-the-air packets.

Once the firmware is ready, it would make most sense to directly integrate your Crazyswarm changes here, without the use of a fork or submodule (simply via a pull request).

Looking forward to your contribution,
Wolfgang

[jpreiss]

I agree with Wolfgang's suggestions. A couple of notes:

The peer localization system only includes neighbors' positions, not velocities. Velocities would need to be estimated from the position signal using differentiation and filtering. This would be a good standalone contribution if needed - several people have asked for it.

If your algorithm can be expressed completely by generating a setpoint for the Mellinger controller, then you might be able to implement it in the same way as the current collision avoidance (that uses buffered Voronoi cells).

On the other hand, if your algorithm needs a tighter integration with the Mellinger controller (e.g. you wanted to generate the thrust vector instead of a position setpoint, and just use Mellinger for nonlinear attitude control) then it would be a good use case for library-ization of controllers that we discussed @whoenig @knmcguire.