Actin  Version 5.5.1
Software for Robotics Simulation and Control
The Manipulation Director Backend Architecture

Introduction

The manipulation director coordinates the manipulation, or movement, of multiple robots simultaneously to perform tasks. The manipulation director can be thought of as the director of a play, and the individual robots can be thought of as the actors in the play. The play consists of a manuscript, or script, and casting. The script defines roles, as well as directions for each role, and the casting defines the mapping between the actors and the roles. This document describes the architecture and usage of the manipulation director backend.

The manipulation director backend is implemented in the manipulationDirector library. The backend can be broken down into the following groups: high-level architecture, stage directions, manipulation directions, conditions, director object directory, state, simple state, and visitors. Additionally, it is possible to extend the backend with custom pieces.

High-Level Architecture

The high-level architecture of the manipulation director backend is shown in Figure 1 below.

manipDirectorFramework_image1.png
Manipulation director high-level architecture
High level classes of the Manipulation Direction architecture
Class Description
EcManipulationDirector This class is the highest level interface in the manipulationDirector library. It consists of three components: the director object directory, the active script, and the cast. The director object directory is described in section DirectorObjectDirectory. The script is described below. The cast is simply a mapping (EcXMlStringU32Map) from a string “role” name to an integer that indicates the manipulator index of the “actor”. An active script is one of script obejcts from the directory that was active recently.
EcDirectorObjectDirectory This class provides a hierarchical directory structure for storing director objects. It is essentially a database of reusable objects, such as scripts, scenes, directions or poses, that can be used in a script. Each object is stored in EcDirectorObjectContainer. Further documentation of the director object directory is included in sectionsection DirectorObjectDirectory
EcManipulationScript This class is composed of one or more scenes or scene references. Scene reference means the reference(path) to a scene object in the director object directory. The scene is described below. While a scene encapsulates a lower-level task, a script combines the lower-level tasks in order to accomplish a higher-level task. For example one scene could involve attaching a gripper to a robot, and another scene could involve using the gripper to pick up an object. The script could combine the two scenes together. When a script uses a scene as reference, the changes that happen in the scene will be effective the script also.
EcBaseManipulationScene, EcManipulationScene, EcManipulationSceneReference EcBaseManipulationScene is an abstract interface for two types of scenes used in a script. The scene is composed of directions and cues for each role that is active in the scene. Each direction is stored in EcManipulationSceneDirectionContainer below. Each role has a vector of directions, and the scene stores this vector in a map that is keyed by the role name. The scene also contains a map of cues keyed by role name. Each cue is defined in EcManipulationSceneCue. Multiple cues can be defined for each of the role’s directions. EcManipulationSceneReference contains the reference/ path of a scene object in a director object directory.
EcManipulationSceneCue The cue provides a synchronization point between directions for multiple roles. Each cue can either be a simultaneous cue or a following cue. A simultaneous cue implies that specific directions for multiple roles should be executed simultaneously. In the case of coordinated movement of an object being grasped by two robot roles, robot role “A” must move simultaneously with robot role “B”. A following cue implies that a specific direction for a role must wait until a specific direction for another role completes before it can begin execution. In the case of an object hand off between two robot roles, robot role “A” must wait until robot role “B” grabs the object before robot role “A” can release its grasp on the object.
EcManipulationSceneDirection This is an abstract interface for all directions used in a scene. More docuementation is provided in the section below. There are two basic types of scene directions: stage directions and manipulation directions.
EcManipulationSceneDirectionContainer This class holds objects of type EcManipulationSceneDirection (see EcManipulationSceneDirection). It allows different implementations of EcManipulationSceneDirection to be stored generically.
EcStageDirection This is an abstract interface for all stage directions. A stage direction is a direction that takes effect instantaneously, and it does not require an update loop. Consider tool attachment as an example. Moving the robot into position to attach to a tool requires an update loop; therefore, the movement should be implemented as a manipulation direction. Once in position, the attachment of the tool to the robot should be instantaneous, so the attachment should be implemented as a stage direction. See the stage directions section for additional documentation.
EcManipulationDirection This is an abstract interface for all manipulation directions. Unlike a stage direction, a manipulation direction requires an update loop. The update method for the direction will be called until the direction indicates that it has either completed successfully or failed. Generally, manipulation directions require commanding robotic movements; however, this is not always the case. For example, a “tracking” direction might attempt to use a camera to track an item in its field of view. In the tracking example, the tracker direction would continue to update until a successful track is established, and no robotic movement would need to be commanded while the tracker is running. Manipulation Directions below includes additional documentation on manipulation directions.

