Hello,
I'm interested in using some combination of the Flow Deck, LPS deck, and the Multiranger in order to fly a swarm of Crazyflies that are capable of identifying, or at the very least counting, how many other CFs are flying in the area. I'm curious if this is within the capabilities of the Multiranger, and if so, if there's any evidence of this having been done before? Is there a particular sample code on the github, or that someone has written, which would be a good starting place for designing this?
Thanks!
Crazyflies identifying other Crazyflies?
Re: Crazyflies identifying other Crazyflies?
Detecting other Crazyflie with the Multiranger only is going to be very tricky. I am not aware of anyone that has done that already and I am not sure it can work. You would have to aim the multiranger sensors very accurately to be able to detect a small target like the Crazyflie.
If detecting other Crazyflie using other means works for your project, something that might work is to use the P2P packet capabilities of the Crazyflie: https://www.bitcraze.io/documentation/r ... s/p2p_api/. The Crazyflie can send and receive broadcast P2P packets, you could make an app in the Crazyflie that sends the Crazyflie ID at random interval and receives IDs from the neighbor. You can even add more information like position to the packets.
A good place to start with P2P is the app example linked in the documentation, it already implement sending regular beacon.
Please note that it is currently not possible to connect the Crazyflie client while using P2P packets. This is something that is still work in progress but the best we have so far is to use a Crazyflie connected over USB as a relay to observe what is happening.
If detecting other Crazyflie using other means works for your project, something that might work is to use the P2P packet capabilities of the Crazyflie: https://www.bitcraze.io/documentation/r ... s/p2p_api/. The Crazyflie can send and receive broadcast P2P packets, you could make an app in the Crazyflie that sends the Crazyflie ID at random interval and receives IDs from the neighbor. You can even add more information like position to the packets.
A good place to start with P2P is the app example linked in the documentation, it already implement sending regular beacon.
Please note that it is currently not possible to connect the Crazyflie client while using P2P packets. This is something that is still work in progress but the best we have so far is to use a Crazyflie connected over USB as a relay to observe what is happening.
Re: Crazyflies identifying other Crazyflies?
Thanks for the input! If it seems like there's little hope of detecting the other drones visually (and I have to agree with you, the more I tinker with the Multiranger the less I think this is possible) then the P2P system would be a fine substitute. I definitely think I could make the functionality you described of sending their URIs and positions to one another work for this project, but I'm a little confused by your last comment. Do you mean that the drones are unable to fly in this mode and must receive signals via USB, or simply that visualization is limited because CFClient won't function?
Thanks for the insight!
Thanks for the insight!
Re: Crazyflies identifying other Crazyflies?
Hi!
I think what @arnaud is trying to say, is that the connection of the crazyflie to crazyradio PA is not stable enough for the cfclient if it is also sending out p2p commands to other drones. They are always able to fly, but then you would need to use the app layer or such and send a command for them to take off also using a 'peer2peer' packet. I did something similar for this implementation.
but still it would be handy to still have the cfclient possibility so we should definitely look at it again. I've made an issue about this: https://github.com/bitcraze/crazyflie-f ... issues/817
I think what @arnaud is trying to say, is that the connection of the crazyflie to crazyradio PA is not stable enough for the cfclient if it is also sending out p2p commands to other drones. They are always able to fly, but then you would need to use the app layer or such and send a command for them to take off also using a 'peer2peer' packet. I did something similar for this implementation.
but still it would be handy to still have the cfclient possibility so we should definitely look at it again. I've made an issue about this: https://github.com/bitcraze/crazyflie-f ... issues/817
Re: Crazyflies identifying other Crazyflies?
Alright, I think I'm understanding. From what you're saying and the linked documents, it seems like I should be able to use the P2P functionalities in python code, so long as I use two Crazyradios?
Re: Crazyflies identifying other Crazyflies?
The problem is that, in the current implementation, the client will use 100% of the radio time available removing any chance for the Crazyyflies to hear each-other P2P communication. That is unless the crazyflie tries to use P2P 100% of the time, then it is communication with Crazyradio that will be disabled (there has been this case on the forum before ....). One added limitation is that Crazyradio does not have out-of-the box support for the P2P packets yet, so the P2P packets are only for CF-to-CF communication.
One way to bypass these limitation is to make the Crazyflies completely autonomous and to monitor there state using a USB-connected Crazyflie that monitors the P2P communication and prints on the console useful info. This is quite inconvenient to work with though.
One possible hack that is working is to make the lib much less agressive in regards to communication. This will leave enough air-time to the Crazyflie to communicate with each-other but it will also reduce a lot the available bandwidth from Crazyradio to the Crazyflies. This can be done by increasing the variable "wait_time" in the radio driver in the lib: https://github.com/bitcraze/crazyflie-l ... #L640-L642. This is the time, in seconds, the lib will wait between 2 packets, setting both to 0.01 will make the lib wait 10ms between each packets. The higher this number, the more P2P will be reliable, but the less bandwidth you will have to communicate with the Crazyflies. You can experiment to find a good spot for your experiments.
Using 2 Crazyradio will not help as you need to have all your Crazyflies on the same channel for P2P to work, so you can only use one radio.
One way to bypass these limitation is to make the Crazyflies completely autonomous and to monitor there state using a USB-connected Crazyflie that monitors the P2P communication and prints on the console useful info. This is quite inconvenient to work with though.
One possible hack that is working is to make the lib much less agressive in regards to communication. This will leave enough air-time to the Crazyflie to communicate with each-other but it will also reduce a lot the available bandwidth from Crazyradio to the Crazyflies. This can be done by increasing the variable "wait_time" in the radio driver in the lib: https://github.com/bitcraze/crazyflie-l ... #L640-L642. This is the time, in seconds, the lib will wait between 2 packets, setting both to 0.01 will make the lib wait 10ms between each packets. The higher this number, the more P2P will be reliable, but the less bandwidth you will have to communicate with the Crazyflies. You can experiment to find a good spot for your experiments.
Using 2 Crazyradio will not help as you need to have all your Crazyflies on the same channel for P2P to work, so you can only use one radio.