This point is particularly important in field robotics, in order to debug sensor data directly on the field.
We had issues with sending lidar data via wi-fi, so we had to make a TCP tunnel package, so that our base station could receive point clouds with TCP.
2 Likes
Maybe the new work on RMW should look at adding a semi-reliable transport protocol. In this case, the data is retried for a few times then gives up so you do not have endless delays on lossy networks. I built one a long time ago using GRE for VPNs so we could encapsulate both TCP and UDP without knowing what the protocol was. This patent has expired by now (https://patents.google.com/patent/US6621799B1/en) There are other semirelaible transport protocols out there as well
Suprised that nobody mentioned ZeroMQ so far. Some extra work is required to implement the discovery mechanism, which in my opinion is the best feature of DDS, making it useful for large distributed self-reconfiguring systems.
OpenCyphal doesnāt think itās too early. Weāve looked deep into 802.1Qbv and have on our roadmap to support this and other parts of the TSN technology family as Cyphal/TSN. Thereās a lot of support in the newest hardware for the most important parts of TSN so itās definitely something that new systems can look at already but which existing systems probably donāt have the ability to utilize. Whatās important to note is that precision time, normally distributed via gPTP, is required to run the Time-Aware traffic shaper to a high degree of precision. If you want to utilize another clock as the domain leader youāll need to account for that in the middleware APIs (e.g. GNSS time sources).
1 Like
Cool stuff. Didnāt think of such a work-around. So what does the TCP tunnel package do when it runs out of bandwidth? The ROS1 transport would drop entire ROS messages (as opposed to packets) which would still leave you with useful messages coming through, just at a reduced rate. Is that how your TCP tunnel package manages congestion as well?
2 Likes
Yes, exactly like in ROS 1, the TCP tunnel drops messages.
More details are available in this section of the README.
While this is a good thing to reduce the latency it is dropping the new data in favor of the old. If a tcp packet is having trouble being delivered, new data will be discarded until the old data is processed. What should happen is old data should be thrown out in favor of new data.
At the expense of adding a central brokerā¦ that is a deal breaker for distributed, robust, swarm systems.
ā¦ subject to the choice rules set up by QoS.
I think itās a case of āhorses for coursesā. ROS2 is being slowly adopted into industry - maybe at first as sandboxes and in synthetic environments for training where the overlaying distributed applicationsā algorithms require sophistication. Going back to messaging constraints of ROS1 would be retrograde in these cases. I guess there could be different layers of choice, but the resources for support and participation of the community are finite.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.