Why does takeoff() take off better than cmdposition()?

[ucaszzw]

@whoenig Hi, I am using a pa to control 20 'cf's to test (when I use multiple PAs, it sometimes causes cfs to crash).
I'm using the cmdposition() command throughout because I find that the takeoff( ) and cmdposition() commands create errors when bridging.

I found a problem: when I use cmdposition() to control the cf to take off, sometimes ~10% probability, three or four cfs out of 20 drones don't take off and stay on the ground without moving. And when I use takeoff() for takeoff, every cf can take off.

I am not sure the reason why takeoff succeeds every time? I noticed in reading the code that each takeoff() instruction is actually repeated 15 times. I would like to ask for the following questions.
Why is each takeoff() instruction repeated 15 times? Is it to overcome the loss of communication? In which part of the process does the loss of control instructions usually occur?
2. Does takeoff() take off better than cmdposition() because t repeats 15 times

[ucaszzw]

[whoenig]

1. Takeoff (landing, goTo, and most other high-level commands) use broadcast commands without any feedback / acknowledgement. Thus, it is possible that one or more drones simply don't receive the command. We have no way of detecting this key (since there is no feedback), so we reduce the probability of this happening to close to 0 by repeating many times. In contrast, cmd_position uses unicast commands and should at receive an acknowledgement on the PC side. The PC will automatically re-send the command until an acknowledgement is received.
2. I am actually surprised you can control that many drones with a single radio using unicast commands. For unicast, we only recommend using 4 CFs/radio, since the bandwidth requirements are significantly higher compared to broadcasts.

[jpreiss]

Really, cmd_position is reliable? Since it's a streaming setpoint the controller should be sending fresh cmd_position at a high rate anyway. Seems more bandwidth-efficient to be UDP-like and rely on that contract.

[whoenig]

Unfortunately, in Crazyswarm1 it's using unicast and checks for acks. Even the official cflib does it that way, but I agree that it should actually be a non-ack unicast instead (In Crazyswarm2 we have a prototype for that, but hard to tell if it makes any difference).

[jpreiss]

OK, even if non-ack doesn't help much with bandwidth I feel like it's a good choice for clarifying design intent of streaming commands. A user reading code/docs might be confused to learn that cmd_position is reliable.