From Rocon Wiki
Revision as of 16:24, 7 May 2015 by Jihoonl (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search



We need a reference to communicate across groups, but don’t get hung up on the exact word. There are many different users/devs in the rocon ecosystem (e.g. robot, software, web, control, service) so the concept is more important than the exact terminology.


Represents the entirety of that which fulfills the needs of a problem or a customer using a mix of robots, devices, tablets/phones and software. There is a familiar analogy in the IT world where business such as IBM act as solution providers that aim to meet the needs of their clients by specifying and providing the computer hardware and software needed to meet the project goals. Another viewpoint is that it is simply a multi-robot-device-tablet system that enables a collection of services.

  • Example: A cafe running a coffee delivery service in parallel with various cleaning services.
  • Example: A mobile warehouse floor co-ordinating machine arrangement and workflow.
  • Example: A dynamic environment with robot and human actors that are not controlled, but simply interact.


"A world of interactions".

Various components and rules governing their relationships will be required at the concert level to bring everything together. We loosely use use the term orchestration (not to be confused with the stricter definitions of orchestration and choreography for software services) to define the necessary components and their interactions. This is a large topic in itself, consequently it has its own dedicated section on this wiki.


"Doing something for someone".

A single solution will be responsible for managing a collection of services in parallel, very much like a pc web server often runs multiple services in parellel (e.g. apache, issue tracker, code repository, file server, ...). A service should generally be thought of as a programmed workflow in a multi-robot-device-human ecosystem that can request robotic resources or permission to execute software and accept interactions from humans via appropriate interfaces. A major objective for us is to allow services to be programmed without constraints the language to encourage experimentation at this level. For example, ros, static link graph, orc and bpel style services will be initially supported with commonality at the resource requesting, software sharing and interactions interfaces.


The combination of services will often make for a more complete solution:

  • Example: Make a Map service
  • Example: Annotate a Map service
  • Example: Teleop service
  • Example: Delivery service

Simpler Definitions


  • Rocon URI : 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.
    • e.g - rocon://concert_name/hardware_platform/name/application_framework/operating_system#rocon_app

Concert Definitions

  • Concert : the centralised multi-robot framework pictured previously.
  • Concert Client : any robot/device satisfying requirements to connect and run inside the concert.
    • Retaskable Concert Client : clients that can be re-tasked with different applications (usually retaskable robots).
  • Human Interactive Application : representing a human in the system via tabs/phones/web apps (sometimes referred to as interactive concert clients).
  • Software Node : usually a software process requested by a service or other concert client and allocated by the scheduler.
  • Resources : fundamental representation and specification of 'something that delivers a certain functionality' in the system
    • e.g. a specific software launch configuration running on a robot, the software and interfaces provided by a software node executing on a virtual pc.
  • Concert Master : collection of components (including a ros master) that initiates the minimum requirements of a concert.
  • Conductor : handles invitations, connections, platform info and app management on each client.
  • Resource Scheduler : handles requests for resources from services and schedules/allocates them (hopefully intelligently).
  • Auto-Discovery : the whole system should be auto-discoverable on the LAN (apple’s bonjour style).

Orchestration Definitions

  • The Backstage : a loose term describing all the machinery required to facilitate orchestration of the concert (e.g. tools for connectivity, logging, introspection, databases).
  • Concert Client Introspection : the ability of a concert client to introspect about whether a task it is given is feasible.
    • e.g. a robot introspecting whether it can accommodate the payload size, weight and shape for a delivery task.
  • Job : is a tentative term to define an invoked workflow in service. (e.g 1 order in drink delivery service)

Appable Robot Definitions

  • Appable Robot : a robot engineered for retaskable operation inside the concert environment.
  • App Manager : opposite end of the conductor, platform info, app installation and execution.
  • Capabilities : internal layer to simplify development, installation and execution of apps.
  • Bootstrap Layer : the robot specific software base (usually custom).
Personal tools

Getting Started