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 »

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: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: Broadcast settings and ad-hoc development

Post by arnaud »

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 »

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
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: Broadcast settings and ad-hoc development

Post by arnaud »

I am not sure I understand the full story: your python script should send packet to E7 on port 0x09 channel 3 in order for this packet to be broadcasted to P2P.

Registering a callback should be enough to get the packet sent via the send function. I think an easier test to verify that things are working at very low level would be to do:
- Program E7 with a firmware that sends a P2P packet every second as well as blinking an LED.
- Program E8 to blink an LED as soon as a P2P packet is received.

If you get both LEDs to blink at the same time, you have P2P working between the two Crazyflies.

The things I would check if it does not work is that the Crazyflies are flashed with the latest master version of crazyflie2-nrf-firmware with ble disabled ("make clean; make BLE=0; make BLE=0 cload"). You should of course also use the latest master version of the Crazyflie-firmware.
Post Reply