The EcManipulationSceneDirection class

EcManipulationSceneDirection is an abstract interface for all directions used in a scene. There are two basic types of scene directions: stage directions and manipulation directions.

All direction classes derived from EcManipulationSceneDirection must implement the following methods: EcManipulationSceneDirection::descriptor, EcManipulationSceneDirection::init, and EcManipulationSceneDirection::convert.

EcManipulationSceneDirection Interface Methods
Manipulation Scene Direction Required Method Description
EcManipulationSceneDirection::descriptor This method returns a string description that is used as a default label for the direction in the frontend interface.
EcManipulationSceneDirection::init This method is called during the initialization of the manipulation director. It should return true if the direction is valid and false if the direction is invalid. If this initialization fails, then the overall manipulation director initialization will also fail. It can be used to validate the directions also. All the validations of the directions like to check the availability of the roles, poses, plugins and sensors need to be done in this method.
EcManipulationSceneDirection::convert This method is used to convert a direction state (ManipulationDirectorState) into a simple state (see section Manipulation Director Simple State).

Apart from the above mentioned methods, there are few virtual methods that can be overridden to support the visitors.

There are two sets of method, one set that allow modifications EcManipulationSceneDirectionsVisitorModifiyMethods and antoher set that do not allow modifications, take const reference objects EcManipulationSceneDirectionsVisitorConstMethods.

Manipulation Scene Direction Visitor support Method for modifications Description
EcManipulationSceneDirection::acceptDodLibraryVisitor The default implementation is provided in the base class. If any of the directions do not allow visitation, need to override the method.
EcManipulationSceneDirection::traverseDodLibraryVisitor The compound directions may have to implement the general traversal by overriding this method.
EcManipulationSceneDirection::handleLibraryEvent During visitation, if a direction requires any modification like rename role or rename pose, then this method needs to be overridden as required.

Manipulation Scene Direction Visitor support Methods with Const objects Description
EcManipulationSceneDirection::acceptDodReaderVisitor The default implementation is provided in the base class. If any of the directions do not allow visitation, need to override the method.
EcManipulationSceneDirection::traverseDodReaderVisitor The compound directions may have to implement the general traversal by overriding this method.
EcManipulationSceneDirection::handleLibraryEvent The implementation during visitation on how the direction object need to be validated or observed need to be handled here.

Stage Directions

A stage direction is a direction that takes effect instantaneously, and it does not require an update loop. This includes dynamic changes to the simulation configuration including setting collision exclusions and attachments. Reading a sensor values, setting variables or sending signals are also examples of operations that do not require an update loop and therefore are implemented as stage directions.

Stage Direction Interface

All stage directions deriving from EcStageDirection must implement the methods described in the table below in addition to those described in the table above.

EcStageDirection Interface Methods
Stage Direction Interface Method Description
EcStageDirection::apply This method is called at the point in the script where the stage direction should be executed. It should return true if the direction was successfully executed and false if the direction failed to execute.

Stage Direction Implementations

manipDirectorFramework_image2.png
Stage direction implementations included in the manipulation director backend.

The table below describes the EcStageDirection derived classes.

