There are communication problems with using three radios to control 20 cfs

[swarm5]

Hello everyone, I have a problem and want to ask you for help:
What I want to do is to upload the trajectory file to 20 cfs using three radios to control the 20 cfs. I used figure8_csv for testing. The plane I use is cf2.1, the type is single-point tracking, and the channels of the three radios are set to 30 40 50.Both my PA and cf firmware have been updated to the latest version.

I encountered a few problems:

1. For some cfs, it will take off for a while before taking off. After executing the trajectory, a certain cf does not land and hover in the air. (I just recorded a video, you can refer to it)（The cf in the first row and second column of the video was one second slower during takeoff; when landing, the cf in the first row and fourth column of the video did not execute the landing command.）https://www.youtube.com/watch?v=HIjcZO3QAsw
2. Another problem, I found that when using three channels, sometimes a large number of cfs will lose positioning information and lose their display in rviz. The process at that time was that after I finished running figure8_csv.py, I ran figure8_csv.py again after cf landed. At this time, a large number of cfs cannot receive positioning data and fly out of the field. (Should be all cfs of 30 40 channels, I did not confirm)

I want to ask a few questions:

1. Has the three-channel control drone been tested successfully? Because before I used two channels to control 20 cfs, the flight effect was very good. Therefore, I suspect it is the problem of adding a third channel.
2. The channel settings are relatively close, will there be interference? My channels are set to 30 40 50 respectively. Will it be better if I set it to 30 60 90?
3. Will there be jamming of the PA receiver? How should I detect if the PA receiver channel is blocked? When I finished running figure8_csv.py, the flight effect of cfs was very good; after cf landed, I ran figure8_csv.py again, at this time a large number of cfs could not receive positioning data. I suspect it is a problem with the PA receiver, because the flight effect is very good when using two channels.
4. I want to reduce the frequency of positioning data to reduce the amount of information sent by the PA radio. I would like to ask, what is the minimum positioning frequency? My current FPS is set to 120HZ.
5. I am very puzzled about the two phenomena of being slow during takeoff and not landing after executing the trajectory. Does anyone know the reason?
6. Is there a size limit for the trajectory uploaded to cf? I want to know, what is the maximum file track I can upload to cf?
7. I want to use three channels to control 20 drones in two modes: upload trajectory execution and send low-level streaming commands. Therefore, I am very concerned about the debugging method of radio PA. I want to know when the capacity or bandwidth of my three PAs has reached the upper limit, or the channel has been blocked? Is there such a debugging method?

[swarm5]

Hi @whoenig , I have seen your answer before and mentioned that you have tested three radios to control cfs. Have you encountered this situation?

[whoenig]

1. Yes, the original paper used 3 and we didn't change the threading since. Make sure you compile in release mode and that you have enough cores (at least 4 in this case).
2. No, see below.
3. There are test scripts to find a good channel: https://github.com/bitcraze/crazyflie-lib-python/blob/master/examples/radio-test.py. You can also run the com_test in crazyflie_tools.
4. See below.
5. For the takeoff the Crazyflie might not have finished its internal calibration (check that it said "ready to fly"). For the missed landing, it looks like a high packet loss, so perhaps one of the channels you picked is very congested.
6. Yes, see https://github.com/bitcraze/crazyflie-firmware/blob/master/src/modules/src/crtp_commander_high_level.c#L79-L83
7. You cannot upload a trajectory while flying, currently. There is some work in progress, which will do more intelligent load balancing, avoiding the bandwidth issues you are pointing out. You can read more at https://www.bitcraze.io/2021/02/communication-reliability/. However, it will take a long time before this will make it into the Crazyswarm, since crazyflie_cpp has to be rewritten to use this new high-performance link.

[jpreiss]

2. I think there is less concern about the channels interfering with each other, and more concern about channels interfering with other 2.4GHz devices like WiFi. Try searching through old issues - I believe @whoenig has written some advice about this before.

[whoenig]

2M requires channels to be spaced apart by 2; Spacing more than that has no effect, apart from avoiding overlap with other 2.4Ghz devices.

[jpreiss]

4. We tested down to 10Hz without problems using full-pose. Not sure how single marker changes this. Maybe stick with 20Hz to be conservative.