[ros-users] multi-master support for Fuerte

Daniel Stonier d.stonier at gmail.com
Thu Sep 8 16:31:15 UTC 2011


Hi Ken, Jeff,

On 8 September 2011 23:07, Ken Conley <kwc at willowgarage.com> wrote:

> On Thu, Sep 8, 2011 at 4:30 AM, Jeff Rousseau <jrousseau at aptima.com>
> <JRousseau at aptima.com> wrote:
> > Hey Folks,
> >
> > I haven’t seen the topic brought up lately, so I’m not sure if someone is
> > already working on this for Fuerte—What is the state of multi-master
> support
> > in ROS and are there any plans for further development?
>
> The Fuerte planning is in progress, but there are currently no plans
> on my end re: multi-master work.  During the Electric development
> cycle, we played around a bit with multimaster_experimental and
> developed the app_manager, which is one (of many) approaches for doing
> multi-master work. We started off wanting to do multi-robot, but
> rosjava refocused our efforts on using an Android device to interface
> with a robot -- similar techniques, but different assumptions.
>
> Our general conclusion there was that multi-master is very
> application-specific as you have to make assumptions about
> connectivity and configuration in order to pull it off.  The
> app_manager has a master-syncing approach that works under good
> connectivity; more work is necessary to make it work under bad
> connectivity and really test it in multi-robot scenarios (it was
> generally used for multi-master, single robot use case).
>
> I do plan on seeing what can be done in the wifi realm re: ROS, i.e.
> things that will improve a single master, multi-machine setup.
>
>
Been a while as I got diverted to some other projects, but we've been
playing around your multi-master/app manager/app store for the last month
and a half Ken. The test environment at the moment is just an android tab,
small windows robot, a larger ros robot, and a master pc that runs a bit
like a base station (concert master).

So long as we're locked into a world of ros masters, its a nice way of
ensuring autonomy of your robots, even when they go out of wifi range. And,
although perhaps a little application specific, it seems to match our needs
for most scenarios we can think of for a set of classrooms, shop, or small
office building.

Configuration is a large area. Even setting up a single robot with ros takes
a fair amount of ip configuration, parameterising and launchfile remappings.
So we're concentrating on automating some of those areas so we can look at
providing multi-robot/device solutions and maintenance with a minimum of
effort. To get started we're zeroconf'ing the network and the components
that need to find each other. We've got an avahi node on linux that can be
configured at runtime and jmdns roughly working on the android tab. Might
put bonjour on windows and look at avahi's embedded library (no dbus
depenendency) for our embedded robot. It's got a few rough edges, but seems
to be working out. With the help of some tiny xmlrpc servers sitting
alongside the app manager, the concert master will automatically retrieve
platform information from the robots and decide to (or not) invite robots to
join. The android tab will use the user in the loop to make a connection to
the automatically discovered concert master. With everything
auto-discovered, it's also an easy way to do multi-robot configuration.

We had to change our thinking a bit when adding the android too - the robot
app manager concept just didn't fit. For now we're experimenting with a
daemon that can scan for concerts on the lan (existing multi-robot
solutions) and pick up notifications from those (a bit like the wireless
interface in android works). And we've also been thinking about what might
be done differently if we move the concert master from a pc to a mobile
tablet. Am interested to hear what your thoughts might be in that direction.

One observation coming out of the experimentation, is that it truly isn't
multi-master. It's more a lord of the rings style master, one to rule them
all. That may be a practical constraint that is, for now, required to jump
to the next level of complexity so that we can begin to provide multi-robot
solutions. And probably quite acceptable in most environments. But I am
wondering just how big the chasm is to providing truly distributed
multi-master solutions (in the style of git).

Connectivity and robustness to wireless issues is looming high on the
agenda, but we've not got around to looking at that yet.

> I’ve been using
> > foreign_relay for a number of months and it mostly works, but I’d like to
> > see first-class multi-master support in ROS and am willing to commit
> > development time towards it.
>

I'd also be willing to get together to talk/work on these things further.

Regards,
Daniel Stonier (Yujin)

Glad to hear it, what do you have in mind?
>
> > PS I noticed “Building Manager” meeting notes which had discussions about
> > implementing proper multi-master support seems to have stalled…
>
> See above.
>
> cheers,
> Ken
>
> >
> >
> >
> > Jeff
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110909/8498254b/attachment-0002.html>


More information about the ros-users mailing list