JP2007048094A - Plan execution device, plan execution method and plan execution program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a plan execution device capable of resuming a suspended plan achieving a goal after execution of an interrupt plan without increasing a processing burden. <P>SOLUTION: This plan execution device has: a plan execution control means 160 suspending execution of the plan during execution when acquiring the interrupt goal, evacuating the plan held in an in-execution plan holding means 164 to an in-suspension plan holding means 166, and making the in-execution plan holding means 164 hold the interrupt plan prepared by a plan preparation means 150; a plan update means 120 updating contents of the plan held by the in-suspension plan holding means 166 on the basis of execution contents; and a plan resumption control means 120 moving the plan of the in-suspension plan holding means 166 to the in-execution plan holding means 164 when completing the execution of the interrupt plan, and resuming the execution of the plan held by the in-execution plan holding means 164. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a plan execution device, a plan execution method, and a plan execution program.

  Conventionally, another plan may be interrupted while executing a plan that is a certain task sequence. In this case, a scheduling method is known as a method for managing execution of the interrupt plan. As this scheduling method, for example, when there are a plurality of interrupts, a method for giving priority to these interrupts is known (see, for example, “Patent Document 1”).

  Furthermore, when a plan for achieving a goal that is a goal to be achieved is being executed, planning is required so that the goal can be achieved even if another plan is executed by interruption. .

Japanese Patent Laid-Open No. 06-187171

  However, if another plan is executed by interruption and a plan that achieves the goal is planned again, a plan including the plan executed by interruption may be created.

  To cope with this problem, it is possible to keep the history of the executed plan, but it is necessary to keep the history, and rules to avoid executing the executed plan are required. There is a problem that the amount of processing increases because it is necessary to create.

  The present invention has been made in view of the above, and is a plan for interrupting a plan for achieving a certain goal without increasing the processing burden and achieving the goal after executing another interrupt plan. It is an object of the present invention to provide a plan execution device that can resume the process.

  In order to solve the above-described problems and achieve an object, the present invention is a plan execution apparatus that executes a plan that achieves a goal that represents a certain object, and that is an executing plan that holds a plan that can achieve the goal Holding means, plan executing means for executing the plan held in the executing plan holding means, suspended plan holding means for holding a plan that has been interrupted by the plan executing means, and the plan executing means While executing the plan, goal acquisition means for acquiring an interrupt goal to be achieved in preference to the goal by interruption, and achieving the interrupt goal based on the interrupt goal acquired by the goal acquisition means A plan creation means for creating an interrupt plan to be executed in order to execute, and when the goal acquisition means acquires the interrupt goal, the plan execution means Suspends execution of a plan being executed, saves the plan held in the executing plan holding means to the saving plan holding means, and executes the interrupt plan created by the plan creating means Plan execution control means to be held by the plan holding means, and a plan for updating the contents of the plan held by the suspended plan holding means based on the execution contents when the plan execution means executes the interrupt plan When the updating unit and the plan execution unit complete the execution of the interrupt plan, the updated plan held in the suspended plan holding unit is moved to the executing plan holding unit, And plan resumption control means for resuming execution of the plan held in the executing plan holding means.

  The plan execution apparatus according to the present invention updates not only the currently executed plan but also the plan held in the suspended plan holding means according to the execution contents, so that it is held in the suspended plan holding means. When resuming the current plan, it is possible to execute an appropriate plan reflecting the contents of the already executed plan.

  Hereinafter, embodiments of a plan execution device, a plan execution method, and a plan execution program according to the present invention will be described in detail with reference to the drawings. Note that the present invention is not limited to the embodiments.

  FIG. 1 is a diagram illustrating a functional configuration of a mobile robot 10 including a plan creation device according to the present embodiment.

  The mobile robot 10 includes a goal receiving unit 100, a goal holding unit 110, an execution management unit 120, a belief DB 130, a plan creation knowledge DB 140, a plan creation unit 150, a plan DB control unit 160, and an action execution unit. 170.

  The goal receiving unit 100 acquires a goal. The goal receiving unit 100 further receives designation of whether the goal is a normal goal or an interrupt goal. Here, the goal is a task desired to be completed or a state desired to be achieved. As another example, a target state to be achieved may be used. The interrupt goal is a goal achieved by interruption, and the normal goal is a goal other than the interrupt goal, that is, a goal to be processed in the order of acquisition of the goals.

  The goal holding unit 110 has an interrupt goal queue 112 and a normal goal queue 114. The interrupt goal queue 112 holds the interrupt goals acquired by the goal receiving unit 100 in the order of acquisition. The normal goal queue 114 holds the normal goals acquired by the goal receiving unit 100 in the order of acquisition.

  The belief DB 130 stores belief information. Here, the belief information is information that is dynamically updated, such as information on the state of the mobile robot 10 to be processed and a situation that is a premise of the process. For example, when the robot is on the stairs, the information regarding the state of the robot 10 is information indicating that the position of the robot is the stairs. This information indicates that a task that should be executed at a place other than the stairs cannot be executed.

  Further, as a precondition for processing, for example, there are a current time, a current date and the like. For example, a task of outputting “Good morning” as a voice is not suitable for a time zone other than in the morning. Based on the belief indicating the current time, it is possible to determine whether or not to execute the task of outputting the voice “Good morning”.

  The belief DB 130 further stores a topological map of an area to be moved by the mobile robot 10. Thus, the belief DB 130 holds information regarding the processing state of the mobile robot 10 and the external state as belief information.

  The plan creation unit 150 creates a plan corresponding to the first goal in the interrupt goal queue 112 or the normal goal queue 114. Here, the plan and action will be described in detail with reference to FIG.

  FIG. 2 is a diagram showing the relationship between plans and actions. The plan represents the task execution order. For example, as shown in FIG. 2, the total order plan “Task1, Task2, Task3” first executes a task “Task1”, then executes a task “Task2”, and finally executes a task “Task3”. Indicates to execute.

  In the present embodiment, a task that can be executed by the action execution unit 170 is referred to as an action. In other words, an action is a process of an execution unit of the action execution unit 170. The plan has a plurality of actions. In the present embodiment, the total order plan is referred to as a plan.

  There are concrete plans and abstract plans. Here, the specific plan is a plan that represents only the execution order of actions. An abstract plan is a plan in which there are tasks that are not actions. The mobile robot 10 decomposes the abstract plan into specific plans and executes them.

  The plan creation knowledge DB 140 stores plan creation knowledge, which is information to be referred to when the plan creation unit 150 creates a plan. Specifically, it stores actions to be included in the plan. Further, pre-execution conditions and execution effects are stored in association with each action. The pre-execution condition and the execution effect will be described later.

  The plan DB control unit 160 controls the executing plan DB 164 and the suspended plan DB 166. The executing plan DB 164 stores an execution target plan. The suspended plan DB 166 stores a suspended plan.

  Specifically, it manages the execution, suspension and resumption of plans. In addition, the contents of the plan are updated. If a plurality of plans are stored, a plan to be executed is selected from the plurality of plans. Furthermore, an action is generated from the plan.

  The action execution unit 170 executes an action that appears in the plan stored in the executing plan DB 164. That is, a plurality of actions are executed in order according to the order of actions included in the plan.

  The execution management unit 120 manages the goal holding unit 110, the belief DB 130, the plan creation unit 150, the plan DB control unit 160, and the action execution unit 170. For example, when the action execution by the action execution unit 170 is completed, the information in the belief DB 130 is updated to the state after the action is executed.

  FIG. 3 is a diagram schematically showing a topological map stored in the belief DB 130. This topological map is a map of an area where the mobile robot 10 moves. Points (nodes) on the map: node1, node2, node3, node4, node5, and node6 are (0,20), (10,20), (0,10), (10,10), (0,0), (10,0).

This belief information is specifically stored in the belief DB 130 as the following description.

belief (coordinate (node1, 0, 20)).
belief (coordinate (node2, 10, 20)).
belief (coordinate (node3,0,10)).
belief (coordinate (node4, 10, 10)).
belief (coordinate (node5,0,0)).
belief (coordinate (node6,10,0)).

Exhibits: exhibition1, exhibition2, exhibition3, and exhibition4 are respectively in node1, node2, node3, and node4. Specifically, such belief information is stored in the belief DB 130 as the following description.

belief (location (exhibition1, node1)).
belief (location (exhibition2, node2)).
belief (location (exhibition3, node3)).
belief (location (exhibition4, node4)).

In addition, as for explanations about exhibits: exhibition1, exhibition2, exhibition3, exhibition4 and toilet: toilet, "This is the world's first Japanese word processor.", "This is robot operation software.""This is a robot that turns a piece." Specifically, such belief information is stored in the belief DB 130 as the following description.

