istituto

per

la

ricerca

scientifica

e

tecnologica

Povo

-LRB-

Trento

-RRB-

Italy

Tel.

39 461 314575

Fax

39 461 314591

e-mail

prdoc@itc.it

url

Flexible

planning

by

integrating

multilevel

reasoning

Armando

A.

Cimatti

A.

Giunchiglia

E.

Pecchiari

P.

Spalazzi

L.

Traverso

P.

January

Technical

Report

c

Istituto

Trentino

di

Cultura

limited

distribution

notice

This

report

has

been

submitted

for

publication

outside

of

ITC

and

will

probably

be

copyrighted

if

accepted

for

publication

It

has

been

issued

as

a

Technical

Report

for

early

dissemination

of

its

contents

In

view

of

thetransfer

of

copyright

to

the

outside

publisher

its

distribution

outside

of

ITC

prior

to

publication

should

be

limited

to

peer

communications

and

specific

requests

After

outside

publication

requests

should

be

filled

only

by

reprints

or

legally

obtained

copies

of

the

article

Flexible

planning

by

integrating

multilevel

reasoning

A.

A.

E.

P.

L.

P.

DIST

Universit?a

di

Genova

Via

Opera

Pia

Genova

Italy

Fax

+39 10 3532948

farmando,enrico,peckg@dist.unige.it

IRST

Localit?a

Pant?e

di

Povo

Trento

Italy

Fax

+39 461 314591

fcx

leafg@irst.it

Dipartimento

di

Informatica

Universit?a

di

Ancona

Via

Brecce

Bianche

Ancona

Italy

Fax

+39 71 2204474

Abstract

The

successful

application

of

a

general

purpose

planning

system

on

real

world

complex

application

domains

depends

on

which

extent

the

activities

of

plan

formation

plan

execution

monitoring

and

failure

handling

can

be

flexibly

interleaved

This

paper

presents

a

multilevel

reasoning

system

-LRB-

called

MRG

-RRB-

where

low

level

functionalities

-LRB-

e.g.

navigation

vision

and

speech

understanding

-RRB-

are

flexibly

combined

with

higher

level

reasoning

capabilities

through

a

set

of

specialized

subreasoners

At

the

top

of

the

architecture

there

is

a

high

level

reasoning

system

implemented

using

a

programming

language

based

on

the

notion

of

tactic

MRG

is

currently

used

as

the

core

of

an

intelligent

robot

able

to

navigate

within

an

unpredictable

environment

and

to

exchange

information

with

human

users

Introduction

This

paper

presents

a

multilevel

reasoning

system

called

MRG

which

is

the

core

of

MAIA

an

intelligent

mobile

robot

able

to

navigate

within

an

unpredictable

environment

and

to

exchange

information

with

humans

in

order

to

solve

high

level

objectives

such

as

finding

persons

within

the

institute

and

helping

people

-LSB-

-RSB-

Three

are

the

main

characteristics

of

MRG

First

MRG

is

a

modular

hierarchically

organized

architecture

At

the

bottom

level

there

are

a

set

of

interfaces

directly

interacting

with

the

peripheral

devices

-LRB-

e.g.

low

level

sensors

and

actuators

controllers

man-machine

graphical

interfaces

-RRB-

On

top

of

such

modules

there

are

two

subreasoners

grouping

the

functionalities

provided

by

the

peripheral

devices

in

navigation

and

interaction

tasks

Finally

these

two

sub-reasoners

are

coordinated

by

a

central

reasoner

which

is

responsible

of

the

high

level

management

of

the

activities

This

architecture

reflects

the

natural

decomposition

of

each

activity

into

a

set

of

more

primitives

ones

till

the

directly

executable

primitives

The

advantage

is

that

each

problem

is

faced

at

the

right

level

of

detail

by

the

appropriate

module

Second

MRG

is

able

to

have

rapid

reactions

to

external

stimuli

-LRB-

e.g.

a

person

jumping

in

front

of

the

robot

-RRB-

plan

for

high

level

objectives

-LRB-

e.g.

look

for

a

person

-RRB-

switch/intermix

flexibly

these

two

phases

in

order

to

behave

in

different

ways

according

to

different

situations

and

application

requirements

Most

of

the

planning

systems

developed

so

far

support

a

single

planning

modality

which

can

be

roughly

classified

as

belonging

either

to

the

planning

ahead

paradigm

-LSB-

-RSB-

relying

on

an

a

priori

modelization

of

the

external

world

or

to

the

reactive

paradigm

-LSB-

-RSB-

where

the

system

is

almost

completely

driven

by

external

stimuli

Each

approach

suffers

from

-LRB-

apparently

unavoidable

-RRB-

shortcomings

The

planning

ahead

approach

seems

not

suited

to

application

domains

in

which

highly

unpredictable

events

may

occur

while

the

reactive

based

approach

is

unable

to

reproduce

high

level

behaviors

Efforts

have

been

spent

in

trying

to

integrate

the

two

approaches

-LSB-

-RSB-

but

no

attempt

has

been

made

towards

the

design

of

a

general

framework

where

the

two

approaches

can

be

flexibly

integrated

Given

the

functionalities

of

MRG

and

high

unpredictability

of

its

application

environment

both

the

reactive

and

the

planning

ahead

paradigms

turn

out

to

be

insufficient

if

not

flexibly

integrated

In

order

to

achieve

the

required

level

of

flexibility

therefore

the

solution

strategies

synthesized

by

each

reasoner

are

expressed

in

a

programming

language

based

on

the

notion

of

Within

such

a

language

the

domain

of

application

is

described

in

terms

of

goals

and

actions

and

both

the

control

mechanisms

and

the

solution

strategies

can

be

easily

programmed

-LSB-

-RSB-

This

gives

the

capability

to

define

plans

according

to

the

reactive

or

to

the

look

ahead

paradigms

and

to

define

plans

where

different

control

strategies

-LRB-

belonging

to

different

paradigms

-RRB-

can

be

flexibly

intermixed

Finally

MRG

allows

to

control

and

recover

from

failures

in

a

flexible

way

This

is

achieved

by

having

explicit

control

constructs

for

failure

handling

in

MRG

plans

This

fact

provides

the

capability

to

recover

from

failure

depending

on

several

factors

such

as

the

particular

situation

where

failure

occurs

the

kind

of

failure

the

application

requirements

and

the

time

constraints

In

MRG

when

failure

occurs

it

is

possible

alternatively

to

replan

for

a

new

course

of

actions

-LRB-

e.g.

when

there

is

enough

time

and

reasoning

about

failure

is

required

-RRB-

to

execute

previously

generated

alternative

plans

-LRB-

e.g.

when

how

to

recover

from

failure

is

known

a

priori

-RRB-

and

to

execute

efficient

and

pre-compiled

exception

handling

routines

-LRB-

e.g.

when

time

is

critical

-RRB-

The

paper

is

organized

as

follows

The

architecture

of

MRG

is

presented

in

section

In

section

the

central

reasoner

is

presented

together

with

the

main

features

of

the

implementation

language

Sections

and

are

a

brief

description

of

the

navigation

system

and

the

interaction

system

respectively

Some

conclusions

are

given

in

section

terms

tactic

and

tactical

are

borrowed

from

ML

-LSB-

-RSB-

a

procedural

metalanguage

for

the

specification

of

theorem

proving

strategies

There

actually

exist

some

similarities

between

the

two

languages

but

there

are

rather

strong

conceptual

and

technical

differences

mainly

due

to

the

different

domains

of

application

The

multilevel

architecture

Task

of

MRG

is

to

manage

and

coordinate

the

functionalities

provided

by

a

set

of

peripheral

modules

which

are

external

to

MRG

and

carry

out

the

interaction

with

the

outside

world

They

are

ffl

the

vision

navigation

module

-LSB-

-RSB-

it

controls

the

navigation

of

the

mobile

platform

according

to

the

plan

generated

by

the

navigation

planner

It

is

able

to

process

data

from

a

set

of

cameras

and

sonars

in

order

to

drive

the

mobile

platform

avoiding

local

obstacles

ffl

the

speech

module

-LSB-

-RSB-

it

is

responsible

of

the

interaction

with

people

by

performing

speech

recognition

