Broadcasting with Crazyflie

Firmware/software/electronics/mechanics
Post Reply
keffi
Beginner
Posts: 18
Joined: Mon Feb 25, 2019 10:35 pm

Broadcasting with Crazyflie

Post by keffi »

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.
kimberly
Bitcraze
Posts: 1050
Joined: Fri Jul 06, 2018 11:13 am

Re: Broadcasting with Crazyflie

Post by kimberly »

Hi!

Just to respond on the p2p app.
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 addressing receivers. But maybe we missed something.
Currently the only way to do p2p communication as implemented on the cf-firmware is only broadcast. The crazyflie to crazyflie (with an unique address) functionality has not been implemented yet. All crazyflies on the same channel will receive the same packet if one crazyflie sends with:
radiolinkSendP2PPacketBroadcast(&pk);
It will send it to an broadcast address which all CFs can receive.
The procedure is explained here and this was at the time tested with the comunication test rig, so we are pretty sure that this is only sending broadcast messages. It also been used for the applayer variant of this work, which deals with only broadcast messages. The tickets that implemented this and hold the discusion can be found here for the STM side and the NRF side. If this does not seem to not work as I explain it, then you would need to make an issue on the github.
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
It is indeed true that there is no message collision avoidance strategy in the p2p API. Clock syncing would be very important in this case, but maybe until a certain quantity of Crazyflies, a send frequency that is just slightly off with the rest might be enough. I would say that after 6 crazyflies, this can already start to become a problem, but I haven't tested it througly. A round robin approach might also be an option.

But it would be nice to have a more sophisticated implementation of the p2p application, as the one that we implemented was more bear bone and just opening the possibility. So very happy that you guys are digging into this as well, so let's discuss on how to make it better:) Maybe we can start some issues on the github repos about each feature specifically.
Christos Z.
Beginner
Posts: 1
Joined: Sat Apr 18, 2020 6:46 pm

Re: Broadcasting with Crazyflie

Post by Christos Z. »

Hallo everyone,

i am working with Mr. Keffi on this issue and currently trying to implement our approach on the nRF51822-Chip. I would like to give you a little bit more light on how we are planning to implement the mentioned by Mr. Keffi broadcasting protocol.

But first i would like to thank you Kimberly for you fast response and the very interesting works that you mentioned, especially the Enabling Swarm Exploration, which is for us really relevant. I am going to take a better look, at their approach, as they also published their code.

First of all I would like to mention my setup (Toolchain) and the hardware that i use.
  • i work with Eclipse under Windows 10, where I set a custom ARM-Toolchain (arm-none-eabi-gcc, GDB, OpenOCD and SEGGER-Debugger)
  • a bunch of Crazyflies 2.0
  • for debugging of the nRF-DK Board i use the integrated J-Ling SEGGER Debugger with GDB, and as Debug console i use the RTT
An issue that i have right now with my setup is, that i also tried to build the Crazyflie-nRF-Firmware with SEGGER RTT, but it would not built because of RAM error. I assume that there is not enough space in the nRF-Chip. Nevertheless i would like to know if you guys use the SEGGER RTT Debugging console, and if yes how do you do it? Which debug devices are you using?

The grob description of what we are trying to do is already mentioned by Mr. Keffi, so to not repeat it all i am going to dive in of what i have done until now and why i did it, maybe you could give some extra tips:
  • I removed some of the existing code, because i noticed that there would not be enough space in the RAM for our broadcasting protocol. The things that i removed for now is all the BLE stuff and i am planning to remove also the current implementation of ESB in the nRF-Chip
  • I reconfigured the RADIO peripheral of the nRF-Chip. I done this for two reasons, one to just make myself a little bit more known with chip and secondly because we want to increase the maximum payload size of a packet to the one that is limited from the hardware, which is 254 Bytes. Before, the RADIO was configured so that it was compliant with nRF24LU+ Chip (ESB-Protocol), which it is used in the Crazyradio PA. Furthermore it is not possible to keep the Crazyflies compliant with the Crazyradio, because of hardware limitation of the the nRF24LU+ Chip, the two chips can only communicate through nRF-proprietary protocols such as Gizell and ESB. https://devzone.nordicsemi.com/f/nordic ... o-nrf24l01.
    Here i have question about the Syslink Protocol (between STM32 and nRF51), is it possible to transfer through syslink packet bigger than
  • i also reconfigured the RADIO interrupt, so we can also generated interrupts from ADDRESS and END events
  • rewrote the send and receive sequences of the RADIO
  • started new project for the nRF51-DK Board, to control and debug the broadcasting network online