Overview of classes derived from EcStageDirection
Stage Direction Derived Class Description
EcAssignObjectRoleDirection Some actions are defined relative to an object. For instance a manipulation sequence can utilize an object relative offset. This allows the manipulation to adapt to the location of the object; however, it requires the object to be specified prior to executing the action. This concrete stage direction defines the object role to be used for such object relative actions.
EcAttachToDirection This is a concrete stage direction that attaches or detaches a role to or from another role. This is similar to EcSetAttachmentDirection; however, this direction is issued the “attaching” role instead of the “base” role. In the case of a robot with multiple tools, tool role “Tool A” can be attached to robot role “A” by issuing this direction to “Tool A”.
EcCollisionExclusionDirection There are times when the collision exclusion map needs to be modified in order. Attachment, detachment, gripping, and releasing are a few examples. During attachment collisions between robot role “A” and tool role “Tool A” need to be excluded in order for the robot to move into a close position to attach to the tool. Similarly, when the tool is detached, the previously-excluded collisions should be removed from the collision exclusions. This concrete stage direction provides the ability to add or remove collision exclusions.
EcSendSignalDirection This concrete stage direction provides the ability to send a signal that can be received by any other code running on the same process as the manipulation director. For instance, a signal could be used to turn on a camera at a certain point during a visual servoing script.
EcSetAttachmentDirection This is a concrete stage direction that attaches or detaches a role to or from another role. This is similar to EcAttachToDirection; however, this direction is issued the “base” role instead of the “attaching” role. In the case of a robot with multiple tools, robot role “A” can attach tool role “Tool A” to itself by issuing this direction.
EcToolOffsetDirection This concrete stage direction provides the ability to adjust the tool offset of an end effector. For instance, it is often desirable to adjust the tool offset to be at the gripper when attaching to a gripper tool.

Manipulation Directions

Manipulation Direction Interface

All manipulation directions deriving from EcManipulationDirection must implement the methods described in the table below in addition to those listed in the table above.

EcManipulationDirection Interface Methods
Manipulation Direction Interface Method Description
EcManipulationDirection::update This method is called at the point in the script where this manipulation direction should be updated. It should return FAILED if there was a failure when updating the direction, SUCCESS if the direction completed successfully, or IN_PROGRESS if the direction is incomplete.
EcManipulationDirection::activeState This method returns the active state (EcManipulationActiveState) for the manipulation direction. The active state is described in section /ref SECT_ManipulationActiveState
EcManipulationDirection::dataMap This method returns a data map.
EcManipulationDirection::progress This method returns the progress if this direction. The progress should always be between 0.0 and 1.0, where 0.0 indicates that the direction just started and 1.0 indicates that the direction completed successfully.
EcManipulationDirection::statusString This method returns a status string that can be presented to the user.

Manipulation Direction Implementations

Figure 3 below shows the manipulation direction implementations included in the manipulation director backend.

manipDirectorFramework_image3.png
Manipulation direction implementations

The table below describes the EcManipulationDirection derived classes.

Overview of classes derived from EcManipulationDirection
Manipulation Direction Derived Class Description
EcConditionalDirection Conditional directions have preconditions, post conditions, persistent conditions, sub directions, and exceptions. Preconditions are conditions that must be satisfied before the sub directions are executed. As an example, a gripping operation might check to see that the gripper tool is attached as a precondition. Post conditions are conditions that must be satisfied after the sub directions are executed. As an example, a gripping operation might check to ensure an item is attached to the gripper as a post condition. Persistent conditions are conditions that must be satisfied while the sub directions are executed. As an example, a gripping operation might ensure that the gripper tool remains attached throughout the execution of the sub directions. See the Conditions section below for additional documentation regarding conditions. The sub directions are the nominal directions that should execute if all of the preconditions, post conditions, and persistent conditions pass. Exceptions are directions that are executed upon the failure of a condition or a sub direction. Exceptions provide the ability to self-correct after an unexpected event.
EcManipulationDirectionReference This direction references a direction object that is defined in the director object directory.
EcManualPauseDirection This direction waits until an operator manually issues a command to continue.

