Semantic Robot Description Language

The Semantic Robot Description Language (SRDL) extends KnowRob with representations for robot hardware, robot software and robot capabilities. The hardware models can automatically be imported from a URDF description, and are annotated with additional semantic information. For example, one can annotate semantically meaningful groups of links such as the left arm or the right gripper (see image on the right). SRDL integrates this information into KnowRob, allowing the system to reason about the robot's configuration. In addition, SRDL provides inference mechanisms that operate on the robot model and are able to check which dependencies of action descriptions are available on the robot. This allows to identify missing components or capabilities.

The SRDL ontology is organized in a modular way, e.g. to describe only components or only capabilities. The diagram below shows which parts of the ontology import which other ones.

• srdl2: Only generic cross-file relations like the generic dependsOn property
• srdl2-comp: Classes of hardware and software components, aggregation of components to kinematic chains, composition of components
• srdl2-cap: Classes of capabilities, including their dependencies on components or other capabilities
• srdl2-action: Dependency specifications for common actions
• Robot model: Description of a concrete robot instance including its kinematic structure (auto-generated from URDF file), other hardware/software components and hardcoded capabilities
• Task model: Description of the concrete task at hand, using the action classes defined in the srdl-action ontology

Read all components of a robot. There is no distinction between robots and components any more, robots are just complex components that consist of many parts.

?- srdl2:sub_component(tumrosie:'TUM_Rosie1', Sub).
Sub = 'http://ias.cs.tum.edu/kb/TUM_Rosie.owl#TUM_Rosie_WheeledOmnidirPlatform1' ;
Sub = 'http://ias.cs.tum.edu/kb/TUM_Rosie.owl#TUM_Rosie_Torso1' .

… Check whether a component of a certain type exists on a robot (or, in general, as part of another component):

?- srdl2:comp_type_available(tumrosie:'TUM_Rosie1', CompT).
CompT = 'http://ias.cs.tum.edu/kb/srdl2-comp.owl#VectorFieldArmController' ;
CompT = 'http://ias.cs.tum.edu/kb/srdl2-comp.owl#ArmMotionController' ;
CompT = 'http://ias.cs.tum.edu/kb/srdl2-comp.owl#MotionControllerComponent' ;
...

Check which capabilities exists on a robot

?- srdl2:cap_available_on_robot(Cap, tumrosie:'TUM_Rosie1').
Cap = 'http://ias.cs.tum.edu/kb/srdl2-cap.owl#ArmMotionCapability' ;
Cap = 'http://ias.cs.tum.edu/kb/srdl2-cap.owl#BaseMotionCapability' ;
Cap = 'http://ias.cs.tum.edu/kb/srdl2-cap.owl#GripperMotionCapability' ;
Cap = 'http://ias.cs.tum.edu/kb/srdl2-cap.owl#HeadMotionCapability' ;
...

Capabilities an action depends on:

?- srdl2:required_cap_for_action(tablesetting:'TableSetting', Cap).
Cap = 'http://ias.cs.tum.edu/kb/srdl2-cap.owl#PuttingDownAnObjectCapability' ;
Cap = 'http://ias.cs.tum.edu/kb/srdl2-cap.owl#PickingUpAnObjectCapability' ;
Cap = 'http://ias.cs.tum.edu/kb/srdl2-cap.owl#BaseMotionCapability' ;
Cap = 'http://ias.cs.tum.edu/kb/srdl2-cap.owl#ArmMotionCapability' ;
...

Components an action depends on (either directly or via required capabilities that depend on these components)

?- srdl2:required_comp_for_action(tablesetting:'TableSetting', Comp).
Comp = 'http://ias.cs.tum.edu/kb/srdl2-comp.owl#MobileBase' ;
Comp = 'http://ias.cs.tum.edu/kb/srdl2-comp.owl#ArmMotionController' ;
Comp = 'http://ias.cs.tum.edu/kb/srdl2-comp.owl#ArmComponent' ;
...

?- missing_cap_for_action(tablesetting:'TableSetting', tumrosie:'TUM_Rosie1', Cap).
Cap = 'http://ias.cs.tum.edu/kb/srdl2-cap.owl#PuttingDownAnObjectCapability' ;
Cap = 'http://ias.cs.tum.edu/kb/srdl2-cap.owl#PickingUpAnObjectCapability' ;

?- missing_comp_for_action(tablesetting:'TableSetting', tumrosie:'TUM_Rosie1', Comp).
false.

The matching can effectively reduced to the following statement:

missing_cap_for_action(Action, Robot, Cap) :-
   required_cap_for_action(Action, Cap),
   \+ cap_available_on_robot(Cap, Robot).

A missing capability is thus defined as one that is required by an action, but not provided by the robot. Required means that either the action itself or any sub-action has a dependency on this capability:

required_cap_for_action(Action, Cap) :-
   class_properties(Action, srdl2cap:'dependsOnCapability', Cap).
required_cap_for_action(Action, Cap) :-
   plan_subevents_recursive(Action, SubAction),
   class_properties(SubAction, srdl2cap:'dependsOnCapability', Cap).

There are three possibilities to express that a capability is available on a robot: Either it is asserted to be available for the whole class of robots (e.g. every PR2 has a holonomic base), for a specific robot instance, or it can be concluded that the capability should be available because all specified dependencies on components or other capabilities are fulfilled:

% capability asserted for robot instance
cap_available_on_robot(Cap, Robot) :-
   class_properties(Robot, srdl2cap:'hasCapability', Cap).

% capability asserted for robot class
cap_available_on_robot(Cap, Robot) :-
   rdfs_individual_of(Robot, RobotClass),
   class_properties(RobotClass, srdl2cap:'hasCapability', Cap).

% capability depends only on available components or capabilities
cap_available_on_robot(Cap, Robot) :-

   rdfs_subclass_of(Cap, srdl2cap:'Capability'),

   forall( class_properties(Cap, srdl2comp:'dependsOnComponent', CompT),
           comp_type_available(Robot, CompT) ),

   forall( class_properties(Cap, srdl2cap:'dependsOnCapability', SubCap),
           cap_available_on_robot(SubCap, Robot) ).

The matching procedure is equivalent for components.

SRDL2 is a re-implementation of the original Semantic Robot Description Language presented by Kunze et al (ICRA 2011). The code has been completely re-written to improve its flexibility and generality. The main changes are the following:

• No distinction between primitive and composite capabilities.
• Actions, capabilities and components can depend on other components, actions and capabilities can depend on other capabilities
• There are no “CapabilityProvisionAlternatives” any more, which are replaced by simple sub-classes of a capability
• The modeling of sub-components was improved by using transitive properties that are derived from 'subComponent' instead of many different relations. The same holds for the 'dependsOn' relation that subsumes 'dependsOnComponent' and 'dependsOnCapability'.
• Dependencies can now be described using OWL restrictions, which is important to specify more details, e.g. the dependency on an object recognition model that allow to recognize a certain kind of object (and not just an arbitrary model)
• The descriptions for components, capabilities and actions have been separated in order to facilitate the description of robots and actions, and to keep the system as modular as possible.
• Instead of lists, the system now uses the more Prolog-like backtracking.