When cf is hovering, there is a problem of turning around

[swarm5]

Recently, I used the single-point tracking mode to realize the function of a single crazyradio PA to control the hover and execute trajectory of 8 aircraft.
However, the overall flight effect is not very stable, and there are several problems:

1. When I hover multiple cfs, sometimes several cfs (a small part, 1~3) will turn around the hovering point, and the circle will turn bigger and bigger until it rolls over . I guess this problem is related to filtering, I am using Kalman filtering. I would like to ask, how can I solve this problem?
2. When I let the cfs fly according to the trajectory, sometimes there are some (3~6) cfs, which do not execute the corresponding trajectory, they just hover in the air. I guess this problem is related to crazyradio PA, maybe the trajectory was not successfully uploaded to the corresponding cfs. The farthest distance between crazyradio PA and cfs is about 5~6 meters. Is it because they are too far apart? I would like to ask, is there a way to increase the transmit power of the crazyradio PA, such as changing to a better antenna or modifying its firmware?

Now, the entire system can achieve most of the functional effects, but it still lacks stability, because it often circles or does not execute trajectories when hovering. What should I do to achieve more stable flight of cfs?

[whoenig]

1. Which tracking mode are you using? Usually this means that the mocap system has lost tracking and the CFs operate with the on-board sensors alone. I found that single-marker tracking and a fairly large marker on top of each CF can improve the situation for mocaps with "bad" coverage. In terms of debugging, a uSD deck is very helpful. Then you could log the onboard state estimate or the mocap data and find out why crashed CFs misbehaved. If you don't have uSD decks, you can log the rostopics during the flight and check if the tracking was correct.

2. First, check your connection quality with rosrun crazyflie_tools comCheck. If the data there is fine, you probably use a good channel and just run into some lost packets that are related to recent communication issues we are investigating with Bitcraze. A good hotfix for now is to add for-loops around the commands, e.g., https://github.com/USC-ACTLab/crazyswarm/blob/master/ros_ws/src/crazyswarm/src/crazyswarm_server.cpp#L395 could add a for-loop that repeats the command multiple times with short sleep's in between, similar to https://github.com/USC-ACTLab/crazyswarm/blob/master/ros_ws/src/crazyswarm/src/crazyswarm_server.cpp#L1817-L1822. The Crazyradio PA already has a power amplifier enabled by default - the issues you are seeing are likely pure SW issues that were created with recent firmware changes.

[swarm5]

First of all, thank you for your suggestions. Your answer has given me a lot of new ideas. Do I have enough uSD card sockets? I will carry out experimental tests as soon as possible.
I have one more question and I hope to confirm with you:

1. Regarding the first question, I am using the defaultSingleMarker mode. cf appears to circle around the hovering point. Obviously, the accurate optitrack positioning data information is not successfully received by cf. I suspect there are two reasons: the first, as you said, maybe that the mark points are too small. Second, I suspect that it is the communication firmware problem, which caused the loss of optitrack positioning data? ?
2. Regarding the second question, I have used rosrun crazyflie_tools comCheck, and the data looks good. I think there must be a problem with the firmware. First of all, I will follow your suggestions and use for to make corrections. However, I still have another idea to try. Can I git clone other branches and use the previous firmware to compare and verify the problem? Do you have any other stable branches recommended (I'm just for testing)?
3. The rostopic record data you mentioned refers to genericLogTopic_log1_Variables: ["stateEstimate.x", "ctrltarget.x"]? ? I would like to ask, what is the physical meaning of "stateEstimate.x"? the optitrack system estimates the position of cf in the x direction? Is it the location data before sending to cf?
   I have recorded this variable before, and it seems that there is no big problem. I suspect it is a problem during the transmission of crazyradio PA.

[whoenig]

1. I think you already verified that there is no problem with that by looking at the logging variables (see 3.)
2. You can test with the firmware that comes with the Crazyswarm which we did test. In general, the latest master version should work. However, please don't forget to update also the NRF51 firmware (and the Crazyradio firmware).
3. stateEstimate.{x,y,z} is the estimate from the EKF. That fuses the onboard IMU with the external absolute data from optitrack. There is another logging variable for the raw mocap data, but it will only report the correct data if you only have a single CF.

[swarm5]

Recently, I discovered that this phenomenon seems to be related to the hardware itself. However, I am currently not sure if it is related to the sensor or the motor or propeller. If I find something later, I will update it below.