On 8 September 2011 23:07, Ken Conley
<kwc@willowgarage.com> wrote:
On Thu, Sep 8, 2011 at 4:30 AM, Jeff Rousseau <
jrousseau@aptima.com>
<
JRousseau@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?
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@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users