Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add functionality to allow the STM32 to send/receive P2P radio packets #29

Open
ataffanel opened this issue Mar 26, 2019 · 1 comment

Comments

Projects
None yet
1 participant
@ataffanel
Copy link
Member

commented Mar 26, 2019

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:

  • Sending P2P packet to a specific address or broadcast
  • Receiving P2P packet, either unicast or broadcast
  • There is 16 P2P 'port'. Eatch packet, unitcast or broadcast, is sent on one port.
  • Crazyflie <-> Crazyflie payload size up to 63 Bytes, Crazyradio PA <-> Crazyflie payload size up to 30 Bytes.

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.

@ataffanel

This comment has been minimized.

Copy link
Member Author

commented Jun 2, 2019

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.

@ataffanel ataffanel changed the title Add functionality to allow the STM32 to send/receive raw radio packets Add functionality to allow the STM32 to send/receive P2P radio packets Jun 2, 2019

ataffanel pushed a commit that referenced this issue Jun 2, 2019

ataffanel pushed a commit that referenced this issue Jun 7, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.