Automated Action Planning for Autonomous Mobile Robots: Papers from the 2011 AAAI Workshop (WS-11-09)
Execution and Representation of Actions and
Plans in ActionPool Method
Tapio Taipalus
Department of Automation and Systems Technology
Aalto University, Finland
Abstract
Action pool
Task
Task
In this paper, a practical example of implemented high
abstraction-level control of mobile robot is presented. A
method to represent abstract plans is shown along with
a mechanism to schedule the actions within the plans
for concurrent execution. Furthermore, a mechanism to
consider contingencies and dynamic environment is explained.
Action pool
Event Listener
Action
Action
Task
Action
Action
Action
Action
Event Listener
Action
Task
Event Listener
Action
Event Listener
Action
Action
Task
Task
Task
Task
Plan of selected Action
Plan of selected Action
EL
DB
EL
Plan execution
Plan execution
Perception
Perception
Perception
Agent Agent Agent
Resource
Resource
Robot body
Environment
Figure 1: Overview of ActionPool method See the text for
explanation of the component names.
Introduction
Planning in mobile robotics is a very challenging problem.
The unexpectedly changing environment and complexity of
the experimental setups make the experiments slow to conduct and difficult to repeat. Furthermore, the actual outcome
and effect of the action can also be difficult to perceive. For
example, how can a vacuum cleaning robot know if the area
that it has covered is actually clean or not?
ActionPool
The ActionPool method is a resource usage scheduling
method developed for service robots. It includes definition
of the plan representation and dynamic reactions to the
changes in the environment or to the course of execution.
The main idea is to use actions in the specified abstraction
level. An action in this context is one “usage” of the resource, i.e. action can not be interrupted without compromising its success.
Typically, in a service-robot there are physical resources
that occupy some space. Furthermore, you can reserve the
resource based on a point in the space, i.e. you can move
the mobile robot to desired co-ordinates, you can place the
endpoint of the manipulator into certain point . As a definition, one resource can not be divided among multiple actions
concurrently because the resource can not be in two places
simultaneously.
As the name suggests, in the ActionPool method the actions, that are ready for execution, are placed into a pool
(AP). Each time an action is removed or added to the pool,
the best suited action for the situation is selected for execution. When the selected action is completed, it is removed
from the pool. The overall schema of the ActionPool architecture is presented in Figure 1. The tasks add actions to the
Action pool. The Event Listeners (EL) watch for changes in
In automated planning the representation of the plan is
done in terms of the planning process. The approach in this
paper stems more from the requirements of the execution
process and experiments.
In this work, a multi-tasking mobile service robot operating in an unstructured environment shared with other independent agents is studied. The effect of the domain dictates
the assumptions that can be made and thus has a dominant
effect on the solution. The following assumptions, used in
this work, can be made based on the described domain: 1)
We can not anticipate or numerate the possible outcome of
the action. 2) A robot does not understand the purpose of the
action in real-world. 3) A robot has a perception capable of
recognizing and localizing relevant objects. 4) A robot has a
map of relevant objects that it can not recognize or localize.
In this paper, a representation of planned actions and their
execution is examined. First, the ActionPool method for the
mobile robot and notation for the plan are briefly introduced.
Next, a more detailed explanation of the action selection and
world model are given. Finally, the work is summarized in
the conclusions.
c 2011, Association for the Advancement of Artificial
Copyright Intelligence (www.aaai.org). All rights reserved.
78
the environment and add their corrective actions to the pool.
ELs do not observe the environment directly but observe the
world model database (DB). The DB is updated by the Perception Agents.
Two cascaded control loops from the environment are depicted in Figure 1: first, the tighter control loop with direct
observations from the environment, and second, a somewhat
slower loop through Perception Agents and ELs for the more
abstract control.
action selection, a comparison value is calculated for each
action in the pool according to the following equation.
−t
t=
λ = p + e tave , where
tp + tr + vp +
vr
tp + tr + tw + vp + vr + vw
if running action
other actions in the pool
(1)
.
Here, the current situation is first represented by the wind-up
time of the action under execution (tw and its variance vw )
and next by the resource reservation time(tr and its variance
vr ). The resource reservation time is an estimated time for
the resource to move from the current pose to the pose where
from the action-plan can start execution.
Plan Representation Generally, the plan is an ordered set
of actions to accomplish a task. In this ActionPool context,
the ordering of the actions is based on the successive sets of
actions and with “and” and “or” rules inside a set. For example, set S0 is to either complete actions A0 and A1 , or only
action A2 (mathematically: (A0 ∧ A1 ) ∨ A2 ). The task-plan
is then formed as sequence of these sets [S0 , S1 , S2 , ..., Sn ].
Each action in the task-plan is an abstraction of the robot’s
atomic functions. Thus, an action requires it’s own actionplan too. The format of the action-plan is irrelevant to the
task-plan. These two cascaded plans are reflected in the
above mentioned feed-back channels in Figure 1.
Worl Model
The perception process has to store the observations (Assumption 3) as well as other user generated information
about the environment (Assumption 4). This kind of representation of the world has to be readable for both, user and
the robot. It is used as a medium to transfer the parameters
to the tasks and actions. The only requirement is to communicate the reference to the world model (DB).
The DB provides abstract sensor readings. It can also hold
other abstract data, such as the names of places. The other
components of the system can use the DB as a global memory and indirect communication channel to coordinate their
interactions.
Contingency Management Contingencies have to be
considered in action scheduling. The first problem is to recognize the contingency or discrete event from the continuous flow of environment changes. This is typically done
by monitoring certain parameters from the environment and
triggering a discrete event when the value transgresses a
designed threshold. Many robot control architectures define similar mechanisms (trigger agent in AuRA (Arkin and
Balch 1997), monitor task or exception handling in TCA
(Simmons and Apfelbaum 1998), plan adaption process in
RHINO (Beetz et al. 2001). In the ActionPool method, these
condition checks are inside the EL software agents.
The response to the event is addition and/or removal of
actions from the AP. One common procedure is to restart
the action and that would be achieved by the removal of the
action currently being executed and its later addition. EL is
conceptually close to the repair tasks in (Joyeux et al. 2009).
Starting and stopping of ELs is embedded into the action
before and after the action-plan execution. The EL functionality is defined separately from the action and just the reference to the EL, the threshold level for the event, and the
response are stored in the action. In this way, the same EL
implementation can be reused by different actions.
Conclusions
In this paper, a practical implementation of the plan scheduling for service robot was described. It supports off-line planning with plans including contingency management and online planning by simply adding actions to the pool. These
paradigms can even be utilized simultaneously. A notation
for the partial order plan was also presented. The interaction
of the components and feasibility of the ActionPool were
tested with numerous experiments. A detailed description of
experiments can be found from (Taipalus 2010).
References
Arkin, Ronald, C., and Balch, T. 1997. AuRA: Principles
and practice in review. Journal of Experimental & Theoretical Artificial Intelligence 9(2):175–189.
Beetz, M.; Arbuckle, T.; Belker, T.; Cremers, A.; Schulz,
D.; Bennewitz, M.; Burgard, W.; Hahnel, D.; Fox, D.; and
Grosskreutz, H. 2001. Integrated, plan-based control of autonomous robot in human environments. Intelligent Systems,
IEEE 16(5):56–65.
Joyeux, S.; Alami, R.; Lacroix, S.; and Philippsen, R. 2009.
A plan manager for multi-robot systems. The International
Journal of Robotics Research 28(2):220.
Simmons, R., and Apfelbaum, D. 1998. A task description
language for robot control. In in Proceedings of the Conference on Intelligent Robots and Systems (IROS), 1931–1937.
Taipalus, T. 2010. Actionpool: A novel dynamic task
scheduling method for service robots. Technical report,
Teknillinen korkeakoulu, Espoo.
Action Selection
In practical sense, it is impossible to enumerate or identify
all possible outcomes of an action in real-world scenario
(Assumption 1). Also the purpose and deeper utility of the
action is very difficult to model (Assumption 2). In the ActionPool method, these are abstracted into two variables: the
expected duration of execution tp and the priority p of the
action.
These values can be gathered with relative ease. The duration tp can be statistically gathered from the experiments.
The variation in the duration vp represents the level of nondeterminism of the action. The user given priority p is a measure of the utility of the task that the action is a part of. At
79