How does crazyswarm2 process data? What are the outputs to crazyflies? Documentation on the inner workings and data flow.

[boomer319]

Resources I have found:
I really enjoy @whoenig 's detailed paper about the workings of "the first" crazyswarm.
This blog post by @knmcguire is a welcomed behind the scenes on the developement of a ROS2 alternative of the crazyswarm.
I have seen the overview in the crazyswarm2 documentation.

What I want to know and why:
I want to have an idea of the whole system architecture for crazyswarm2. Essentially the way it is portrayed in the crazyswarm paper in section IV and V.

To add some background information: I want to make the crazyflies do obstacle avoidance using the AI deck (optical flow using NanoFlowNet) as a part of my bachelor's thesis. They will be given a flight path and shall modify it on their own based on obstacles.

Questions:
Is there a similar style paper for crazyswarm2?

In case there is no paper or documentation surpassing the mentioned ressources:
What parts of "crazyswarm1" live on in crazyswarm2 and what are the differences between the two? Meaning: What parts of the crazyswarm1 paper are still valid for crazyswarm2?

How does crazyswarm2 process the Mocap data when relying on libRigidBodyTracker(ICP still?)? Funnily enough I am using a one marker arrangement and the "libRigidBodyTracker" has no issues assuming the position.

What is implemented in terms of keeping individual drones from trying to knock each other down? Or is there just raw waypoint sending using cflib?

What do the outputs to the crazyflies look like?

I'll be happy to answer any questions in case there are things left unclear.

Thanks!

Best regards

[whoenig]

• There is no paper for Crazyswarm2, yet. But there will be one in the (not very near) future.
• There is a high-level comparison in https://imrclab.github.io/crazyswarm2/faq.html#how-do-crazyswarm2-and-crazyswarm-differ.
• libRigidBodyTracker has two modes: when having 3+ markers, it's unchanged from the Crazyswarm1 paper, when having a single marker, it solves an optimal assignment algorithm with the cost as Euclidean distance each frame, using a max-flow-min-cost formulation. We are currently working on a new hybrid mode that combines both (i.e., it would be possible to have some CFs with a single marker and some with 3+ markers)
• There is collision avoidance using Buffered Voronoi Cells onboard the official firmware (contributed by James Preiss). This can be enabled for collision avoidance. There is no other supervisor on the ROS 2 side.
• The output is typically trajectories, waypoints, or low-level commands (such as rpy and thrust), depending on what topics/services you are using.

Your thesis topic sounds very interesting. It does sound like it mostly requires changing the firmware of the AI deck and STM32 to make it work. For testing, you could use any host software, such as cflib, crazyswarm2, or perhaps even cfclient.

[boomer319]

Thank you very much!