Instability when using 8 Crazyflies (7 works perfectly)

[JY-HIM4U]

Hello!
I'm running into an unusual stability issue with Crazyswarm2 + Crazyflie 2.1 + Lighthouse V2, and I’d really appreciate any guidance.

With my setup (4 Lighthouse V2 base stations), 7 Crazyflies fly completely stable, but adding any 8th drone makes the whole group unstable. This instability happens during the initial goTo() hover, before my own control loop starts—so it’s entirely on the firmware’s onboard controller + Lighthouse tracking.

A few things I’ve checked:

• All drones fly perfectly when tested individually

• Any combination of 7 drones works — the problem appears only at 8

• Crazyradio is unlikely the cause (the instability appears before any high-rate setpoints)

This makes me think the problem may be related to Lighthouse tracking load or timing constraints.

Is it reasonable for me to suspect that the Lighthouse system is the bottleneck here?
Or is there any known issue in Crazyswarm2 that could cause this kind of instability when scaling from 7 → 8 drones?

[whoenig]

Lighthouse is fully distributed and shouldn't have that problem.

Which radio are you using (PA or 2)? Which backend are you using (cflib or cpp)?

[JY-HIM4U]

Thanks for your reply!
I am using Crazyradio PA and cpp as backend.

[ataffanel]

This looks like a bug we are seeing with Crazyradio2 so I am thinking it might be related? @whoenig Is there any broadcast packets sent when using Crazyswarm with lighthouse? The Crazyradio 2 bug seems to be triggered by sending multiple full Broadcast packets in a row and I am wondering if it might be similar there.

Would it help to use 2 radios on 2 different channels?

[JY-HIM4U]

Thanks for your reply!

Currently, I am using two Crazyradio dongles, with four drones assigned to each dongle.
I defined the channels and addresses as follows:

uri: radio://0/80/2M/E7E7E7E716
uri: radio://0/80/2M/E7E7E7E710
uri: radio://0/80/2M/E7E7E7E711
uri: radio://0/80/2M/E7E7E7E709

uri: radio://1/100/2M/E7E7E7E712
uri: radio://1/100/2M/E7E7E7E713
uri: radio://1/100/2M/E7E7E7E714
uri: radio://1/100/2M/E7E7E7E7E7

To hover the drones, I use the following code:

positions = self._get_positions()
for ii, pos in enumerate(positions):
    print(f"Current position: {pos}")
    pos_target = pos + np.array([0.0, 0.0, 0.5])
    self.cfs[ii].goTo(pos_target, 0.0, self.goto_target_duration)

[whoenig]

With lighthouse there should be no broadcasts send (unless using allcfs in Python, which isn't the case in the example code).

It would be helpful to see what happens in your case:
a) when using a single radio (rather than 2);
b) when using the cflib backend (rather than cpp)

Thanks!

[JY-HIM4U]

Thanks you so much for your suggestion.

Unfortunately, I tried both but the same problem happened.

Is it right that I can use cflib by adding backend:cflib when I launch the launch file?

Thank you!

[whoenig]

You would use ros2 launch crazyflie launch.py backend:=cflib (so := not :).

[JY-HIM4U]

Thanks for your suggestion.

I tried, but the same problem happened.

[whoenig]

If I understand correctly, hovering is not a problem (i.e., the initial takeoff command works fine, even if you then hover for a while, rather than issuing a take-off command)?

Could you describe "makes the whole group unstable"? Does this mean that all of your drones become unstable, or is it always just a (potentially random) subset?

Finally, could you try using broadcasts so we can really rule out the communication part:

positions = self._get_positions()
for ii, pos in enumerate(positions):
    print(f"Current position: {pos}")
    pos_target = pos + np.array([0.0, 0.0, 0.5])
    self.cfs[ii].goTo(pos_target, 0.0, self.goto_target_duration)

should be replaced by

self.allcfs.goTo(np.array([0.0, 0.0, 0.5]), 0.0, self.goto_target_duration)

(the broadcast version of goTo is automatically relative to the current position of each drone).

[knmcguire]

just to add to @whoenig here, you need to do this with the cpp backend (so the default).

[JY-HIM4U]

I truly appreciate your feedback and suggestions.

I’d like to share some videos that summarize the experiments:

I gradually increased the number of drones
(3Drones_1Base → 4Drones_1Base → 5Drones_1Base → 6Drones_1Base),
and you can see that the initially stable hovering becomes unstable as more drones take off.

At first, I suspected that the last three added drones had poor hovering performance, but the '3Drones' experiment confirmed that they hover normally when flying alone.

In these videos, I’m still using the command self.cfs[ii].goTo(pos_target, 0.0, self.goto_target_duration) with the default cpp backend. I connected all crazyflies with a single radio
.
I’ll try your suggested approach (using self.allcfs.goTo) soon and share an update!

[JY-HIM4U]

I tried using self.allcfs.goTo for all 6 Crazyflies. Similar to the self.cfs[ii].goTo command, it still showed noticeable drift during hovering.

I’ve added the new video to the same drive folder under the name “6Drones_1Base_allcfs”.

Thanks again for your help!

[whoenig]

Thanks for sharing the videos! What you observe is caused by the aerodynamic interaction forces between the robots and does not indicate a problem with the communication or tracking, but rather with the controller. Are you using the Mellinger controller (

crazyswarm2/crazyflie/config/crazyflies.yaml

Line 112 in 121e3c4

controller: 2 # 1: PID, 2: mellinger

), which should have the best out-of-the-box performance for this case? If yes, try to move the drones further apart from each other and check if the problem goes away. If it does, then you would need more sophisticated controllers to achieve lower tracking error (such as NeuralSwarm or an INDI formulation).

[JY-HIM4U]

Thanks for your feedback!

The reason I suspected a communication or tracking issue rather than aerodynamic interaction is that the stability seemed to depend on how many drones were added, even when the distances between them were the same.

For example, if you compare the videos “3Drones_1Base” and “6Drones_1Base,” the original three drones—which were stable on their own—become unstable after adding three more drones. This happens even though the additional drones are placed at least 1 m away from the initial group.

What do you think about this?

Currently, I am using a PID controller!