[Documentation] [TitleIndex] [WordIndex] 

Hitchhiker's Guide to an Indigo Concert

This guide is published by "Megababo Publications", a dim light in the land of open source obscurities.

Contents

  1. Hitchhiker's Guide to an Indigo Concert
    1. Overview
    2. Getting Started
      1. Installation
      2. Standalone Tools
      3. Standalone Concepts
    3. Human Interactions
      1. About
      2. Tutorials
    4. The Appable Robot
      1. About
      2. Capabilities
      3. Rapps
      4. The Rapp Manager
      5. Pairing
    5. Basic Multimaster
      1. Tools
      2. The Gateway Model
      3. Retaskable Autonomy
    6. The Concert
      1. Overview
      2. Tutorials
      3. The Scheduler
      4. Concert Services
      5. Service Interactions
      6. Gazebo Concerts
    7. Footnotes

Overview

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.

Getting Started

Installation

  1. Installation

    Installing the complete rocon environment.

Standalone Tools

Rocon Launch

The rocon_launch tool is a convenient tool for launching multiple roslaunch instances each in their own terminal.

  1. 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.

  1. Publishing Master Information

    Provide data about your ros master to clients that wish to introspect.

Standalone Concepts

The following concepts provide an easy intro into some of the more fundamental things that are used in and around the rocon framework.

Rocon URIs

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. 

rocon://concert_name/hardware_platform/name/application_framework/operating_system#rocon_app

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.

Human Interactions

About

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.

Tutorials

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.

  1. Getting Started

    A walkthrough of the rocon interactions concepts.

  2. Documentation Interactions

    Defining interactions pointing to documentation on the web.

  3. Qt Interactions

    Defining interactions for qt based frontends.

  4. Rviz Interactions

    Defining interactions for rviz configurations.

  5. Web App Interactions

    Defining interactions for web apps.

  6. Android Interactions

    Defining interactions that can launch android activities.

The Appable Robot

About

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
  • Launching
  • Retasking
  • 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.

    Appable Robot

Capabilities

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.

  1. Capabilities Demo

    Demonstrating the capabilities of the capability server.

.

Rapps

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.

Specifications

Tutorials

  1. Introspect Rapps

    How to use the rapp tools

  2. Create a Robot App

    How to create and install a robot application (rapp) for pairing or concert modes.

  3. 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.

  1. Install Rocon App Manager

    Installing the rocon_app_platform environment.

  2. Configure Rapp Manager for Robot

    describes how to setup rapp manager for the robot

  3. Bring up Rapp Manager

    describes what happens when you start rapp manager.

  4. Start Rapp via QT Rapp Manager

    shows starting rapps via rocon_qt_app_manager

Pairing

  1. Pairing

    Launching rapps in tandem with rocon interactions.

  2. Run Interactions with QT Remocon

    shows start interactions via rqt remocon

  3. Run Interactions with Android Remocon

    shows start interactions via android remocon

  4. Run Interactions with Web Remocon

    shows start interactions via web remocon

Basic Multimaster

The components listed here for basic multimaster are not concert specific. You can use these to build an alternative multimaster framework if you wish.

Tools

  1. 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:

Retaskable Autonomy

ToDo: this is awaiting a minor redesign and a rewrite of some hydro tutorials

  1. Multimaster Rapp Manager

    Enabling the rapp manager for multimaster via rocon gateways.

The Concert

Overview

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.

The Concert

Tutorials

Quick Demos

  1. Chatter Concert

    An example concert demonstration, talker-listener style.

  2. Chatter Concert - Distributed

    Distributing chatter concert on multiple machines

  3. Chatter Concert - Wireless

    Wireless handling of distributed chatter concerts

  4. Turtle Concert

    An example concert demonstration, turtlesim style.

  5. Turtle Teleop Concert

    The concert teleop service with simulated turtles.

Create Your own Solution

  1. Create Your Own Solution

    how to create your own solution

  2. Bring up a Concert

    how to start the concert

  3. Customise Service Configurations

    how to create your own solution

  4. Enable Web Interactions

    how to access and interact with concert via web

  5. Advanced Solution Customisation

    describes what arguments concert provides

Make Your Robot To Join Concert

  1. Concert Client Preparation

    what to install and todo for concert mode preparation

  2. Create Concert Mode Launcher

    how to prepare your robot to use in your concert

  3. Join Concert as a Client

    describes how to join a concert as a client

  4. Teleop a robot via Concert

    describes how to capture a robot and teleop via concert

Create Your own Service

  1. Create Your Own Service

    how to create your own service

Gazebo Concert

  1. Concert Service Gazebo Overview

    Describes design flow of concert service gazebo

  2. How to add a new robot type

    How to add a new robot type to use in concert service gazebo

  3. How to spawn robots in concert gazebo

    how to spawn robots in concert gazebo

The Scheduler

ToDo : port our various notes into here, write some tutorials on writing requesters/schedulers

Concert Services

ToDo : lots of tutorials and sphinx documentation needed here

Service Interactions

ToDo : one simple tutorial should suffice

Gazebo Concerts

ToDo : running gazebo as a concert service

Footnotes

  1. 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)

  2. 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)

  3. 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)

2024-11-16 14:54