Page 1 of 1

PC-Communication vs p2p

Posted: Thu Dec 17, 2020 1:05 pm
by sAz
Hi everybody,

I was experimenting p2p communication and drone-pc communication for a while. I was trying to find out why pc-drone communication causes high p2p-packet loss.

I also tried to understand if p2p communication can disturb pc-drone communication.

For that I have written the following function:

Code: Select all

void sendPacket()
	for(int u = 0; u <10;u++)

By that I try to achieve a higher p2p packet rate.
What happens is that the drones receive all p2p-packets, but when I try to give instructions from the pc, the drones don't react.

I looked at the functions in radiolink.c, especially radiolinkSyslinkDispatch(SyslinkPacket *slp) to try to understand this behaviour but I couldn't find an answer.

Is there an explanation for this behaviour in the documentation?

Re: PC-Communication vs p2p

Posted: Thu Dec 17, 2020 1:34 pm
by kimberly

If you are sending a lot of peer 2 peer packets so quickly after one another, you will block the CRTP packets from the computer. Have you tried adding some kind of wait function in the loop like in here?

If you use p2p, this will cause a lower quality communication with the computer by default though.

Re: PC-Communication vs p2p

Posted: Fri Dec 18, 2020 1:45 pm
by sAz
Ok I see. So p2p packets are competing with pc-packets (if I am not wrong). That means that one communication type blocks the other right?

If one communication type blocks the other, than how is it possible to use p2p and pc-communication at the same time? Is there some prioritization?

Yes I tried the example you have mentioned, but when I use a wait function I lose too many p2p packets (I use a radio dongle at the same time). This is why I tried to increase the p2p packet rate.

To be clear, I can use pc-communication and I can use p2p too. I am just trying to understand why there is a trade off between the two communication types.

Re: PC-Communication vs p2p

Posted: Mon Dec 21, 2020 10:36 am
by arnaud
The current P2P implementation is very simple and does not implement any prioriatization of any kind: When you send a P2P packet, the radio is taken and the packet is sent without any check for what the radio is currently doing. So if you send a lot of packet in a tight loop you are effectively using the radio all the time and not letting any time for Crazyradio.

On the other side, when communicating with Crazyradio, the Crazyflie is never sending packet by itself but only answering packets from the Crazyradio. So Crazyradio has to poll the Crazyflie by sending packets are regular interval to get data from the Crazyflie. By default this polling loop is very tight, so the Crazyradio is going to use most of the air-time and will not let you much to communicate with P2P packets.

So, as of the current state, both systems will have a hard time working reliably together. One easy thing you can try is to relax the polling time when communicating with Crazyradio, for example by setting waitTime to 0.01 or 0.005 in the communication loop in the lib: ... This will greatly limit the available downstream bandwidth, but it will give more air-time to the P2P packets.

There has been talk about being less 'brutal' with sending P2P packet, and only sending the packet if a communication is not currently in progress with a random back-off wait to avoid mass-collision. I am waiting for a PR on that but I am not sure what the progress it. Together with relaxed Crazyradio polling timing this would greatly help.