improve udp driver based on other driver receiver thread implementati…#592
improve udp driver based on other driver receiver thread implementati…#592llanesc wants to merge 5 commits intobitcraze:masterfrom
Conversation
ataffanel
left a comment
There was a problem hiding this comment.
Looks great. I have a couple of small comment, the most important being that this changes the protocol so we should make sure it is documented.
|
@ataffanel Do you think I should also add an out_queue? Or is that particular to the radio hardware limitations? I noticed that if the server is lagging because of a slower than real time firmware simulation some packets are lost. This might benefit from the "safe_link" method implemented in the radio. |
…entation with changelogs.
|
For network the out queue might not be required as the network stack will be the queue and will likely be more than fast enough. However if you see packet loss it might be required to switch to TCP instead of UDP. I do not think implementing Safelink over UDP would be very efficient since it requires to implement fast ping pong communication. We have had great success using ZMQ for communicating over network, maybe it would be a better fit for this use-case? |
|
I verified this version works on CrazySim. I spawned 4 crazyflies on 19850-19853 and they all appeared on the cfclient. crazysim-cfclient.mp4 |
Pull request for #590
I have been using this modified udpdriver for CrazySim. The old one was a bit outdated. It basically just includes the receiver thread and has similar features to the other drivers. It also includes a scan feature that scans if a port exists in 19850-19859 for the cfclient.