and

synshesis

ffl

the

graphic

module

-LSB-

-RSB-

it

allows

the

operator

to

interact

with

the

system

by

means

of

a

graphical

interface

displaying

the

map

and

the

movements

of

the

mobile

platform

The

internal

organization

of

MRG

is

given

by

the

multilevel

architecture

depicted

in

figure

At

the

bottom

of

the

architecture

there

is

a

set

of

interface

modules

Their

role

is

to

control

and

synchronize

the

flow

of

information

exchanged

between

the

upper

modules

and

the

peripheral

modules

performing

data

conversion

when

needed

From

a

structural

point

of

view

they

play

the

fundamental

role

of

abstracting

upper

modules

from

the

way

the

lower

modules

have

been

realized

Immediately

on

top

of

the

interface

modules

two

subreasoners

the

I/O

manager

and

the

navigation

planner

-LSB-

-RSB-

group

and

coordinate

the

activities

carried

out

by

the

peripheral

modules

providing

a

higher

level

set

of

functionalities

to

the

central

reasoner

Each

subreasoner

is

a

special

purpose

planner

dedicated

to

solve

a

particular

class

of

problems

by

controlling

the

activities

of

the

peripheral

modules

More

in

detail

ffl

The

I/O

manager

is

devoted

to

the

management

of

the

interaction

modules

-LRB-

i.e.

the

speech

module

and

the

graphic

module

-RRB-

It

coordinates

the

interaction

with

people

by

choosing

the

best

communication

modality

with

respect

to

the

current

situation

and

invoking

the

most

appropriated

peripheral

module

ffl

The

navigation

planner

exploiting

the

functionalities

provided

by

the

navigation

module

and

the

information

stored

in

the

map

provides

a

wide

spectrum

of

navigation

capabilities

being

able

both

to

react

to

external

events

and

to

deal

with

navigation

failures

This

organization

reflects

the

classification

of

the

activities

in

-LRB-

i

-RRB-

interaction

activities

processing

the

requests

coming

from

the

user

and

yielding

-LRB-

the

representation

of

-RRB-

corresponding

goals

to

be

solved

by

the

system

and

-LRB-

ii

-RRB-

navigation

activities

generating

a

navigation

plan

that

if

successfully

executed

by

the

vision

navigation

module

leads

the

robot

in

the

desired

place

The

obvious

advantage

of

such

a

structure

is

that

low

level

activities/decisions

-LRB-

e.g.

how

to

communicate

to

the

user

where

is

a

person

which

is

the

best

route

according

to

different

input

parameters

-RRB-

are

directly

solved

by

the

appropriate

sub-reasoner

Moreover

according

to

such

a

schema

it

is

possible

to

have

each

reasoner

running

for

a

different

goal

simultaneously

e.g.

the

I/O

manager

reasoning

about

the

interaction

with

the

user

while

MAIA

is

navigating

The

central

reasoner

-LSB-

-RSB-

which

is

on

the

top

of

the

architecture

carries

on

strategical

activities

such

as

the

activation

coordination

and

control

of

the

subreasoners

Given

a

goal

the

central

reasoner

chooses

a

plan

and

executes

it

The

execution

of

the

plan

may

require

the

activation

of

one

-LRB-

or

both

-RRB-

of

the

subreasoners

but

direct

access

to

the

peripheral

modules

-LRB-

via

the

interfaces

-RRB-

is

retained

to

keep

the

hierarchical

organization

Notice

that

the

proposed

architecture

besides

the

already

quoted

advantages

has

the

fundamental

and

practical

advantage

of

forcing

the

enucleation

of

the

set

of

-LRB-

primitives

-RRB-

functionalities

each

module

has

to

guarantee

to

the

upper

ones

i.e.

of

the

interfaces

between

modules

In

fact

once

this

has

been

done

the

development

and

maintainment

of

each

module

is

independent

of

the

way

other

modules

have

been

realized

provided

that

the

interface

is

the

same

The

central

reasoner

Task

of

the

central

reasoner

is

to

plan

coordinate

and

activate

the

functionalities

of

the

navigation

planner

and

of

the

I/O

manager

in

order

to

achieve

high

level

objectives

Given

a

goal

the

central

reasoner

by

exploiting

the

knowledge

it

has

about

the

capabilities

of

the

subreasoners

decides

a

combination

of

actions

-LRB-

i.e.

a

plan

-RRB-

that

when

executed

activate

and

control

the

sub-reasoners

to

achieve

the

goal

It

is

crucial

for

the

reasoner

to

perform

flexibly

these

tasks

mixing

the

phases

of

plan

formation

and

execution

in

suitable

ways

Consider

for

instance

the

following

examples

The

MAIA

robot

needs

to

look

for

a

person

in

IRST

that

is

known

to

work

usually

at

his

office

In

this

case

a

good

strategy

could

be

to

plan

everything

ahead

-LRB-

i.e.

to

generate

a

plan

combining

navigation

and

interaction

activities

-RRB-

and

execute

the

plan

In

case

of

failure

the

reasoner

can

replan

for

a

new

course

of

actions

This

sequence

of

plan

formation

followed

by

plan

execution

and

in

case

of

failure

by

replanning

is

very

similar

to

the

usual

classical

planning

control

mechanism

-LRB-

see

for

instance

-LSB-

-RSB-

-RRB-

Let

us

suppose

now

that

the

person

to

look

for

is

known

to

work

either

in

the

IRST

lab

or

at

his

office

In

this

case

a

good

strategy

could

be

to

plan

to

acquire

additional

information

-LRB-

e.g.

plan

the

path

to

a

close

secretary

office

execute

the

navigation

and

interact

to

actually

get

information

-RRB-

plan

for

moving

to

the

place

suggested

by

the

secretary

and

finally

execute

this

plan

to

actually

find

the

person

In

this

case

the

central

reasoner

can

not

generate

the

whole

plan

in

advance

as

it

depends

on

the

information

acquired

after

execution

is

activated

This

is

an

example

of

the

well

known

technique

of

deferred

planning

-LRB-

see

for

instance

-LSB-

-RSB-

-RRB-

Notice

how

given

a

goal

the

same

plan

formation

and

execution

phases

are

combined

in

a

different

way

with

respect

to

the

previous

example

Consider

finally

the

case

in

which

the

secretary

rather

than

providing

the

expected

information

informs

the

robot

about

an

unexpected

and

dangerous

event

-LRB-

e.g.

a

fire

-RRB-

and

the

goal

of

the

robot

is

to

execute

some

-LRB-

simple

-RRB-

safety

task

In

this

case

we

do

not

want

the

reasoner

to

activate

a

complex

plan

formation

task

to

find

a

plan

There

is

not

actually

enough

time

for

this

We

would

like

the

reasoner

to

skip

the

plan

formation

phase

and

switch

directly

to

the

execution

of

a

precompiled

plan

as

quickly

as

possible

This

control

mechanism

-LRB-

i.e.

no

plan

formation

phase

but

quick

response

to

environmental

events

-RRB-

resembles

in

some

way

most

of

the

embedded

planners

control

mechanisms

-LRB-

see

for

instance

-LSB-

-RSB-

-RRB-

The

flexibility

needed

to

combine

plan

formation

and

execution

in

the

most

suitable

way

is

also

required

for

failure

handling

Classical

planners

-LRB-

see

for

instance

-LSB-

-RSB-

-RRB-

when

failure

occurs

at

execution

time

always

replan

that

is

switch

the

control

to

the

plan

formation

phase

However

in

the

applications

we

want

MRG

to

support

failures

may

occur

with

different

features

e.g.

may

be

very

difficult

to

predict

and

prevent

may

not

allow

to

spend

time

in

replanning

or

may

require

a

reasoning

phase

about

the

causes

of

failure

in

order

to

devise

the

most

suitable

reaction

The

development

of

MRG

was

driven

by

the

requirement

of

flexibility

We

did

not

focus

on

the

classical

problems

of

planning

e.g.

how

to

represent

actions

by

means

of

preconditions

and

postconditions

over

their

applicability

which

particular

algorithms

can

be

used

to

perform

the

plan

formation

search

on

whether

to

use

a

state

space

search

or

a

partial

plan

search

On

the

contrary

