Robotics in Concert
Overview
This just documents the previous/current work going on at Yujin. Multi-master is a huge umbrella, so this is just a small part of it, but I do think there is alot of overlap between multi-robot style solutions, and whatever tools we create for the solution we're currently working on should ideally be available for re-use on other multi-robot solutions, or ones that we'd like to tackle in the future.
Background
We (Yujin Robot) started looking at this area almost a year ago. After some discussion, it turned out Ken was also working on some similar concepts with the Building Manager. So if you're familiar with that, it should be easy to follow the ideas below as we've been working when we've had time in and around that space.
Target
Our main target is to be able to provide multi-robot/device solutions. The scope of such solutions, initially, is to provide for homes/shops/classrooms/small businesses/labs/buildings etc. We want to digitally connect what is already there (devices/computers etc), and insert robots into the mix. That'll let us achieve some wonderfully exotic things and also probably help make our robots cheaper by offloading cpu power/sensors/devices.
We're hoping to start up/run a couple of small businesses (as yet in planning) in Seoul as a test bed for this.
Goals
With relevance to multimaster:
Minimise Effort
Our priorities are a bit different to a one-shot setup in a research lab environment. We would like to be able to do this in a big way and can't afford the development or setup/configuration time (ok, we're lazy buggers!). So anywhere we can automate or eliminate work in the development process is great. To this end, we would like to automate the following pipelines as much as possible for our concert style solutions:
- Robot configuration
- Software installation
- Robot/Service discovery
- Unique name serving for robots
- Extend cross platform/language communications for maximum interaction
- Semi-Automatic solution management
The last one is a big area of concern. We'd like to reconfigure the robot/device arrangement and still serve the solution, automatically. A kind of portability.
Security
- Block access to a robot's ros master and control what is exposed.
Robust Wireless Connectivity
- Detect/identify/remember robots involved in a solution as they move in and out of range.
- Gracefully handle individual communication connections dropping in and out.
Big Picture
Its using a concert master to rule them all. I.e. to manage, connect and execute a solution on top of a set of concert-ready robots/devices. Very similar to the Building Manager, but where Ken's been playing around with an app manager and multimaster syncing, we've been playing around a bit with connectivity over the last month or two.
Theoretically I'm not really comfortable with such a centralised (one authoritive master) solution. I'd rather see a completely distributed set of tools just coming together in an ad-hoc way. But practically, it seems to be the easiest way to move towards a couple of decent implementations that we could run for the kinds of targets we're looking at in a relatively short time period.
Current Spheres of Work
App Manager
Pretty much wrapping Ken's app_manager and master sync and putting a few pieces around that.
- CMake mechanisms for rolling concert app .debs (to use in an app store)
- Zeroconf discovery to resolve concert master's it might want to connect to.
- Zeroconf advertisement of a small xml-rpc server running beside the app manager for pre-connection setup.
- Provides naming hints, platform information
- Has a callback to handle an invitation from a concert master.
- Whitelists/blacklists for controlling acceptance/rejection of invitations.
Android
- Daemon program to zeroconf discover available concert masters.
This would be a bit like the wireless daemon that runs in an android. It could be used to set concert priorities, blacklists, handle popup notifications from concert masters, provide available concert master addresses to apps that want to connect, etc. Still rather experimental given the state of rosjava's android build environment and also because we're just trying a first idea.
I noticed Willow's set up a master chooser that can use manual input or qrcoded input. The qrcoded input is also interesting.
Ideally, the goal is to make connections from your phone/tablet as automatic as possible. I think there's three kinds of cases we're considering
- User connects to the solution upon entry into a shop
- Using an android tablet as the concert master itself (e.g. shop owner)
- Connecting to one of many concert's running in a robot soccer competition building.
Auto-Discovery
Decided to do this with zeroconf similarly to what Jon wanted to try. However, we didn't see any reason to implicate the master with zeroconf. The app manager was already handling the public/private exposure and I like to keep working units as distinct as possible. Zeroconf is also something that is potentially desirable for other parts of the ros system as well (e.g. might want to advertise a remote configuration handle whilst keeping your ros master hidden).
So we started some ros packages that would present a regular api and a ros api (topics and services) for avahi and jmdns that could be utilised as standard building blocks. I've put some of our code up on github. If others find that useful, even temporarily, I'd like to work with whoever's interested in standardising the api for a cross platform set of zeroconf utilities.
Unique Identification
Zeroconf doesn't really handle this in a dynamic network. It provides unique names, but they don't help you if your robot go out of range, then comes back - there's no guarantee it will serve you up the same name. So we're using a combination of unique keys (similar to ssh keys) and name hints to generate unique human readable names. It's the concert master's responsibility to retrieve and manage these and make a database of what's around for the duration of the solution. Probably not the only way, but a necessary part of automating configuration of an up-down solution.
Future
Something we'll probably really start looking at in the short term is setting up a robust wireless framework. I think thats the biggest blocker to actually making multi-robot stuff easier. We actually haven't done a whole lot of testing yet, so I still need to learn a bit more on what currently goes wrong and what is possible. I suspect the current api probably needs to gracefully handle problems better than it currently does, which is important, but I think we really need a good solution at a higher level. UDP can help keep things running, but we sometimes need the robot to know the connection state to alter its behaviour accordingly.
This is probably an area where we would like to/can significantly contribute to for the next release.
