While running our ICRA demo, we came across a bug in the Crazyflie python-lib radio handling, limiting the number of Crazyflie that could be controlled using one Crazyradio PA. Communication with many Crazyflies is crucial as flying swarms is becoming more of an interesting topic for research and education. So we decided to take the problem at hand and create a radio test-bench:
To make the test-bench we have attached 10 roadrunner boards to a plank of wood together with USB switches that can provide enough power to the roadrunners. We used the roadrunner because it is mechanically easier to use in this context and it has an identical architecture to the Crazyflie 2.1 when it comes to the radio implementation.
Initially we will use the test-bench to run test scripts that pushes the communication to its limits and that consistently test the communication stack functionalities. This should allow us to find bug and verify that we solve them as well as discovering and documenting limitations.
Eventually we want to connect a raspberry-pi to the test-bench and run tests for each commit and pull-request to the crazyflie-firmware, crazyflie2-nrf-firmware and crazyflie-lib-python projects. This will guarantee that we do not introduce new limitations in the communication stack. The test-bench will also be very useful in implementing new functionalities like direct crazyflie-to-crazyflie P2P communication.
As a final note, the Crazyswarm project is not affected by the Crazyflie-lib bug since it is using the C++ implemented crazyflie-ros driver. Hence Crazyswarm can control more Crazyflies per Crazyradio PA, so it is still the preferred way to fly a swarm mostly when using a motion capture system. Though, with the progress made on LPS and Lighthouse positioning, running swarms, using the python API directly is a probably a more lightweight alternative.
Great idea! A few comments:
1.) crazyflie_ros also works with LPS and lighthouse (it does require Ubuntu+ROS, though)
2.) Another interesting radio issue is that some packets seem to get lost between NRF and STM, see https://forum.bitcraze.io/viewtopic.php?f=11&t=3507.
3.) I used the link echo port for a little comCheck tool (https://github.com/whoenig/crazyflie_tools/blob/master/src/comCheck.cpp), which might be helpful. Among other things, this tool can measure the overall roundtrip latency, which on my test systems is surprisingly high (~20ms).
Hi Wolfgang, thanks for the comment and the precision about Crazyswarm!
For 2), I pushed a fix last week that might solve some packet loss (https://github.com/bitcraze/crazyflie-firmware/issues/434).
Thanks for the echo tool, sounds like something we need to look at. I would indeed assume a roundtrip latency of a couple of milliseconds. The results I get are a but funny though: with BLE enabled I get ~11ms and without BLE I get ~31ms. I will investigate a bit more.