Hitchhiker's Guide to an Indigo Concert
This guide is published by "Megababo Publications", a dim light in the land of open source obscurities.
Hitchhiker's Guide to an Indigo Concert
- Getting Started
- Human Interactions
- The Appable Robot
- Basic Multimaster
- The Concert
The rocon framework is a set of tools and modules that can be used together to run a customised multimaster ros system with a higher level service on top. It doesn't try and define what kinds of services to run1, nor does it try and reach out too aggressively towards cloud robotics. Think of it as a centralised workplace where you can process incoming information and local directives for a multi-robot-device system2.
Rather than illuminating the whole concert at once, this guide will walk through modules, many of which can be used independently. This should serve to highlighting the concert's features like any good crescendo.
Installing the complete rocon environment.
The rocon_launch tool is a convenient tool for launching multiple roslaunch instances each in their own terminal.
- Rocon Launch for Single Masters
Spawn multiple roslaunch terminals working with a single master.
Rocon Master Info
We tend to publish some basic information about our ros masters (name, description, icon). This is generally for the benefit of concert remocons (later), but can actually done for any standalone ros master which would like to provide some info for clients to introspect on.
- Publishing Master Information
Provide data about your ros master to clients that wish to introspect.
The following concepts provide an easy intro into some of the more fundamental things that are used in and around the rocon framework.
Rocon universal resource identifier strings are key to describing the various entities (robots, remocons), the compatible apps that run on them and allow us to shape requests for these resources as well as their allocation at a higher level.
You will often see these being flung around at the ros api level in various messages. Information about these strings is buried in the sphinx documentation for the rocon_uri package.
Specification - details how a rocon_uri string may or may not be assembled.
Rules - the list of valid fields you may use in a rocon uri string.
Usage - the python api and examples.
The rocon_interactions package provides a framework for establishing interactions between human users and a running ros master system. Basically it addresses the problem of what do I run and how do I configure it?. Finding the right launchers to run, or setting up rviz sessions are good examples - the user shouldn't need to scratch around to figure out what to run or where to find documentation. With rocon interactions, all the user needs to do is point a remocon (either qt or android versions) at a running ros master, choose a role and they will be presented with a number of ways they can interact with the concert. This works for many kinds of interactions - android, qt, launchers, web apps and even to point a user at documentation.
For a deeper understanding of rocon's human interaction framework, peruse the introduction on the rocon_interactions wiki page.
If you just want a quick demo, tackle the Getting Started tutorial below. The remaining tutorials are there as a reference if you wish to dive deeper into the rocon interactions framework.
- Getting Started
A walkthrough of the rocon interactions concepts.
- Documentation Interactions
Defining interactions pointing to documentation on the web.
- Qt Interactions
Defining interactions for qt based frontends.
- Rviz Interactions
Defining interactions for rviz configurations.
- Web App Interactions
Defining interactions for web apps.
- Android Interactions
Defining interactions that can launch android activities.
The Appable Robot
Robots in the scenarios and contexts that we often deploy (real world scenarios) are often just another kind of person. It goes to work, will sometimes work within a team and sometimes autonomously. In almost all of these situations, the work is task driven and this is the focus we wanted for interaction with the robots. It is familiar and a natural extension of the way we think and approach tasks as a human.
The hard part of a task driven approach is to step back and let the robot do the task to the best of its ability without trying to interfere with their autonomy as much as possible. This is a difficult balance, but without this in mind, higher level orchestration can quickly become overly complex.
So if a robot is taskable, it should almost certainly in many cases be retaskable to maximise its potential. Multitasking would be nice, but is a pandora's box of problems to open. To enable our retaskable robots, we iterated on the robot app platform initially instigated by Ken and others at Willow as it was a convenient fit. This is less about 'apps' than it is about providing a very convenient way to deploy, start, stop and manage your robot in a task driven way.
The appable robot is intended to be a complete framework intended to simplify:
- Software Installation
- Connectivity (pairing or multimaster modes)
- Writing portable software
and provide useful means of interacting with the robot over the public interface via two different modes:
- Pairing Mode : 1-1 human-robot configuration and interaction.
- Concert Mode : autonomous control of a robot through a concert solution.
Capabilities are a means of providing an abstraction layer at the bootstrap level. This makes writing robot agnostic "apps" easier. If a robot can declare that it implements the standardized interface for the navigation capability, then an app can rely on the the ROS interface used to utilize that capability. A more detailed explanation of what capabilities are about and the api documentation can be found on the capabilities wiki page.
- Capabilities Demo
Demonstrating the capabilities of the capability server.
Applications that utilise and run on top of both capabilities and some bootstrap layer for the robot we refer to as rapps (aka rocon apps, or robot apps - to be easily distinguishable from mobile phone apps). These are essentially launchers with no code. Where capabilities are designed to reflect some sub-functionality of the robot that can be run in parallel with their own conflict management, rapps should represent the launch environment and its configuration for the robot's current activity, or task, e.g. beer delivery. Given this conceptual constraint, only one rapp should ever be running on a robot at one time.
This decision was made primarily to simplify the way the robot interacts at a higher level. Just like humans in a team, our robots in a higher level framework (such as the concert which we introduce later) are designed to be retaskable resources. For the appable robot, this means stopping and starting the appropriate rapp. This lets us tune configuration of launched software or rerun entirely different software as needed. This is especially important on robots which do not have the computational capacity of a pr2.
- Introspect Rapps
How to use the rapp tools
- Create a Robot App
How to create and install a robot application (rapp) for pairing or concert modes.
- Troubleshooting Rapps
How to troubleshooting an invalid rapp
The Rapp Manager
The rocon app manager handles the discovery, discovery and lifecycle management (e.g. start/stop) of rapps. For discovery and installation of platform compatible rapps the rapp manager uses modules from rocon_app_utilities. At runtime it also interacts with the capability server to ensure all required capability dependencies of a rapp are available and appropriately started and stopped along with the rapp.
- Install Rocon App Manager
Installing the rocon_app_platform environment.
- Configure Rapp Manager for Robot
describes how to setup rapp manager for the robot
- Bring up Rapp Manager
describes what happens when you start rapp manager.
- Start Rapp via QT Rapp Manager
shows starting rapps via rocon_qt_app_manager
Launching rapps in tandem with rocon interactions.
- Run Interactions with QT Remocon
shows start interactions via rqt remocon
- Run Interactions with Android Remocon
shows start interactions via android remocon
- Run Interactions with Web Remocon
shows start interactions via web remocon
The components listed here for basic multimaster are not concert specific. You can use these to build an alternative multimaster framework if you wish.
- Rocon Launch for Multiple Masters
Spawn multiple roslaunch terminals over multiple ros masters.
The Gateway Model
The gateway model is the engine of a rocon multimaster system. They are used by the app manager and the concert level components to co-ordinate the exchange of ros topics, services and actions between masters, but in general, you do not need to know in detail how they operate to play with a rocon concert. If you would like to find out more about them, start here:
ToDo: this is awaiting a minor redesign and a rewrite of some hydro tutorials
The concert is a multimaster framework running on top of the interactions, appable robot and gateway components that tries enable a centralised workspace on the network (usually LAN) from which to co-ordinate and manage a group of robots, devices involved in some kind of scenario. This can be used standalone, or it can be further developed as a useful bridge to the cloud3. Some features:
Wireless Connectivity : technology for robust handling of wirelessly connected robots.
Multi-Service Handling : services as parallelisable orchestration blocks at a higher level
- Think services running on a web server, but here we have teleop, make a map, annotate a map, foo...
Robot Scheduling : expose robots as retaskable resources that can be requested by concert services.
Software Sharing : spawn and share access to software instances across concert services.
Human Interactions : infrastructure for coercing humans as interactive participants of concert services.
More detailed concept notes can be found if you go walkabout from our Terminology page on the rocon wiki.
- Chatter Concert
An example concert demonstration, talker-listener style.
- Chatter Concert - Distributed
Distributing chatter concert on multiple machines
- Chatter Concert - Wireless
Wireless handling of distributed chatter concerts
- Turtle Concert
An example concert demonstration, turtlesim style.
- Turtle Teleop Concert
The concert teleop service with simulated turtles.
Create Your own Solution
- Create Your Own Solution
how to create your own solution
- Bring up a Concert
how to start the concert
- Customise Service Configurations
how to create your own solution
- Enable Web Interactions
how to access and interact with concert via web
- Advanced Solution Customisation
describes what arguments concert provides
Make Your Robot To Join Concert
- Concert Client Preparation
what to install and todo for concert mode preparation
- Create Concert Mode Launcher
how to prepare your robot to use in your concert
- Join Concert as a Client
describes how to join a concert as a client
- Teleop a robot via Concert
describes how to capture a robot and teleop via concert
Create Your own Service
- Create Your Own Service
how to create your own service
- Concert Service Gazebo Overview
Describes design flow of concert service gazebo
- How to add a new robot type
How to add a new robot type to use in concert service gazebo
- How to spawn robots in concert gazebo
how to spawn robots in concert gazebo
ToDo : port our various notes into here, write some tutorials on writing requesters/schedulers
ToDo : lots of tutorials and sphinx documentation needed here
ToDo : one simple tutorial should suffice
ToDo : running gazebo as a concert service
If you know the ultimate, unified orchestration type for multi-robot systems, please do let us know. We're pretty sure that no matter what we choose, it will inevitably be wrong! :P (1)
How you use this to then connect to the web is up to you, but the concert should provide you with extra flexibility to make that jump. (2)
Putting the concert on a pc that resides on the ethernet backbone to gather and process incoming/outgoings can be alot more practical than pushing everything from every wirelessly connected robot to the cloud. (3)