Differences
This shows you the differences between two versions of the page.
| doc:modeling_tasks_and_actions [2013/04/22 09:34] – created admin | doc:modeling_tasks_and_actions [2014/01/17 09:30] (current) – removed gkazhoya | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Modeling tasks and actions ====== | ||
| - | |||
| - | This page describes how actions and tasks are modeled in KnowRob. There are two kinds of descriptions: | ||
| - | |||
| - | ===== ABOX or TBOX? ===== | ||
| - | |||
| - | In KnowRob, Knowledge is modeled in [[http:// | ||
| - | |||
| - | In case of actions, these instances may be | ||
| - | * actually observed or performed actions (something that happened at a certain time) | ||
| - | * planned actions (something one intends to do) | ||
| - | * inferred actions (something one imagines that happens) | ||
| - | * asserted actions (some action someone told me has happened) | ||
| - | In any case, one talks about an action that could be asserted a (past or future) time and actor. | ||
| - | |||
| - | In contrast, the tbox describes general information about classes of actions. These can be quite general classes like PuttingSomethingSomewhere, | ||
| - | |||
| - | ===== Modeling action classes (TBOX) ===== | ||
| - | |||
| - | KnowRob provides a taxonomic structure describing several subclasses of Action: | ||
| - | |||
| - | * //Action// -> PurposefulAction | ||
| - | * // | ||
| - | * // | ||
| - | * // | ||
| - | * // | ||
| - | * // | ||
| - | * // | ||
| - | * // | ||
| - | * // | ||
| - | * // | ||
| - | |||
| - | There are many more and more detailed action classes available, and the taxonomy can easily be extended. These action classes form the vocabulary for describing the different kinds of actions the system knows. | ||
| - | |||
| - | Each of these actions can be described by its properties: For instance, one could state that every action of type Movement-TranslationEvent is a subclass of Action with the properties fromLocation, | ||
| - | |||
| - | |||
| - | As an example, let's have a look at the description of the class PuttingSomethingSomewhere that corresponds to transporting an object from one position to another. Obviously, this kind of action involves to pick up the object, move to the goal position, and put the object down again. These sub-events are modeled in the following piece of code: | ||
| - | |||
| - | < | ||
| - | | ||
| - | < | ||
| - | < | ||
| - | | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | </ | ||
| - | </ | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | </ | ||
| - | </ | ||
| - | | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | </ | ||
| - | </ | ||
| - | | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | </ | ||
| - | </ | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | </ | ||
| - | </ | ||
| - | | ||
| - | </ | ||
| - | | ||
| - | Note that the ordering of the three subEvent restrictions in the OWL file does not have any meaning. In order to describe their allowed orderings, we need to add some constraints. These constraints are described as follows: | ||
| - | |||
| - | < | ||
| - | < | ||
| - | < | ||
| - | </ | ||
| - | |||
| - | < | ||
| - | < | ||
| - | < | ||
| - | </ | ||
| - | |||
| - | Unfortunately, | ||
| - | |||
| - | ===== Composing actions to tasks (TBOX) ===== | ||
| - | |||
| - | Complex robot tasks can be decomposed into primitive actions and movements. If the sub-actions for lower-level actions are already modeled, tasks can be described conveniently on a rather abstract level, like the already mentioned PuttingSomethingSomewhere actions. The following code is an excerpt of a plan for setting a table. | ||
| - | |||
| - | The upper region describes the task SetATable as a subclass of Action with a set of sub-actions. | ||
| - | |||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | </ | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | </ | ||
| - | | ||
| - | [...] | ||
| - | | ||
| - | </ | ||
| - | </ | ||
| - | </ | ||
| - | </ | ||
| - | | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | </ | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | </ | ||
| - | </ | ||
| - | </ | ||
| - | </ | ||
| - | </ | ||
| - | | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | </ | ||
| - | < | ||
| - | </ | ||
| - | </ | ||
| - | </ | ||
| - | </ | ||
| - | | ||
| - | [...] | ||
| - | |||
| - | The lower part shows how task-specific subclasses describe actions with certain parameters. While setting a table, the robot may be told to put a place mat in front of the chair. This command is translated into a class specification: | ||
| - | |||
| - | Though the modeling of such tasks in the TBOX may seem a bit clumsy at first glance, it is necessary to describe the general ' | ||
| - | |||
| - | ===== Describing observed actions (ABOX) ===== | ||
| - | |||
| - | General task descriptions are useful for storing general knowledge about activities and for planning actions. Whenever the robot is reasoning on actually performed actions, either by itself or by a human, it needs to describe action instances. | ||
| - | |||
| - | These instances can, for example, be generated by an action recognition system that interacts with the knowledge base and populates the set of action instances based on observations of humans. Based on these observations, | ||
| - | |||
| - | For more information, | ||
| - | |||
| - | ===== Putting it all together ===== | ||
| - | |||
| - | So why all this effort? | ||
| - | |||
| - | * Action recognition: | ||
| - | |||
| - | * Action verification: | ||
| - | |||
| - | * Action execution: The abstract task model can be used to generate code for the robot' | ||
| - | |||