Direction Conditions

EcDirectionCondition

Direction Condition Interface

This is an abstract interface for all conditions. All EcDirectionCondition derived classes must implement the following methods:

EcDirectionCondition Interface Methods
Direction Condition Interface Method Description
EcDirectionCondition::init This method is called during the initialization of the manipulation direction where the condition is used. It should return true if the condition is valid and false if the condition is invalid. All the validations of the conditions like to check the availability of the roles, poses, plugins and sensors need to be done in this method.
EcDirectionCondition::test This method returns true of the condition passes or false if the condition fails.
EcDirectionCondition::text This method returns a text description of the condition that is useful to display in the frontend.

Direction Condition Implementations

Figure 4 below shows the condition architecture. The table below describes the classes deriving from EcDirectionCondition.

manipDirectorFramework_image4.png
Condition architecture
Overview of classes derived from EcDirectionCondition
Direction Conditoin Derived Class Description
EcDirectionConditionContainer This class holds objects of type EcDirectionCondition. It allows different implementations of EcDirectionCondition to be stored generically.
EcUnaryDirectionCondition This is an abstract interface for a condition that operates on a single wrapped condition.
EcBinaryDirectionCondition This is an abstract interface for a condition that operates on a two wrapped conditions.
EcNotDirectionCondition This is a concrete implementation of a unary condition that negates the results from the wrapped condition.
EcAndDirectionCondition This is a concrete implementation of a binary condition that combines the results of the two wrapped conditions with a logical
EcOrDirectionCondition This is a concrete implementation of a binary condition that combines the results of the two wrapped conditions with a logical OR.
EcXorDirectionCondition This is a concrete implementation of a binary condition that combines the results of the two wrapped conditions with a logical XOR (exclusive OR).
EcHasAttachmentCondition This is a concrete condition that tests if the current role has a specified attachment.
EcIsAttachedToCondition This is a concrete condition that tests if the current role is attached to another specified role.

Director Object Directory

Figure 5 below shows the director object directory architecture.

manipDirectorFramework_image5.png
Director object directory architecture
Key classes in the Director Object Directory architecture
Class Description
EcDirectorObjectDirectory This class provides a hierarchical directory structure for storing director objects represented by EcDirectorObject. Such objects are reusable components that can be referenced within a script or a scene.
EcDirectorObject This is an abstract interface for all objects stored inside the director object directory. See the section on the Director Object below
EcDirectorObjectContainer This class holds objects of type EcDirectorObject. It allows different implementations of EcDirectorObject to be stored generically.

EcDirectorObject class

Director Object Interface

This is an abstract interface for all objects stored inside the director object directory. The table below gives shows the interface methods provided by EcDirectorObject.

EcDirectionCondition Interface Methods
Director Object Interface Method Description
EcDirectorObject::script If a EcManipulationScript is stored in the director object, then this method should return a pointer to that sript. Otherwise, this method should return a null pointer.
EcDirectorObject::scene If a EcManipulationScene is stored in the director object, then this method should return a pointer to that scene. Otherwise, this method should return a null pointer.
EcDirectorObject::directionContainer If a EcManipulationSceneDirectionContainer is stored in the director object, then this method should return a pointer to that direction container. Otherwise, this method should return a null pointer.
EcDirectorObject::pose If a EcPose is stored in the director object, then this method should return a pointer to that pose. Otherwise, this method should return a null pointer.

Director Object Implementations

The table below shows the classes that derive from EcDirectorObject.

Overview of classes derived from EcDirectorObject
Director Object Derived Class Description
EcManipulationScriptDirectorObject This is a concrete director object that stores a EcManipulationScript object.
EcManipulationSceneDirectorObject This is a concrete director object that stores a EcManipulationScene object.
EcManipulationSceneDirectionDirectorObject This is a concrete director object that stores a EcManipulationSceneDirection object.
EcPoseDirectorObject This is a concrete director object that stores a EcPose object.

