Bitcraze Forums

Hello all,

I am trying to make it possible for two crazyflie drones to communicate with each other directly. To do this, I thought it would be possible to call radioLinkSetChannel, radioLinkSetAddress, and radioLinkSetDatarate to that of the other crazyflie. Then, I would be able to treat the drone as if it were a computer with radio dongle communicating with another drone. However, when the drone calls these functions, it gives an error (SYS: No assert information found) and resets (Spins all 4 motors and does the melody). Does anyone know why this is the case, or if I am on the right track to drone to drone communication?

Thanks in advance

This is currently not implemented in the firmware and requires some deeper changes in both NRF and STM firmwares. Basically, currently the Crazyflie is always receiving data, and the Crazyradio is always sending data (the Crazyflie can respond by attaching some payload to the Acknowledgements). For drone-to-drone communication, you'll need to look into implementing the PTX mode on the firmware side as well.

whoenig wrote: ↑Mon Jul 23, 2018 10:23 pm This is currently not implemented in the firmware and requires some deeper changes in both NRF and STM firmwares. Basically, currently the Crazyflie is always receiving data, and the Crazyradio is always sending data (the Crazyflie can respond by attaching some payload to the Acknowledgements). For drone-to-drone communication, you'll need to look into implementing the PTX mode on the firmware side as well.

@whoening

I'm also trying to do something similar where I just hardcode a drone to talk to another and would like some clarification if you can help.

I've looked into the PTX mode at your suggestion, and have come to a few roadblocks. On the crazyflie-firmware, it appears that only eskylink.c and nrf24link.c have the option to set the radioMode to either PRX or PTX within their init, but it appears that radiolink.c is the one which is called. So then within radiolink.c it seems there are two options, try and set PTX mode for the nrf24 within there (and adjust the make file) or try and set PTX mode for the nrf51 on the crazyflie2-nrf-firmware.

Which one of these two would lead to the correct implementation? I understand your hint about NRF firmware changes to imply the second option being the correct one, but I don't quite understand how to set the nrf51 to PTX as the function calls referenced online are unavailable. I've tried looking online all day and don't see a clear answer so any help would be great!

It basically depends on which Crazyflie you are using. Crazyflie 2.0 uses NRF51 and STM32, where the NRF51 handles the communication and power management and the STM32 handles flight control. Both chips communicate over UART (called syslink).
If you work in the Crazyflie 2.0, you'll need to change crazyflie2-nrf-firmware. You might also need to change the syslink, depending on where your decision in which mode you want to be happens.

One good resource is https://github.com/NordicPlayground/nrf51-micro-esb. Of course, you can also see if you could somehow upgrade the SDK in the nrf firmware and use the officially recommended library, instead.

Good luck and keep us posted!

If you work in the Crazyflie 2.0, you'll need to change crazyflie2-nrf-firmware.

I think I'm getting a bit closer to getting it working, but am stuck on understanding the already written RX code in the esb.c file on crazyflie2-nrf-firmware. Based on the NRF51 spec, it appears that setting "NRF_RADIO->TASKS_RXEN = 1U;" in esbInit should start the rampup sequence, and then generate a ready task (what I'm interepreting the RXIDLE state to signify). However I don't see where this is being done, let alone where the ACKs are being sent.

If I understood this, I think I'd be able to change "NRF_RADIO->TASKS_RXEN = 1U;" to "NRF_RADIO->TASKS_TXEN = 1U;" and adjust the RX loop to be transmitting instead of receiving. Correct?

A lot happens in hardware, using interrupts, so take a look at https://github.com/bitcraze/crazyflie2- ... #L352-L355, https://github.com/bitcraze/crazyflie2- ... #L352-L355, https://github.com/bitcraze/crazyflie2- ... #L352-L355, and estInterruptHandler. I am not expert here, so unfortunately I can't provide much more helpful information.

Should those links all be the same? In any case I'll take a look and thanks for the help!

No, certainly not. However, I meant to refer to the same file, but different instances on where the NRF_RADIO->SHORTS are changed.