Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Add functionality to allow the STM32 to send/receive P2P radio packets #29
One common request for the Crazyflie lately has been to be able to have Crazyflies communicating directly with each-other (P2P). This functionality has not been implemeted yet for two main reason: the Crazyflie communication protocol is optimized to have as low latency as possible with one host and to do so it is organized as a star network around the host, also there is no generic use-case for P2P communication, each use case requires very different communication scheme.
So to get started we could implement a simple low level way for the STM32 to send and receive P2P radio packets that could run in independently from the existing CRTP link.
The proposed solution is to create functionalities and Syslink packets for:
In this mode the ack packet payload would always be empty (unlike CRTP that uses the ack packet payload as downlink). The TX/RX channel and device address is common with CRTP.
On the radio, this is implemented by prepending the packet with [0x3f, 0x8x] with x being the P2P port number. In P2P this decodes as a NULL packet, the nRF firmware will recognize the pattern and send the packet to the STM32 as a P2P packet. By keeping the current radio packet unchanged, the payload size can be increased to 63 bytes. This meas that Crazyflie to Crazyflie P2P communication packets can have a payload of up to 61 bytes (63 - 2). Crazyradio to Crazyflie will have a payload up to 30 bytes.
A ticket needs to be created in the bitcraze/crazyflie-firmware repos to implement the STM32 API side.
I think this would allow to implement commonly requested schemes like exchanging sensor values between Crazyflie or event some relaying of information or simple mesh network. Though the implementation of a specific use-case is out of scope, it will require custom code on the STM32 side.
Edited description to remove the use of specific radio addresses for P2P communication and add a CRTP header instead to send and receive P2P packets using the existing CRTP unicast and broadcast address.
This has the drawback of reducing the useful payload by 2 bytes. However it makes implementation and documentation much simpler: if we where to use new addresses for P2P there would be rules about what address can be used and there would anyway be a link between P2P and CRTP addresses, this is due to the way the address matching is implemented in the nRF51 radio. Having the same radio address for CRTP and P2P simplifies things: one Crazyflie, one address.
To stay compatible with Crazyradio PA (nRF24LU1), the radio packet has a size field of 6 bits, which allows to encode a packet size of up to 63 bytes in the air when communicating Crazyflie to Crazyflie (Crazyradio PA is still limited to 32 Bytes packets). The nRF51 is capable of handling payload of up to 254 Bytes, though this would make the Crazyflie incapable of communicating with Crazyradio PA.