Bitcraze Forums

Posted: **Tue Aug 25, 2020 4:56 am**

This is a new issue from the last post in the following link
viewtopic.php?f=5&t=4416

During p2p communication, the message was interrupted when connecting to the client.

Code: Select all

---
SYS: Crazyflie 2.1 is up and running!
SYS: Build 59:f7b0222a3a17 (2020.06 +59) CLEAN
SYS: I am 0x20393743484850170035003F and I have 1024KB of flash!
CFGBLK: v1, verification [OK]
DECK_CORE: 0 deck(s) found
IMU: BMI088 Gyro I2C connection [OK].
IMU: BMI088 Accel I2C connection [OK]
IMU: BMP388 I2C connection [OK]
ESTIMATOR: Using Complementary (1) estimator
CONTROLLER: Using PID (1) controller
MTR-DRV: Using brushed motor driver
EEPROM: I2C connection [OK].
IMU: BMI088 gyro self-test [OK]
STAB: Wait for sensor calibration...
SYS: Free heap: 13224 bytes
Waiting for activation ...
[RSSI: -35 dBm] Message from CSTAB: Ready to fly.
[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C
...

I thought this problem was caused by multiple calls to callback, so a new callback function message was printed before the string was processed.
But you said the problem was due to a lot of radio work, so where should I modify the radio communication call cycle to solve this?

Posted: **Wed Aug 26, 2020 8:11 am**

The main problem is indeed that there is a conflict between the P2P communication and the communication to the PC. This is a fundamental limitation with the current implementation and the real fix would be to have the PC part of the P2P network, in your case the easiest way to achieve that is to conect one Crazyflie via USB and use it as a gateway. I updated the P2P example documentation to reflect this. Eventually, the Crazyradio should be able to receive and send P2P messages. This should already be possible using PRX mode of the latest firmware but I have never used it. In that case though you would not be able to use the client, you would have to implement a P2P node on the PC.

Now, as I said in the other thread, there might be ways to help a bit, you will still loose a lot of P2P packets but it might not be completely blocked.

I did this change to the crazyflie-lib-python project. This does greatly slows down the communication, but it allows the P2P communication to work with less packet loss:

Code: Select all

diff --git a/cflib/crtp/radiodriver.py b/cflib/crtp/radiodriver.py
index 16a2c97..d5bac05 100644
--- a/cflib/crtp/radiodriver.py
+++ b/cflib/crtp/radiodriver.py
@@ -525,9 +525,9 @@ class _RadioDriverThread(threading.Thread):
                 if (emptyCtr > 10):
                     emptyCtr = 10
                     # Relaxation time if the last 10 packet where empty
-                    waitTime = 0.01
+                    waitTime = 0.02
                 else:
-                    waitTime = 0
+                    waitTime = 0.02
 
             # get the next packet to send of relaxation (wait 10ms)
             outPacket = None

I am checking the console problem to understand why we get incomplete line in the console.

Posted: **Wed Aug 26, 2020 9:01 am**

FYI, I just pushed a fix for the printing problem, it was a buffer overflow when printing the message on the console. The printout is now as expected.

Bitcraze Forums

Delay in radio communication with client

Delay in radio communication with client

Re: Delay in radio communication with client

Re: Delay in radio communication with client