CF communication is broken when I use a lot of goTo statements.

[imrd1123]

Hi @whoenig @jpreiss

I am trying to control a CF using the goTo statement of the Crazyswarm Python API.
The CF is equipped with an LED-Deck to check the communication status.
The CF has an LED-Deck attached to it to check the communication status.
When we run the program and the goTo statement is executed about 8 times, the LED-Deck light on the CF turns red and flies away slowly.
This problem occurs no matter how many times I run the program.

What are the causes of these communication missing?
What is the cause of these communication missing, and how can I control them so that they do not occur?

P.S.
I read this discussion #406, and I wonder if it is not good to use too many goTo statements, and if it is better to control by trajectory.

[whoenig]

I think the problem might be unicast vs. broadcast communication. At which rate do you issue goTo commands and how many Crazyflies are you controlling? There are two solutions:

1. Use cmd_pos rather than goTo.
2. Use the broadcast version of goTo. If you have multiple Crazyflies (less than 8), you can use the groupMask to limit the commands to individual Crazyflies.

The current behavior should be improved once we switched to crazyflie-link-cpp as the backend.

[imrd1123]

Thank you for your answer.

I understand "High-level communication" causes the lack of packets.
So, it maybe better to use "streaming control mode".
I already use the the broadcast version goTo method.
I was able to move a cf by 8 of goTo method, but at the 9th of goTo method,
and the message below emerged.

From the above, I think that the maximum number of RAM trajectory uploads may have been reached. In crazyswarm, is there a command to release the trajectory storage area(RAM)?

[whoenig]

GoTo is executed onboard - there is no trajectory being uploaded.

The messages you are seeing indicate that the tracking is not perfect. These warnings can be ignored, however, if they only occur sporadically. The on-board state estimator can handle short outages well. From your initial description, there should be many more warnings reported at the time when the CF flies away?