we

focused

on

how

the

different

basic

plan

formation

mechanisms

provided

by

the

sub-reasoners

could

be

combined

with

the

execution

phase

and

how

to

deal

with

failures

that

require

different

kinds

of

recoveries

This

was

achieved

by

providing

MRG

with

a

programming

language

where

actions

solution

strategies

plan

formation

and

execution

are

uniformly

represented

as

expressions

called

tactics

The

tactic

language

is

provided

with

a

variety

of

control

mechanisms

which

-LRB-

i

-RRB-

allow

to

compose

simpler

plans

yielding

complex

ones

-LRB-

ii

-RRB-

make

natural

the

capturing

and

reaction

to

failures

and

-LRB-

iii

-RRB-

simplify

the

interchange

between

plan

formation

and

plan

execution

phase

This

gives

MRG

the

ability

to

combine

and

integrate

various

planning

techniques

makes

it

easy

to

add

new

modules

and

widens

the

range

of

applicability

of

MRG

to

domains

where

different

strategies

are

better

suited

The

tactical

language

Tactics

are

classified

in

primitive

tactics

and

compound

tactics

Primitive

tactics

represent

atomic

actions

executable

by

the

lower

level

modules

The

association

among

a

primitive

tactic

and

the

corresponding

action

is

stored

in

a

data

structure

called

tactic-action

pair

For

instance

the

primitive

tactics

t-set-arc-inaccessible

t-plan-shortest-routeand

t-exec-nav-plan

are

associated

to

the

functionalities

of

the

navigation

planner

set-arc-inaccessible

plan-shortest-route

and

the

navigation

interface

exec-nav-plan

respectively

Other

primitive

tactics

are

t-user-interface-confirm

and

t-user-interface-inform

Such

primitive

tactics

are

associated

to

the

functionalities

user-interface-confirm

and

user-interface-inform

of

the

I/O

manager

When

a

primitive

tactic

is

interpreted

the

corresponding

actions

is

executed

according

to

their

success

or

failure

the

primitive

tactic

is

said

to

succeed

or

to

fail

Compound

tactics

are

built

starting

from

the

primitive

ones

by

means

of

a

set

of

special

control

constructs

called

tacticals

A

compound

tactic

represents

a

complex

plan

which

may

be

also

a

planning

strategy

controlling

the

execution

of

different

activities

By

composing

tactics

various

planning

phenomena

can

be

reproduced

For

instance

interleaving

plan

formation

and

plan

execution

global

or

local

replanning

ad

hoc

strategies

execution

and

reaction

to

environmental

changes

The

tacticals

implemented

in

MRG

are

THEN

LET

IF

ORELSE

and

ffi

-LRB-

i.e.

composition

-RRB-

We

describe

briefly

the

interpretation

of

the

tacticals

-LRB-

in

the

following

are

tactics

var

a

variable

-RRB-

THEN

The

-LRB-

THEN

tn

-RRB-

tactical

builds

sequential

tactics

The

argument

tactics

are

intended

to

be

executed

in

the

given

sequential

order

If

one

of

ti

fails

of

the

following

tactics

will

be

executed

and

the

overall

tactic

fails

The

following

tactic

makes

the

mobile

platform

to

move

along

the

path

-LRB-

-LRB-

t-exec-nav-plan

plan

-RRB-

-RRB-

and

then

tell

the

user

that

the

navigation

has

phase

is

terminated

-LRB-

t-user-interface-inform

-RRB-

-LRB-

THEN

-LRB-

t-exec-nav-plan

plan

-RRB-

-LRB-

t-user-interface-inform

the

navigation

is

finished

-RRB-

-RRB-

LET

The

-LRB-

LET

-LRB-

-LRB-

var

-RRB-

-RRB-

-RRB-

tactical

is

used

to

evaluate

and

to

store

its

return

value

in

var

which

can

be

subsequently

used

by

A

LET

tactic

fails

if

and

only

if

either

or

fails

The

following

tactic

makes

the

system

to

plan

a

route

-LRB-

t-plan-shortest-route

-RRB-

to

store

the

route

in

the

variable

plan

to

communicate

the

user

the

plan

-LRB-

t-user-interface-inform

-RRB-

and

finally

to

execute

the

plan

-LRB-

t-exec-nav-plan

-RRB-

-LRB-

LET

-LRB-

-LRB-

plan

-LRB-

t-plan-shortest-route

location

-RRB-

-RRB-

-RRB-

-LRB-

THEN

-LRB-

t-user-interface-inform

plan

-RRB-

-LRB-

t-exec-nav-plan

plan

-RRB-

-RRB-

-RRB-

IF

The

IF

tactical

builds

conditional

tactics

In

-LRB-

IF

-RRB-

is

executed

first

If

it

succeeds

or

are

executed

according

to

the

result

A

conditional

tactic

fails

if

and

only

if

one

of

the

executed

tactics

fails

Via

the

IF

tactical

it

is

possible

for

example

to

ask

the

user

whether

a

given

plan

is

right

before

executing

-LRB-

IF

-LRB-

t-user-interface-confirm

plan

-RRB-

-LRB-

t-exec-nav-plan

plan

-RRB-

-LRB-

t-user-interface-inform

the

plan

has

not

been

executed

-RRB-

-RRB-

ORELSE

-LRB-

ORELSE

-RRB-

tries

and

in

case

of

failure

then

tries

Hence

ORELSE

is

the

control

construct

for

the

management

of

failure

ORELSE

is

in

a

certain

sense

the

most

important

tactical

Tactics

built

without

ORELSE

fail

any

time

the

execution

of

a

primitive

tactic

fails

This

is

completely

in

disagreement

with

the

intuition

that

after

the

failure

of

an

action

some

alternatives

should

be

tried

and

the

overall

process

might

succeed

anyway

Accordingly

-LRB-

ORELSE

-RRB-

may

be

thought

of

as

a

retrial

point

if

fails

then

is

tried

Since

and

can

represent

the

internal

activities

of

the

planner

-LRB-

e.g.

plan

formation

and

plan

execution

see

section

-RRB-

then

ORELSE

can

specify

different

kinds

of

failure

recoveries

The

following

tactic

plans

a

route

of

the

mobile

platform

-LRB-

t-plan-shortest-route

-RRB-

and

in

case

of

planning

failure

updates

the

map

-LRB-

t-set-arc-inaccessible

-RRB-

and

looks

for

a

new

plan

-LRB-

ORELSE

-LRB-

t-plan-shortest-route

location

-RRB-

-LRB-

THEN

-LRB-

t-set-arc-inaccessible

-RRB-

-LRB-

t-plan-shortest-route

location

-RRB-

-RRB-

-RRB-

ffi

The

ffi

tactical

means

functional

composition

The

tactical

ffi

is

necessary

in

order

to

use

tactics

as

arguments

of

other

tactics

as

in

-LRB-

t-exec-nav-plan

-LRB-

t-plan-shortest-route

location

-RRB-

-RRB-

The

language

to

describe

strategies

as

it

has

been

defined

so

far

always

forces

us

to

refer

to

combinations

of

primitive

tactics

the

system

also

features

a

definition

mechanism

-LRB-

through

the

construct

DEFTAC

-RRB-

to

introduce

new

tactic

identifiers

These

tactics

are

then

expanded

according

to

their

definition

at

execution

time

Consider

the

problem

of

sending

a

mobile

platform

to

a

given

place

in

a

building

-LRB-

location

-RRB-

only

if

the

operator

agrees

on

the

path

generated

by

the

planner

A

defined

tactic

which

can

perform

this

function

is

the

following

-LRB-

DEFTAC

t-goto-ask-user

-LRB-

location

-RRB-

-LRB-

LET

-LRB-

-LRB-

plan

-LRB-

t-plan-shortest-route

location

-RRB-

-RRB-

-RRB-

-LRB-

IF

-LRB-

t-user-interface-confirm

plan

-RRB-

-LRB-

t-exec-nav-plan

plan

-RRB-

-LRB-

t-user-interface-inform

the

plan

has

not

been

executed

-RRB-

-RRB-

-RRB-

-RRB-

The

tactic

t-goto-ask-user

defined

by

the

DEFTAC

construct

plans

for

a

route

where

