<p>Hello, </p>
<p>As an additional input, we have developed a generic message transport plugin architecture [1]. This allows to implement your own kind of transport for any type. For instance, we've implemented a udp multicast and a shared mem transport.<br>

This could be a framework to implement your link, although it is a single master approach.</p>
<p>[1] <a href="http://www.ros.org/wiki/ethzasl_message_transport">http://www.ros.org/wiki/ethzasl_message_transport</a></p>
<p>HTH</p>
<p><blockquote type="cite">On Feb 14, 2011 10:15 AM, "Raymond Sheh" <<a href="mailto:rsheh@cse.unsw.edu.au">rsheh@cse.unsw.edu.au</a>> wrote:<br type="attribution">  Hi Stefan,<br>
<br>
Thank you for your information!<br>
<br>
I did follow a few of the multi-robot topics in the archives and they're<br>
certainly related but I guess the emphasis of what I'm trying to<br>
accomplish here relates more to allowing the various nodes on each end<br>
of the comms link to manage the unreliability of the link in their own<br>
way (and thus having the relay mechanism expose these details - which I<br>
understand is in a somewhat different direction to the approaches that<br>
try to abstract the link away as much as possible).<br>
<br>
For example, a node that deals with formatting data for a remote teleop<br>
video feed (with a codec that can handle packet loss) will need to<br>
specify that its data should always be dropped if it can't be sent,<br>
rather than buffered. Ideally, it should also have a medium to high<br>
priority on the link and should be notified if delays go up or bandwidth<br>
begins to drop so we can do thing like increase compression. In<br>
contrast, a remote logging node would be low priority and buffer rather<br>
than drop when the link drops out. Also, nodes that handle control and<br>
realtime teleop should be actively informed by the relay system when the<br>
link has dropped out (rather than relying on a timeout).<br>
<br>
Of course, having a wishlist like this is one thing, figuring out what's<br>
worth implementing and how to go about it is another! ;-) In our<br>
previous work we used completely different systems for the different<br>
data and while it kinda worked, I'm trying to see if there's a viable<br>
way of doing this all under the one infrastructure.<br>
<br>
Cheers!<br>
<font color="#888888"><br>
- Raymond<br>
</font><p><font color="#500050"><br>On 14/02/2011 5:01 PM, Stefan Kohlbrecher wrote:<br>> Hi,<br>><br>> one of your team area neighbors from Sin...</font></p></blockquote></p>