Hi! These days, we have got 50 crazyflies and try to make drone show. But there are some problems.
We use 8 anchors, TDOA mode in 5m X 5m X 2M.
1. We want to fly more than 10 drones. However, if we use more than 10 drones with a single dongle, communication problems always arise. Some drones do not communicate with the dongle. In Python scripts, the conneting phrase is displayed, but the connected phrase is often not displayed. it often happens that the parameter download function can not be passed even if it is conneted. The drones' leds that can not pass over are no longer blinking. In this case, rebooting the drone may cause communication again. But we want all drones over 10 to always communicate well. We have tested with all the drones we have and have done a lot of experiments, but the results have always been the same. I tried changing the channels, using several channels, and trying a number of drones, but I could not communicate with all of drones. The maximum amount of communication that can be done smoothly was 8 drones. In this case too, the connection was not good at one time and two or three attempts were made to go through the reset_estimator step and run_sequence was done. Are there any wrong way in our experimental?
URI1 = 'radio://0/80/2M/E7E7E7E7D1'
URI2 = 'radio://0/80/2M/E7E7E7E7D3'
URI3 = 'radio://0/80/2M/E7E7E7E7D9'
URI4 = 'radio://0/80/2M/E7E7E7E7A2'
URI5 = 'radio://0/80/2M/E7E7E7E7A3'
URI6 = 'radio://0/80/2M/E7E7E7E7A4'
URI7 = 'radio://0/100/2M/E7E7E7E7D8'
URI8 = 'radio://0/100/2M/E7E7E7E7D9'
URI9 = 'radio://0/100/2M/E7E7E7E7A1'
URI10 = 'radio://0/100/2M/E7E7E7E7A2'
URI11 = 'radio://0/100/2M/E7E7E7E7A3'
URI12 = 'radio://0/100/2M/E7E7E7E7E1'
URI13 = 'radio://0/100/2M/E7E7E7E7E8'
2. Also, there are problems in parameters.
The more drones we fly, the more we find that some drones always fly in strange directions. So I checked the parameter values before launching the drones, and found that some drones were getting the wrong x, y, z coordinates, or that the yaw, pitch, roll, and motion shutter values were strange. If the yaw, pitch, and roll values of the drones on the ground were abnormally large or small, the drones always made a strange flight. Also, when the motion shutter(what is motion shutter?) value is 900 or less than 8000, the drones are overturned as soon as they fly. I always check the value in a Python script before flying a drones, and the drones that have strange values are rebooted or replaced with other drones. What we are wondering is why this happens. Experiments have shown that there are always two or three drones with abnormal values as they fly over 10 drones.
3. Our ultimate goal is to launch 25 drones using two or more dongles. We are now trying to use 12 drones with two dongles, but there are still communication problems and parameter problems. More problems arise when two drones are used to launch 12 drones, rather than 6 drones using one dongle. How do I resolve it?
Communication errors and abnormal values in multiple drones
-
kristoffer
- Bitcraze
- Posts: 630
- Joined: Tue Jun 30, 2015 7:47 am
Re: Communication errors and abnormal values in multiple drones
Hi!
Sounds like an exciting project!
1. The best setup for the radios is to use one channel per radio and different addresses for each copter. It looks like you are using the same dongle (the first number in the URIs) for all connections. Maybe try to add a second radio and change URI7 - URI13 to 'radio://1/100/2M/E7E7E7E7D8' and so on.
There is a bandwidth limitation for each radio dongle as well, if you subscribe to log data from the Crazyflies this might also be a limiting factor. Try to keep the log data at a minimum. The same is true for transmitted data from the radio dongles, try to not send setpoints unnecessarily often, 5Hz is probably a good rate.
In theory the limitation of the radios should be the total bandwidth used by all connections, but we have recently found that there is a problem in the current implementation that degrades the performance with multiple connections. We are working on a solution but it is still work in progress.
Our experience is that it is possible to transmit position setpoints to 8-10 copters concurrently.
2. This sounds like the kalman filter has not converged in some drones. The kalman filter is responsible for estimating the position of the crazyflie based on available sensor data. It maintains information on position, pitch, yaw and so on that it updates when new sensor data is available. In some cases it takes a while to find the correct state and this is probably what you see, the estimated position moves around randomly. When the kalman filter has found the correct position it is usually stable and tracks well.
It is essential that the filter has converged before take off, otherwise the copter thinks it is in a completely different location and will probably go off in a random direction.
There is no really good way to make sure the filter has converged before take off but we have a hack that works well. Check out the reset_estimator() method in https://github.com/bitcraze/crazyflie-l ... equence.py. It resets the kalman filter and waits for it to converge.
The shutter parameter is related to the Flow deck (the shutter speed of the camera). Unless you use Flow decks it should not be important in your setup.
3. I think this might be related to your URIs (see 1.) since it looks like you actually only were using one radio dongle. To make sure both radios are used, check that the LEDs on both radios are lit up.
- Kristoffer
Sounds like an exciting project!
1. The best setup for the radios is to use one channel per radio and different addresses for each copter. It looks like you are using the same dongle (the first number in the URIs) for all connections. Maybe try to add a second radio and change URI7 - URI13 to 'radio://1/100/2M/E7E7E7E7D8' and so on.
There is a bandwidth limitation for each radio dongle as well, if you subscribe to log data from the Crazyflies this might also be a limiting factor. Try to keep the log data at a minimum. The same is true for transmitted data from the radio dongles, try to not send setpoints unnecessarily often, 5Hz is probably a good rate.
In theory the limitation of the radios should be the total bandwidth used by all connections, but we have recently found that there is a problem in the current implementation that degrades the performance with multiple connections. We are working on a solution but it is still work in progress.
Our experience is that it is possible to transmit position setpoints to 8-10 copters concurrently.
2. This sounds like the kalman filter has not converged in some drones. The kalman filter is responsible for estimating the position of the crazyflie based on available sensor data. It maintains information on position, pitch, yaw and so on that it updates when new sensor data is available. In some cases it takes a while to find the correct state and this is probably what you see, the estimated position moves around randomly. When the kalman filter has found the correct position it is usually stable and tracks well.
It is essential that the filter has converged before take off, otherwise the copter thinks it is in a completely different location and will probably go off in a random direction.
There is no really good way to make sure the filter has converged before take off but we have a hack that works well. Check out the reset_estimator() method in https://github.com/bitcraze/crazyflie-l ... equence.py. It resets the kalman filter and waits for it to converge.
The shutter parameter is related to the Flow deck (the shutter speed of the camera). Unless you use Flow decks it should not be important in your setup.
3. I think this might be related to your URIs (see 1.) since it looks like you actually only were using one radio dongle. To make sure both radios are used, check that the LEDs on both radios are lit up.
- Kristoffer