Broadcasting with Crazyflie
Posted: Mon May 04, 2020 5:22 pm
Hello everyone,
we are currently trying to implement a Broadcasting function within the Crazyflie 2.0 / the nrf51822. What we are looking for is a discussion/similarities/differences between the p2p API of bitcraze and our approach - maybe avoiding some issues/problems we are not seeing yet. In addition, we would like to get a modified version with stays compliant with the bitcraze framework.
Maybe it is not an issue for the forum but better suited for a "four eye discussion", so feel free to suggest a separate discussion
Our requirements are:
- CF should be able to broadcast by sending one message which can be received in several Crazyflies
- Approach should be flexible to handle new CFs entering the agent team members (although having a unique ID) and also handle CFs leaving the agent team
- Guaranteed package delivery may be sacrificed, algorithms working on the broadcasted data have to take potential loss of data into account. Any data which is of special importance should demand some sort of acknowledgement from the receivers but only if acknowledge is demanded by sender
- However, having a lot of CFs in broadcast mode, the chance of package collisions should be reduced applying some sort of medium access control at best with priorities of messages
- At best: some parts of the existing bitcraze functions can coexist (e.g. setting parameters)
- At best: Crazyradio PA can be used to monitor inter CF communication and for sending operator/Mission data to the agents, but in our view, Crazyradio PA is hardware limited to ESB, so that might be impossible.
p2p App (as far as we understood):
Actually, we tested with the p2p-app in October 2019 (transmitting data successfully between two CFs) but we came to the conclusion, that it does not fit to these requirements in the sense that there is only a peer-to-peer connection in between pairs of crazyflies which is due to the current way of adressing receivers. But maybe we missed something.
On the other hand, even with a broadcasting ability where one CF can send a message to all CFs in range, a message collision avoidance strategy needs to be applied. At least implementing CSMA/CA is not trivial with the nrf51822 as discussed in https://devzone.nordicsemi.com/f/nordic ... or-csma-ca
Our approach that we want to discuss, at best we will find out that it is compliant with the p2p App:
- CFs broadcasting simultaneously can cause message collisions which might be undetected, so in order to limit the chance of package collisions, we try to implement a CSMA/CA like approach based on interrupts available on the nrf51822.
- all CF's nrf51822 are in receive status by default, listening to the same adress. If one tries to send a package the respective nrf51822 will check whether there is traffic evaluating the interrupt due to reception of an message. So, if the ADRESS interrupt has been received but not yet followed by an END-Interrupt, the respecting CF will withdraw, stay in receive mode and a random delay-timer is started (which can also incorporate priorities of messages by setting the random interval), after this time has been past, a next try to send is initiated. Due to this approach, we can only send single packages of size 253 Bytes, longer data has to be handled separately within some sort of "message manager"
- However, our approach is not compliant with the Crazyflie Radio PA and the hardware-implemented ESB protocoll and due to limited capabilities of the nrf51822 the existing code had to be deleted to free space for the required functions. Of course, we have to send some sort of control/Operator commands to the swarm (and receive the CF signals for debugging during developement/monitoring), which might be done, using a nrf51-DK Developerboard
One of our team members is working on this issue for some time now and our expert on this topic, so I am kind of the door-opener. He will monitor this forum and he can answer questions more precisely than I can and we both are available for discussions and really grateful for any advices.
we are currently trying to implement a Broadcasting function within the Crazyflie 2.0 / the nrf51822. What we are looking for is a discussion/similarities/differences between the p2p API of bitcraze and our approach - maybe avoiding some issues/problems we are not seeing yet. In addition, we would like to get a modified version with stays compliant with the bitcraze framework.
Maybe it is not an issue for the forum but better suited for a "four eye discussion", so feel free to suggest a separate discussion
Our requirements are:
- CF should be able to broadcast by sending one message which can be received in several Crazyflies
- Approach should be flexible to handle new CFs entering the agent team members (although having a unique ID) and also handle CFs leaving the agent team
- Guaranteed package delivery may be sacrificed, algorithms working on the broadcasted data have to take potential loss of data into account. Any data which is of special importance should demand some sort of acknowledgement from the receivers but only if acknowledge is demanded by sender
- However, having a lot of CFs in broadcast mode, the chance of package collisions should be reduced applying some sort of medium access control at best with priorities of messages
- At best: some parts of the existing bitcraze functions can coexist (e.g. setting parameters)
- At best: Crazyradio PA can be used to monitor inter CF communication and for sending operator/Mission data to the agents, but in our view, Crazyradio PA is hardware limited to ESB, so that might be impossible.
p2p App (as far as we understood):
Actually, we tested with the p2p-app in October 2019 (transmitting data successfully between two CFs) but we came to the conclusion, that it does not fit to these requirements in the sense that there is only a peer-to-peer connection in between pairs of crazyflies which is due to the current way of adressing receivers. But maybe we missed something.
On the other hand, even with a broadcasting ability where one CF can send a message to all CFs in range, a message collision avoidance strategy needs to be applied. At least implementing CSMA/CA is not trivial with the nrf51822 as discussed in https://devzone.nordicsemi.com/f/nordic ... or-csma-ca
Our approach that we want to discuss, at best we will find out that it is compliant with the p2p App:
- CFs broadcasting simultaneously can cause message collisions which might be undetected, so in order to limit the chance of package collisions, we try to implement a CSMA/CA like approach based on interrupts available on the nrf51822.
- all CF's nrf51822 are in receive status by default, listening to the same adress. If one tries to send a package the respective nrf51822 will check whether there is traffic evaluating the interrupt due to reception of an message. So, if the ADRESS interrupt has been received but not yet followed by an END-Interrupt, the respecting CF will withdraw, stay in receive mode and a random delay-timer is started (which can also incorporate priorities of messages by setting the random interval), after this time has been past, a next try to send is initiated. Due to this approach, we can only send single packages of size 253 Bytes, longer data has to be handled separately within some sort of "message manager"
- However, our approach is not compliant with the Crazyflie Radio PA and the hardware-implemented ESB protocoll and due to limited capabilities of the nrf51822 the existing code had to be deleted to free space for the required functions. Of course, we have to send some sort of control/Operator commands to the swarm (and receive the CF signals for debugging during developement/monitoring), which might be done, using a nrf51-DK Developerboard
One of our team members is working on this issue for some time now and our expert on this topic, so I am kind of the door-opener. He will monitor this forum and he can answer questions more precisely than I can and we both are available for discussions and really grateful for any advices.