search

IMRCLab / crazyswarm2

A Large Quadcopter Swarm
MIT License
117 stars 64 forks source link

Maximum of 5 crazyflies taking-off #93

Open CharlesSol7 opened 2 years ago

CharlesSol7 commented 2 years ago

Hello, I try to fly a swarm of 10 crazyflies but there is an issue while flying more than 5 of them. If I want to fly 6, the first one won't take off. For 7 of them, the first two won't take off. You can see that in this video : https://user-images.githubusercontent.com/71951031/199629172-635c6006-e618-41fb-90ff-cb7fe7ef3197.mp4

Where do you think the problem comes from? I tried on 1 or 2 crazyradios and the same thing happened, Moreover, I had to reduce the Vicon rate to 50Hz because, at 100Hz, all the crazyflies were crashing at takeoff, but this will be an issue for later.

I am using Crazyswarm2 on ROS2 galactic on Ubuntu 20.04 with a Vicon system, and single marker configuration. Thank you

knmcguire commented 2 years ago

Hi! Could you let us know the crazyflies.yaml you are using and how your launch file looks like?

Would you also know which backend you are using ? (cflib or cpp)

CharlesSol7 commented 2 years ago

Hi, thank you for this fast answer. You can see the files I am using in the following zip folder. I guess I am using cpp if it is default, I always launch with this command : ros2 launch crazyflie launch.py How to change to cflib? maybe I can try that. I modified one of your file to read my trajectory (stored in a numpy array file). I run it with ros2 run crazyflie_examples track_offline (after having added it to the setup file). The yaml configuration file is also on the zip. Thank you!

Issue93.zip

knmcguire commented 2 years ago

The problem with the current cflib backend is that the trajectory upload has not been implemented yet: https://github.com/IMRCLab/crazyswarm2/issues/71

But just for regular take off and landing you could check if there is a difference of behavior between the cpp and cflib

ros2 launch crazyflie launch.py backend:=cflib

if this fails make sure to have installed the crazyflie firmware library with: pip3 install cflib

Mind that fully connecting to all of them takes a while, so please be patient with that :)

knmcguire commented 2 years ago

ah wait... sorry, I see that you are using a mocap system. that will not work on the cflib backend just yet! currently only onboard positioning systems like loco positioning system, lighthouse positioning system and flowdeck will work.

knmcguire commented 2 years ago

When you tried 2 crazyradios, did you also change the URI from radio://0/105/2M/E7E7E7E707 to radio://1/85/2M/E7E7E7E707 ? Also make sure that each crazyradio is on a different channel.

CharlesSol7 commented 2 years ago

When I tried with two crazyradios, I used exactly those channels (radio://0/105/2M/E7E7E7E701, radio://1/85/2M/E7E7E7E702, radio://0/105/2M/E7E7E7E703, ...), but the same behavior happens. I will continue to do some tests next week and I will give some updates here.

In the meanwhile, do you have an idea why all crazyflies are crashing at takeoff when increasing Vicon frequency above 50Hz? Thank you, I really appreciate the service you provide on this forum!

whoenig commented 2 years ago

In Crazyswarm2, we always send the mocap information to all crazyflies, so using multiple radios doesn't have the same scaling effect as in Crazyswarm1. The reason for this was to support some algorithms such as collision avoidance better, although we might re-introduce the old behavior as an option. In your setting this could certainly fix the problem for now, assuming that you don't have problems flying 5 CFs?

Nevertheless, 10 CFs with single-marker tracking should technically not be a problem. However, I personally tested Crazyswarm2 only with up to 5 CFs. What you describe does sound like some sort of bandwidth issue with the radio. When you reduce the mocap frequency, you also reduce the number of packets that are being sent. A crash during takeoff indicates that the CF either has no, or stale data. One way to debug this, is to put the uSD card deck and log the event when the CF receives data from the mocap - even without flying one would be able to see if not enough messages arrive.

knmcguire commented 2 years ago

Maybe things might be improved with the latest PR @whoenig ? https://github.com/IMRCLab/crazyswarm2/pull/109

whoenig commented 2 years ago

Yes, if broadcasts were used, this changes should have fixed that problem. I've seen issues with lost packets with even fewer drones in the swarm.

knmcguire commented 2 years ago

@CharlesSol7 could you update your repo, build again and try out with more than 5 CFs with broadcasting and the cpp (default) backend? Let us know if the issue has been fixed

CharlesSol7 commented 1 year ago

Sorry for my late answer, I just redid some new tests after updating the crazyswarm2 package and I get the same bug. However, it worked only twice when the 6 drones took off, but I did not succeed to reproduce it reliably. It may have worked because I did not reboot the previous drones of the previous flight, but I need more testing to confirm that. I will keep you updated. thank you for your previous answers.

CharlesSol7 commented 1 year ago

Some precisions, after redoing some tests, I manage to get everything working when I first fly 5 drones, then added three more without rebooting the five first. If I reboot all the drones before trying to fly all of them, I have the bug where only five crazyflies are flying.

When the issue occurs, it happens at takeoff. For those last tests, I used only one crazyradio. (It was not as successful with 2 crazyradios doing the same not-rebooting method, but I did not do as many tests as with a single crazyradio).

whoenig commented 1 year ago

Which firmware version are you using? After rebooting, do you see "ready to fly" for all drones in the terminal output? (Sometimes drones refuse to take-off if a self-test has failed.) Also, do you see the same issues if you only use high-level commands (e.g., using takeoff/land to the /all topic on the joystick)?