the

mobile

platform

has

to

be

sent

-LRB-

t-plan-shortest-route

-RRB-

by

invoking

the

navigation

planner

records

the

route

in

the

variable

plan

asks

the

user

whether

the

path

plan

is

satisfactory

-LRB-

t-user-interface-confirm

-RRB-

for

instance

by

calling

the

speech

module

to

interact

by

voice

Only

if

the

answer

is

positive

MRG

actually

executes

the

plan

to

move

the

mobile

platform

along

the

path

-LRB-

t-exec-nav-plan

-RRB-

calling

the

vision

navigation

module

otherwise

the

failure

is

notified

by

the

graphic

interface

module

-LRB-

t-user-interface-inform

-RRB-

Flexible

planning

This

section

presents

how

plan

formation

and

execution

can

be

flexibly

represented

combined

and

interleaved

within

MRG

As

the

MRG

language

is

typed

-LRB-

an

example

of

type

being

goal

-RRB-

tactics

performing

plan

formation

and

execution

phases

can

be

classified

as

follows

according

to

their

type

Plan

formation

In

MRG

plan

formation

activities

are

represented

by

tactics

whose

argument

is

of

type

goal

and

whose

return

value

is

of

type

tactic

We

call

these

kinds

of

tactics

plan-for

tactics

There

are

several

plan-for

tactics

in

the

MRG

library

They

can

be

either

primitive

or

defined

tactics

A

primitive

plan-for

tactic

represents

a

fixed

process

searching

over

tactics

to

find

a

solution

to

the

given

goal

The

simplest

plan-for

tactic

we

can

think

of

is

a

function

that

given

a

goal

returns

the

corresponding

tactic

in

a

goal-tactic

table

-LRB-

this

idea

resembles

in

some

way

the

reactive

planning

approach

-LSB-

-RSB-

-RRB-

Of

course

a

plan-for

tactic

can

also

be

very

complex

for

instance

it

could

call

a

full

blown

classical

planner

The

tactic

t-plan-shortest-route

shown

in

section

is

a

plan-for

tactic

A

defined

plan-for

tactic

is

built

from

primitive

ones

Its

definition

is

accessible

by

the

user

and

is

modifiable

according

to

the

application

domain

The

tactic

t-goto-ask-user

shown

in

section

is

a

defined

plan-for

tactic

Plan

execution

Plan

execution

activities

are

represented

by

exec

tactics

whose

argument

has

type

tactic

When

interpreted

by

the

MRG

interpreter

an

exec

tactic

executes

the

argument

tactic

In

case

of

success

it

returns

the

result

of

the

execution

otherwise

it

fails

The

tactic

t-exec-nav-plan

shown

in

section

is

an

exec

tactic

Plan

formation

execution

The

global

task

of

MRG

is

to

carry

out

the

functionalities

of

subreasoners

and

interfaces

in

order

to

achieve

some

defined

purpose

This

task

is

represented

in

MRG

by

the

solve

tactics

whose

argument

is

of

the

type

goal

Simple

solve

tactics

are

compositions

of

plan-for

and

exec

tactics

where

plan

formation

is

followed

by

plan

execution

This

is

what

usually

happens

in

classical

planners

-LRB-

as

for

instance

in

-LSB-

-RSB-

-RRB-

For

instance

-LRB-

DEFTAC

t-classic-goto

-LRB-

position

-RRB-

-LRB-

t-exec-nav-plan

-LRB-

t-plan-shortest-route

position

-RRB-

-RRB-

-RRB-

where

t-exec-nav-plan

and

t-plan-shortest-route

are

an

execution

and

a

plan

formation

tactic

respectively

Note

that

the

two

fundamental

planning

steps

plan

formation

and

plan

execution

are

represented

explicitly

and

kept

separated

by

the

t-plan-shortest-route

and

the

t-exec-nav-plan

tactics

Given

the

ability

of

performing

flexible

planning

MRG

can

express

the

capability

of

exploring

not

only

the

information

contained

in

the

model

of

the

world

described

in

the

map

and

in

the

knowledge

base

but

also

the

information

provided

by

the

real

world

This

information

can

be

acquired

from

the

world

during

the

problem

solving

activity

by

deferring

the

plan

formation

phase

-LSB-

-RSB-

It

is

thus

possible

to

perform

deferred

planning

interleaving

plan

formation

and

execution

in

order

to

acquire

information

at

execution

time

as

shown

by

the

following

example

-LRB-

DEFTAC

t-deferred-goto

-LRB-

desk-loc

-RRB-

-LRB-

THEN

-LRB-

t-exec-nav-plan

-LRB-

t-plan-shortest-route

-LRB-

t-door-loc-of

-LRB-

t-office-of

desk-loc

-RRB-

-RRB-

-RRB-

-RRB-

-LRB-

IF

-LRB-

t-door-open

-RRB-

-LRB-

t-exec-nav-plan

-LRB-

t-plan-shortest-route

desk-loc

-RRB-

-RRB-

-LRB-

THEN

-LRB-

t-open-door

-RRB-

-LRB-

t-exec-nav-plan

-LRB-

t-plan-shortest-route

desk-loc

-RRB-

-RRB-

-RRB-

-RRB-

-RRB-

-RRB-

The

tactic

t-deferred-goto

is

a

strategy

to

make

the

mobile

platform

to

reach

a

desk

location

in

an

office

desk-loc

Rather

than

planning

to

go

to

the

desk

location

the

tactic

plans

to

move

the

mobile

platform

to

the

door

of

the

office

where

the

desk

is

located

-LRB-

-LRB-

t-door-loc-of

-LRB-

t-office-of

desk-loc

-RRB-

-RRB-

-RRB-

The

generation

of

the

plan

to

reach

the

desk

location

-LRB-

t-exec-nav-plan

-LRB-

t-plan-shortest-path

-RRB-

-RRB-

is

then

deferred

until

MRG

knows

whether

the

door

of

the

office

is

open

t-door-open

or

not

Notice

that

the

apparent

similarity

of

MRG

tactics

with

conventional

programming

languages

-LRB-

e.g.

LISP

-RRB-

is

only

syntactical

First

of

all

the

building

blocks

of

the

MRG

language

primitive

tactics

represent

basic

planning

activities

Second

we

have

circumscribed

the

constructs

of

a

programming

language

that

are

needed

for

controlling

planner

activities

For

instance

ORELSE

allows

us

to

handle

failure

Furthermore

MRG

provides

an

architecture

to

manage

tactics

to

relate

tactics

to

goals

and

facts

and

to

activate

tactics

to

respond

to

goals

and

facts

These

mechanisms

are

not

provided

by

general

purpose

programming

languages

Finally

and

perhaps

most

importantly

for

the

practical

use

of

MRG

the

level

of

abstraction

is

much

higher

than

in

a

general

purpose

programming

language

Within

MRG

libraries

of

reusable

tactics

are

provided

-LRB-

see

-LSB-

-RSB-

for

more

details

-RRB-

so

that

the

application

does

not

have

to

be

developed

from

scratch

The

navigation

system

Task

of

the

navigation

system

is

-LRB-

i

-RRB-

to

devise

a

plan

that

-LRB-

if

successfully

executed

-RRB-

should

make

the

mobile

platform

reach

the

desired

location

-LRB-

ii

-RRB-

to

interact

with

the

vision

navigation

module

to

have

the

plan

executed

-LRB-

iii

-RRB-

to

monitor

execution

and

-LRB-

iv

-RRB-

to

recover

from

failure

This

approach

allows

to

achieve

simultaneously

both

the

capability

of

immediately

responding

to

most

of

the

arising

unpredictable

situations

-LRB-

e.g.

the

mobile

platform

stops

if

a

person

abruptly

appears

in

front

of

it

-RRB-

and

the

ability

of

providing

high

level

navigation

functionalities

to

the

central

reasoner

The

main

component

of

the

navigation

system

is

the

navigation

planner

which

plans

with

different

modalities

the

route

of

the

mobile

platform

by

exploiting

an

internal

map

of

the

building

-LRB-

see

section

-RRB-

The

execution

of

plans

is

carried

out

by

exploiting

the

functionalities

provided

by

the

vision

navigation

module

-LSB-

-RSB-

