Cflib backend and a limit on the number of CFs

[joonlee16]

Hi, I started exploring to see if I can fly at least 5+ CFs at the same time. With cpp backend, I could not even fly 2 CFs, so I have been using cflib and got to fly up to 5 drones. However, whenever I add one more CF and launch a script, it seems like it is not working, as one processor cannot handle more than 5 CFs. It seems like it is happening because it is only using threading. Has anyone found a way to solve this issue, maybe multiprocessing?

[knmcguire]

Hi!

it should be able to handle more than 5, but the time it takes to retrieve all the parameters takes a long time I believe and perhaps that is the bottle neck here.... The swarm class of the cflib uses those python thread: https://github.com/bitcraze/crazyflie-lib-python/blob/master/cflib/crazyflie/swarm.py

The hope is that at one point I'll have the time to rewrite the backend to not use the swarm class at all, so just async call backs and no threads. The hope is that this would improve that situation you are facing right now, but I'm not sure how quickly I'll be able to do this. In the mean time, would it be possible to use more crazyradios perhaps and different instances of the node?

@whoenig maybe you have some tips as well for that.

[joonlee16]

Hi, thank you for reply. I have tried putting two different servers on two different radios, but I am getting a following error:
[Errno 98] Address already in use

It seems like both servers are trying to get on the same radio. Is there a way to change which radio it uses, maybe another config file? I just could not find one.

[knmcguire]

Ah yes you can change that in the URI. That one looks like radio://0/80/2M/E7E7E7E701 and the first zero right after radio, you can change that to 1 or higher (depended on how many crazyradios you have attached)

[joonlee16]

Thank you for your answer!

[KhAlamdar11]

Hello,

I'm facing an issue while flying two Crazyflies. During takeoff, one Crazyfly is perfectly stable while the other starts jiggling and eventually crashes. I've tried renaming the address endings from E7E7E7E7E7 to E7E7E7E701/02, and I've used both the cpp and cflib backends, but the issue persists. Individually they take off and land fine, and even work perfectly when integrated with Optitrack mocap.

Initially, I thought the problem might be related to ROS 2 DDS because I was getting the 'RTPS_TRANSPORT_SHM Error' at some point, but that error no longer appears. Also, I'm running the package from a Docker container.
Any suggestions on how to resolve this would be appreciated.

[knmcguire]

This seems to be not a similar issue that what the original poster was having. Could you start a new discussion thread for this?