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.

  

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

• Rapp Specification