A request for upcoming versions of Reachview.
Can you add the option for UDP output (in addition to TCP)?
When using the reach for active guidance, UDP is a better fit. It allows the latest message to get through and if you loose a message, it’s best to just move on vs TCP working to make sure it goes through. Should just be a simple option to select TCP or UPD output method and then the code / script behind to choose UDP or TCP. Thanks!
Hi John,
Thanks for the suggestion!
We are not planning to add UDP connection.
UDP is mostly used for big permanent streams, but Reach outputs small amount of data several times per second. If your network is not stable, a TCP package can be delayed, while UDP will just be lost.
Hi Tatiana, I would also like to request UDP as an output option. I am the author of AgOpenGPS which is an open source Agricultural application that does many facets of Precision Agriculture. It provides various pattern forms guidance for steering, machine application control, automatic headland turns, mapping, google earth and physical methods for multiple boundaries and more.
The other part includes fully autonomous tractor operation and machine control. All the systems and modules communicate with UDP since we really don’t care about previous data, but require immediate data in a stream. Loss of packets is of no consequence whatsoever. TCP however, should it get dropped which may happen often in a large noisy dirty environment or very large machinery and is difficult to immediately reconnect, UDP solves that issue. An autonomous vehicle needs a continuous stream of data AND the ability to reconnect right away each and every time.
All modules utilize UDP communication including steering and valve control, section control, machine driving control, LIDAR module,s electro-hydraulic modules etc and receive the udp broadcast much the same way CanBus functions. UDP is critical for the operation, and has proven very reliable. TCP has proven troublesome.
Many farmers all over the world are using AgOpenGPS and the Reach is an excellent product to recommend, but unfortunately if it doesn’t output udp, it is of limited value in a huge area of application, Precision Agriculture. Please reconsider the addition of UDP being available for the sending of the NMEA sentences.
Brian Tischler
https://www.thecombineforum.com/forums/31-technology/278810-agopengps.html#post3303445
Hi Tatiana
I would like to second John & Brians requests for UDP. I am a user of Brians AgOpenGPS application and am currently looking for RTK gps recievers, unfortunately your response to John seems to preclude Emlid from our use, pity, as otherwise it seems a good product.
Andrew
So is that a no? Hello?
From an engineer’s standpoint, the advice would be to fix your network to allow TCP to work properly. But in the real world, we can understand that it might be better to just jiggle the wires until a minimal amount of UDP data is coming through and the job can get finished (and then fix the network later, right? Right.
)
Programs that employ UDP sacrifice complete data integrity in exchange for speed.1
So, from your explanation above, it is easy to understand how UDP can provide a real-time connectionless data stream. What is missing is the convincing argument that shows why sacrificing the data integrity of TCP is a sane decision.
Is there an additional level of data integrity checks being added into the UDP data in e.g. machine driving control? If so, that needs to be discussed as well to help the argument.
Or is having timestamp and checksum in the NMEA protocol simply all the data integrity that is required?
Hi @farmerBrianTee, @apm,
Sorry for the delayed response and thank you for bringing it to our attention!
We will consider adding UDP output in the future.
At the moment, you can use TCP. We believe that it should be sufficient.
Please let us know if you find any performance issues when using TCP streamed data from Reach.
There is no data integrity required. Only a current real time stream of data. For this, udp is ideal especially on an extremely quiet network dedicated to this application and its modules.
Many tests have been done on the feasibility of udp in robotics. 100 million packets, non dropped, or out of order
is sufficient integrity. UDP for Robot Control
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.