belief (contents (exhibition1, 'This is the world's first Japanese word processor.')).
belief (contents (exhibition2, 'This is software for robot operation')).
belief (contents (exhibition3, 'This is a computer for robot operation')).
belief (contents (exhibition4, 'This is a robot that turns a piece.')).

From node1 to node2 is movable, and from node2 to node1 is also movable. Specifically, the belief information is stored in the belief DB 130 as the following description.

belief (connects (node1, node2)).
belief (connects (node2, node1)).

Similarly, the connection relationship between nodes is described as follows and stored in the belief DB 130.

belief (connects (node1, node3)).
belief (connects (node3, node1)).
belief (connects (node2, node4)).
belief (connects (node4, node2)).
belief (connects (node3, node4)).
belief (connects (node4, node3)).
belief (connects (node3, node5)).
belief (connects (node5, node3)).
belief (connects (node4, node6)).
belief (connects (node6, node4)).
belief (connects (node5, node6)).
belief (connects (node6, node5)).

Assume that the position of the mobile robot 10 in the initial state is node6. This belief information is specifically stored in the belief DB 130 as the following description.

belief (at (node6)).

Here, at (node6) does not hold when the mobile robot 10 moves from node6. That is, the true / false value of at (_) changes dynamically. Here, “_” is an anonymous variable and indicates that any value may be substituted. In addition to the fact that the true / false value changes dynamically as described above, specifically, the following description is stored in the belief DB 130.

dy (at (_)).

It is assumed that the mobile robot 10 in the initial state is with a person: taro. This belief information is specifically stored in the belief DB 130 as the following description.

belief (with (taro)).

Here, with (taro) is no longer valid when taro leaves the mobile robot 10. Therefore, the following description is declared in the belief DB 130.

dy (with (_)).

In addition, the following beliefs are stored.

pick (Selected, ListRest, List)

This indicates that when one element of the list: List is selected and that element is selected, the remaining list of List is ListRest. However, Selected is a variable and ListRest and List are variables of the list.

Such a description (pick (Selected, ListRest, List)) is specifically stored in the belief DB 130 as the following description.

belief (pick (H, T, [H | T])).
belief (pick (X, [H | Rest], [H | T]), [
pick (X, Rest, T)
]).

This means that pick (H, T, [H | T]) always holds, and if pick (X, Rest, T) holds, pick (X, [H | Rest], [H | T]) also holds. It expresses that.

  FIG. 4 is a diagram schematically showing plan creation knowledge stored in the plan creation knowledge DB 140. Specifically, knowledge for creating a plan is an action to be included in the plan. Furthermore, pre-execution conditions and execution effects given to the actions are stored. Here, the pre-execution condition is a condition that needs to be satisfied immediately before the action is executed. The execution effect is a state or property that is continuously established immediately after the execution of the action. Even in the same action, the pre-execution condition may be different because the plan including the action is different. Therefore, in this embodiment, the pre-execution condition and execution effect of each action included in the plan are explicitly recorded in the plan.

  For the action “move from A to B” shown in FIG. 4, “current position is A” is recorded as a pre-execution condition. In addition, “the current position is no longer A” and “the execution position is B” are recorded as execution effects.

  For the action “Move from B to C”, “current position is B” is recorded as a pre-execution condition. In addition, “the current position is no longer B” and “the execution position is C” are recorded as execution effects.

Specifically, the above contents are recorded in the plan creation knowledge DB 140 as the following description.

[precond ([at (a)], []),
move (a, b),
effect ([terminates (at (a)), initiates (at (b))])
precond ([at (b)], []),
move (b, c),
effect ([terminates (at (b)), initiates (at (c))])]

Here, “move (a, b)” represents an action of moving from point a to point b. “Precond ([at (a)], [])” indicates a pre-execution condition of the action “move (a, b)”. Here, “at (a)” represents being at point a.

  Further, “effect ([terminates (at (a)), initiates (at (b))]” ”represents an execution effect for the action“ move (a, b) ”. “Terminates (at (a))” represents that the current position is not a point a. Further, “initates (at (b))” represents that the current position is a point b.

  Similarly, “move (b, c)” represents an action of moving from point b to point c. “Precond ([at (b)], [])” represents a pre-execution condition of the action “move (b, c)”. Also, “effect ([terminates (at (b)), initiates (at (c))]” ”represents an execution effect.

For example, the action of reading text has no pre-execution condition and no execution effect. Thus, when the pre-execution condition and the execution effect do not exist, the following description is stored in the plan creation knowledge DB 140.

action (speak (Text), [
], [
]).

Note that this description represents an action when the target of the reading operation is “text”, but “Text” of “speak (Text)” is a variable and is substituted by an arbitrary character string. Reads a character string.

The action of moving from the current node to a node that can be moved directly without going through another node is described as follows.

action (gotoNextNode (NextNode), [
at (CurrentNode),
connections (CurrentNode, NextNode)
], [
terminates (at (CurrentNode)),
initiates (at (NextNode))
]).

Here, “gotoNextNode (NextNode)” represents an action. Further, “CurrentNode” represents a current node. Here, CurrentNode is a variable. NextNode represents the destination node. Here, NextNode is a variable.

  “At (CurrentNode)” is a pre-execution condition. This indicates that the current node is the CurrentNode. Also, “connects (CurrentNode, NextNode)” is a pre-execution condition. This indicates that it is possible to move directly from the CurrentNode to the NextNode. The effect “terminates (at (CurrentNode)), initiates (at (NextNode))” of this action indicates that the current position changes from CurrentNode to NextNode.

Also, for example, changeGoal (Goal) represents an action of ending the execution of the action being executed and executing the goal: Goal (Goal is a variable) instead. In other words, this represents an action of deleting all the executing plans from the executing plan DB 164 and replacing them with a plan for a task called Goal. Since there are no pre-execution conditions and execution effects for this action, the following description is stored in the belief DB 130.

action (changeGoal (Goal), [
], [
]).

The belief DB 130 stores a definition of a method for disassembling a task that is not an action. The task "Move from node: Node to node: Node":

gotoNodeWide (Node, Node)

Does not have pre-execution conditions and execution effects, and is described as follows.

htn (gotoNodeWide (Node, Node), [
], [
]).

Here, Node is a variable.

The task "Move from node: StartNode to node: GoalNode":

gotoNodeWide (StartNode, GoalNode)

The execution is achieved by executing a plurality of tasks shown below. That is, first, a task “moving from the current node: StartNode to the next node: NextNode”:

gotoNextNode (StartNode, NextNode)

Execute. Next, the task of “moving from the next node: NextNode to the destination node: GoalNode”:

gotoNodeWide (NextNode, GoalNode)

Execute. Here, StartNode, NextNode, and GoalNode are variables. This is described as follows.

htn (gotoNodeWide (StartNode, GoalNode), [
], [
gotoNextNode (StartNode, NextNode),
gotoNodeWide (NextNode, GoalNode)
]).

Also, a task “I will explain about the object: Object”:

explain (Object, Person)

Is a task of “character string: text is output by voice” when the following four pre-execution conditions (pre-execution condition 1, pre-execution condition 2, pre-execution condition 3 and pre-execution condition 4) are satisfied:

spike (Text)

Execution is achieved by executing Here, Object, Node, and Text are variables.

The pre-execution condition 1 is that the current position is a node: Node, and is described as follows.

at (Node)

The pre-execution condition 2 is that the position of the object: Object is the current position node: Node, and is described as follows.

location (Object, Node)

The pre-execution condition 3 is that the robot is with a person: Person, and is described as follows.

with (Person)

The pre-execution condition 4 is that the description of the object: Object is Text, and is described as follows.

contents (Object, Text)

The above contents are described as follows.

htn (explain (Object, Person), [
at (Node),
location (Object, Node),
with (Person),
contents (Object, Text)
], [
spike (Text)
]).

In addition, the task “People: Person is taken before the subject: Exhibition to explain the subject”:

show (Exhibition, Person)

Is a task “object: go to node with Exhibit: GoalNode” when the following two pre-execution conditions (pre-execution condition 1 and pre-execution condition 2) are satisfied:
gotoNodeWide (StartNode, GoalNode)

And after that, the task “explain to the person: Person about the object: Exhibition”:

explain (Exhibition, Person)

Execution is achieved by executing Here, exhibition, Person, StartNode, and GoalNode are variables.

Pre-execution condition 1 is that the current node is a StartNode, and is described as follows.

at (startNode)

The pre-execution condition 2 is that the location where the object: Exhibition is located is a GoalNode, and is described as follows.

location (Exhibition, GoalNode)

The above contents are described as follows.

htn (show (Exhibition, Person), [
at (StartNode),
location (Exhibition, GoalNode)
], [
gotoNodeWide (StartNode, GoalNode),
explain (Exhibition, Person)
]).

Also, a task called showAround (Objects, Person) goes to a place where the object is located for each object in the list of zero or more objects: Objects, and explains the object to Person: Person. It is a task to do. For example, there are the following description examples.

htn (showAround ([], _), [
], [
]).

If the list of objects is an empty list: [], nothing needs to be done. “_” Is an anonymous variable.

In addition, there are the following description examples.

htn (showAround ([Exhibition | EXs], Person), [
pickOne (NextEXhibition, RestEXs, [Exhibition | EXs])
], [
show (NextExhibition, Person),
changeGoal (showAround (RestEXs, Person))
]).

This is a list where the list of objects contains one or more objects:

[Exhibition | EXs]

One pre-execution condition that if one appropriate object: NextExhibition is selected from a list of one or more objects, the remaining list of objects is RestEXs:

pickOne (NextExhibition, RestEXs, [Exhibition | EXs])

If is true, the task:

showAround ([Exhibition | EXs], Person)

In order to execute, “Task: Explain the subject to Person: Person in front of NextExhibition”:

show (NextExhibition, Person)

After executing the above, “remaining object list: task of guiding around RestEXs: task of instructing execution of showAround (RestEXs, Person) as the next goal”:

changeGoal (showAround (RestEXs, Person))

Indicates that it should be executed. Here, Exhibition, NextExhibition, Person, and Object are variables. EXs and RestEXs are list variables.

  FIG. 5 is a flowchart illustrating plan execution processing when the mobile robot 10 according to the embodiment executes a plan. First, the goal receiving unit 100 acquires a goal (step S100). Next, the goal type acquired by the goal receiving unit 100 is determined. Specifically, it is determined whether the goal is a normal goal or an interrupt goal.

  If it is a normal goal, the acquired normal goal is inserted at the end of the normal goal queue 114 of the goal holding unit 110. If it is an interrupt goal, the acquired interrupt goal is inserted at the end of the interrupt goal queue 112 of the goal holding unit 110 (step S102).

  Next, the execution management unit 120 checks whether an interrupt goal is stored in the interrupt goal queue 112 of the goal holding unit 110. If there is no interrupt goal (No at Step S104), it is further checked whether or not a plan is stored in the executing plan DB 164. When a plan exists (step S106, Yes), it is further confirmed whether at least one of the stored plans is an already executed empty plan.

  When the empty plan is not stored in the executing plan DB 164, that is, when the execution of any plan is not completed and the plan to be executed is stored (No in step S108), Of the actions included in this plan, the action that is executed first, that is, the head is executed (step S110). Next, post-execution plan update processing is performed based on the content of the executed action (step S112). Here, the post-execution plan update process is a process of deleting the corresponding action from the executing plan DB 164 and the suspended plan DB 166 based on the content of the executed action. The post-execution plan update process will be described later.

  In step S108, when an empty plan is stored in the executing plan DB 164, that is, when an already executed plan is stored in the executing plan DB 164 (step S108, Yes), each of the executing plan DB 164 The plan is deleted (step S120). Next, it is confirmed whether or not a plan is stored in the suspended plan DB 166. When the plan exists (step S122, Yes), the restart plan update process is performed (step S124). Here, the resuming plan update process is a process performed when the plan of the suspended plan DB 166 is moved to the executing plan DB 164, and is a process of breaking the plan into tasks. The resume plan update process will be described later.

  In step S122, when the plan does not exist in the suspended plan DB 166 (step S122, No), the execution management unit 120 further has a goal in the interrupt goal queue 112 or the normal goal queue 114 of the goal holding unit 110. Check if it exists. If a goal exists (step S126, Yes), goal processing is performed (step S128). Here, the goal process is a process for creating a plan based on the goal. The goal process will be described later.

  In step S104, when an interrupt goal is stored in the interrupt goal queue 112 (step S104, Yes), it is further confirmed whether or not a plan is stored in the executing plan DB 164. If the plan is stored (step S130, Yes), the executing plan group that is the plan stored in the executing plan DB 164 is moved to the interrupting plan DB 166 (step S132), and the process proceeds to step S128. In step S130, when the plan is not stored in the executing plan DB 164 (No in step S130), the process proceeds to step S128.

  FIG. 6 is a flowchart showing detailed processing in the post-execution plan update processing (step S112) described in FIG. When the execution of the action is successful (step S200, Yes), the executed action is deleted from each plan in which the first task is the action that has been successfully executed (step S204).

  As described above, since the executed actions are deleted from the pun stored in the executing plan DB 164 and the suspended plan DB 166, when these plans are resumed, the already executed actions are repeatedly executed. Can be avoided.

  Next, the content of the belief DB 130 is updated based on the execution content (step S206). Next, the plans stored in the executing plan DB 164 and the suspended plan DB 166 are updated (step S208). The plan update process will be described later.

  In step S200, if the action fails (step S200, No), all plans that are actions for which the top task has failed to execute are deleted (step S212).

  FIG. 7 is a flowchart showing detailed processing in the plan update processing (step S208) described in FIG. First, it is confirmed whether or not the pre-execution condition assigned to each task included in each plan stored in the executing plan DB 164 and the suspended plan DB 166 is satisfied (step S220). Processing for confirming whether or not the pre-execution condition is satisfied will be described later.

  Then, all plans including a task that does not satisfy the pre-execution condition are deleted from the executing plan DB 164 and the suspended plan DB 166 (step S224).

  Next, the task appearing in the plan stored in the executing plan DB 164 is disassembled (step S228). At this time, it is preferable that all tasks in the plan being executed out of the plans stored in the executing plan DB 164 are broken down into actions. For other plans, it is preferable to disassemble until at least the first task becomes an action.

  Further, the task appearing in the plan stored in the suspended plan DB 166 is disassembled (step S232). Here, it is preferable to disassemble until at least the first task of each plan becomes an action. This completes the plan update process.

  Note that the task disassembly process performed on the task appearing in the plan stored in the suspended plan DB 166 in step S232 is the same process as the task disassembly process (step S228).

  In this way, in the plan update process, it is not necessary to disassemble all the tasks of the plan into actions, and instead of disassembling all the plans into actions, the task immediately before execution, that is, the first task included in the plan Only break down into actions. Accordingly, an appropriate action can be created based on the state immediately before execution, that is, based on the information stored in the belief DB 130 immediately before execution. Moreover, since the action is sequentially decomposed, memory consumption can be suppressed.

  FIG. 8 is a flowchart showing detailed processing in the pre-execution condition confirmation processing (step S220) described in FIG. It is determined whether or not the first condition, the second condition, and the third condition are satisfied. Each condition will be described later.

  As a premise, when the execution of the action stored in the executing plan DB 164 is completed, the action that has been executed is deleted from the executing plan DB 164.

  If the first condition is satisfied (step S240, Yes), it is determined that the pre-execution condition “X” is satisfied (step S248). Also, when the second condition and the third condition are satisfied (step S242, Yes, step S244, Yes), it is similarly determined that the pre-execution condition “X” is satisfied (step S248).

  On the other hand, when neither condition is satisfied (step S240, No, step S242, No, step S244, No), it is determined that the pre-execution condition “X” is not satisfied (step S246).

FIG. 9 is a diagram for explaining the first condition. Here, it is assumed that the pre-execution condition of the action “Tx” of the plan “P1” is “X”. The first condition is as a belief in the belief DB 130,
belief (X)

Is stored, that is, the belief X is satisfied, and the action “Tx having an execution effect“ terminates (X) ”that causes the pre-execution condition“ X ”to end before the execution of the action“ Tx ”is performed. -M "is not scheduled to be executed. That is, the pre-execution condition “X” does not end before the execution of the action “Tx”.
FIG. 10 is a diagram for explaining the second condition. In contrast to the pre-execution condition “X” of the action “Tx” of the plan “P1”, the second condition is an execution effect “initates (X) that starts the pre-execution condition“ X ”before the execution of the action“ Tx ”. ) "
Tx-n ”is scheduled to be executed, and there is no action that terminates the pre-execution condition“ X ”between the action“ Tx-n ”and the action“ Tx ”.

The third condition is that a certain condition “C1 to Cn” is satisfied at the time when the pre-execution condition “X” must be satisfied, and the belief in the belief DB 130:
belief (X, [C1,... Cn])

Is stored.

  FIG. 11 is a flowchart showing detailed processing in the task disassembly processing (step S228) described in FIG. If a plan exists in the executing plan DB (step S260, Yes), it is confirmed whether or not the head task of each plan has already been decomposed into actions. If there is a head task that has not been disassembled (step S261, No), a plan including this head task is selected (step S262).

  On the other hand, when the top task of each plan in the executing plan DB has already been decomposed into actions (step S261, Yes), and when other tasks are further decomposed (step S263, Yes), An arbitrary plan in which an unresolved task exists is selected (step S264).

  Next, the first task that appears in the plan and is not disassembled is selected (step S265). If the selected task is an action (step S266, Yes), it is further confirmed based on information stored in the belief DB 130 whether or not the pre-execution condition for this action is satisfied. Specifically, confirmation is performed by the pre-execution condition confirmation process (step S220) described with reference to FIGS.

  When the pre-execution condition is satisfied (step S267, Yes), an execution effect is given. Further, a pre-execution condition is assigned (step S268). Then, the process proceeds again to step S261. Here, the pre-execution condition to be assigned is only the pre-execution condition in which whether or not the condition is satisfied dynamically changes. For example, when the pre-execution condition is a condition related to the position of the mobile robot 10, whether or not the pre-execution condition is satisfied changes every time the mobile robot 10 moves. Only such conditions are given.

  If there are n ways to satisfy the pre-execution condition, n copies of the target plan are created. Then, n pre-execution conditions are assigned to each of the n plans. Then, the target plan is replaced with n newly created plans.

  On the other hand, when the pre-execution condition is not satisfied (step S267, No), the target plan is deleted from the executing plan DB 164 (step S269). And it progresses to step S260 again.

  On the other hand, if the task is not an action in step S266 (No in step S266), first, a task disassembly method that satisfies the pre-execution condition is specified. Specifically, the pre-execution condition confirmation process (step S220) described with reference to FIGS. 8 and 9 confirms whether the pre-execution condition is satisfied, and specifies the task decomposition method.

  If there is a task decomposition method that satisfies the pre-execution condition (step S271, Yes), the task is decomposed based on the identified task decomposition method. Then, a pre-execution condition is assigned to the obtained task (step S272). And it progresses to step S260 again.

  When there are n task decomposition methods, n copies of the target task are created. Then, n task decomposition methods are applied to each of the n plans. Then, n decomposed plans are obtained. Then, the target plan is replaced with n decomposed plans. If there are m ways to satisfy the pre-execution condition of the decomposed plan, m copies of the plan are created. Then, m pre-execution conditions are assigned to each of the m plans. Thereafter, the decomposed plan is replaced with newly created m plans. Note that the pre-execution conditions given here are only dynamic pre-execution conditions. Thus, the task disassembly process is completed.

  On the other hand, in step S271, when there is no task disassembly method that satisfies the pre-execution condition (step S271, No), the process proceeds to step S269 and the plan is deleted.

  FIG. 12 is a flowchart showing detailed processing in the restart plan update processing (step S124) described in FIG. If a plan is stored in the suspended plan DB 166 (step S122, Yes), first, the plan group stored in the suspended plan DB 166 is moved to the running plan DB 164 (step S300). When a plurality of plan groups are stored in the suspended plan DB 166, the most recently stored plan group is moved to the executing plan DB 164.

  After the plan group is moved to the executing plan DB 164, task disassembly processing is performed on the tasks appearing in the plans stored in the executing plan DB 164 (step S302). The task disassembly process (step S302) is the same process as the task disassembly process (step S228) described with reference to FIG. This completes the restart plan update process.

  FIG. 13 is a flowchart showing detailed processing in the goal processing (step S128) described in FIG. If there is a goal in the interrupt goal queue 112 of the goal holding unit 110 (step S400, Yes), the first goal is extracted from the goals stored in the interrupt goal queue 112 (step S402). On the other hand, when there is no goal in the interrupt goal queue 112 (step S400, No), the first goal among the goals stored in the normal goal queue 114 is taken out (step S404).

  Next, a plan for the extracted goal is created (step S410), and the created plan is stored in the executing plan DB 164 (step S412). Here, when there are n plans that can achieve the goal, n plans are created and stored in the executing plan DB 164, respectively.

  Thereafter, task decomposition processing is performed on the plan stored in the executing plan DB 164 (step S414). The task disassembly process (step S414) is the same process as the task disassembly process (step S228) described with reference to FIG. This completes the goal process.

  As described above, in the plan execution process according to the present embodiment, when a predetermined plan is executed, all other plans stored in the executing plan DB 164 and the suspended plan DB 166 are also updated. Then, when resuming a plan that has been suspended, the plan updated according to the execution of the plan is executed. Therefore, it is possible to resume an appropriate plan according to the state at the time of resumption.

  When a plurality of plans are created from the same goal, each plan is updated according to the execution of the plan. Therefore, when the position of the mobile robot 10 is changed at the time of resuming the plan that has been suspended, and the suspended plan cannot be resumed, another plan created from the same goal is saved. The goal can be achieved by resuming.

The plan execution process described above with reference to FIGS. 5 to 13 will be described more specifically. It is assumed that the goal receiving unit 100 acquires a normal goal of “explaining each object to a person: taro in front of the objects: exhibition1 and exhibition2”. FIG. 14 is a diagram schematically showing this normal goal. Note that the position of the mobile robot 10 at this time is assumed to be the initial position (node 6). This normal goal is described as follows.

showAround ([exhibition1, exhibition2], taro)

Also, as a premise, at this time, it is assumed that no goal is held in the interrupt goal queue 112 and the normal goal queue 114 of the goal holding unit 110.

When the goal receiving unit 100 acquires the normal goal, the goal receiving unit 100 holds the normal goal in the normal goal queue 114 of the goal holding unit 110. Furthermore, the plan creation unit 150 creates a plan for the normal goal. The created normal goal is stored in the executing plan DB 164. Specifically, the plan creation unit 150 has the plan creation knowledge stored in the plan creation knowledge DB 140:

htn (showAround ([Exhibition | EXs], Person), [
pickOne (NextEXhibition, RestEXs, [Exhibition | EXs])
], [
show (NextExhibition, Person),
changeGoal (showAround (RestEXs, Person))
]).

And stored in the belief DB 130:

belief (pick (H, T, [H | T])).
belief (pick (X, [H | Rest], [H | T]), [
pick (X, Rest, T)
]).

Based on the task:
showAround ([exhibition1, exhibition2], taro)

Is divided into the following two plans (plan 1 and plan 2).

Plan 1:
[
show (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

Plan 2:
[
show (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))
]

  These plans are decomposed until the first task to be executed is an action (the smallest unit of tasks). Plan 1 is a plan for guiding exhibition 1 first. On the other hand, plan 2 is a plan for guiding exhibition 2 first. Note that changeGoal (X) included in plan 1 and plan 2 deletes the plan currently being executed and the plan stored in the suspended plan DB 166, and newly stores the plan for goal X in the executing plan DB 164. This is a task for executing a plan for this goal X.

  As described above, the plan creation unit 150 creates a plurality of plans when one goal can be achieved by the plurality of plans.

The plan creation unit 150 then has the following plan creation knowledge:

htn (show (Exhibition, Person), [
at (StartNode),
location (Exhibition, GoalNode)
], [
gotoNodeWide (StartNode, GoalNode),
explain (Exhibition, Person)
]).

And the following beliefs:

dy (at (_)).
belief (at (node6)).
belief (location (exhibition1, node1)).

Based on the above, plan 1 is decomposed into the following plan (plan 3).

Plan 3:
[
precond ([at (node6)], []),
gotoNodeWide (node6, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]
Here, precond ([at (node6)], []) is a pre-execution condition that must be satisfied before the task: gotoNodeWide (node6, node1). At (node 6) that may change dynamically is recorded.

Similarly, plan 2 is decomposed into the following plan (plan 4). However, in this case, belief (location (exhibition 2, node 2)) is used instead of belief (location (exhibition 1, node 1)).

Plan 4:
[
precond ([at (node6)], []),
gotoNodeWide (node6, node2),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))
]

Next, plan 3 is disassembled. The plan creation unit 150 has the following plan creation knowledge:

htn (gotoNodeWide (StartNode, GoalNode), [
], [
gotoNextNode (StartNode, NextNode),
gotoNodeWide (NextNode, GoalNode)
]).

action (gotoNextNode (CurrentNode, NextNode), [
at (CurrentNode),
connections (CurrentNode, NextNode)
], [
terminates (at (CurrentNode)),
initiates (at (NextNode))
]).

And the following beliefs:

belief (connects (node6, node4)).
belief (connects (node6, node5)).

Based on the above, plan 3 is decomposed into the following two plans (plan 5 and plan 6).

Plan 5:
[
precond ([at (node6)], []),
gotoNextNode (node6, node4),
effect ([initates (at (node4)), terminates (at (node6))]),
gotoNodeWide (node4, node1),
explain (exhibition1, taro)
changeGoal (showAround ([exhibition2], taro))
]

Plan 6:

[
precond ([at (node6)], []),
gotoNextNode (node6, node5),
effect ([initates (at (node5)), terminates (at (node6))]),
gotoNodeWide (node5, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

Similarly, the plan creation unit 150 decomposes the plan 4 into the following two plans (plan 7 and plan 8).

Plan 7:
[
precond ([at (node6)], []),
gotoNextNode (node6, node4),
effect ([initates (at (node4)), terminates (at (node6))]),
gotoNodeWide (node4, node2),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))
]

Plan 8:

[
precond ([at (node6)], []),
gotoNextNode (node6, node5),
effect ([initates (at (node5)), terminates (at (node6))]),
gotoNodeWide (node5, node2),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))
]

  The first tasks of plan 5, plan 6, plan 7 and plan 8 are all actions. Therefore, the plan creation unit 150 compares the costs of these plans and decomposes the plan with the lowest cost.

The plan creation unit 150 according to the present embodiment considers only the cost related to the movement of the mobile robot 10. Specifically, each task related to movement appearing in these plans: gotoNextNode (node6, node4), gotoNextNode (node6, node5), gotoNodeWide (node4, node2), gotoNodeWide (node4, node1), goode1 (nodeNode), , GotoNodeWide (node4, node2), and total cost (approximate) of gotoNodeWide (node5, node2) are calculated and compared.

The following beliefs:

belief (coordinate (node1, 0, 20)).
belief (coordinate (node2, 10, 20)).
belief (coordinate (node4, 10, 10)).
belief (coordinate (node5,0,0)).
belief (coordinate (node6,10,0)).

From, a linear distance between node6 and node4, a linear distance between node6 and node5, a linear distance between node4 and node2, a linear distance between node4 and node1, a linear distance between node5 and node1, a linear distance between node4 and node2, The straight line distance between node5 and node2 is specified. Then, each of these distances is set as a cost, and the total moving distance in each plan is calculated as a total cost (approximate). The plan with the smallest total cost calculated in this way is selected as the plan to be executed. In this example, the cost of the plan 7 is minimized and the plan 7 is selected.

  The cost calculation method is not limited to this example. For example, in addition to the movement distance, the cost for the time required to execute the task may be calculated. Further, a total cost may be calculated from both of these costs.

The plan creation unit 150 further provides the following plan creation knowledge:

htn (gotoNodeWide (Node, Node), [
], [
]).

htn (gotoNodeWide (StartNode, GoalNode), [
], [
gotoNextNode (StartNode, NextNode),
gotoNodeWide (NextNode, GoalNode)
]).

action (gotoNextNode (CurrentNode, NextNode), [
at (CurrentNode),
connections (CurrentNode, NextNode)
], [
terminates (at (CurrentNode)),
initiates (at (NextNode))
]).

And the following beliefs:

belief (connects (node2, node1)).
belief (connects (node2, node4)).
belief (connects (node4, node2)).

First, plan 7 which is the plan with the lowest cost is decomposed into the following three plans (plan 9, plan 10 and plan 11).

Plan 9:
[
precond ([at (node6)], []),
gotoNextNode (node6, node4),
effect ([initates (at (node4)), terminates (at (node6))]),
precond ([at (node4)], []),
gotoNextNode (node4, node2),
effect ([initates (at (node2)), terminates (at (node4))]),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))
]

