[ros-users] ROS-to-X Bridge SIG?

Nicholas Butko nbutko at ucsd.edu
Tue Sep 13 16:14:21 UTC 2011


Having just done exactly this for my own lab (to interoperate with Flash), and already doing it previously (to interoperate with iOS and java), I would like to second this effort. 


On Sep 13, 2011, at 8:26 AM, "Jenkins, Odest Chadwicke" <odest_jenkins at brown.edu> wrote:

> The "elephant in the room" wrt to the current SIGs is bridging
> ROS-to-X, where X is most often some custom codebase already in use by
> some lab.  From informal interactions, I hear that many groups use ROS
> as a service with some custom ad hoc network-based bridge for
> connecting to their codebase.  There are also bridges for ROS-to-ROS
> (multi-master, foreign relay), ROS-to-web (rosjs), ROS-to-Arduino
> (rosserial), ROS-to-Matlab (ipc-bridge), and many many others (just
> google "ros ipc").
> This fragmentation on top of ROS is and will be a major problem,
> especially for people who want to build on the contributions of the
> greater ROS community (not just the chosen first-class client
> libraries).  Such fragmentation limits interoperability and furthers
> reinvention (as everyone designs their own custom protocol), and
> confuses potential applications developers looking for a consistent
> interface to ROS.
> Thus, I would propose a "ROS-to-X Bridging" SIG if there are several
> others who voice an interest, and express a willingness to coordinate
> the SIG.
> -Chad
> Date: Fri, 9 Sep 2011 18:11:16 -0700
> From: Ken Conley <kwc at willowgarage.com>
> Subject: Re: [ros-users] multi-master support for Fuerte
> To: User discussions <ros-users at code.ros.org>
> Message-ID:
>       <CAAsdojxc659LfujOa8nePRnyDCOPARdOHrUNSbcSEgtPJsD6xA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> On Fri, Sep 9, 2011 at 12:56 PM, Armstrong-Crews, Nicholas - 0447 -
> MITLL <nickarmstrongcrews at ll.mit.edu> wrote:
>> Are we sure flaky/intermittent connectivity is just a sub-topic of multi-master? Evidentially, even operating a single robot over wifi poses challenges with latency, message buffering, and bandwidth. Wouldn't it be great to have some kind of network quality-of-service support built in to the core pubsub? If not feasible under the pubsub hood, maybe a library analogous to actionlib or at least some examples / best practices?
> While it is possible to attempt separate SIGs, those working on
> multirobot comms *have* to think about wifi issues, so the separate
> SIG may just increase process overhead.  For example, I'm already
> thinking about combining the 'target platforms' and 'thirdparty
> library normalization' SIGs as the target platform decisions will in
> part be driven by decisions regarding thirdparty libraries.
> - Ken
>> As a testimonial, in the past, we implemented a multi-master multi-robot system over wifi without any changes to the rosmaster code (OK, there was a one-line change). However, we were stymied by the wifi issues I mentioned above (message buffering, etc.); we had to build logic to react to dropped connections in each node individually. Still, the latency in detecting a dropped connection (TCP timeout?) had lethal consequences.
>> One other aside: I feel like multi-master is not quite the same as multi-robot. It might be worthwhile to consider the multi-robot use case independently; for example, even if the robots use a single master on a reliable network, how should namespaces (in ROS node/topic names and in tf frames) be used effectively? Also, I notice that if both robots have complex 3D models, then hundreds of frames are sent between them (at very high rates, even if most of the joints are "fixed"); but Robot1 probably doesn't care about the position of the left toe of Robot2. Time sync is another an issue that might be able to be handled nicely in the ROS core framework.
>> All that said, guess I should join (at least one) SIG :)
>> Regards,
>> -Nick
>> -----Original Message-----
>> From: ros-users-bounces at code.ros.org [mailto:ros-users-bounces at code.ros.org] On Behalf Of Ken Conley
>> Sent: Thursday, September 08, 2011 10:09 PM
>> To: User discussions
>> Subject: Re: [ros-users] multi-master support for Fuerte
>> I'm travelling now so I don't have the proper bandwidth to respond to
>> the comments here, but I think it's already demonstrating that an SIG
>> will have more than enough to talk about. ? ?I've added my name to the
>> signup.
>> cheers,
>> Ken
>> On Thu, Sep 8, 2011 at 10:12 AM, Jeff Rousseau <jrousseau at aptima.com>
>> <JRousseau at aptima.com> wrote:
>>>> Sounds like multi-master is a potential SIG for Fuerte planning
>>>> (http://www.ros.org/wiki/fuerte/Planning). ?As Ken alluded, it'll likely be
>>>> hard to find the one-size-fits-all solution, but there would be a lot of value in
>>>> polishing up multi-master support for a couple of common use cases.
>>>> ? ? ? brian.
>>> Added the SIG to the wiki for anyone who wants to sign up:
>>> http://www.ros.org/wiki/fuerte/Planning#Multi-Master_Support
>>> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users

More information about the ros-users mailing list