Rocon Authoring

From Rocon Wiki
Jump to: navigation, search

Contents

What is ROCON Authoring ?

This is an interesting question. Koreans are typically crazy about the idea of authoring their robots and have been doing various work along these lines for some time. Fundamentally the question is just about what tools you need to help you quickly derive interesting applications on top of your robots. That's an easy question to answer for single robot development, but what does it mean with what we are trying to do? This causes quite some confusion in Korea since they're often not quite disconnecting the idea of multimedia or musical content from what it means to robotics.

Let's investigate the problem here.

Dictionary Definition of Authoring

Going back to the root of the problem. What does it mean to be an 'author'? Some common definitions:

  1. The writer of a book, article, software program (especially a hypertext or multimedia application).
  2. The maker of anything; creator; originator: e.g. the author of a new tax plan.
  3. One who writes or constructs an electronic document or system, such as a website.

Preconcepts

pub?w=319&h=207&.png

As mentioned previously, the idea of authoring is not novel - it has been around for some time in Korea and to a lesser extent in western countries. That means we're working against/with predefined concepts in the area of robotics. What are these?

Typically the focus was on single robots - how to create flash'able user interfaces to robots as well as connecting events to create a useful scenario. Occasionally this idea was extended to multiple robots where the authoring typically controlled very tightly the behaviour of the robots (dumb mechanical machines!) - god mode!

Both results are very closely associated with Definition 1): writing books (stores) or generating robot-aspected multimedia. This is fine and does the job for single robots and simple scenarios, but hasn't been an extremely important topic for robotics in general. Perhaps because the achievable scenarios are still quite simple, perhaps also because there are just so many problems in robotics and this one is lower priority.

Putting it in Context

Definition and preconcept - that clearly gives us an idea of what we stand against. How is what we are trying to do different? Should it be different? Let's put it in context and analyse exactly what we are trying to do with ROCON.

pub?w=403&h=302&.png

Goal

Fundamental Goal of Rocon: walk into a customer's building/office and build solutions for them that provide real services.

Naturally, the next question is what kind of solutions? We are service oriented (service robotics). Typically humans provide services utilising human, paper and machine resources. We'd like to expand what they can offer by automating and integrating existing resources with robots, phones, tablets and the digital world. This can be done without robots, but for a service robotics company, introducing the robot represents challenges that are uniquely different, hence ROCON.

Requirements

Assuming we want to walk into a situation and provide a solution for a customer's wish. What do we need to do?

Circled are the two items that 'authoring' traditionally focused on. In the context of a multi-robot-device-human solution though, this is just a small part of what is required to be done to meet the goals.

The Definitive Answer

The requirements presents us with rather a long list we, need to make/need to create/need to AUTHOR. This falls in line with Definition 2), so lets consider the following answer to the original question...

ROCON Authoring is the process of creating or customising any component or plan in the solution development pipeline.

This is a very useful exercise as it expands the concept of 'authoring' in a way that allows us to consider quite usefully the question of what is needed to author solutions for the customer in the best way possible. This should involve authoring of individual components, workflows, right through to authoring the big picture that is involved.

Authoring Priorities

Given the preceding list, there are many areas we could invest effort. Those below identify those with a higher priority.

Drafting...

Integration

Authoring a solution requires integration and co-ordination across a varied group of teams (often remote), individuals, skills and styles. Most of whom are largely incompatible and cannot use the same suite of tools to develop with. In our experience, the most difficult part of authoring the solution is connecting and integrating the results of these disparate groups to provide a consistent result that would comply with the customer's needs. To solve this, we envisage requiring a tool that addresses the needs of communication and the big picture. It would allow the project manager to oversee the project from inception to deliverable and ensure communications and specifications are shared effectively. For the participants in the development, it would provide them with a means to automatically receive notifications, address issues in related components and track discussions and development in other parts of the project to assist in ensuring their sub-component aligns with the project in the best way possible.

In some ways, it should reflect what social internet services do for normal communications for a very mixed development team.

Service/Solution Creation

These are unavoidable.

Configuration

Helper Tools

Personal tools
Namespaces

Variants
Actions
Navigation
Documentation
Getting Started
Resources
Toolbox