Director State Architecture

When a manipulation director is executing, it is designed to remain constant. An architecture of state classes keeps tack of the current execution state of the manipulation director. Figure 6 below shows the manipulation director state architecture.

manipDirectorFramework_image6.png
Manipulation director state architecture
Key classes in the Director State architecture
Class Description
EcManipulationDirectorState This class contains the execution state of EcManipulationDirector, which includes the script state as well.
EcManipulationScriptState This class contains the execution state of EcManipulationScript, which includes the states for each scene included in the script.
EcManipulationSceneState This class contains the execution state of EcManipulationScene, which includes the states for each direction included in the scene.
EcManipulationSceneDirectionState This is an abstract interface for the execution state of EcManipulationSceneDirection.
EcManipulationSceneDirectionStateContainer This class holds objects of type EcManipulationSceneDirectionState. It allows different implementations of EcManipulationSceneDirectionState to be stored generically.
EcManipulationDirectionState The base class that provides and interface for any manipulation direction state

EcManipulationDirectionState

The table below includes a set of classes derived from EcManipulationDirectionState.

Overview of classes derived from EcManipulationDirectionState
Director Object Derived Class Description
EcActionDirectionState This class contains the execution state of EcActionDirection, which includes the state for the corresponding EcManipulationAction.
EcConditionalDirectionState This class contains the execution state of EcConditionalDirection, which includes the state for each sub direction or exception included I the conditional direction.
EcManipulationDirectionReferenceState This class contains the execution state of EcManipulationDirectionReference, which includes the state for the corresponding direction that is referenced.
EcManualPauseDirectionState This class contains the execution state of EcManualPauseDirection.

Simple State Architecture

The state architecture documented in the Director State Architecture section above often includes data that is not readily serializable to XML. EcActionDirectionState, for example, includes a pointer to a EcManipulationAction, and the pointer would be meaningless to write to XML. The simple state architecture was designed to allow the state to be written to file or sent over the network. Conversion routines are provided to convert a state into a simple state. Additionally, methods are provided to fast forward a state, given a simple state. By combining the convert and fast forward methods, it is possible to restore the manipulation director state from any saved simple state. Figure 1 below shows the manipulation director simple state architecture.

manipDirectorFramework_image7.png
Manipulation director simple state architecture
Key classes in the Director Simple State architecture
Class Description
EcManipulationDirectorSimpleState This class contains the simplified execution state of EcManipulationDirector, which includes the simplified script state as well.
EcManipulationScriptSimpleState This class contains the simplified execution state of EcManipulationScript, which includes the simplified states for each scene included in the script.
EcManipulationSceneSimpleState This class contains the simplified execution state of EcManipulationScene, which includes the simplified states for each direction included in the scene.
EcManipulationSceneDirectionSimpleState This is an abstract interface for the simplified execution state of EcManipulationSceneDirection.
EcManipulationSceneDirectionSimpleStateContainer This class holds objects of type EcManipulationSceneDirectionSimpleState. It allows different implementations of EcManipulationSceneDirectionSimpleState to be stored generically.

EcManipulationSceneDirectionSimpleState

The table below shows the classes that derive from EcManipulationSceneDirectionSimpleState.

Overview of classes derived from EcManipulationSceneDirectionSimpleState
Simple State Derived Class Description
EcActionDirectionSimpleState This class contains the simplified execution state of EcActionDirection.
EcBasicDirectionSimpleState This class contains the simplified execution state for any directions that do not have more specialized simplified states. It is a generic placeholder.
EcConditionalDirectionSimpleState This class contains the simplified execution state of EcConditionalDirection.

Visitors

Manipulation Director Visitors