which

executes

real

word

actions

and

acquires

information

from

the

environment

by

using

several

types

of

sensors

A

bidirectional

interface

-LRB-

the

navigation

interface

-LSB-

-RSB-

-RRB-

manages

the

interaction

between

the

navigation

planner

and

the

vision

navigation

module

An

example

of

information

sent

to

the

navigation

planner

is

the

success

or

failure

during

execution

The

map

The

map

-LSB-

-RSB-

is

the

data

base

encoding

the

knowledge

about

the

navigation

domain

Such

information

is

exploited

by

the

navigation

system

during

the

plan

formation

activity

The

main

problem

is

to

determine

the

relevant

information

needed

by

the

navigation

system

about

the

domain

The

map

is

organized

as

a

graph

whose

nodes

represent

areas

of

the

building

and

whose

arcs

represent

the

connections

between

them

In

figure

is

depicted

a

map

currently

used

by

MRG

The

nodes

are

defined

and

classified

depending

on

the

navigation

capabilities

of

the

reactive

system

Currently

the

following

four

types

of

nodes

are

provided

corridor

open-space

room

and

cross

This

classification

is

important

since

MAIA

has

different

navigation

capabilities

depending

on

the

type

of

area

For

instance

in

a

corridor

the

mobile

platform

is

able

to

navigate

following

the

walls

while

in

an

open

space

it

may

try

to

follow

the

route

suggested

by

the

navigation

planner

Arcs

are

classified

as

open

and

door

An

arc

of

type

open

represents

for

instance

a

virtual

connection

between

two

pieces

of

the

same

physical

corridor

or

between

a

corridor

and

a

cross

An

arc

of

type

door

can

represent

a

door

connecting

areas

of

any

type

Associated

to

each

arc

and

node

is

a

complex

data

structure

storing

significant

information

about

the

navigation

and

a

set

of

different

costs

representing

the

difficulty

of

navigation

between

the

nodes

connected

by

the

arc

Namely

-LRB-

i

-RRB-

a

geometrical

cost

-LRB-

function

of

the

distance

between

the

nodes

-RRB-

-LRB-

ii

-RRB-

a

navigation

cost

-LRB-

curves

are

more

expensive

than

aligned

nodes

-RRB-

and

-LRB-

iii

-RRB-

a

crowding

cost

-LRB-

crowded

areas

are

more

difficult

to

navigate

-RRB-

Such

costs

may

assume

as

value

a

positive

integer

or

INFINITE

The

latter

case

represents

the

impossibility

to

navigate

through

the

arc

Besides

information

useful

for

the

navigation

to

each

node

it

is

also

associated

the

set

of

contained

objects

each

one

described

by

the

coordinates

of

its

own

center

of

gravity

dimensions

and

so

on

Figure

is

a

list

of

the

most

significant

primitives

providing

access

to

the

information

stored

in

the

map

Most

of

the

information

is

stored

in

the

map

at

the

moment

of

the

definition

of

the

navigation

domain

but

part

of

it

-LRB-

e.g.

descriptions

of

navigation

sessions

success

or

failure

obstacle

descriptions

-RRB-

can

be

also

updated

by

MRG

at

run

time

and

be

exploited

during

the

planning

phase

For

instance

if

many

navigation

failures

occur

due

to

crowding

in

the

same

area

the

corresponding

crowding

cost

can

be

updated

The

navigation

planner

The

navigation

planner

-LSB-

-RSB-

plans

for

a

trajectory

-LRB-

i.e.

a

sequence

of

adjacent

nodes

in

the

map

-RRB-

which

can

be

executed

by

invoking

the

vision

navigation

module

Since

the

planning

phase

needs

to

be

fast

but

also

to

devise

trajectories

with

different

features

it

is

actually

performed

by

a

set

of

special

purpose

algorithms

called

planners

planners

search

through

the

graph

of

nodes

minimizing

one

-LRB-

or

a

given

combination

-RRB-

of

costs

In

this

way

for

instance

if

navigation

time

is

important

a

navigation

plan

through

-LRB-

usually

-RRB-

less

crowded

areas

-LRB-

as

returned

by

least-crowded-path

-RRB-

can

be

better

than

a

plan

devised

taking

into

account

only

geometrical

information

-LRB-

e.g.

by

shortest-path

-RRB-

There

are

also

more

complex

functionalities

which

are

used

when

the

navigation

goal

is

more

complex

than

reaching

a

single

location

the

search

can

be

performed

to

reach

a

node

belonging

to

a

given

set

of

final

nodes

and

constraints

can

be

put

on

the

admissible

paths

like

avoiding

certain

nodes

or

passing

through

a

list

of

nodes

with

-LRB-

or

without

-RRB-

a

given

order

The

most

significant

planners

are

listed

in

figure

The

navigation

interface

The

navigation

interface

-LSB-

-RSB-

hides

the

functionalities

of

the

vision

navigation

module

by

providing

for

a

set

of

queries

and

navigation

commands

the

most

important

being

reported

in

figure

Navigation

commands

control

the

navigation

of

the

robot

along

a

plan

of

the

form

produced

by

the

planners

For

instance

the

navigation

command

exec-nav-plan

activates

the

navigation

of

the

robot

along

the

path

specified

as

input

Queries

return

information

about

the

status

of

the

navigation

For

instance

the

query

query-position

returns

the

node

in

the

map

representing

the

current

position

of

the

mobile

robot

Since

the

navigation

planner

handles

symbolic

information

-LRB-

e.g.

nodes

of

the

map

-RRB-

and

the

vision

navigation

module

performs

numerical

computations

the

interface

also

performs

the

data

conversion

between

the

two

formats

Reasoning

about

navigation

strategies

The

map

the

planners

and

the

interface

provide

the

basic

steps

of

the

navigation

activity

However

these

steps

have

to

be

combined

and

integrated

with

different

modalities

according

to

the

goal

of

the

navigation

and

to

the

success

or

failure

of

navigation

Choosing

a

particular

sequence

of

steps

-LRB-

e.g.

plan

for

a

path

with

a

particular

planner

execute

it

and

if

a

failure

occurs

replan

and

reexecute

-RRB-

is

not

satisfactory

at

all

different

navigation

modalities

and

different

failure

recovery

strategies

may

be

more

suitable

for

different

-LRB-

high

level

-RRB-

goals

For

this

reason

the

navigation

strategies

are

expressed

and

combined

as

tactics

where

the

modalities

of

navigation

and

reaction

to

failure

are

explicitly

represented

As

an

example

consider

that

the

vision

navigation

module

is

able

to

avoid

mobile

obstacles

like

human

users

but

in

case

of

failure

it

does

not

verify

whether

an

obstacle

is

permanent

it

only

communicates

the

failure

Possible

reactions

may

be

to

try

to

execute

the

rest

of

the

plan

assuming

that

obstacle

is

fixed

or

modify

the

map

by

cutting

the

suitable

arcs

with

the

primitive

set-arc-inaccessible

and

then

replan

for

a

different

path

The

interaction

system

The

interaction

system

is

activated

by

the

central

reasoner

in

order

to

have

an

interaction

goal

executed

The

main

module

of

the

interaction

system

is

the

I/O

manager

Task

of

the

I/O

manager

is

to

plan

the

dialogue

with

people

and

to

coordinate

the

peripheral

modules

-LRB-

namely

the

speech

module

and

the

graphic

module

-RRB-

Given

an

interaction

goal

to

achieve

the

I/O

manager

can

directly

invoke

the

peripheral

modules

or

perform

some

planning

to

decide

the

peripheral

modules

to

activate

and

the

order

of

activation

Simpler

tasks

are

achieved

by

executing

a

single

action

for

instance

the

task

to

synthesize

a

phrase

has

the

simple

solution

of

activating

the

speech

module

A

more

complex

interaction

task

consists

of

asking

the

user

-LRB-

for

instance

through

the

graphic

interface

-RRB-

whether

a

given

route

for

the

mobile

platform

is

satisfactory

allowing

the

user

to

modify

or

specify

the

route

by

means

of

a

combined

use

of

speech

and

graphic

capabilities

The

interaction

between

the

central

reasoner

and

the

I/O

manager

may

occur

either

because

the

central

