No updated pose for CF cf1 for 0.05s

[EnricaSo]

Hello,

I am having an issue when controlling single/multiple crazyflies with single marker tracking with Optitrack, and either Mellinger or PID controller. Occasionally, I can see ore (or more) crazyflie either dropping and crashing or achieving to recover for the next command. It seems to me like the drones lose one packet. What's strange is that this happens also when I use the uploadTrajectory.

I would like to debug this behavior to achieve more reliable and reproducible settings. I started debugging with one drone only. The issue is there from time to time. The occasional WARNINGs I get from the terminal are two:

1. Latency too high
2. No updated pose for CF cf1

First, I tried to set enableLogging: True to record the positions/attitudes of the drones and see if there is anything strange. Then, I set print_latency: True to check the latencies of broadcasting and tracking. I also reduced the camera frame rate of Optirack to 60 Hz. I checked that the markers (15 mm) are well and stably seen (~6-16 pixels in the image) by many (~6) cameras.

I attach here the terminal output.

How could I further proceed to detect the source of the problem?

Many thanks for your help and work!

[whoenig]

What kind of commands are you sending to the CF? Usually the latency to high warning appears if you try to send lots of unicast commands, for example if you try to upload a trajectory while flying. This is currently not supported, since there is no QoS scheduler that re-prioritizes the motion capture packets.

[EnricaSo]

Thank you for your reply!

When I upload a trajectory, I do it in the same way as in figure8_csv.py. First, I upload the trajectories for all drones and then I play them. Is there any check on the integrity of the received trajectory? If so, the problem must be in the tracking, correct?

The other way I usually control the drones is by sending goTo commands to go to the initial positions, and then either cmdPosition or cmdFullState.

[EnricaSo]

Btw, I've seen on another discussion that you're suggesting using the latest radio firmware version. I have the one in the prebuilt folder of crazyswarm. Would you suggest testing the newest?

[EnricaSo]

P.s. Sorry for having opened an issue. I did not notice this Discussion thread before.

[whoenig]

I moved it from an issue to this discussion - no worries.

• The Crazyradio PA firmware should be from the prebuilt folder. The STM32 and NRF51 should be the latest official firmware (e.g., 2021.03 release). There are a few bug fixes in that firmware related to the communication, but I am not sure if what you describe would be caused by that.
• There is no integrity check for the trajectories explicitly, but radio packets do have a checksum (in hardware) that prevents garbage data. Thus, your problem might be caused by something related to the tracking.
• Your way of communicating sounds good. For how long do you get the No updated pose for CF cf1 message, i.e., what is the number it prints for <number> s? In the screenshot above this is at most 0.1s, which should not really be a problem. If there are longer durations of outage, this might cause instability.
• In terms of debugging, my goto method is the uSD card deck (& disabling logging). Do you have such a deck and a matching uSD card? If so, I suggest you record "stateEstimate.{x,y.z}", "ctrltarget.{x,y,z}", and "locSrv.{x,y,z}" and plot the data over time after a crash. This should give an indication if its more a tracking or a control problem, hopefully.

[EnricaSo]

Yes, I have bought some SD decks for this purpose and I'll definitely try some debugging next week.
I'll let you know how it goes and if I come to a conclusion.
Thank you!