The manipulation director architecture is complex. It can be challenging to make changes to a manipulation director, especially if that also involves changing the associated state as well. A visitor framework is available to simplify some of the common tasks. Figure 8 below shows the visitor framework.

manipDirectorFramework_image8.png
Manipulation director visitor framework
Key classes in the Manipulation Director Visitor architecture
Class Description
EcManipulationDirectorVisitor This is an abstract interface for all visitors.
EcAppendSceneVisitor This visitor appends a scene to the script contained in the manipulation director. The scene to append is specified in the constructor.
EcDirectionCuesChangedVisitor This visitor replaces the old set of cues with a new set of cues for a specified direction. The scene index, role name, and direction index are specified in the constructor to determine the specific direction requiring the adjusted cues. Additionally, the old cues and new cues are specified in the constructor to determine how to adjust the cues.
EcInsertDirectionVisitor This visitor inserts a new direction at a specified position in a scene. The scene index, role name, direction, and direction index are specified in the constructor. The direction index indicates the desired position for the new direction inside the role’s vector of directions.
EcMoveDirectionVisitor This visitor moves a direction to a specified position in a scene. The scene index, role name, old direction index, and new direction index are specified in the constructor. The old direction index indicates the current position of the direction in the tole’s vector of directions, while the new direction index indicates the position the direction should be moved to.
EcRemoveDirectionVisitor This visitor removes a direction from a scene. The scene index, role name, and direction index are specified in the constructor. The direction index indicates the index of the direction to remove from the role’s vector of directions.

DOD visitors

The Director Object Directory contains many ojects where one item depends on another one. For example, a scene uses directions, so any change in direction name needs to reflect in the scene. DOD visitor framework helps to simplify these tasks. Figure 8.1 below shows the DOD visitor framework. EcDodObjectVisitor visitors allow modifications during visitation.

manipDirectorFramework_image8_1.png
DOD visitor framework
Key classes in the DOD Visitor architecture
Class Description
EcDodObjectVisitor This is an abstract interface for all the DOD visitors.
EcDODRemoveRoleVisitor This visitor removes a role from the director. The role name is specified in the constructor.
EcDODRenameActionVisitor This visitor renames an action, updates the references in the directory. The old name and new name are specified in the constructor.
EcDODRenamePoseVisitor This visitor renames a pose and updates the references in the directory. The old pose name and new name are specified in the contructor.
EcDODRenameRoleVisitor This visitor renames the role in the directory. The old name and new name are specified in the constructor.

Const DOD visitors

Sometimes it is required to access the Director object directory objects and find out the dependencies, and perform anyother searches. EcDodReaderVisitor visitors do not allow modifications during visitation and work on const objects.

manipDirectorFramework_image8_1.png
DOD visitor framework
Key classes in the const DOD Visitor architecture
Class Description
EcDodReaderVisitor This is an abstract interface for all the DOD visitors to work on const objects.
EcDodFindVisitor This visitor is used to find dependencies like objects uses given pose.

Extensions

It is possible to extend the manipulation director backend with custom direction implementations. Adding extensions requires the following steps: implement the extensions, build the extensions into a plugin, and use the plugin with the appropriate container classes.

Extensions can be added for the following abstract interfaces: EcManipulationSceneDirection, EcManipulationSceneDirectionState, EcManipulationSceneDirectionSimpleState, and EcDirectionCondition. Each extension implementation must include two static methods: “classToken” and “creator”. The “classToken” static method returns a EcToken for the extension class. The “creator” static method constructs an instance of the extension class on the heap and returns a pointer to that instance as a EcXmlObject (base class) pointer.