reasoner

wants

some

information

to

be

transferred

to

the

user

or

because

the

I/O

manager

communicates

a

navigation

goal

-LRB-

on

request

by

the

user

-RRB-

to

be

achieved

The

main

interaction

primitives

provided

by

the

interaction

system

are

ffl

user-interaction-inform

communicates

to

the

user

the

result

of

the

execution

of

the

planning

and

of

the

navigation

activities

ffl

user-interaction-confirm

communicates

to

the

user

the

path

given

in

input

and

returns

the

confirmation

or

the

rejection

by

the

user

ffl

user-goal-ask

ask

the

user

for

a

goal

The

peripheral

modules

provide

the

I/O

manager

with

the

following

functionalities

ffl

Speech

Module

The

interaction

between

the

I/O

manager

and

the

speech

module

takes

place

by

means

of

the

two

primitive

operations

SAY

and

LISTEN

SAY

activates

the

synthesis

of

the

sentence

given

in

input

and

LISTEN

activates

the

recognition

process

on

the

sentence

uttered

by

the

person

returning

the

understood

sentence

The

of

these

operations

is

specified

in

figure

and

ffl

Graphic

Module

The

graphical

information

is

organized

in

views

A

view

is

a

data

structure

encoding

the

graphical

information

about

the

navigation

domain

description

of

the

semantical

and

pragmatical

import

of

the

language

is

out

of

the

goals

of

the

paper

-LRB-

more

information

can

be

found

in

-LSB-

-RSB-

-RRB-

However

an

intuitive

understanding

of

the

meaning

of

the

phrases

can

be

inferred

by

the

mnemonic

names

of

the

syntactical

categories

involved

in

the

BNF

grammar

-LRB-

retrieved

by

the

knowledge

base

-RRB-

the

state

of

the

robot

-LRB-

e.g.

position

and

orientation

-RRB-

the

paths

of

navigation

and

the

navigation

planner

activity

-LRB-

obtained

by

the

central

reasoner

-RRB-

The

graphics

module

by

drawing

onto

the

screen

the

information

stored

in

the

views

provides

a

set

of

functionalities

-LRB-

e.g.

generation

and

composition

of

views

zoom

simple

animation

of

the

robot

's

movements

for

monitoring

and

simulation

visualization

and

selection

of

the

navigation

path

-LRB-

s

-RRB-

for

the

robot

communication

capabilities

to

exchange

goals

with

the

I/O

manager

-RRB-

Application

in

MAIA

MRG

at

the

moment

is

being

used

in

MAIA

-LRB-

Advanced

Model

of

Artificial

Intelligence

-RRB-

a

mobile

robot

that

has

to

deliver

mail

faxes

and

packs

around

in

the

IRST

laboratory

Mail

can

be

delivered

on

a

routinary

basis

from

a

centralized

position

to

target

places

and

users

Faxes

and

packs

can

be

transported

on

request

Due

to

the

real-time

application

tasks

MRG

must

be

very

efficient

Most

of

the

implemented

classical

planners

are

very

slow

and

can

not

be

used

in

real-time

systems

On

the

other

hand

MRG

tactics

can

be

customized

to

achieved

desired

performances

So

far

we

have

mainly

worked

on

designing

efficient

tactics

for

the

navigation

planning

task

which

is

the

most

fundamental

task

Table

reports

data

with

the

planning

time

to

build

a

navigation

path

in

a

map

of

nodes

-LRB-

each

node

containing

an

average

of

objects

-RRB-

that

is

the

current

map

representing

the

IRST

building

in

the

MAIA

application

Given

the

maximum

robot

speed

-LRB-

meter/second

-RRB-

the

average

speed

of

m/sec

MAIA

is

thus

able

to

reach

a

meter

far

destination

in

less

than

minutes

Of

course

such

a

result

considers

normal

situations

i.e.

that

the

planned

route

is

effectively

viable

-LRB-

not

obstructed

-RRB-

In

cases

in

which

the

route

is

not

viable

then

the

re-planning

time

and

the

time

needed

to

go

from

the

actual

to

the

desired

position

must

be

also

taken

into

account

MAIA

is

realized

as

a

distribuited

architecture

comprising

the

mobile

robot

depicted

in

figure

and

several

other

machines

each

dedicated

to

a

particular

task

More

in

detail

on

board

of

the

mobile

platform

resides

sensors

computers

and

motors

Actually

sensorial

devices

comprise

sonars

odometers

and

cameras

Other

sensorial

devices

under

consideration

-LRB-

but

not

yet

installed

-RRB-

are

gyros

micro-switches

and

laser

scanners

The

robot

has

two

hours

maximum

autonomy

and

one

hour

average

autonomy

In

future

developments

the

robot

will

be

able

to

change

batteries

autonomously

MRG

itself

is

installed

as

a

distribuited

system

A

supervision

station

whose

functions

are

centralized

supervision

monitoring

and

control

is

installed

on

a

SUN-SPARCstation

workstation

Transportation

tasks

can

be

requested

potentially

from

several

different

machines

and

terminals

In

the

current

MAIA

implementation

requests

can

be

entered

from

four

workstations

SUN-SPARCstation

MRG

is

mainly

implemented

in

Lucid

Common

Lisp

in

UNIX

The

pheripheral

systems

-LRB-

e.g.

reactive

navigation

vision

processing

and

speech

recognition

-RRB-

that

usually

require

very

time-consuming

processes

are

installed

on

dedicated

machines

-LRB-

either

on

board

or

not

of

the

robot

-RRB-

They

are

implemented

in

programming

languages

different

from

Lisp

for

instance

most

of

the

reactive

navigation

and

visiom

modules

are

implemented

in

C-language

The

comunication

between

modules

either

within

MRG

or

between

MRG

modules

and

peripheral

modules

has

been

implemented

using

different

supports

mainly

sockets

and

files

depending

on

the

kind

of

processes

that

have

to

be

connected

For

instance

sockets

are

used

to

exchange

quickly

not

high

amounts

of

data

between

MRG

and

the

navigation

shell

An

interface

service

implemented

in

MRG

provides

a

communication

modality

independent

of

the

type

of

channel

that

is

used

This

improves

modularity

and

maintenance

which

are

very

critical

features

in

large-scale

heterogeneous

complex

applications

like

MAIA

A

further

technical

problem

that

we

have

faced

is

the

fact

that

even

if

UNIX

provides

efficient

remote

comunication

supports

not

all

the

programming

languages

-LRB-

e.g.

Lisp

w.r.t.

sockets

-RRB-

can

used

them

For

this

reason

we

have

implemented

in

C-language

a

library

of

fuctions

that

work

on

sockets

The

comunication

primitives

get

thus

implemented

in

C-language

and

imported

as

compiled

code

Finally

MRG

is

also

being

used

in

FIRST

-LRB-

Friendly

Interactive

Robot

for

Service

Tasks

-RRB-

an

EUREKA

project

that

aims

at

building

an

automatic

system

for

transportation

in

hospital

environments

The

system

is

organized

around

a

central

station

that

controls

a

group

of

robots

The

main

task

of

the

robots

is

the

transportation

of

materials

-LRB-

like

food

sheets

and

medicines

-RRB-

from

the

central

store

of

the

hospital

to

the

departments

For

this

tasks

MRG

needs

to

be

extended

to

control

and

coordinate

more

than

one

robot

navigating

and

interacting

in

the

environment

This

project

is

currently

in

the

design

phase

Conclusions

The

successful

application

of

a

general

purpose

planning

system

on

real

world

complex

application

domains

depends

on

which

extent

the

activities

of

plan

formation

plan

execution

monitoring

and

failure

handling

can

be

flexibly

interleaved

In

this

paper

we

presented

a

multilevel

reasoning

system

-LRB-

called

MRG

-RRB-

where

low

level

functionalities

-LRB-

e.g.

navigation

vision

and

speech

understanding

-RRB-

are

flexibly

combined

with

higher

level

reasoning

capabilities

through

a

set

of

specialized

subreasoners

In

most

of

the

existing

planning

systems

the

planning

activities

and

the

control

mechanism

are

fixed

in

the

implementation

code

The

basic

feature

of

MRG

is

that

there

is

no

commitment

to

a