Plan 10:
[
precond ([at (node6)], []),
gotoNextNode (node6, node4),
effect ([initates (at (node4)), terminates (at (node6))]),
precond ([at (node4)], []),
gotoNextNode (node4, node2),
effect ([initates (at (node2)), terminates (at (node4))]),
precond ([at (node2)], []),
gotoNextNode (node2, node1),
effect ([initates (at (node1)), terminates (at (node2))]),
gotoNodeWide (node1, node2),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))
]

Plan 11:
[
precond ([at (node6)], []),
gotoNextNode (node6, node4),
effect ([initates (at (node4)), terminates (at (node6))]),
precond ([at (node4)], []),
gotoNextNode (node4, node2),
effect ([initates (at (node2)), terminates (at (node4))]),
precond ([at (node2)], []),
gotoNextNode (node2, node4),
effect ([initates (at (node4)), terminates (at (node2))]),
gotoNodeWide (node4, node2),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))
]

Here, the pre-execution conditions for the second task of plan 9, plan 10 and plan 11 are:

precond ([at (node4)], [])

At (node4) described in is the effect of the first action:

effect ([initates (at (node4)), terminates (at (node6))]))

Is established.

Next, the plan 9 with the lowest total cost (estimated) is selected from the plans (plan 5, plan 6, plan 9, plan 10, plan 11 and plan 8) held by the executing plan DB 164, and the plan Continue disassembling. The plan creation unit 150 has the following plan creation knowledge:

