concept of service robots

The concept of Service Robot

Luis A. Pineda and

the Golem Group Department of Computer Science

IIMAS, UNAM [email protected]

http://golem.iimas.unam.mx

What is the object of study of a research project in service

robots?

Dr. Luis A. Pineda, DCC-IIMAS, UNAM, Ago. 2013.

One has to consider… •  The history of the group •  The background and interest of the group

members (group and personal agendas) •  The research network •  The explicit agenda of short, middle and long

term goals •  Favorite tools and methodologies •  Context and orientation: academic versus

industrial/commercial •  Underlying motivation: cutting edge research

versus teaching and human resources development!


How do we orientate the effort and asses productivity?


One has to consider… •  Robotic devices & algorithms •  Journal papers •  Conference and workshop papers •  Patents and designs •  Corpora •  Thesis: doctoral, masters, bachelors •  Occasionally a full operational general purpose service

robot! •  Demonstrations (Academic and for the general public) •  Formal evaluation methodologies and practice •  Competitions (of course)


In practice research groups assemble robots and focus on:

•  Navigation •  Manipulation •  Vision •  Audio •  Control/Signal processing •  Operating Systems •  Speech & Language Processing •  Machine Learning •  AI techniques and Methodologies •  Interaction (RHI) •  Other


But where is the…

SERVICE ROBOT?


The standard bottom-up view •  The robot “emerges” as a side effect of the

functionalities: It is mostly integration! •  I have a nice algorithm and a piece of

hardware (have or build): •  Where do I put it •  The “robot” provides the context! •  What is the appropriate task to show it off

•  The rest is “implementation”


Why is it that most open/demo/final challenges focus in exhibiting

a list of functionalities?


What about…

CARS?


Bugatti 57SC Atlantic 1936

The Car! •  Function:

 Transporting people… with some needs in mind! •  Enabling devices and technologies

 The body shell  The engine  Transmission system  Suspension system  Steering  Brakes  Electrical equipment


The function

The enabling technologies

A virtuous cycle!


The evolved Car! •  Function:

 Satisfying Transporting needs! •  Enabling devices and technologies

 Nice body shell  Powerful engine  Fine transmission system  Robust Suspension system  Fine Steering  Secure Brakes  Sophisticated Electrical equipment


The Service Robot! •  Function:

 Providing daily life services to people… with some needs in mind!

•  Enabling devices and technologies (hardware and software):  The platform/base  The inference engine  The navigation system  The vision system  The manipulation system  The speech and language system  The sound system  …


An implementation issue!

The enabling technologies

A virtuous cycle?

?


The proposal:

Let’s focus on the story!


RoboCup’s standard tests (e.g. clean-up, cocktail party, restaurant)

are nice because they provide us with stories!


What the robot does!

Task structure


Practical Tasks’ Hypotheses The structure of practical tasks,

although complex, is significantly simpler than open human tasks

•  Domain-Independent: within the genre of practical tasks the structure of the tasks and tasks management are independent of the task domain and the particular task being performed

•  After Allen’s corresponding hypotheses for practical dialogues.


Armchair theorizing on… •  Navigation? •  Manipulation? •  Vision? •  Audio? •  Control/Signal processing? •  Operating Systems? •  Speech & Language Processing? •  Machine Learning? •  AI techniques and Methodologies? •  Interaction (RHI)? •  Other?


RoboCup’s standard tests are toy instances of practical tasks!


Task structure •  Often NOT included in the list of

disciplines! •  Often considered an “implementation

issue” •  General and specialized programming

languages


The system’s levels The Knowledge Level (A. Newell, AI Magazine, 1981):

  Knowledge level   Symbol level   Transfer-register level   Logic circuit Level   Electronic circuit level   Device level   Physical level


The system’s levels

  Service Robot level   Symbol level   Transfer-register level   Logic circuit Level   Electronic circuit level   Device level   Physical level


The system’s levels Marr’s levels (related to the reference task):

  Functional (The what)   Algorithmic (The how)   Implementation (Logical and physical

resources)


Service Robot’s system levels •  The what: Functions that enable task

structure:   Specific domain   General purpose

•  The how:   Recognition and action algorithms   Hardware devices

•  The implementation: Middleware (Software agents, OS & communications, hardware drivers, etc.)


The concept of Service Robot •  The conceptual model of a service robot

is defined (explicitly or implicitly) by:   What is the set of functionalities or behaviors

at the level of the task!   How basic behaviors are composed in the

execution of complex tasks


An example: RoboCup@Home’s GPSR

•  Type 1: Go to the kitchen, take the coke and leave the apartment.

•  Type 2: Carry a snack to a table.