fixed

planning

paradigm

Rather

it

is

possible

to

choose

the

most

appropriate

planning

technique

according

to

the

current

application

This

is

achieved

by

representing

the

different

reasoning

steps

control

strategies

and

error

recovery

mechanisms

explicitly

in

the

language

of

tactics

Acknowledgements

This

work

has

been

conducted

as

part

of

MAIA

an

integrated

AI

project

under

development

at

IRST

and

has

been

done

with

the

partial

support

of

the

Italian

National

Research

Council

-LRB-

CNR

-RRB-

Progetto

Finalizzato

Sistemi

Informatici

e

Calcolo

Parallelo

-LRB-

Special

Project

on

Information

Systems

and

Parallel

Computing

-RRB-

Fausto

Giunchiglia

has

supervised

the

development

of

MRG

and

provided

many

of

the

underlying

intuitions

Roberto

Giuri

and

Marco

Marinucci

have

participated

to

design

and

implementation

of

MRG

References

References

-LSB-

-RSB-

L.

Stringa

An

Integrated

Approach

to

Artificial

Intelligence

the

MAIA

Project

at

IRST

Technical

Report

IRST

Trento

Italy

-LSB-

-RSB-

R.

Fikes

P.

Hard

and

N.

Nilsson

Learning

and

executing

generalized

robot

plans

In

Readings

in

Artificial

Intelligence

pages

-LCB-

Palo

Alto

Columbia

-LSB-

-RSB-

D.

E.

Wilkins

Practical

Planning

extending

the

classical

AI

planning

paradigm

Morgan

Kaufmann

San

Mateo

-LSB-

-RSB-

R.

A.

Brooks

A

robust

layered

control

system

for

a

mobile

robot

IEEE

Journal

of

Robotics

and

Automation

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

L.P.

Kaelbling

An

architecture

for

intelligent

reactive

systems

In

Reasoning

about

actions

and

plans

Procedings

of

the

Workshop

Morgan-Kaufmann

Publishers

-LSB-

-RSB-

M.

Georgeff

A.

Lansky

and

M.

Schoppers

Reasoning

and

planning

in

dynamic

domains

An

experiment

with

a

mobile

robot

Technical

Report

A.I.

Center

SRI

International

-LSB-

-RSB-

R.

Simmons

Coordinating

planning

perception

and

action

for

mobile

robots

In

AAAI

Spring

Symposium

on

Integrated

Intelligent

Architectures

pages

-LCB-

SIGART

Bulletin

vol

no.

-LSB-

-RSB-

M.J.

Gordon

A.J.

Milner

and

C.P.

Wadsworth

Edinburgh

LCF

A

mechanized

logic

of

computation

volume

of

Lecture

Notes

in

Computer

Science

Springer

Verlag

-LSB-

-RSB-

P.

Traverso

A.

Cimatti

L.

Spalazzi

and

E.

Giunchiglia

Building

planners

with

explicit

control

mechanisms

In

Proceedings

International

Symposium

on

Artificial

Intelligence

Cancun

Mexico

AAAI

Press

Revised

version

of

IRST

Technica

Report

IRST

Trento

Italy

-LSB-

-RSB-

R.

Cattoni

and

B.

Caprile

Navigation

Shell

Planning

and

Supervising

Reflexive

Indoor

Navigation

Forthcoming

IRST

Technical

Report

-LSB-

-RSB-

B.

Angelini

G.

Antoniol

M.

Dal

Zotto

R.

De

Mori

D.

Giuliani

R.

Gretter

and

G.

Lazzari

Use

of

procedural

networks

for

task

oriented

dialogue

modelling

in

mobile

robot-operator

voice

communication

In

EUSIPCO

pages

-LCB-

Barcelona

Spain

September

-LSB-

-RSB-

S.

Dalbosco

F.

Giunchiglia

and

Jon

Slack

Funzionalit?a

dell

interfaccia

grafica

M/M

nel

progetto

MAIA

Forthcoming

IRST

Technical

Report

-LSB-

-RSB-

S.

Dalbosco

and

F.

Giunchiglia

Il

pianificatore

di

navigazione

Technical

Report

IRST

Trento

Italy

-LSB-

-RSB-

A.

Cimatti

P.

Traverso

S.

Dalbosco

and

A.

Armando

Navigation

by

Combining

Reactivity

and

Planning

In

Proc

Intelligent

Vehicles

Detroit

IRST

Technical

Report

IRST

Trento

Italy

-LSB-

-RSB-

L.

Spalazzi

A.

Cimatti

and

P.

Traverso

Implementing

planning

as

tactical

reasoning

In

Proc

AIS

AI

Simulation

and

Planning

in

High

Autonomy

Systems

Conference

pages

-LCB-

Perth

Australia

IEEE

Computer

Society

Press

Revised

version

of

Technical

Report

IRST

Trento

Italy

-LSB-

-RSB-

P.

Traverso

A.

Cimatti

and

L.

Spalazzi

Beyond

the

single

planning

paradigm

introspective

planning

In

Proceedings

pages

-LCB-

Vienna

Austria

IRST-Technical

Report

IRST

Trento

Italy

-LSB-

-RSB-

R.

E.

Fikes

and

N.

J.

Nilsson

STRIPS

A

new

approach

to

the

application

of

Theorem

Proving

to

Probl

em

Solving

Artificial

Intelligence

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

E.H.

Durfee

and

V.R.

Lesser

Incremental

Planning

to

Control

a

Blackboard-based

Problem

Solver

In

Proc

of

the

National

Conference

on

Artificial

Intelligence

Philadelphia

PA

-LSB-

-RSB-

M.

P.

Georgeff

Situated

Reasoning

and

Rational

Behaviour

Technical

Report

Australian

AI

Institute

Carlton

Victoria

Australia

-LSB-

-RSB-

R.

Simmons

Concurrent

planning

and

execution

for

a

walking

robot

In

Proc

IEEE

International

Conference

on

Robotics

and

Automation

pages

-LCB-

Sacramento

CA

-LSB-

-RSB-

M.

Georgeff

and

A.

L.

Lansky

Reactive

reasoning

and

planning

In

Proc

of

the

National

Conference

on

Artificial

Intelligence

pages

-LCB-

Seattle

WA

USA

-LSB-

-RSB-

M.

Georgeff

An

embedded

reasoning

and

planning

system

In

J.

Tenenberg

J.

Weber

and

J.

Allen

editors

Proc

from

the

Rochester

Planning

Workshop

from

Formal

Systems

to

Practical

Systems

pages

-LCB-

Rochester

-LSB-

-RSB-

D.H.D.

Warren

WARPLAN

A

System

for

Generating

Plans

Dept.

of

Computational

Logic

Memo

Artificial

Intelligence

University

of

Edinburgh

-LSB-

-RSB-

A.

Tate

Generating

Project

Networks

In

Proc

of

the

International

Joint

Conference

on

Artificial

Intelligence

pages

-LCB-

-LSB-

-RSB-

E.D.

Sacerdoti

A

Structure

for

Plans

and

Behaviour

Elsevier-North

Holland

-LSB-

-RSB-

P.R.

Davis

and

R.T.

Chien

Using

and

Reusing

partial

plans

In

Proc

of

the

International

Joint

Conference

on

Artificial

Intelligence

Cambridge

Massachussets

-LSB-

-RSB-

B.

Caprile

R.

Cattoni

A.

Cimatti

F.

Giunchiglia

and

P.

Traverso

Proposta

di

interfaccia

ragionamento

meccanizzato-visione

nell

ambito

del

progetto

maia

versione

IRST

Internal

Report

no.

-LSB-

-RSB-

S.

Dalbosco

and

F.

Giunchiglia

La

mappa

dell

IRST

Versione

Technical

Report

IRST

Trento

Italy

Internal

Report

-LSB-

-RSB-

S.

Dalbosco

and

F.

Giunchiglia

Software

per

la

gestione

di

un

sistema

di

navigazione

Versione

Technical

Report

IRST

Trento

Italy

-LSB-

-RSB-

R.

Cattoni

A.

Cimatti

and

S.

Dalbosco

Proposta

di

interfaccia

Ragionamento

Meccanizzato-Visione

nell

ambito

del

progetto