Right now I am working on my interrupt routine and the send and receive sequences of the radio packets. I will keep you update as long as i have new results. My plan is to use the ADDRESS event to implement a similar CSMA/CA for message collision avoidance protocol. This should work in the following manner:
  • rump up the Crazyflies always in receive modus
  • if an ADDRESS event is generated, then set a flag that we are currently receiving a packet. This should be done in the RADIO interrupt routine. The ADDRESS event is always generated after the RADIO has received a valid PREAMBLE. Here i have some concerns, because while the RADIO is in PRX-Modus it is always receiving some undefined signals which could correspond to a valid PREAMBLE, and set falsely the receiving flag. I need to investigate this a little bit more, maybe it is possible to configure complex PREAMBLEs, but this should guarantee that we set always the receiving flag correctly
  • after that if the END event has occurred, then we reset the receiving flag, should also happen in the RADIO interrupt routine
  • if in the meanwhile, the Crazyflie should send a broadcast message. It checks first if the receiving flag is set, if not it rumps up in the transmitting mode and broadcast the message. But if the flag is set, then waits for a random time and retries again.
So basically what we are trying to do here is, to check always if there is traffic, before we broadcast any messages, like in the CSMA/CA protocol. I hope this gives you a better idea on how we are going to implement the mentioned broadcast protocol. Further questions, i can happily answer. All the above mentioned points are base on the reference manual of the nRF51822 Chip https://infocenter.nordicsemi.com/index.jsp.

Kimberly, i see that you have had several requests for p2p-Communication and similar networks, for this i have some suggestions. After a lot of research about the nRF-Chips, i saw that Nordic Semiconductor has some new way more capable chips on the market, which would make the implementation of such protocols way easier. For example you could change the Chip of the Crazyradio PA to an nRF51822 Dongle, or maybe go even further and use the nRF52840, which features protocols such IEEE 802.11, BLE Mesh (actually really easy to configure communication networks, as one pleases). Furthermore it is also possible to implement BLE Mesh for nRF51822 Chip, which would make the p2p-API just perfect, as any desired networks could be constructed. For us is unfortunately BLE Mesh not suitable, as we want to keep our network dynamic and BLE Mesh requires some beforehand adjustments.

If you see a point where we could start issues on the github repos, be happy to mention it.

Best regards
Christos
Kaiser1401
Beginner
Posts: 11
Joined: Tue Apr 21, 2020 11:36 am

Re: Broadcasting with Crazyflie

Post by Kaiser1401 »

Just replying to state interest in a communication scenario where messages can be broadcasted (maybe even addressed and routed to drones out of range) in a flexible setup (e.g. drones entering and leaving) with optional message ACK and ideally debugging through the PA.

-another Klaus
kimberly
Bitcraze
Posts: 1050
Joined: Fri Jul 06, 2018 11:13 am

Re: Broadcasting with Crazyflie

Post by kimberly »

About scheduling the communication. Might also be an option to implement STDMA ? My old lab (the MAVlab at tudelft) implemented this on Bluegiga bluetooth dongles (https://link.springer.com/article/10.10 ... 018-9760-3), so it might be possible to implement this also on the NRF side of things.
kimberly
Bitcraze
Posts: 1050
Joined: Fri Jul 06, 2018 11:13 am

Re: Broadcasting with Crazyflie

Post by kimberly »

An issue that i have right now with my setup is, that i also tried to build the Crazyflie-nRF-Firmware with SEGGER RTT, but it would not built because of RAM error. I assume that there is not enough space in the nRF-Chip. Nevertheless i would like to know if you guys use the SEGGER RTT Debugging console, and if yes how do you do it? Which debug devices are you using?
We use the STLink v2 with a debug addapter. Then I use VScode with the openocd GDB in order to debug my program. Works fine so far for me. (I explained the procedure here: viewtopic.php?f=6&t=4267)


Btw. there is some RAM discussion going on on github and the forum. I would suggest to keep an eye on those
Post Reply