htn (explain (Object, Person), [
at (Node),
location (Object, Node),
with (Person),
contents (Object, Text)
], [
spike (Text)
]).

action (speak (Text), [
], [
]).

action (changeGoal (Goal), [
], [
]).

And the following beliefs:

belief (location (exhibition2, node2)).
belief (with (Person)).
dy (with (_)).
belief (contents (exhibition2, 'This is software for robot operation')).

From the plan 9, the following plan (plan 12) is created.

Plan 12:
[
precond ([at (node6)], []),
gotoNextNode (node6, node4),
effect ([initates (at (node4)), terminates (at (node6))]),
precond ([at (node4)], []),
gotoNextNode (node4, node2),
effect ([initates (at (node2)), terminates (at (node4))]),
precond ([at (node2), with (taro)], []),
spike ('This is software for robot operation'),
effect ([]),
precond ([], []),
changeGoal (showAround ([exhibition1], taro)),
effect ([])
]

  In the plan 12, all tasks are actions. Furthermore, pre-execution conditions and execution effects are assigned to each action. Therefore, this is a plan to be executed. Note that the execution plan DB 164 further holds Plan 5, Plan 6, Plan 8, Plan 10, and Plan 11 as alternative plans for the plan 12. In this way, not only the optimal plan but also other executable plans are retained.

