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
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 |
ataffanel
left a comment
ataffanel
left a comment
There was a problem hiding this comment.
Great changes!
One last comment about documentation. It does not need to be extensive but just enough to allow someone to implement the other side of this driver.
| Scanning feature assumes a crazyflie server is running on port 19850-19859 | ||
| that will respond to a null CRTP packet with a valid CRTP packet. | ||
|
|
||
| v2.0 changelog: |
There was a problem hiding this comment.
This paragraph will end up in the documentation so rather than doing a changelog I think we should document the functionality, I am thinking of at least:
- Wire protocol (ie. packet format, one packet per UDP datagram)
- Scan behavior in respect to UDP port and SCAN_ADDRESS
This together with the above paragraph will allow for anyone seeing it to re-implement the other side.
2 participants
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.