Broadcasting implementation details

[NageshEranki]

Hi!

Thanks for sharing this awesome project! I am looking around for solutions to control multiple crazy flies and Crazyswarm2 seems like an excellent option since it is also enables software-in-the-loop testing (another requirement for my project). I am interested in learning more about how broadcasting is implemented since this will influence future design choices.

For example, one risk with broadcasting is the problem of packet collision when the Crazyflies attempt to send back log data. I'm curious if/how Crazyswarm2 addresses issue.

I am a newcomer to the ROS ecosystem (sorry!) and so it is difficult to navigate through the source code. Any help is appreciated!

Thanks is advance!

[whoenig]

Hi, broadcasts are only used with the cpp-backend for sending messages that all robots need to receive, including: motion capture data, commands to takeoff/land/start trajectory. Logging is still possible, but uses unicast communication.

ROS is just the highest layer. On the low-level side, we developed and use crazyflie-link-cpp, which takes care of the radio messages. There is essentially one queue per radio of packets, and packets can be either unicast or broadcast.

Broadcasts are automatically repeated (by default 15 times, every 2ms, but this is configurable), to get the probability of a lost packet close to zero. Unicast packets use a mechanism called "safelink" that in theory guarantees that packets are repeated until they are received (although we do see in some cases for large swarm that this "guarantee" seems to be violated).