Next, processing when the plan (plan 12) created in this way is executed will be described. The action execution unit 170 first takes an action that appears first in the plan 12:

gotoNextNode (node6, node4),

Execute. As a result, the mobile robot 10 moves from node 6 to node 4 as shown in FIG. 15, and the mobile robot 10 is located at node 4.

Information on the execution effect of this action added to plan 12 after execution of this action:

effect ([initates (at (node4)), terminates (at (node6))]))

Accordingly, at (node4) in belief DB 130 is rewritten to at (node6). In addition, actions performed from plan 12:

gotoNextNode (node6, node4)

Is deleted. At this time, the pre-execution condition and execution effect for this action are also deleted.
Thereby, the plan 12 is changed as follows.

Plan 12:
[
precond ([at (node4)], []),
gotoNextNode (node4, node2),
effect ([initates (at (node2)), terminates (at (node4))]),
precond ([at (node2), with (taro)], []),
spike ('This is software for robot operation'),
effect ([]),
precond ([], []),
changeGoal (showAround ([exhibition1], taro)),
effect ([])
]

At this time, the action already executed from the plan 5, the plan 10, and the plan 11 also stored in the executing plan DB 164 is:

gotoNextNode (node6, node4)

Is deleted. Thereby, each plan is changed as follows.

Plan 5:
[
gotoNodeWide (node4, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

Plan 10:
[
precond ([at (node4)], []),
gotoNextNode (node4, node2),
effect ([initates (at (node2)), terminates (at (node4))]),
precond ([at (node2)], []),
gotoNextNode (node2, node1),
effect ([initates (at (node1)), terminates (at (node2))]),
gotoNodeWide (node1, node2),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))

Plan 11:
[
precond ([at (node4)], []),
gotoNextNode (node4, node2),
effect ([initates (at (node2)), terminates (at (node4))]),
precond ([at (node2)], []),
gotoNextNode (node2, node4),
effect ([initates (at (node4)), terminates (at (node2))]),
gotoNodeWide (node4, node2),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))
]

Further, since the top task of the plan 5 is not an action, the plan 5 is further disassembled. Specifically, the following planning knowledge:

htn (gotoNodeWide (StartNode, GoalNode), [
], [
gotoNextNode (StartNode, NextNode),
gotoNodeWide (NextNode, GoalNode)
]).

action (gotoNextNode (CurrentNode, NextNode), [
at (CurrentNode),
connections (CurrentNode, NextNode)
], [
terminates (at (CurrentNode)),
initiates (at (NextNode))
]).

And the following beliefs:

belief (connects (node4, node2)).
belief (connects (node4, node3)).
belief (connects (node4, node6)).

Is used to decompose plan 5 into the following three plans (plan 13, plan 14 and plan 15).