MAIA

Versione

IRST

Internal

Report

no.

-LSB-

-RSB-

F.

Giunchiglia

P.

Traverso

A.

Cimatti

and

L.

Serafini

Documento

di

interfaccia

tra

il

ragionatore-pianificatore

centrale

ed

il

modulo

di

voce

-LRB-

versione

-RRB-

IRST

Internal

Report

no

AUTHOR

'S

BIOGRAPHIES

Alessandro

Armando

received

the

M.S.

in

electronic

engineering

from

the

University

of

Genoa

Italy

in

He

is

currently

attending

a

Ph.D.

program

within

the

Mechanized

Reasoning

Group

at

the

Dipartimento

di

Informatica

Sistemistica

e

Telematica

dell

Universit?a

di

Genova

His

present

research

interests

include

planning

problem

solving

and

automated

deduction

Alessandro

Cimatti

received

the

M.S.

in

electronic

engineering

from

the

University

of

Genoa

Italy

in

Since

he

has

a

researcher

position

within

the

Mechanized

Reasoning

Group

at

Istituto

per

la

Ricerca

Scientifica

e

Tecnologica

in

Trento

Italy

Currently

he

is

interested

in

introspective

systems

for

planning

and

automated

deduction

Enrico

Giunchiglia

received

the

M.S.

in

electronic

engineering

and

the

Ph.D.

in

electronic

and

computer

science

from

the

University

of

Genoa

Italy

in

and

respectively

He

is

currently

working

in

the

Mechanized

Reasoning

Group

at

the

Dipartimento

di

Informatica

Sistemistica

e

Telematica

dell

Universit?a

di

Genova

His

present

research

interests

include

planning

and

knowledge

based

architectures

Paolo

Pecchiari

received

the

M.S.

in

Mathematics

from

the

University

of

Trento

Italy

in

He

is

currently

working

in

the

Mechanized

Reasoning

Group

at

the

Dipartimento

di

Informatica

Sistemistica

e

Telematica

dell

Universit?a

di

Genova

where

he

attends

a

Ph.D.

program

in

electronic

and

computer

science

His

main

research

interests

are

the

development

and

theoretical

study

of

knowledge

based

systems

in

robotics

CAD

systems

and

theorem

proving

applications

Luca

Spalazzi

received

the

M.S.

in

electronic

engineering

at

the

University

of

Ancona

Italy

in

He

is

currently

attending

a

Ph.D.

program

within

the

Mechanized

Reasoning

Group

at

the

Istituto

di

Informatica

dell

Universit?a

di

Ancona

His

present

research

interests

include

the

integration

of

deductive

and

reactive

planning

Paolo

Traverso

-LRB-

-RRB-

studied

electronic

engineering

at

the

University

of

Genoa

where

he

graduated

in

He

is

currently

a

senior

researcher

within

the

Mechanised

Reasoning

Group

at

IRST

Istituto

per

la

Ricerca

Scientifica

e

Tecnologica

Trento

Italy

His

present

research

interests

include

the

integration

of

deductive

and

reactive

planning

the

design

and

implementation

of

architectures

for

complex

real

world

largescale

applications

and

meta

level

reasoning

techniques

List

of

Figures

The

mobile

robot

MAIA

The

multilevel

architecture

of

MRG

The

map

Function

accessing

to

the

map

Most

significant

planners

Navigation

commands

The

syntax

of

a

SAY

operation

The

syntax

of

a

LISTEN

operation

Figure

The

mobile

robot

MAIA

Average

Minimum

Maximum

Table

Navigation

Planning

Times

-LRB-

in

seconds

-RRB-

MOBILE

ROBOT

NAVIGATION

PLANNER

NAVIGATION

INTERFACE

VISION

NAVIGATION

NAVIGATION

SYSTEMMAP

GRAPHICS

INTERFACE

GRAPHICS

INTERACTION

SYSTEM

MRG

SPEECH

INTERFACE

SPEECH

USER

KB

CENTRAL

REASONER

I/O

MANAGER

Figure

The

multilevel

architecture

of

MRG

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

aess

oe

oe-oe

oe

oe

oe

oe

oe

oe

oe

oe

oe

oe

oe

oe

oe

oe

oe-oe

oe-oe-oe

oe

oe

oe

Figure

The

map

map

access

primitive

computed

result

node-get-objects

list

of

objects

associated

to

the

node

given

in

input

arc-get-type

type

of

the

arc

given

in

input

-LRB-

i.e.

door

or

open-space

-RRB-

arc-get-geocost

geometrical

cost

associated

to

the

arc

given

in

input

-LRB-

i.e.

the

distance

between

the

barycenters

of

the

connected

areas

-RRB-

arc-get-navcost

navigation

cost

associated

to

the

arc

given

in

input

-LRB-

i.e.

the

difficulty

in

navigating

through

the

arc

-RRB-

arc-get-crowding

crowding

cost

associated

to

the

arc

given

in

input

-LRB-

i.e.

the

statistical

probability

to

find

the

arc

crowded

-RRB-

set-arc-inaccessible

sets

the

geometrical

navigation

and

crowding

costs

to

INFINITE

Figure

Function

accessing

to

the

map

planner

computed

path

shortest-path

geometrically

shortest

path

least-crowded-path

best

path

according

to

the

crowding

cost

easiest-path

best

path

according

to

the

navigation

cost

least-cost-path

best

path

according

to

the

cost

function

provided

as

input

-LRB-

it

can

be

a

combination

of

other

costs

contained

in

the

map

-RRB-

all-paths

list

of

the

possible

paths

from

starting

to

target

position

ord-constrained-paths

list

of

all

the

paths

from

starting

to

target

position

constrained

to

pass

through

a

list

of

specified

locations

according

to

a

supplied

ordering

relation

unord-constrained-paths

list

of

all

the

paths

from

starting

to

target

position

constrained

to

pass

through

a

list

of

specified

locations

in

the

most

convenient

order

shortest-ord-constrained-path

geometrically

shortest

path

between

the

ones

satisfying

the

set

of

ordered

constraints

specified

Figure

Most

significant

planners

function

navigation

command

exec-nav-plan

translates

the

navigation

plan

in

a

sequence

of

landmarks

sends

the

sequence

to

the

modules

controlling

the

sensors

and

actuators

of

the

mobile

robot

and

receives

information

about

the

navigation

execution

suspend-nav-plan

stops

the

navigation

in

the

current

state

restart-nav-plan

restarts

a

suspended

navigation

kill-nav-plan

terminates

the

navigation

exec-monitor-node

given

a

tactic

representing

a

path

as

input

executes

the

tactic

by

monitoring

information

each

time

the

robot

navigates

through

a

new

node

in

the

map

exec-monitor-distance

executes

a

tactic

and

monitors

the

position

of

the

robot

every

time

the

robot

has

navigated

for

a

given

distance

exec-monitor-time

executes

a

tactic

and

monitors

the

position

of

the

robot

at

each

given

time

interval

signal-robot-presence

activates

one

or

more

devices

-LRB-

e.g.

a

beeper

a

hazard

light

-RRB-

to

signal

the

presence

of

the

robot

perceive-fixed-obstacle

activates

the

navigation

level

to

recognize

the

presence

of

fixed

obstacles

perceive-crowding

activates

the

navigation

level

to

recognize

the

presence

of

crowding

query-position

returns

the

node

in

the

map

representing

the

current

position

of

the

mobile

robot

query-state

returns

the

current

state

of

navigation

-LRB-

e.g.

navigating

suspended

success

failure

-RRB-

query-failure-description

returning

a

description

of

the

failure

query-navigation-history

returns

a

path

describing

the

navigation

so

far

Figure

Navigation

commands

<say-phrase>

SAY

<phrase>

<phrase>

<utterance>

<question>

<question>

y/n-question

<wh-question>

<wh-question>

<who-question>

<where-question>

<what-question>

Figure

The

syntax

of

a

SAY

operation

<listen-label>

LISTEN

<label>

<label>

<label>

Or

<label>

Seq

<label-list>

List

<label>

Goal

Person

Location

Relativelocation

Condition

Side

Direction

Truthvalue

Figure

The

syntax

of

a

LISTEN

operation

integrated system
planning and reasoning