Having trouble flying 2 Crazyflies as a swarm with obstacle avoidance code

[rowancllzz]

Hi,

I was recently able to write a Python program with my friend which successfully allows a Crazyflie 2.0 to fly to a specific coordinate while avoiding obstacles placed in its away. It uses the multiranger deck. However, when I have two drones simultaneously following the code as a swarm, they manage to fly together but don't fly in sequence and always glitch up somehow. I have attached 4 videos below - 2 videos have each Crazyflie individually following the code successfully without any obstacles placed in the way. The other 2 show the failed flights when the 2 Crazyflies follow the code as a swarm.

Was wondering if anyone have ideas that could be causing these failures and if there's anything I can do to fix this problem. I tried placing them apart at least .3 meters both horizontally and vertically. Would be more than happy to provide more information if necessary. Thanks.

crazyflievid4.mp4

crazyflievid3.mp4

crazyflievid2.mp4

crazyflievid1.mp4

[evoggy]

Hi!

Looking at the videos it seems as if they "drift away" when you're running two at the same time, or?

Could you give us some more details on how you're controlling them (what class, how many radios etc) or some code?

Also how are you positioning them? I see some Lighthouse base stations and maybe some LPS nodes, or are you using the flow deck?

[rowancllzz]

I am generally using the Motion Commander class and one Crazyradio PA. The Crazyflies that I am using for this code, I have attached a flow deck and multiranger deck.

I attached some of my code below (apologize for the messy comments). Essentially, I have an obstacle dodger function which runs through a routing order which has the x, y, and z axis. When a given axis is first in the routing order, its velocity is positive or negative until it reaches the margin or the Crazyflie observes an obstacles.

This is just the obstacle dodging function though. I have after this functions for the position and ranger callbacks as well as functions which print information for both of these. Would be more than happy to provide more of my code if that is helpful. Thank you!

obstacle_dodging.txt

[knmcguire]

I think that you will need to provide more of the code. As this is due to the swarm class probably, we need to see how that is implemented.

Perhaps it would be good to provide a more minimal example? Just both Crazyflies going forward and sideways or something similar?

[rowancllzz]

For sure, I can just attached my entire code since that may be more helpful.

My guess is that it is most likely a swarm class implementation problem as well. I also have other code which uses the swarm class and simpler motion commands to program a sequence and works generally well with flying a swarm of 2 and 3 (though a little bit of drift problems still but not too bad). However, the code for the swarm class there is very similar but can send some of that code too. If that would be of help too, I can send it here.

obstacle_avoidance_rc.txt

[knmcguire]

Hi!

Looking at your code it is a bit difficult to see why your code is behaving differently with 2 than with 1. The common explanation is that it is dealing with threads, and since your solution is very timing based, it means that probably the sleeps() are handled different, or the start_linear motion are dealt with differently, or the range measurements are read out at different times. It is unfortunately very difficult to say with python threads especially when they are receiving range measurements too. By definition, the crazyflies needs to share the packet limitation, and since you are using the motion commander, it's sending a lot of packages per second. I'm also not sure if the motion commander reacts with the swarm thread as we don't provide these in our examples

So I have some alternative ways for you to proceed:

• Still use the motioin commander but have 2 crazyradios (so one crazyradio per crazyflie) and two instances of your python script for each crazyflie
• Rewrite the code to send hover commands instead directly from the generic commander class, in particular the send_hover_setpoint. (see this example). This case you can control how often you send it, but you just have to make sure to send a command at least every 0.5 second (swarm example)
• Not to use the motion commander but the high level commander. It should only require one command to make it go into a direction = less communication (although I'm not sure if the go_to() command is what you want)