Plan 13:
[
precond ([at (node4)], []),
gotoNextNode (node4, node2),
effect ([initates (at (node2)), terminates (at (node4))]),
gotoNodeWide (node2, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

Plan 14:
[
precond ([at (node4)], []),
gotoNextNode (node4, node3),
effect ([initates (at (node3)), terminates (at (node4))]),
gotoNodeWide (node3, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

Plan 15:
[
precond ([at (node4)], []),
gotoNextNode (node4, node6),
effect ([initates (at (node6)), terminates (at (node4))]),
gotoNodeWide (node6, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

Further, the current position of the mobile robot 10 is changed from node6 to node4 by execution of the action. Therefore, the pre-execution conditions of plan 6 and plan 8 stored in the executing plan DB 164:

at (node6)

Is no longer satisfied. Therefore, the plan 6 and the plan 8 cannot be resumed in the future, and are deleted from the executing plan DB 164.

  At this time, any task that first appears in each plan (plan 10, plan 11, plan 12, plan 13, plan 14, and plan 15) stored in the executing plan DB 164 is an action.

Next, the plan having the minimum total cost is selected from the plan 10, the plan 11, the plan 12, the plan 13, the plan 14, and the plan 15 stored in the executing plan DB 164. Here, the plan 12 is selected, and the following actions are executed according to the plan 12.

gotoNextNode (node4, node2),

As a result, the mobile robot 10 moves from node 4 to node 2 as shown in FIG. 16, and the mobile robot 10 is located at node 2.

Then the effect of executing this action:

effect ([initates (at (node2)), terminates (at (node4))]))

Accordingly, at (node4) stored in the belief DB 130 is rewritten to at (node2). Further, the executed action is deleted from the plan 12. The plan 12 after the executed action is deleted is described as follows.

Plan 12:

[
precond ([at (node2), with (taro)], []),
spike ('This is software for robot operation'),
effect ([]),
precond ([], []),
changeGoal (showAround ([exhibition1], taro)),
effect ([])
]

At this time, the action already executed from the plan 10, the plan 11 and the plan 13 held in the currently executing plan DB 164 is also:

gotoNextNode (node4, node2),

Is deleted. As a result, each plan is changed as follows.

Plan 10:
[
precond ([at (node2)], []),
gotoNextNode (node2, node1),
effect ([initates (at (node1)), terminates (at (node2))]),
gotoNodeWide (node1, node2),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))

Plan 11:
[
precond ([at (node2)], []),
gotoNextNode (node2, node4),
effect ([initates (at (node4)), terminates (at (node2))]),
gotoNodeWide (node4, node2),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))
]

Plan 13:
[
gotoNodeWide (node2, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

The top task of the plan 13 is not an action. Therefore, the plan creation unit 150 further decomposes the plan 13. Specifically, the plan creation unit 150 has the following plan creation knowledge:

htn (gotoNodeWide (StartNode, GoalNode), [
], [
gotoNextNode (StartNode, NextNode),
gotoNodeWide (NextNode, GoalNode)
]).

action (gotoNextNode (CurrentNode, NextNode), [
at (CurrentNode),
connections (CurrentNode, NextNode)
], [
terminates (at (CurrentNode)),
initiates (at (NextNode))
]).

And the following beliefs:

belief (connects (node2, node1)).
belief (connects (node2, node4)).

Is used to decompose the plan 13 into the following two plans (plan 16 and plan 17).

Plan 16:
[
precond ([at (node2)], []),
gotoNextNode (node2, node1),
effect ([initates (at (node1)), terminates (at (node2))])
gotoNodeWide (node1, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

Plan 17:
[
precond ([at (node2)], []),
gotoNextNode (node2, node4),
effect ([initates (at (node4)), terminates (at (node2))])
gotoNodeWide (node4, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

Further, the current position of the mobile robot 10 has been changed from node4 to node2 by executing the action. Therefore, the plan 14 and plan 15 pre-execution conditions stored in the executing plan DB 164:

at (node4)

Is no longer satisfied. Therefore, the plan 14 and the plan 15 cannot be restarted in the future, and are deleted from the executing plan DB 164.

Furthermore, when execution of the above actions is completed, an external interrupt goal:

show (exhibition1, hanako)

The case where is entered will be described. FIG. 17 is a diagram schematically showing this interrupt goal.

  When the goal accepting unit 100 accepts an interrupt goal, the execution managing unit 120 suspends the plan (plan 10, plan 11, plan 12, plan 16, and plan 17) stored in the interrupt goal queue 112. Move to DB166. That is, it is pushed onto the stack of the executing plan DB 164. Further, the interrupt goal received by the goal receiving unit 100 is held in the interrupt goal queue 112 of the goal holding unit 110.

Then, a plan for the interrupt goal received by the goal receiving unit 100 is created. The created plan is stored in the executing plan DB 164. Here, the following four plans (plan 30, plan 31, plan 32, and plan 33) are created.

Plan 30:
[
precond ([at (node2)], []),
gotoNextNode (node2, node1),
effect ([initates (at (node1)), terminates (at (node2))])
precond ([at (node1), with (hanako)], []),
spike ('This is the world's first Japanese word processor'),
effect ([])
]

Plan 31:
[
precond ([at (node2)], []),
gotoNextNode (node2, node1),
effect ([initates (at (node1)), terminates (at (node2))]),
precond ([at (node1)], []),
gotoNextNode (node1, node2),
effect ([initates (at (node2)), terminates (at (node1))]),
gotoNodeWide (node2, node1),
explain (exhibition1, hanako)
]

Plan 32:
[
precond ([at (node2)], []),
gotoNextNode (node2, node1),
effect ([initates (at (node1)), terminates (at (node2))]),
precond ([at (node1)], []),
gotoNextNode (node1, node3),
effect ([initates (at (node3)), terminates (at (node1))]),
gotoNodeWide (node3, node1),
explain (exhibition1, hanako)
]

Plan 33:
[
precond ([at (node2)], []),
gotoNextNode (node2, node4),
effect ([initates (at (node4)), terminates (at (node2))]),
gotoNodeWide (node4, node1),
explain (exhibition1, hanako)
]

  The first task that appears in each created plan (plan 30, plan 31, plan 32, and plan 33) is an action.

  In this example, it is assumed that the condition “with (taro)”, that is, the condition “Taro turns around the mobile robot 10” is satisfied even during execution of the interrupt plan.

The action execution unit 170 executes a plan having a minimum total cost among the four created plans (plan 30, plan 31, plan 32, and plan 33). Here, the first action that appears in the plan 30 with the lowest total cost:

gotoNextNode (node2, node1)

Is executed. As a result, the mobile robot 10 moves from node2 to node1 and is located at node1, as shown in FIG.

Then the effect of executing this action:

effect ([initates (at (node1)), terminates (at (node2))])

Accordingly, at (node2) stored in the belief DB 130 is rewritten to at (node1). Furthermore, the executed action is deleted from the plan 30, the plan 31, and the plan 32. The plan 30, the plan 31, and the plan 32 after the executed action is deleted are respectively described as follows.

Plan 30:
[
precond ([at (node1), with (hanako)], []),
spike ('This is the world's first Japanese word processor'),
effect ([])
]

Plan 31:
[
precond ([at (node1)], []),
gotoNextNode (node1, node2),
effect ([initates (at (node2)), terminates (at (node1))]),
gotoNodeWide (node2, node1),
explain (exhibition1, hanako)
]

Plan 32:
[
precond ([at (node1)], []),
gotoNextNode (node1, node3),
effect ([initates (at (node3)), terminates (at (node1))]),
gotoNodeWide (node3, node1),
explain (exhibition1, hanako)
]

In addition, the current position of the mobile robot 10 is changed from node2 to node1 by executing the action. Therefore, the pre-execution condition of the plan 33 stored in the executing plan DB 164:

at (node2)

Is no longer satisfied. Therefore, the plan 33 cannot be resumed in the future, and is deleted from the executing plan DB 164.

Furthermore, the plans (plan 10, plan 11, plan 12, plan 16, and plan 17) pushed on the stack of the suspended plan DB 166 are also changed. Specifically, from Plan 10 and Plan 16, the executed actions are as follows:

gotoNextNode (node2, node1)

Delete information about.

Plan 10:
[
gotoNodeWide (node1, node2),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))

Plan 16:
[
gotoNodeWide (node1, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

In addition, pre-execution conditions of the plan 11, the plan 12, and the plan 17 stored in the suspended plan DB 166 by executing the action:

at (node2)

Is no longer satisfied. Therefore, since the plan 11, the plan 12, and the plan 17 cannot be resumed in the future, they are deleted from the executing plan DB 164.

Also, the first task of plan 10 is not an action. Therefore, the plan 10 is further disassembled. Thereby, the following plans (plan 18, plan 19 and plan 20) are created.

Plan 18:
[
precond ([at (node1)], []),
gotoNextNode (node1, node2),
effect ([initates (at (node2)), terminates (at (node1))]),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))
]

Plan 19:
[
precond ([at (node1)], []),
gotoNextNode (node1, node2),
effect ([initates (at (node2)), terminates (at (node1))]),
precond ([at (node2)], []),
gotoNextNode (node2, node1),
effect ([initates (at (node1)), terminates (at (node2))]),
gotoNodeWide (node1, node2),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))
]

Plan 20:
[
precond ([at (node1)], []),
gotoNextNode (node1, node2),
effect ([initates (at (node2)), terminates (at (node1))]),
precond ([at (node2)], []),
gotoNextNode (node2, node4),
effect ([initates (at (node4)), terminates (at (node2))]),
gotoNodeWide (node4, node2),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))
]

Also, the first task of plan 16 is not an action. Therefore, the plan 16 is disassembled, and the following plans (plan 21, plan 22, and plan 23) are created.

Plan 21:
[
precond ([at (node1), with (taro)]),
spike ('This is the world's first Japanese word processor'),
effect ([]),
changeGoal (showAround ([exhibition2], taro))
]

Plan 22:
[
precond ([at (node1)], []),
gotoNextNode (node1, node2),
effect ([initates (at (node2)), terminates (at (node1))]),
gotoNodeWide (node2, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

Plan 23:
[
precond ([at (node1)], []),
gotoNextNode (node1, node3),
effect ([initates (at (node3)), terminates (at (node1))]),
gotoNodeWide (node3, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

In addition, the execution of the interrupt plan continues. The interrupt plans stored in the executing plan DB 164 at this time are the plan 30, the plan 31, and the plan 32. Among these, the plan 30 with the lowest cost is executed. Specifically, the action that appears first in the plan 30:

spike ('This is the world's first Japanese word processor.')

Is executed. Then, the executed action is deleted from the plan 30. Thereby, the plan 30 is changed as follows.

Plan 30:
[
]

That is, the plan 30 is an empty plan. Therefore, there is no plan that has not been executed, and all executions of the interrupt goal are completed. At this time, the execution management unit 120 deletes all plans stored in the executing plan DB 164.

  The suspended plan stored in the suspended plan DB 166 is updated. At this point, the suspended plan DB 166 stores plan 18, plan 19, plan 20, plan 21, plan 22, and plan 23.

Of these, the action that appears first in the plan 21 is the same as the executed action, and is therefore deleted. Thereby, the plan 21 is changed as follows.

Plan 21:
[
changeGoal (showAround ([exhibition2], taro))
]

Furthermore, pre-execution conditions and effects are assigned to the first task of the plan 21. Thereby, the plan 21 is changed as follows.

Plan 24:
[
precond ([], []),
changeGoal (showAround ([exhibition2], taro)),
effect ([])
]

  The pre-execution conditions for the other plans (plan 18, plan 19, plan 20, plan 22, plan 23) stored in the executing plan DB 164 are still established. Therefore, these plans are continuously held in the suspended plan DB 166.

  Since execution of the interrupt plan has been completed, the execution management unit 120 next executes the suspended plans (plan 18, plan 19, plan 20, plan 22, plan 23, and plan 24) stored in the suspended plan DB 166. Resume execution. Specifically, these plans are popped from the suspended plan DB 166 and moved to the executing plan DB 164.

Then, the plan 24 having the smallest total cost is executed among the plan 18, the plan 19, the plan 20, the plan 22, the plan 23, and the plan 24. Specifically, the action:

changeGoal (showAround ([exhibition2], taro))

Execute. By performing this action, the task:

showAround ([exhibition2, taro])

Create and execute your plan.

After that, the action performed from plan 24:

changeGoal (showAround ([exhibition2], taro))

Information about is deleted. As a result, the plan 24 is changed to an empty plan as follows. Thereby, execution of the resumed plan is completed.

Plan 24:
[
]

Then the task:

showAround ([exhibition2], taro)

With this goal, multiple plans are created. Among these, the plan with the smallest total cost is the following plan (plan 40).

Plan 40:
[
precond ([at (node1)], []),
gotoNextNode (node1, node2),
effect ([initates (at (node2)), terminates (at (node4))]),
precond ([at (node2), with (taro)], []),
spike ('This is software for robot operation'),
effect ([]),
precond ([], []),
changeGoal (showAround ([], taro)),
effect ([])
]

As described above, the plan 40 created here does not include a task for guiding the exhibition exhibit 1 to Taro. This is because, in the task of guiding the exhibition exhibition 1 to Hanako, the task of guiding the exhibition exhibition 1 to Taro was executed at the same time, and the task for this was deleted. That is, in the plan 40, as shown in FIG. 19, the mobile robot 10 moves from node1 to node2, and in node2, the exhibit: exhibition2, which has not yet been explained to Taro, is described. Similarly, the plan is executed in accordance with the plan execution process described with reference to FIGS.

  FIG. 20 is a diagram illustrating a hardware configuration of the mobile robot 10 according to the embodiment. The mobile robot 10 includes, as a hardware configuration, a ROM 52 that stores a plan execution program for executing a plan execution process in the mobile robot 10, a CPU 51 that controls each part of the mobile robot 10 according to a program in the ROM 52, and a mobile robot 10 is provided with a RAM 53 for storing various data necessary for the control 10, a communication I / F 57 for connecting to a network for communication, and a bus 62 for connecting each unit.

  The plan execution program in the mobile robot 10 described above is recorded in a computer-readable recording medium such as a CD-ROM, floppy (R) disk (FD), DVD, etc. in an installable or executable format file. May be provided.

  In this case, the plan execution program is loaded onto the main storage device by being read from the recording medium and executed by the mobile robot 10 so that each unit described in the software configuration is generated on the main storage device. It has become.

  Further, the plan execution program of the present embodiment may be provided by being stored on a computer connected to a network such as the Internet and downloaded via the network.

  As described above, the present invention has been described using the embodiment, but various changes or improvements can be added to the above embodiment.

As such a first modification, the plan creation knowledge DB 140 may further store the following plan creation knowledge.

htn (explain (Object, Person), [
at (Node),
location (Object, Node),
contents (Object, Text)
], [
call (Person, Node),
spike (Text)
]).

action (call (Person, Node), [
at (Node)
], [
initiates (with (Person))
])

  Here, when the action “call (Person)” is executed when the robot is in the Node, the person: Person is called to the location where the robot is located: Node in a broadcast in the building or the like. Therefore, this action establishes with (Person) (a robot and a person: Person are together). Here, Person and Node are variables.

  For example, suppose Taro leaves while explaining an exhibit to Hanako by an interrupt goal. In this case, the pre-execution condition “I am with Taro” for the plan “explain the exhibit to Taro” is not satisfied. Therefore, this plan cannot be resumed. On the other hand, if Taro can be called as in this example, after reading Taro back, the plan of “explaining exhibits to Taro” can be executed. It is assumed that a certain cost is required to execute the action call (Person, Node).

The plan creation knowledge is based on the task of “explaining to the person: Person regarding the object: Object”:

explain (Object, Person)

To execute, even before execution condition:

with (Person)

If the following three pre-execution conditions (pre-execution condition 1, pre-execution condition 2 and pre-execution condition 3) hold, even if is not established, “person: Person, node: Node where the current robot is located: Node “To broadcast inside the hall, wait until it actually comes” task:

call (Person)

After executing the task, “object: character string of object description: text is output as voice”:

spike (Text)

Indicates that it should be executed. However, Person, Object, Node, and Text are variables.

The above pre-execution condition 1 is “the current position is a node: Node”, and is described as follows.

at (Node)

The pre-execution condition 2 is “object: the position of the object is the current position node: Node”, and is described as follows.

location (Object, Node))

Further, the pre-execution condition 3 is “the description of the object: Object is Text”, which is described as follows.

contents (Object, Text)

Further, in the same manner as described in the embodiment, the task that the goal accepting unit 100 “explains each object to a person: taro in front of the objects: exhibition1 and exhibition2”:

showAround ([exhibition1, exhibition2], taro)

Is accepted as a normal goal. In this case, the plan creating unit 150 creates the plan 5, the plan 6, the plan 8, the plan 10, the plan 11, and the plan 12 as described in the embodiment. Furthermore, the following plan (plan 12b) is created based on the above-mentioned knowledge for creating a plan.

Plan 12b:
[
precond ([at (node6)], []),
gotoNextNode (node6, node4),
effect ([initates (at (node4)), terminates (at (node6))]),
precond ([at (node4)], []),
gotoNextNode (node4, node2),
effect ([initates (at (node2)), terminates (at (node4))]),
precond ([at (node2)], []),
call (taro, node2),
spike ('This is software for robot operation'),
changeGoal (showAround ([exhibition1], taro)),
]

Next, the plan 12 is selected, and the action execution unit 170 executes the action that appears first in the plan 12. In the case of the plan 12b, the movement distance of the plan 12 is equal to the movement distance of the plan 12, but in the plan 12b, the task:

call (taro)

The total cost increases by the cost for. For this reason, the plan 12b is selected without selecting the plan 12b.

Next, as described in the embodiment, according to the plan 12, the action:

gotoNextNode (node6, node4)

Is executed and then the action:

gotoNextNode (node4, node2)

Is executed.

At this time, the executing plan DB 164 holds the plan 12b in addition to the plan 10, the plan 11, the plan 12, the plan 16, and the plan 17. Note that after the above two actions are executed, the executed actions are deleted from the plan 12b. The updated plan 12b is described as follows.

Plan 12b:
[
precond ([at (node2)], []),
call (taro, node2),
spike ('This is software for robot operation'),
changeGoal (showAround ([exhibition1], taro)),
]

Furthermore, as described in the embodiment, the interrupt goal from the outside at this point:

show (exhibition1, hanako)

Is input. In this case, the execution management unit 120 pushes the plans (plan 10, plan 11, plan 12, plan 12b plan 16, plan 17) held in the running plan DB 164 together onto the stack of the suspended plan DB 166. To do.

Next, the plan creation unit 150 creates an interrupt plan corresponding to the interrupt goal. Specifically, as described in the embodiment, the plan 30, the plan 31, the plan 32, the plan 33, and the plan 34 are created. Furthermore, in this example, the plan 30b shown below is created based on the above-mentioned knowledge for creating a plan.

Plan 30b:
[
precond ([at (node2)], []),
gotoNextNode (node2, node1),
effect ([initates (at (node1)), terminates (at (node2))])
precond ([at (node1)], []),
call (hanako, node1),
spike ('This is the world's first Japanese word processor.')
]

  The plan 30 is selected from these plans, and the action execution unit 170 executes the action that appears first in the plan 30. Note that the costs of the plan 30b and the plan 30 are the same with respect to the moving distance, but the cost of the plan 30b is increased by the amount of call (hanako). Therefore, the total cost of the plan 30b is larger. For this reason, the plan 30b is not selected but the plan 30 is selected.

In addition, according to plan 30, action:

gotoNextNode (node2, node1)

Run and then action:

spike ('This is the world's first Japanese word processor.')

Execute. Thereby, execution of the interrupt goal is completed.

In the embodiment, it is assumed that Taro moves with the mobile robot 10 while performing an action explaining the exhibit to Hanako based on the interrupt goal, but in this example, Taro does not act with Hanako. Therefore action:

gotoNextNode (node2, node1)

After running the belief:

with (taro)

No longer holds.

So first, action:

gotoNextNode (node2, node1)

After executing the above, from the plan 10 and the plan 16, the executed actions are:

gotoNextNode (node2, node1)

Is deleted.

Thereby, the plan 10 and the plan 16 are changed as follows.

Plan 10:
[
gotoNodeWide (node1, node2),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro))
]

Plan 16:
[
gotoNodeWide (node1, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

In addition, since the position of the mobile robot 10 is changed from node2 to node1 by executing the action, the pre-execution condition in the plan 11, the plan 12, the plan 12b, and the plan 17 is:

at (node2)

No longer holds. Therefore, these plans (plan 11, plan 12, plan 12b, and plan 17) are deleted from the suspended plan DB 166.

The task that appears first in the plan 10 is not an action. Therefore, the plan 10 is further disassembled. As a result, the following plans (plan 18 and plan 19) are created.

Plan 18:
[
precond ([at (node1)], []),
gotoNextNode (node1, node2),
effect ([initates (at (node2)), terminates (at (node1))]),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro)
]

Plan 19:
[
precond ([at (node1)], []),
gotoNextNode (node1, node2),
effect ([initates (at (node2)), terminates (at (node1))]),
precond ([at (node2)], []),
gotoNextNode (node2, node1),
effect ([initates (at (node1)), terminates (at (node2))]),
gotoNodeWide (node1, node2),
explain (exhibition2, taro),
changeGoal (showAround ([exhibition1], taro)
]

Also, the task that appears first in the plan 16 is not an action. Therefore, the plan 16 is further disassembled. Thereby, the following plans (plan 21b, plan 22, and plan 23) are created.

Plan 21b:
[
precond ([at (node1)], []),
call (taro, node1),
effect ([initites (with (taro))]),
precond ([at (node1), with (taro)], []),
spike ('This is the world's first Japanese word processor'),
effect ([]),
changeGoal (showAround ([exhibition2], taro))
]

Plan 22:
[
precond ([at (node1)], []),
gotoNextNode (node1, node2),
effect ([initates (at (node2)), terminates (at (node1))]),
gotoNodeWide (node2, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

Plan 23:
[
precond ([at (node1)], []),
gotoNextNode (node1, node3),
effect ([initates (at (node3)), terminates (at (node1))]),
gotoNodeWide (node3, node1),
explain (exhibition1, taro),
changeGoal (showAround ([exhibition2], taro))
]

  With (taro) is not established after the action is executed. Therefore, in the embodiment, the plan 21 created at this point is not created, and the plan 21b is created instead. FIG. 21 is a diagram schematically showing the plan 21b.

Then action:

spike ('This is the world's first Japanese word processor.')

Execute. In this example, thereafter, the plan 18, the plan 19, the plan 20, the plan 21b, the plan 22, and the plan 23 are continuously held in the suspended plan DB 166.

Note that the action at the head of the plan 21b is call (taro, node1). Therefore, the executed action from the plan 21b is:

spike ('This is the world's first Japanese word processor.')

Information about cannot be deleted. At this time, Taro is not moving with the mobile robot 10 and is not in node1. Therefore, Taro has not heard the explanation of exhibition exhibition1 at node1. Therefore, when the suspended plan is resumed, it is necessary to execute an action for explaining the exhibition exhibition1 to Taro.

  When all executions of the plan for the interrupt goal are completed, the execution management unit 120 next selects the plans (plan 18, plan 19, plan 20, plan 21b, plan 22 and plan 23) stored in the suspended plan DB 166. Move to the executing plan DB 164. Then, the execution of the plan for the normal goal is resumed.

Action at this time:

call (taro, node)

The cost of is assumed to be small compared to the cost for the moving distance. In this case, the plan 21b is selected as the plan with the lowest cost. And the action of plan 21b:
changeGoal (showAround ([exhibition2], taro))

Is given pre-execution conditions and effects. As a result, the following plan (plan 24b) is created.

Plan 24b:
[
precond ([at (node1)], []),
call (taro, node1),
effect ([initites (with (taro))]),
precond ([at (node1), with (taro)], []),
spike ('This is the world's first Japanese word processor'),
effect ([]),
precond ([]),
changeGoal (showAround ([exhibition2], taro))
effect ([])
]

The plan 24b will be executed below, but the action:
call (taro, node1)

As a result of the execution, Taro, who had not been acting with Hanako, was called to node1 in the hall information broadcasting etc., and the action:

spike ('This is the world's first Japanese word processor.')

Is different from the embodiment.

That is, in the embodiment, Taro is acting together with Hanako, and the action:

spike ('This is the world's first Japanese word processor.')

Is executed only once when Hanako and Taro are together with the mobile robot 10, whereas in this example, this action is executed twice. That is, in this example, it is executed once when the mobile robot 10 is with Hanako alone, and thereafter, Taro in another place is called and this action is executed again.

  In this way, in this example, if the interrupted plan cannot be resumed during the execution of the interrupt plan, the suspended plan is executed by adding an action that can be resumed. can do.

It is a figure which shows the function structure of the mobile robot 10 provided with the plan creation apparatus concerning this Embodiment. It is a figure which shows the relationship between a plan and an action. It is a figure which shows typically the topological map stored in belief DB130. It is a figure which shows typically the knowledge for plan creation stored in knowledge DB140 for plan creation. It is a flowchart which shows the plan execution process when the mobile robot 10 concerning embodiment performs a plan. It is a flowchart which shows the detailed process in the post-execution plan update process (step S112) demonstrated in FIG. It is a flowchart which shows the detailed process in the plan update process (step S208) demonstrated in FIG. It is a flowchart which shows the detailed process in the pre-execution condition confirmation process (step S220) demonstrated in FIG. It is a figure for demonstrating the 1st condition. It is a figure for demonstrating the 2nd condition. It is a flowchart which shows the detailed process in the task decomposition | disassembly process (step S228) demonstrated in FIG. It is a flowchart which shows the detailed process in the plan update process at the time of restart demonstrated in FIG. 5 (step S124). It is a flowchart which shows the detailed process in the goal process (step S128) demonstrated in FIG. It is a figure which shows an example of a normal goal typically. It is a figure which shows typically the state after action execution. It is a figure which shows typically the state after action execution. It is a figure which shows an example of an interruption goal typically. It is a figure which shows typically the state after action execution. It is a figure which shows typically the state after action execution. It is a figure which shows the hardware constitutions of the mobile robot 10 concerning embodiment. It is a figure which shows the plan 21b typically.

Explanation of symbols

51 CPU
52 ROM
53 RAM
57 Communication I / F
62 Bus 10 Mobile Robot 100 Goal Accepting Unit 110 Goal Holding Unit 112 Interruption Goal Queue 114 Normal Goal Queue 120 Execution Management Unit 130 Belief DB
140 Knowledge DB for creating plans
150 Plan creation unit 160 Plan DB control unit 162 Interrupt plan DB
164 Running plan DB
166 Suspended plan DB
170 Action execution part

Claims (14)

A plan execution device for executing a plan for achieving a goal indicating a certain purpose,
An ongoing plan holding means for holding a plan capable of achieving the goal;
Plan execution means for executing the plan held in the executing plan holding means;
The suspended plan holding means for holding the plan for which the plan executing means has suspended execution;
Goal acquisition means for acquiring an interrupt goal to be achieved in preference to the goal by interruption while the plan execution means is executing the plan;
Based on the interrupt goal acquired by the goal acquisition means, plan creation means for creating an interrupt plan to be executed in order to achieve the interrupt goal;
When the goal acquisition means acquires the interrupt goal, execution of the plan being executed by the plan execution means is suspended, and the plan held in the executing plan holding means is changed to the suspended plan holding means. Plan execution control means for saving and holding the interrupt plan created by the plan creation means in the executing plan holding means;
When the plan execution unit executes the interrupt plan, the plan update unit updates the content of the plan held by the suspended plan holding unit based on the execution content;
When the plan execution unit completes the execution of the interrupt plan, the updated plan held in the suspended plan holding unit is moved to the running plan holding unit, and then the running plan holding is performed. And a plan resumption control means for resuming execution of the plan held by the means. The executing plan holding means holds a plurality of plans that can achieve the same goal,
The plan execution means executes a plan among a plurality of plans held by the executing plan holding means,
The plan execution control means, when execution of the plan being executed by the plan execution means is interrupted, causes the plurality of plans held in the executing plan holding means to be saved in the interrupting plan holding means,
The plan update means updates the contents of each of the plurality of plans held by the suspended plan holding means based on the execution contents when the plan execution means executes the interrupt plan,
The plan resumption control means, when the plan execution means completes the execution of the interrupt plan, stores a plurality of updated plans held in the suspended plan holding means to the executing plan holding means. 2. The plan execution apparatus according to claim 1, wherein after executing the movement, the execution of a plan among the plurality of plans held in the executing plan holding unit is resumed. A plan selection unit that selects a plan to be executed by the plan execution unit from the plurality of plans based on an execution cost of each of the plurality of plans held by the executing plan holding unit;
The plan execution device according to claim 2, wherein the plan execution unit executes the plan selected by the plan selection unit.   The plan update unit stores the execution plan holding unit based on the execution contents when the plan execution unit executes a plan among a plurality of plans held in the execution plan holding unit. The plan execution apparatus according to claim 2, wherein each of the plurality of plans is updated. Each of the plan and the interrupt plan includes a plurality of actions that are execution units in the plan execution means,
The plan execution means executes the interrupt plan for each action,
The plan update means includes a first action that is an action to be executed first among actions included in the plan held by the suspended plan holding means, and the interrupt plan executed by the plan executing means. 5. The plan according to claim 1, wherein when the action is the same, the top action is deleted from the plan held by the suspended plan holding unit. 6. Execution device. Action generating means for generating at least the next head action from the deleted plan when the plan updating means deletes the head action from the plan held by the suspended plan holding means;
A pre-execution condition for giving a pre-execution condition that is a condition for executing the action generated by the action generation means and that is a condition related to the state of the target object to the action generated by the action generation means Granting means;
State information holding means for holding state information indicating the state of the target object to be executed by the plan;
The plan update unit includes the action to which the pre-execution condition is assigned when the state information held by the state information holding unit does not satisfy the pre-execution condition given by the pre-execution condition assignment unit. 6. The plan execution apparatus according to claim 5, wherein the plan is deleted from the suspended plan holding unit. The executing plan holding means holds a plurality of interrupt plans created based on the same interrupt goal by the plan creating means,
When the plan execution unit executes the interrupt plan for each action, the plan update unit executes the interrupt executed by the plan execution unit among the interrupt plans held by the executing plan holding unit. The interruption held by the executing plan holding means when the first action included in the interruption plan other than the inclusion plan and the action of the interruption plan executed by the plan execution means are the same The plan execution apparatus according to claim 5 or 6, wherein the head action is deleted from the interrupt plans other than the interrupt plan executed by the plan execution means in the plan. The action generation means, when the plan update means deletes the top action from the interrupt plan held by the executing plan holding means, at least the next top action from the interrupt plan after deletion. Generate
The pre-execution condition assigning means assigns the pre-execution condition of the action generated from the interrupt plan by the action generating means to the action generated from the interrupt plan,
The plan update unit includes the action to which the pre-execution condition is assigned when the state information held by the state information holding unit does not satisfy the pre-execution condition given by the pre-execution condition assignment unit. The plan execution apparatus according to claim 7, wherein the interrupt plan is deleted from the executing plan holding unit.   The plan execution apparatus according to claim 6, wherein the action generation unit generates the action based on the state information held by the state information holding unit. An execution effect imparting means for imparting an execution effect indicating the effect of the execution of the action to the action;
A state information update unit that updates the state information held by the state information holding unit based on the execution effect given to the action each time the plan execution unit executes the action; and
10. The plan update unit according to claim 6, wherein the plan update unit determines whether or not the state information after being updated by the state information update unit satisfies the pre-execution condition. 11. Plan execution device. The plan and the interrupt plan each include a plurality of actions which are execution units in the action execution means,
The plan execution means executes the interrupt plan in action units,
The plan update means is a head which is an action to be executed first among actions included in the plan held by the suspended plan holding means when the plan execution means fails to execute the action When the action and the action of the interrupt plan that the plan execution unit has failed to execute are the same, the plan held by the suspended plan holding unit, the plan of the interrupt plan 5. The plan execution apparatus according to claim 1, wherein the plan including the first action that is the same as an action is deleted. 6. The running plan holding means holds a plurality of interrupt plans created based on the same interrupt goal by the plan creating means,
The plan update unit includes the first action included in the interrupt plan held by the executing plan holding unit and the plan executing unit executed when the plan execution unit fails to execute the action. If the action of the interrupt plan that failed is the same as the action of the interruption plan held by the executing plan holding means, the first action that is the same as the action of the interruption plan The plan execution apparatus according to claim 11, wherein the interrupt plan is deleted. A plan execution method for executing a plan that achieves a goal indicating a certain purpose,
A plan execution step of executing the plan held in the executing plan holding means holding a plan capable of achieving the goal;
A goal acquisition step of acquiring an interrupt goal to be achieved in preference to the goal by interruption during execution of the plan in the plan execution step;
Based on the interrupt goal acquired in the goal acquisition step, a plan creation step for creating an interrupt plan to be executed to achieve the interrupt goal;
When the interrupt goal is acquired in the goal acquisition step, the execution of the running plan is interrupted, the plan held in the executing plan holding means is saved in the interrupting plan holding means, and the A plan execution control step of holding the interrupt plan created in the plan creation step in the executing plan holding means;
A plan update step of updating the content of the plan held by the suspended plan holding means based on the execution content when the interrupt plan is executed;
When the execution of the interrupt plan is completed, the updated plan held in the suspended plan holding means is moved to the running plan holding means, and then held in the running plan holding means. A plan resumption control step for resuming execution of the plan. A plan execution program for causing a computer to execute a plan execution process for executing a plan for achieving a goal indicating a certain purpose,
A plan execution step of executing the plan held in the executing plan holding means holding a plan capable of achieving the goal;
A goal acquisition step of acquiring an interrupt goal to be achieved in preference to the goal by interruption during execution of the plan in the plan execution step;
Based on the interrupt goal acquired in the goal acquisition step, a plan creation step for creating an interrupt plan to be executed to achieve the interrupt goal;
When the interrupt goal is acquired in the goal acquisition step, the execution of the running plan is interrupted, the plan held in the executing plan holding means is saved in the interrupting plan holding means, and the A plan execution control step of holding the interrupt plan created in the plan creation step in the executing plan holding means;
A plan update step of updating the content of the plan held by the suspended plan holding means based on the execution content when the interrupt plan is executed;
When the execution of the interrupt plan is completed, the updated plan held in the suspended plan holding means is moved to the running plan holding means, and then held in the running plan holding means. A plan resumption control step for resuming execution of the plan.

Images