Skip to content
This repository has been archived by the owner on Dec 1, 2021. It is now read-only.

Motion Instructions

Janis Sprenger edited this page Feb 18, 2021 · 1 revision

Motion Instructions

Note
This section could be moved to the Motion Model Unit section.

The formats being described within this section build the core of the MMI framework and are relevant for the usage of the Motion Model Units, the Co-Simulation, as well as for the behavior modeling and the target engine.

Motion Instruction (MInstruction)

The so-called MInstruction class represents an important format in order to specify a desired motion. The format is strongly inspired by the behavior markup language (BML), see [10], [11]. Below, the class diagram as well as a detailed description of the parameters and practical examples are provided.

MInstruction
+ID: string
+Name: string
+MotionType: string
+Properties: map<string,string>
+Constraints: list
+StartCondition: string
+EndCondition: string
+Action: string
+Instructions: list

Detailed description of available parameters:

Parameter Name Required Description
ID: x Represents a unique id, which is utilized to reference the motion instructions. The ID must be generated by the user/behavior, which create the instruction.
Name: x A name, which can be specified for the given instruction. The name does not need to be unique (e.g. “WalkInstruction1”).
MotionType x The type is used to access the desired motion (e.g. walk, grasp). Each MMU has in additional also a specified motion type. By matching the motion types, a suitable MMU can be identified and accessed. The motion type must be specified by the user/behavior creating the instruction. In particular, the available motion types (provided by the MMUs) must be known a priori.
Properties Optional dictionary which can contain properties for the MMUs (e.g. {“Velocity”,”1.0”}, {“TargetObject”, “Object1”} ,{”MMU_ID”, “xy”}).
Constraints Constraints can be optionally set for the instruction. For instance, a constraint describing the end posture (=start posture of subsequent MMU) can be inserted. The different types of constraints in the framework are described in 3.2.4.3.
StartCondition Relevant information for the timing of the motion within the co-simulation. The conditions are strongly inspired by BML: Example: id_task1:end ()
EndCondition Relevant information for the timing of the motion. Given a end-condition a motion can be terminated after a specific event occurred or a specified amount of time is elapsed. Example: id_task1:end ()
Action
Instructions A MInstruction can contain additional MInstruction in order to represent tree structures utilized for hierarchical co-simulation or behavior modeling. Note for MMU utilization is it expected that only one instruction is utilized for each MMU.

Examples:

MInstruction Walk
ID “12345”
Name “Walk Instruction 1”
MotionType “walk”
Properties {“Target”, “Walk Target 1”}
MInstruction Grasp Object
ID “23456”
Name “Grasp Instruction 1”
MotionType “grasp”
Properties {“Target”, “Object1”} {“Hand”, “Left”} {“Velocity”, “1.0m/s”}
Start-condition 12345:End

Motion Instruction Result (MInstructionResult)

Note
Deprecated: MInstructionResult is not found in the thrift files

The so-called MInstructionResult represents the result or status of an executed MInstruction. The co-simulator sends it to the Behavior Execution, which can generate new MInstructions based on it. The MInstructionResult is sent to the Behavior Execution each time an instruction is executed by the co-simulator. In addition to the ID and the state of the executed MInstruction, this contains a list of further MInstructionResults as well as properties that contain possible reasons for a failure.

<<interface>>
MInstructionResult
+MInstructionID: string
+State: MInstructionState
+Properties: map<string,string>
+Instructions: list

Detailed description of available parameters:

Parameter Name Required Description
MInstructionID x The ID of the corresponding instruction.
State x State of the corresponding instruction
Properties Optional dictionary which can contain properties for the MMUs
Instructions Optional list of linked MInstructions
MInstructionState (enum)
FRESH
SUCCEEDED
FAILED

Constraints

For more information on Constraints, please consider the constraints definition.

Boolean Responses

On important format for calling functions with a Boolean response is the so-called MBoolResponse class. This class contains in addition to the Boolean value also a list of string in order to provide information in case of errors.

MBoolResponse
+Value: bool
+Log: list

Detailed description of available parameters:

Parameter Name Required Description
Value x A Boolean value which indicates whether the operation was successful or not
Log An optional list of log strings. This should be used if errors occurred during the processing. This information is helpful for debugging and error handling.

Drawing Calls

The MDrawingCall class is used to exchange information regarding the drawing of geometric elements such as lines. Mainly utilized for debugging.

MDrawingCall
Type: MDrawingCallType
Data: list
Properties: map<string,string>

Detailed description of available parameters:

Parameter Name Required Description
Type x The specific type of the drawing (see MDrawingCallType enum).
Data x The transmitted data (e.g. list of coordinates). The data representations depend on the used MDrawingCallType.
Properties Additional properties that can be specified.

For the MMI framework, a base set of different drawing types (MDrawingCallType) is defined that are listed below.

MDrawingCallType (enum)
DrawLine2D
DrawLine3D
DrawPoint2D
DrawPoint3D

MOSIM Documentation

Introduction

Documentation

Known Issues

Clone this wiki locally