•  Type 3:

 situation: There is nobody in the living room, but there are people in the kitchen. The robot starts in the kitchen

 question: Robot, go to the living room and introduce yourself


Interpretation Model •  Speech acts into behaviors:

  Type 1: A speech act (a command) is interpreted as a behavior directly

  Type 2: A Speech Act may need to be specified and is interpreted as a sequence of behaviors and may recourse over speech acts

  Type 3: Explicit task management and error handling


An example: RoboCup@Home’s GPSR

•  Task level behaviors:  Ask  Find  Follow  Grasp  Deliver  Memorize  Move  Recognize  Say  Scan  See (objects, people, faces, gestures)  Point


['move to', 'go to', 'navigate to', leave, exit] ==> move [get, take, grasp, fetch] ==> get [introduce(robot), 'tell something about'(robot)] ==> say [ask] == ask [memorize] ==> memorize [recognize] ==> recognize [point, show] ==> point [follow] ==> follow [find, detect, identify] == find [retrieve, bring] ==> retrieve [carry, bring] ==> carry

Explicit elocution ==> command (i.e., speech act type and arguments)


Commands type 1 •  A Speech Act is interpreter as a behavior

directly:

move ==> move(Dest)


Commands Type 2

•  A Speech Act may need to be specified and is interpreted as a set of behaviors

  get ==> find, grasp

•  A Speech act is resolved in terms of a set of behaviors and recourse over speech acts!

  retrieve ==> move, get, move, deliver

  carry ==> get, move, deliver


Commands Type 3 •  Explicit task management and error handling!

retrieve(Status) ==> move(Status_Move1), get(Status_Get), move(Status_Move2 ), deliver(Status_Deliver)

carry(Status) ==> get(Status_Get), move(Status_Move), deliver(Status_Deliver)


Speech acts

Behaviors

The Recursion


The Recursion

Speech acts

Behaviors

Language &

Perception Action


The top-down view •  Functional specification at the task level! •  Conceptual Model of the robot as a whole! •  Architecture and algorithms supporting the

conceptual model and functionalities! •  The rest is implementation!


The Acid Test:

Standard tests are instance tasks of the General Purpose

Service Robot!


The Golem’s Group Approach


Dialogue Models •  Task structure defined in advance through

analysis and empirical research •  Set of behaviors supporting functionalities •  Specification and interpretation situations:

  Expectations (speech acts)   Intentional Actions   Recovery protocols

•  SitLog: A Programming Language for Service Robots’ Task, to appear in International Journal of Advance Robotic Systems


Task structure •  Static: Task defined in advance, as

behavior schemas (Standard tests) •  Dynamic: Tasks expressed through

language (GPSR)


Behaviors •  Aspects:

  Internal: SitLog   External: Perception and Action Algorithms

•  Organization:   Basic   Structured: Defined in terms or other

behaviors


Structured Behaviors


Structure of behavior


Dialogue Models

SitLog’s Interpreter

Speech Act Action


IOCA: Interaction-Oriented Cognitive Architecture


Golem’s Conceptual Model Golem

Communication

Reactive

Thought


Golem’s GPSR

Highly abstract Dialogue Model in SitLog that composes and executes behaviors dynamically including error handling and recovery strategies (a DM’s dispatcher)


Extending the Conceptual Model! •  Add functional behaviors! •  Face human-interlocutor in conversation

  Basic communication/interaction functionality   The matrix for language learning and use!   Conversational and task structure   Interesting and important research question!

•  Detection of Location of Sound Sources: DOA and M-DOA


Innovation Award RoboCup@Home

RoboCup Eindhoven 2013!


Perception and action algorithms are developed

(analyzed, selected, integrated, etc.) in order to support behaviors at the

task structure level!


Going beyond the GPSR? •  An explicit central executive system included in IOCA

for handling novel situations:   Going beyond learned or acquired behaviors   Planning or decision making   Error correction and troubleshooting   not well-rehearsed situations or containing novel

sequences of actions   Dangerous or technically difficult   Overcoming a strong habit or resisting temptation

(restrain!)   Self-awareness!


Golem’s group current working-tables

•  Task structure and behaviors (Luis Pineda) •  Audio Processing (Caleb Rascón) •  Speech and Language (Ivan Meza) •  Vision and manipulation (Gibran Fuentes) •  Hardware and Industrial design (Hernando

Ortega and Mauricio Reyes)


•  Luis Pineda •  Ivan Meza •  Caleb Rascón •  Gibrán Fuentes •  Liz Salinas •  Hernando Ortega •  Mauricio Reyes •  Mario Peña •  Joel Ortega •  Arturo Rodríguez •  Varinia Estrada

http://golem.iimas.unam.mx

The Golem Group


Many Thanks!


concept of service robots

Education