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

Michael Carroll carroll.michael at gmail.com
Tue Sep 13 16:20:33 UTC 2011


I'm currently writing a ROS-to-OSC (Open Sound Control) bridge for
interfacing with IO equipment that sound/video guys use.

I would like to third this effort.

~mc

On Tue, Sep 13, 2011 at 11:14, Nicholas Butko <nbutko at ucsd.edu> wrote:

>
> Chad,
>
> 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.
>
> --Nick
>
>
> 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
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110913/2208dae1/attachment-0002.html>


More information about the ros-users mailing list