The following interface classes in the Manipulation Director architecture can be used to create custome Extensions
Extensions to Class Description
EcManipulationSceneDirection All direction extensions must either implement the EcStageDirection interface or the EcManipulationDirection interface. A manipulation direction extension will most likely require an extension to EcManipulationSceneDirectionState as well. An extension to EcManipulationSceneDirectionSimpleState may also be needed.
EcManipulationSceneDirectionState Any manipulation direction extension that needs to keep track of state during execution will also require a corresponding extension for the state.
EcManipulationSceneDirectionSimpleState Any manipulation direction extension that needs the ability to save state to file or restore state from file will also require a corresponding extension for the simple state.
EcDirectionCondition New conditions can be added by extension as well. These condition extensions can be used inside a conditional direction.

Building the Extension as a Plugin

The extension implementations must be built into a plugin in order to be usable by the manipulation director backend. A plugin is essentially a shared library with the extension “.ecp” (or “.ecpd” for debug builds). The plugin requires two “C” functions to be defined: “getClassToken” and “getCreator”. Listing 1 below shows the declaration of these two functions.

Declaration of getClassToken and getCreator functions

#if WIN32
#define EC_DECL_EXPORTS __declspec(dllimport)
#else
#define EC_DECL_EXPORTS
#endif
extern "C" EC_DECL_EXPORTS const EcToken& getClassToken(EcU16);
typedef EcXmlObject* (*EcXmlObjectCreator)();
extern "C" EC_DECL_EXPORTS EcXmlObjectCreator getCreator(EcU16);

“getClassToken” Function

Listing 2 below shows an example definition for the “getClassToken” function. The function should return a token for each extension class included in the plugin. This function will be called with an increasing index value until it returns an empty string. Each extension class should have a corresponding index, ad it must be consistent with “getCreator” (section getCreator). When that index is passed into the function, it should call the associated extension’s “classToken” static method (section getClassToken) to get the appropriate return value. Notice that extensions of different abstract interfaces can be included in the same plugin.

Example definition of getClassToken function

const EcToken& getClassToken
(
EcU16 index
)
{
static const EcToken emptyString;
switch (index)
{
case 0:
{
return EcTimedWaitExampleDirection::classToken();
}
case 1:
{
}
case 2:
{
return EcSendSignalExampleDirection::classToken();
}
default:
{
return emptyString;
}
}
}

“getCreator” Function

Listing 3 below shows an example definition for the “getCreator” function. The function should return a pointer to the static creator method for each class included in the plugin. This function will be called with an increasing index value until it returns a null pointer. Each extension class should have a corresponding index, and it should be consistent with “getClassToken” (section getClassToken). When that index is passed into the function, it should return a pointer to the associated extension’s “creator” static method. Notice that extensions of different abstract interfaces can be included in the same plugin.

Example definition of getCreator function

"getCreator"

(
EcU16 index
)
{
switch (index)
{
case 0:
{
return EcTimedWaitExampleDirection::xmlObjectCreator;
}
case 1:
{
return EcTimedWaitExampleDirectionState::xmlObjectCreator;
}
case 2:
{
return EcSendSignalExampleDirection::xmlObjectCreator;
}
default:
{
return 0;
}
}
}

Using the Exension Plugin

In order to use extensions, the basename of the plugin must be specified in the “addLibraries” of the appropriate container class prior to setting the element of the container to the extension. The code block below shows the example usage of a manipulation director backend plugin.

Example usage of a manipulation director backend plugin

EcXmlStringVector addLibraries;
addLibraries.pushBack(EcXmlString("manipDirectorExtensionsExample"));
container.setAddLibraries(addLibraries);
container.setElement(direction);

In the example, the plugin is named “manipDirectorExtensionsExample.ecp”, and it includes “EcTimedWaitExampleDirection” as a direction extension. The corresponding XML for the above example is shown in Listing 5 below.

Example XML usage of a manipulation direction extension

1 <manipulationSceneDirectionContainer>
2  <addLibraries size = "1">
3  <element>manipDirectorExtensions</element>
4  </addLibraries>
5  <timedWaitExampleDirection>
6  <tag></tag>
7  <waitDuration>30</waitDuration>
8  </timedWaitExampleDirection>
9 </manipulationSceneDirectionContainer>