Broadcast settings and ad-hoc development

Firmware/software/electronics
Post Reply
rbresnahan
Beginner
Posts: 7
Joined: Mon Oct 14, 2019 5:46 pm

Broadcast settings and ad-hoc development

Post by rbresnahan » Thu Nov 07, 2019 6:04 pm

I am trying to develop and ad-hoc linear network using the Crazyflies and the P2P capabilities and would appreciate some clarification on a few things:

Does the channel of the URI represent the signal frequency? If so, how does one change the devid of a Crazyflie so that a broadcast on one channel can be heard by each drone? (modification of write-eeprom.py perhaps?)

The P2P API mentions to only use Port 0x00 (console). Where should I begin modifying if I wanted to send commander and log type data?

Any and all advice is appreciated!



arnaud
Bitcraze
Posts: 2127
Joined: Tue Feb 06, 2007 12:36 pm

Re: Broadcast settings and ad-hoc development

Post by arnaud » Tue Nov 12, 2019 12:58 pm

The channel in the URI is indeed mapped to the frequency, with channel 0 being 2400MHz and channel 80 2480MHz.

If you have multiple Crazyflie that you want to be able to communicate together, you need to set them all to use the same channel and different address, this way you can connect to any of them independently from the ground. You can configure the Crazyflie channel and address using the connect/configure 2.x menu of the Crazyflie client.

The current implementation of P2P packet is broadcast only: as long as all your Crazyflies are setup to the same channel, they will receive all P2P packets from others. It is left to you to fill these packet with enough information to route the packets. You can get the currently configured unicast address using the configblock module: https://github.com/bitcraze/crazyflie-f ... lock.h#L38.

As for the port, the P2P port is different than CRTP, the content of P2P packets is left completely up to you so you need to construct the packets you need for your use-case. Furthermore most of CRTP has been designed assuming one client to one Crazyflie, most of it is not suited for P2P.

The documentation was a bit misleading concerning the ports so I updated it in the hope of making it a bit clearer: https://github.com/bitcraze/crazyflie-f ... p2p_api.md (it should soon be updated on https://www.bitcraze.io/docs/crazyflie- ... r/p2p_api/).

Ps. This is maybe going a bit far but it might be useful to note that it would be possible to route actual CRTP packer from one client to one target Crazyflie passing though a network implemented on P2P packets, this would allow for a mesh network to be built for example. CRTP is quite modular since it was built to work on both Radio and USB, so you could make your own CRTPLink backed by P2P packet.

rbresnahan
Beginner
Posts: 7
Joined: Mon Oct 14, 2019 5:46 pm

Re: Broadcast settings and ad-hoc development

Post by rbresnahan » Mon Nov 18, 2019 11:40 pm

arnaud wrote:
Tue Nov 12, 2019 12:58 pm
Ps. This is maybe going a bit far but it might be useful to note that it would be possible to route actual CRTP packer from one client to one target Crazyflie passing though a network implemented on P2P packets, this would allow for a mesh network to be built for example. CRTP is quite modular since it was built to work on both Radio and USB, so you could make your own CRTPLink backed by P2P packet.
This is very much along the lines of what I'd like to develop, thank you for the CRTPLink suggestion! For the time being I will attempt to piggyback CRTPPackets within the P2PPackets with a dest_addr and TTL field added for a hacky version of unicast. I may need some further guidance on the P2P setup. My current setup is:

-Two Crazyflies at radio//0/80/2M and addressed at E7E7E7E7E7 and E7E7E7E7E8.
-A new CRTP port called ad_hoc using 0x09.
-Python script that sends a CRTPPacket over port 0x09 and channel 1 or 2 (echo and address respectively).
->Channel 3 is for P2P testing and contains radiolinkSendP2PBroadcast.
-A firmware module called adhoc.c/adhoc.h that handles operation of port 9.
-Call p2pRegisterCB(p2pHandler); within the adhoc init function
-p2pHandler is also in adhoc.c and does nothing more than plays with leds.

Perhaps I am missing a step for the P2P function to activate the handler? The drone with address E8 does not seem to receive traffic at all.
Thank you in advance!

*Edited for clarity

Post Reply