Delays with many connections on one radio #118
Comments
ataffanel
added a commit
that referenced
this issue
Sep 30, 2020
This commit implements a queue based radio sharing instead of the previously implemented mutex-based sharing of the radio. This should guarantee that the radio is shared fairly between connections using the same radio. Mutex could not offer this guarantee since Mutex implementation in python uses the underlying OS implementation that does not nececarly guarantee that the thread waiting are unlocked in order.
|
The commit 1a5de7f should solve this issue. It has currently only been tested on connecting the 9 Crazyflies of the ICRA demo, not during operation. When connecting, it does seem to treat all connection fairly and all Crazyflies gets connected at the same time even if the full TOCs had to be fetched (it takes a lot of time to connect but it connects) Lets close this ticket if we manage to run the demo with a single Crazyradio. |
ataffanel
added a commit
that referenced
this issue
Oct 1, 2020
ataffanel
added a commit
that referenced
this issue
Oct 6, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the ICRA demo we experience latency in out going packets when connecting more than 5 Crazyflies to one Crazyradio. When adding a second radio and moving 4 of the copter to it, the latency disappeared.
The new radio used the same frequency (not recommended) so the number of useful packets in the air was probably reduced due to collisions, but performance was still better. The prime suspect for this problem is threading in python but more investigations are required.
The text was updated successfully, but these errors were encountered: