Information Technology Reference
In-Depth Information
The overall architecture is sketched in Fig. 4(a). The central component in this archi-
tecture is the
controller
. When the agent is instructed to perform a list of tasks, then this
list is sent to the controller. The controller calls the planner described in Section 2 and
decides what to do in situations where the planner only returns an intermediate planning
state. Furthermore, the controller invokes the
executor
in order to execute—complete
or partial—plans. The executor is responsible for the execution and execution monitor-
ing of actions. In order to avoid unwanted loops (e.g., perform similar tasks more than
once) it is essential to store relevant information of the execution process in the memory
system. The executor stores information about the executed actions and the outcome of
a sensing action in the memory system such that the domain model can properly be
updated. This information includes acquired information as well as knowledge acquisi-
tion attempts. Knowledge acquisition attempts are stored to avoid submitting the same
query more than once to a certain knowledge source.
1
ps ←
create-intial-ps(
tasks
)
;
2
ps
←
plan(
ps
)
;
3
if
ps
is a final planning state
then
4
r ←
execute(
ps
p
)
;
5
return
r
;
6
else
7
plan
r
←
perform(
p
⊆
ps
p
)
;
controller
if
r
is a success
then
8
tasks
choose
ac ∈ ps
kas
with the minimum cost;
query
9
reasoner
memory
planner
t
ac
←
acquisition-task(
ac
)
;
10
perform(
[
t
ac
]
)
;
11
store
perform(
overall tasks
)
;
12
executor
(a) Illustration of the plan-based control ar-
chitecture.
(b) Algorithm
perform
(
tasks
,
overall tasks
).
Fig. 4.
The behavior of the controller is specified by the algorithm shown at Fig. 4(b). When
the controller is invoked, it first constructs an initial planning state based on the given
task list and invokes the planner (lines 1-2). If the planner returns a final planning state
(i.e., a planning state that contains a complete plan), then the controller directly for-
wards the generated plan to the executor.
However, if the planner returns an intermediate planning state (i.e., a planning state
that only contains a partial plan), then the controller performs a prefix of the already
generated plan, chooses the knowledge acquisition with the minimum expected cost,
performs the corresponding knowledge acquisition task, and continues to perform the
overall tasks. Please note that knowledge acquisition tasks can also require it to perform
additional knowledge acquisition tasks. Furthermore, it usually cannot generically be
determined which part of the already generated plan should be executed. For example,
if we instruct a robot agent to deliver a cup into the kitchen, but it is unknown whether
the door of the kitchen is open or closed, then it is reasonable to start grasping the cup,
move to the kitchen door, sense its state and then continue the planning process. In
contrast, it usually should be avoided to execute critical actions that cannot be undone
until a complete plan is generated. The default strategy of the proposed controller is
