OpenPLX Physics

https://openplx.org/documentation/
Admin
OpenPLX Physics is a collection of OpenPLX bundles designed for modeling complex physical...
Tokens:49,874
Snippets:223
Trust Score:5.3
Update:1 year ago
Show doc for...
Tokens:
Raw
### Three Level SNAP Example - RigidBody and System Setup

Source: https://openplx.org/documentation/0.17.8/Physics3D

Defines a three-level physics hierarchy with a RigidBody, two nested Systems (RodParent and RodParentParent), and MateConnectors for snapping. It demonstrates how SNAP handles transform computations when multiple local transforms are specified.

```javascript
Rod is Physics3D.Bodies.RigidBody: inertia.mass: 10 geometry is Physics3D.Charges.Box: size: Math.Vec3.from_xyz(0.1, 0.1, 1) arrow is Physics3D.Charges.Box: local_transform: position.z: 0.5 rotation: Math.Quat.angleAxis(Math.PI / 4, Math.Vec3.Y_AXIS()) size: Math.Vec3.from_xyz(0.071, 0.1, 0.071) connector is Physics3D.Charges.MateConnector: position.z: -geometry.size.z * 0.6 main_axis: Math.Vec3.Y_AXIS() normal: Math.Vec3.Z_AXIS() RodParent is Physics3D.System: rod is Rod RodParentParent is Physics3D.System: rod_system is RodParent World is Physics3D.System: world_connector is Physics3D.Charges.MateConnector: position.x: 0.5 main_axis: Math.Vec3.Y_AXIS() normal: Math.Vec3.X_AXIS() rod_system is RodParentParent world_lock is Physics3D.Interactions.Lock: charges: [rod_system.rod_system.rod.connector, world_connector] SnapRod is World: rod_system.local_transform.rotation: Math.Quat.fromTo(Math.Vec3.from_xyz(1,0,0), Math.Vec3.from_xyz(1,1,1).normal()) rod_system.rod_system.local_transform.rotation: Math.Quat.fromTo(Math.Vec3.from_xyz(0,1,0), Math.Vec3.from_xyz(1,1,1).normal()) SnapRodParent is World: rod_system.local_transform.rotation: Math.Quat.fromTo(Math.Vec3.from_xyz(1,0,0), Math.Vec3.from_xyz(1,1,1).normal()) rod_system.rod_system.rod.kinematics.local_transform.rotation: Math.Quat.fromTo(Math.Vec3.from_xyz(0,1,0), Math.Vec3.from_xyz(1,1,1).normal()) SnapRodParentParent is World: rod_system.rod_system.local_transform.rotation: Math.Quat.fromTo(Math.Vec3.from_xyz(1,0,0), Math.Vec3.from_xyz(1,1,1).normal()) rod_system.rod_system.rod.kinematics.local_transform.rotation: Math.Quat.fromTo(Math.Vec3.from_xyz(0,1,0), Math.Vec3.from_xyz(1,1,1).normal()) 
```

--------------------------------

### SNAP Algorithm Pseudocode

Source: https://openplx.org/documentation/0.17.8/Physics3D

This pseudocode outlines the step-by-step process of the SNAP algorithm. It details how mates are processed, how undefined transforms are resolved, and how ambiguities are handled to achieve a stable assembly. It serves as a logical blueprint for the algorithm's implementation.

```pseudocode
S ← Set of all mates
D ← Degrees of freedom left from mates being snapped
A, B ← mate connectors
C ← A coordinate system that has an undefined local transform relative its parent
Snap(A, B, C) ← Function that computes a local transform for C which moves A to B, using the SNAP transform.


while there are unused mate's in S:

    N = current_num_used_mates(S)

    for each mate M with mate connectors A and B:
        G ← closest common ancestor of A and B
        [AG[ ← sequence of local transforms from A to G
        [BG[ ← sequence of local transforms from B to G

        if num_undefined_transforms([AG[) == 1 && num_undefined_transforms([BG[) == 0:
            C ← get_first_undefined_transform([AG[)
            T ← Snap(A, B, C)
            C.set_local_transform(T)
            D.insert(generate_degrees_of_freedom(M, C))
        else if num_undefined_transforms([AG[) == 0 && num_undefined_transforms([BG[) == 1:
            C ← get_first_undefined_transform([BG[)
            T ← Snap(A, B, C)
            C.set_local_transform(T)
            D.insert(generate_degrees_of_freedom(M, C))
        else if num_undefined_transforms([AG[) == 0 && num_undefined_transforms([BG[) == 0:
            T ← find_solution_using_degrees_of_freedom(M, D)


    # No frame was positioned in the previous loop
    # SNAP will force a transform to be the identity

    num_dof ← current_num_unused_degrees_of_freedom(D)

    if N == current_num_used_mates(S):
        if num_dof > 0:
            kill_first_degree_of_freedom(D)
            continue    # Now try all mates again, might have got rid of a ambiguity

        M ← first_unused_mate_that_with_undefined_transform_chain(S)
        A, B ← get_mate_connectors(M)
        G ← closest common ancestor of A and B
        [AG[ ← sequence of local transforms from A to G
        [BG[ ← sequence of local transforms from B to G
        if num_undefined_transforms([AG[) > 0:
            C ← get_first_undefined_transform([AG[)
            C.set_local_transform(I)
            continue   # Now try all mates again, might have got rid of a ambiguity
        else if num_undefined_transforms([BG[) > 0:
            C ← get_first_undefined_transform([BG[)
            C.set_local_transform(I)
            continue    # Now try all mates again, might have got rid of a ambiguity
        else:
            # ERROR
            This mate M did not have an undefined transform chain

    break the while loop

```

--------------------------------

### SNAP Transform Computation Formula

Source: https://openplx.org/documentation/0.17.8/Physics3D

Derives the generic formula for computing a target local transform 'S' within a hierarchical structure, based on the equivalence of nested transforms and a target matrix 'A'. This formula is crucial for aligning components using SNAP.

```plaintext
S = N^{-1}AP^{-1}
```

--------------------------------

### Terrain Class Definition and Example

Source: https://openplx.org/documentation/0.17.8/Terrain/Terrain

Defines the Terrain class in OpenPLX, inheriting from Physics3D.Bodies.Body. It specifies properties for terrain dimensions, element size, and maximum depth, along with an example demonstrating its instantiation and configuration within a Physics3D.System.

```openplx
Terrain is Physics3D.Bodies.Body:
    .doc: """
    A Terrain is modifiable by Shovels

    num_elements_x - defines the number of elements in the x direction.
    num_elements_y - defines the number of elements in the y direction.
    element_size - The distance between the height points in the terrain
    max_depth - The maximum depth that the terrain can have.

    The size of the terrain is thus (num_elements_x-1)*element_size x (num_elements_y-1)*element_size

    Example:

    Scene is Physics3D.System:
    local_transform.position.x: 1
    terrain is Terrain.Terrain:
        num_elements_x: 151
        num_elements_y: 201
        element_size: 0.10
        max_depth: 5.0
        # Let terrain starts at origo
        kinematics.local_transform.position.x: (terrain.num_elements_x-1)/2*terrain.element_size
        kinematics.local_transform.position.y: (terrain.num_elements_y-1)/2*terrain.element_size

    """
    num_elements_x is Int
    num_elements_y is Int
    element_size is Real
    max_depth is Real

    material is TerrainMaterial: MaterialLibrary.defaultTerrainMaterial
```

--------------------------------

### Define RigidLink Class in OpenPLX

Source: https://openplx.org/documentation/0.17.8/Robotics/Links/RigidLink

This snippet defines the RigidLink class, inheriting from Physics3D.Bodies.RigidBody. It includes properties for start and end mate connectors, and contact geometry. The class is intended as a base for creating rigid bodies that require manual configuration of physical properties.

```openplx
RigidLink is Physics3D.Bodies.RigidBody:
    .doc: """
An empty rigid link, user needs to add geometry, inertia and mate connectors start and end.
"""
    start is Physics3D.Charges.MateConnector
    end is Physics3D.Charges.MateConnector
    contact_geometry is Physics3D.Charges.ContactGeometry
```

--------------------------------

### Define EngageInput as BoolInput in OpenPLX

Source: https://openplx.org/documentation/0.17.8/Physics/Signals/EngageInput

This snippet defines the EngageInput as a boolean input type within the OpenPLX framework. It includes a documentation string explaining its purpose, emphasizing the distinction between engagement and activation, with examples provided for clarity. The input is of type BoolInput.

```openplx
EngageInput is BoolInput:
    .doc: """
An Input that is a boolean, specifying weather to engage or disengage the source.
Not to be mistaken for ActivateInput. For example a clutch can be engaged, but not activated.
A vacuum gripper can be activated, but is not engaged until an object is in the gripper.
"""

```

--------------------------------

### URDF PackagePath Definition and Usage in OpenPLX

Source: https://openplx.org/documentation/0.17.8/Urdf/PackagePath

Defines the PackagePath structure for URDF packages in OpenPLX, specifying its name and path. It also provides an example of how to declare and use a PackagePath within a robot definition, highlighting its role in referencing external URDF files.

```openplx
PackagePath:
    .doc: """
This is a package path for a URDF package. It is used to specify the location of files that URDFs depend on.

Example:

MyRobot is Robot:
    package_path is Urdf.PackagePath:
        name: \"my_package\"
        path: @\"../packages/my_package\""""
    name is String
    path is String

    fn on_init()
```

--------------------------------

### Define RangeInteraction1DOF in OpenPLX

Source: https://openplx.org/documentation/0.17.8/Physics3D/Interactions/RangeInteraction1DOF

This snippet defines the RangeInteraction1DOF class in OpenPLX. It inherits from Interaction1DOF and specifies properties like flexibility, dissipation, start, and end points of the range. The start and end properties define the boundaries of the one-dimensional range.

```OpenPLX
RangeInteraction1DOF is Physics.Interactions.Interaction1DOF:
    .doc: """
    A limit range, for where the degree of freedom is bound.
    The boundary conditions are considered one dimensional walls,
    with which the two involved bodies will collide, if violated.
    The interaction when bumping in to the range defined with an ElasticityType.
    """
    flexibility is Physics.Interactions.Flexibility.DefaultFlexibility
    dissipation is Physics.Interactions.Dissipation.DefaultDissipation
    start is Real
    end is Real
```

--------------------------------

### Physics3D System Definition and Methods

Source: https://openplx.org/documentation/0.17.8/Physics3D/System

This snippet defines the Physics3D System object, outlining its properties and methods. It includes functionalities for initializing the system, snapping bodies, and transforming bodies/systems relative to the world. It also details attributes like `kinematically_controlled` (deprecated) and `reference_body`.

```openplx
System is Physics.System:
    .doc: """
A physical system is a collection of bodies, interactions, and subsystems.
Each body and subsystem has local transformations relative to the system.
These local transformations can either be explicitly specified or computed by SNAP, given the mate interactions.

Any Physics3D.Bodies.RigidBody, Physics3D.System or PowerLine within a System will be included in the physics simulation.
Geometries, however, will not be part of the simulation unless they belong to a Physics3D.Bodies.RigidBody.

Each system has a reference rigid body that maintains the system's frame of reference.
This reference is applied to the reference body through a redirected mate connector.
The reduce_object_to_root_system_transform() function is utilized by the bundle implementation
to compute transformations relative to the root system.
Physics3D recognizes a reference system at the origin.
on_init() - Used by the bundle implementation, will choose a reference_body, if one is not specified.
reduce_body_to_world_system_transform() - Used by the bundle implementation to compute a transform from a rigid body to the world system.
reduce_to_world_system_transform() - Used by the bundle implementation to compute a transform from this system to the world system.
kinematically_controlled -  deprecated, to specify the motion control of a RigidBody see is_dynamic attribute in RigidBody.openplx.
reference_body - a body chosen to be carry the origin of the system.
                 Will be the first body to get a forced local transform by SNAP,
                 to get past ambiguous states in the SNAP algorithm in a deterministic way.
"""

    local_transform is Math.AffineTransform
    fn on_init()
    static fn resnap(system: System)
    fn reduce_body_to_world_system_transform(rigid_body: Physics3D.Bodies.RigidBody) -> Math.AffineTransform
    fn reduce_to_world_system_transform() -> Math.AffineTransform
    # kinematically_controlled is deprecated, use RigidBody.is_dynamic instead
    kinematically_controlled is Physics3D.Bodies.RigidBody[]: []
    reference_body is Physics3D.Bodies.Body

```

--------------------------------

### Create Matrix4x4 from Various Inputs in OpenPLX

Source: https://openplx.org/documentation/0.17.8/Math/Matrix4x4

Provides static methods to construct Matrix4x4 instances from different data representations, including row-major order, individual rows, individual columns, and combined translation and rotation vectors.

```openplx
static fn from_row_major(r0c0: Real, r0c1: Real, r0c2: Real, r0c3: Real, r1c0: Real, r1c1: Real, r1c2: Real, r1c3: Real, r2c0: Real, r2c1: Real, r2c2: Real, r2c3: Real, r3c0: Real, r3c1: Real, r3c2: Real, r3c3: Real) -> Matrix4x4
    static fn from_rows(r0: Real[], r1: Real[], r2: Real[], r3: Real[]) -> Matrix4x4
    static fn from_columns(c0: Real[], c1: Real[], c2: Real[], c3: Real[]) -> Matrix4x4
    static fn from_vec3_quat(v : Vec3, q : Quat) -> Matrix4x4
```

--------------------------------

### Define CylindricalRoller Component - OpenPLX

Source: https://openplx.org/documentation/0.17.8/Vehicles/Tracks/CylindricalRoller

Defines the CylindricalRoller component, inheriting from CylindricalRoadWheel. It includes documentation explaining its function as a non-motorized wheel that supports vehicle weight and guides tracks in tracked vehicles.

```openplx
CylindricalRoller is CylindricalRoadWheel:
    .doc:  """
Rollers, both road rollers and return rollers, in tracked vehicles
are the wheels that bear the weight of the vehicle or guide the track
on its return path after it leaves the sprocket.
They spin freely and are not motorized. 
They facilitate the movement of the tracks around the path.
"""
    


```

--------------------------------

### Define Input Component in OpenPLX

Source: https://openplx.org/documentation/0.17.8/Physics/Signals/Input

This snippet shows how to define an Input component in OpenPLX. It includes the component's documentation string, its type, and an optional reference ID.

```OpenPLX
Input:
    .doc: """
An Input, ie a receiver of signals.
- Each Input should have a type-attribute, e.g. InputOutputType.Torque1D, Angle, AngularVelocity or any of above.
- Use type Composite when the Input receives a Signal with multiple values.
- reference_id is optional and must be unique within each Robot and can be used to identify the sensor, e.g. when communicating using Click or ROS. Typically the full name will be used if not set.
"""
    type is Int
    reference_id is String: ""
```

--------------------------------

### Define LinkData Structure in OpenPLX

Source: https://openplx.org/documentation/0.17.8/Robotics/Links/LinkData

Defines the LinkData structure in OpenPLX, including physics properties like inertia and geometric properties for start and end points such as position, main axis, and normal vector.

```OpenPLX
LinkData:
    inertia is Physics3D.Bodies.Inertia

    start_position is Math.Vec3
    start_main_axis is Math.Vec3:
        x: 0
        y: 0
        z: 1
    start_normal is Math.Vec3:
        x: 1
        y: 0
        z: 0
    end_position is Math.Vec3
    end_main_axis is Math.Vec3:
        x: 0
        y: 0
        z: 1
    end_normal is Math.Vec3:
        x: 1
        y: 0
        z: 0
```

--------------------------------

### EngagedOutput Signal Definition in OpenPLX

Source: https://openplx.org/documentation/0.17.8/Physics/Signals/EngagedOutput

Defines the EngagedOutput signal, which inherits from Physics.Signals.BoolOutput. It provides a detailed documentation string explaining its function as a boolean output signifying engagement, contrasting it with ActivatedOutput using practical examples.

```OpenPLX
EngagedOutput is Physics.Signals.BoolOutput:
    .doc: """
An Output that is a boolean, answering if the source is engaged or not.
Not to be mistaken for ActivatedOutput. For example a clutch can be engaged, but not activated.
A vacuum gripper can be activated, but is not engaged until an object is in the gripper.
"""


```

--------------------------------

### SignalInterface C++ Extensions for Inputs and Outputs

Source: https://openplx.org/documentation/0.17.8/Physics/Signals/SignalInterface

These C++ extensions provide methods to retrieve all input and output signals from the SignalInterface. They are part of the OpenPLX physics/signals library, allowing programmatic access to signal data.

```cpp
std::unordered_map<std::string, std::shared_ptr<openplx::Physics::Signals::Input>> getInputs() const;
```

```cpp
std::unordered_map<std::string, std::shared_ptr<openplx::Physics::Signals::Output>> getOutputs() const;
```

--------------------------------

### Matrix3x3 Definition and Initialization (OpenPLX)

Source: https://openplx.org/documentation/0.17.8/Math/Matrix3x3

Defines the Matrix3x3 structure in OpenPLX, including its real-valued elements stored in row-major order. It also specifies static factory functions for creating matrices from row-major data, individual rows, columns, or diagonal values.

```OpenPLX
# Matrix3x3
#
# The elements are on row-major order, i.e. the first index represents the row
# and the second the column.
#
# [ e00 e01 e02 ]
# [ e10 e11 e12 ]
# [ e20 e21 e22 ]
#
Matrix3x3:
    # row 0
    e00 is Real: 1.0
    e01 is Real: 0.0
    e02 is Real: 0.0
    # row 1
    e10 is Real: 0.0
    e11 is Real: 1.0
    e12 is Real: 0.0
    # row 2
    e20 is Real: 0.0
    e21 is Real: 0.0
    e22 is Real: 1.0

    static fn from_row_major(r0c0: Real, r0c1: Real, r0c2: Real, r1c0: Real, r1c1: Real, r1c2: Real, r2c0: Real, r2c1: Real, r2c2: Real) -> Matrix3x3
    static fn from_rows(r0: Real[], r1: Real[], r2: Real[]) -> Matrix3x3
    static fn from_columns(c0: Real[], c1: Real[], c2: Real[]) -> Matrix3x3
    static fn diag(x: Real, y: Real, z: Real) -> Matrix3x3
```

--------------------------------

### URDF Robot Definition with Mesh

Source: https://openplx.org/documentation/0.17.8/Urdf

This snippet shows a basic URDF file defining a robot with a link and a collision geometry referencing a mesh file using a package path.

```xml
<robot name="Robot">
	<link name="link A">
        <collision name="link A collision">
            <geometry>
                <mesh filename="package://package_A/subdir/meshA.stl"/>
            </geometry>
        </collision>
	</link>
</robot>

```

--------------------------------

### OpenPLX Scene Configuration with URDF Package

Source: https://openplx.org/documentation/0.17.8/Urdf

This OpenPLX script imports a URDF file and configures a URDF package to resolve package paths for imported assets. It defines a scene with a robot and a package named 'package_A' pointing to a specific directory.

```openplx
import @"robot.urdf"

Scene is Physics3D.System:
    robot is Robot
    package_A is Urdf.PackagePath:
        name: "package_A"
        path: "/from/root/"

```

--------------------------------

### Shovel Terrain Modification in OpenPLX

Source: https://openplx.org/documentation/0.17.8/Terrain/Shovel

This code snippet illustrates the setup of a Shovel object for terrain modification within the OpenPLX framework. It defines the Shovel's properties, including its rigid body, top edge, cutting edge, and cutting direction, using geometric and physics components.

```openplx
Shovel:
    .doc: """
    A Shovel can be used to modify terrain

    Example:

    Scene is Physics3D.System:
        shovel_body is ShovelRigidBody
        shovel is Terrain.Shovel:
            body: shovel_body
            top_edge: Math.Line.from_points(shovel_body.top_left, shovel_body.top_right)
            cutting_edge: Math.Line.from_points(shovel_body.bottom_left, shovel_body.bottom_right)
            cutting_direction: shovel_body.forward

    """
    body is Physics3D.Bodies.RigidBody
    top_edge is Math.Line
    cutting_edge is Math.Line
    cutting_direction is Math.Vec3
```

--------------------------------

### AdaptiveMateConnector Definition in OpenPLX

Source: https://openplx.org/documentation/0.17.8/Physics3D/Charges/AdaptiveMateConnector

Defines the AdaptiveMateConnector component, inheriting from MateConnector. It includes documentation explaining its behavior and use cases, particularly in adapting relative positions between mate connectors.

```openplx
AdaptiveMateConnector is MateConnector:
    .doc: """
    
    When using one AdaptiveMateConnector in a mate, 
    it will transform to the relative position of the owning body/system so that it aligns with the other mate connector.
    There can't be any degrees of freedom left between the MateConnectors, meaning that SNAP has done the work already. 
    This feature can be used to introduce interactions in a non-violated state, without having to specify 
    initial conditions for all 6 degrees of freedom for two mate connectors.
    For example, a mate connector for the suspension that is defined given the chassis of the car may mate with the 
    other parts, and just adapt to how these are placed relative the chassis.
    """

    



```

--------------------------------

### ValueOutputSignal Class Definition (OpenPLX)

Source: https://openplx.org/documentation/0.17.8/Physics/Signals/ValueOutputSignal

Defines the ValueOutputSignal class, inheriting from OutputSignal. It includes static factory methods for creating signals from various primitive types and complex vector types, as well as instance methods for type checking and type casting.

```openplx
ValueOutputSignal is OutputSignal:
    value is Value
    static fn create(v: Value, source: Output) -> ValueOutputSignal
    static fn from_angle(v: Real, source: Output) -> ValueOutputSignal
    static fn from_angular_velocity_1d(v: Real, source: Output) -> ValueOutputSignal
    static fn from_distance(v: Real, source: Output) -> ValueOutputSignal
    static fn from_force_1d(v: Real, source: Output) -> ValueOutputSignal
    static fn from_velocity_1d(v: Real, source: Output) -> ValueOutputSignal
    static fn from_torque_1d(v: Real, source: Output) -> ValueOutputSignal
    static fn from_acceleration_3d(v: Math.Vec3, source: Output) -> ValueOutputSignal
    static fn from_angular_acceleration_3d(v: Math.Vec3, source: Output) -> ValueOutputSignal
    static fn from_angular_velocity_3d(v: Math.Vec3, source: Output) -> ValueOutputSignal
    static fn from_force_3d(v: Math.Vec3, source: Output) -> ValueOutputSignal
    static fn from_torque_3d(v: Math.Vec3, source: Output) -> ValueOutputSignal
    static fn from_velocity_3d(v: Math.Vec3, source: Output) -> ValueOutputSignal
    static fn from_position_3d(v: Math.Vec3, source: Output) -> ValueOutputSignal
    static fn from_rpy(v: Math.Vec3, source: Output) -> ValueOutputSignal
    static fn from_int(v: Int, source: Output) -> ValueOutputSignal
    static fn from_bool(v: Bool, source: Output) -> ValueOutputSignal
    static fn from_fraction(v: Real, source: Output) -> ValueOutputSignal
    static fn from_duration(v: Real, source: Output) -> ValueOutputSignal
    static fn from_torque_range(v: Math.Vec2, source: Output) -> ValueOutputSignal
    static fn from_force_range(v: Math.Vec2, source: Output) -> ValueOutputSignal

    fn is_real() -> Bool
    fn is_vec3() -> Bool
    fn is_vec2() -> Bool
    fn is_int() -> Bool
    fn is_bool() -> Bool
    fn as_real() -> Real
    fn as_vec3() -> Math.Vec3
    fn as_angle() -> Real
    fn as_angular_velocity_1d() -> Real
    fn as_distance() -> Real
    fn as_force_1d() -> Real
    fn as_velocity_1d() -> Real
    fn as_torque_1d() -> Real
    fn as_acceleration_3d() -> Math.Vec3
    fn as_angular_acceleration_3d() -> Math.Vec3
    fn as_angular_velocity_3d() -> Math.Vec3
    fn as_force_3d() -> Math.Vec3
    fn as_torque_3d() -> Math.Vec3
    fn as_velocity_3d() -> Math.Vec3
    fn as_position_3d() -> Math.Vec3
    fn as_rpy() -> Math.Vec3
    fn as_int() -> Int
    fn as_bool() -> Bool
    fn as_fraction() -> Real
    fn as_duration() -> Real
    fn as_vec2() -> Math.Vec2
    fn as_torque_range() -> Math.Vec2
    fn as_force_range() -> Math.Vec2
```

--------------------------------

### SignalInterface

Source: https://openplx.org/documentation/0.17.8/Physics/Signals/SignalInterface

The SignalInterface component allows users to model specific signalling interfaces by grouping inputs and outputs and giving them shorter names. Setting 'enable' to true enables all outputs in the interface.

```APIDOC
## SignalInterface

### Description
Input and output reference attributes will be picked up by the signalling interface allowing the user to model specific signalling interfaces by grouping inputs and outputs and giving them shorter names. Setting enable to true enables all outputs in the interface. Keeping it as false does not disable the outputs.

### Attributes
- **enable** (Bool) - Optional - Default: false. Setting to true enables all outputs in the interface.

### C++ Extensions
- **getInputs()**: Returns a map of input names to shared pointers of openplx::Physics::Signals::Input.
- **getOutputs()**: Returns a map of output names to shared pointers of openplx::Physics::Signals::Output.
```

--------------------------------

### OpenPLX Quat Definition and Methods

Source: https://openplx.org/documentation/0.17.8/Math/Quat

Defines the Quat (Quaternion) structure in OpenPLX with its components (x, y, z, w) and includes methods for applying rotations, calculating the conjugate and inverse, and creating quaternions from various representations like angle-axis, vector pairs, and Euler angles. It also provides a normalization function.

```openplx
Quat:
    x is Real: 0
    y is Real: 0
    z is Real: 0
    w is Real: 1

    # Applies this quaternion as a rotation to a vector, returns the
    # rotated vector.
    fn rotate(v: Vec3) -> Vec3

    fn conj() -> Quat
    fn inverse() -> Quat

    # Creates a quaternion that represents a rotation of angle radians
    # around the specified axis.
    static fn angle_axis(angle: Real, axis: Math.Vec3) -> Quat

    # Creates a quaternion that represents a rotation that would rotate
    # the from vector to the to vector.
    static fn from_to(from: Vec3, to: Vec3) -> Quat

    # Normalizes a quaternion
    static fn normal(q : Quat) -> Quat

    # Creates a new quaternion with the specified values
    static fn from_xyzw(x : Real, y : Real, z : Real, w : Real) -> Quat

    # Factory methods for euler angles of different conventions
    static fn from_euler_angles_xyzs(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_xyxs(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_xzys(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_xzxs(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_yzxs(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_yzys(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_yxzs(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_yxys(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_zxys(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_zxzs(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_zyxs(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_zyzs(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_zyxr(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_xyxr(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_yzxr(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_xzxr(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_xzyr(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_yzyr(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_zxyr(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_yxyr(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_yxzr(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_zxzr(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_xyzr(alpha: Real, beta: Real, gamma: Real) -> Quat
    static fn from_euler_angles_zyzr(alpha: Real, beta: Real, gamma: Real) -> Quat

    # Alias for from_euler_angles_xyzs
    static fn from_euler_angles(alpha: Real, beta: Real, gamma: Real) -> Quat
```

--------------------------------

### AutomaticClutch Definition in OpenPLX

Source: https://openplx.org/documentation/0.17.8/DriveTrain/AutomaticClutch

Defines the AutomaticClutch component, inheriting from ManualClutch and incorporating duration-based engage/disengage features. It specifies parameters like engagement and disengagement durations, initial state, and input/output signals for controlling and monitoring the clutch's state and timing.

```openplx
AutomaticClutch is ManualClutch:
    with Physics.Signals.DurationInputTrait
    with Physics.Signals.DurationOutputTrait
    .doc: """
Extends the manual clutch with an automatic engage/disengage feature.
engagement_duration determine how long it takes to go from fully
open to fully engaged, while the disengagement_duration determine the time for disengagement.
The boolean ClutchEngageInput is used to engage and disengage the clutch.

When using the automatic feature the engagement_fraction parameter is irrelevant.

The automatic clutch is engaged by sending true on the engage_input, and disengaged by sending false.
initially_engaged will tell wether the clutch is engaged or not before any signal has been sent.
"""
    engagement_duration is Real: 0.1
    disengagement_duration is Real: 0.1
    initially_engaged is Bool: false

    engage_input is Physics.Signals.EngageInput:
        source: this
    engaged_output is Physics.Signals.EngagedOutput:
        enabled: false
        source: this

    engagement_duration_input is DriveTrain.Signals.AutomaticClutchEngagementDurationInput:
        source: this

    engagement_duration_output is DriveTrain.Signals.AutomaticClutchEngagementDurationOutput:
        source: this
        enabled: false

    disengagement_duration_input is DriveTrain.Signals.AutomaticClutchDisengagementDurationInput:
        source: this

    disengagement_duration_output is DriveTrain.Signals.AutomaticClutchDisengagementDurationOutput:
        source: this
        enabled: false

```

--------------------------------

### Define Mate Interaction in OpenPLX (Physics3D)

Source: https://openplx.org/documentation/0.17.8/Physics3D/Interactions/Mate

This code defines the 'Mate' interaction in Physics3D. It inherits from Physics.Interactions.Interaction and specifies properties related to mate connectors, dissipation, flexibility, toughness, clearance, and snapping behavior. It uses OpenPLX's specific types for these properties.

```openplx
Mate is Physics.Interactions.Interaction:
    .doc: """
    A mate is a two body interaction which is defined from two MateConnectors.
    The MateConnector define three axes, main_axis, normal and cross, which define an orthonormal basis.
    The degrees of freedom of the mates are defined using these axes.
    For each degree of freedom the mate can have individually specified
    damping, deformation, breakableness and slack.
    """

    charges becomes Physics3D.Charges.MateConnector[]
    dissipation is Physics3D.Interactions.Dissipation.DefaultMateDissipation
    flexibility is Physics3D.Interactions.Flexibility.DefaultMateFlexibility
    toughness is Physics3D.Interactions.Toughness.DefaultMateToughness
    clearance is Physics3D.Interactions.Clearance.DefaultMateClearance
    enable_snap is Bool: true
```

--------------------------------

### ManualClutch Component Definition in OpenPLX

Source: https://openplx.org/documentation/0.17.8/DriveTrain/ManualClutch

Defines the ManualClutch component, a single disk plate clutch with dry friction. It inherits from Physics1D.Interactions.Mate and includes traits for torque, relative velocity, and engagement fraction. The component simulates clutch behavior including engagement, slipping, and a locked mode, with parameters for torque capacity and slip ratio.

```OpenPLX
ManualClutch is Physics1D.Interactions.Mate:
    with Physics.Signals.Torque1DOutputTrait
    with Physics.Signals.RelativeVelocity1DOutputTrait
    with Physics.Signals.FractionInputTrait
    with Physics.Signals.FractionOutputTrait
    .doc: """Single disk plate clutch with dry friction. Input and output shafts are
connected to plates with rough surfaces.  A spring loaded mechanism increases
the normal force between the plates between a minimum and maximum, giving rise
to the concept of torque capacity.  When the plates are at maximum distance
from each other, no force is transmitted.  When they are at zero distance,
maximum pressure is applied.

Together with Coulomb friction, this keeps the plates rotating at nearly the
same angular velocity untill the stick-slip transition is reached,
alternately, when the torque required to move the output shaft at the same
velocity as the input shaft reaches the torque capacity.  This happens when
the load on the output shaft is too difficult to move.  If the two disks move
relative to each other, this is called slipping and is measured with a
ClutchSlipVelocity1DOutput at any time.

The engagement_fraction here represents the value of the torque capacity in
proportion to the maximum capacity, i.e., when the plates are fully closed,
i.e., maximum normal force is achieved.  As for most clutches, this model
includes a "locked" mode in which a clamp is activated to prevent any slip.
This stays "ON" until the clutch is disengaged, or if the output shaft starts
to move faster but in the same direction as the input shaft, as in the case of
dynamic breaking.

For a small enough relative slip ratio, when the slip velocity is small
in proportion to the input shaft velocity, defined by min_relative_slip_ratio.
The copuling is considered perfect, and no slip is anymore possible.
The Clutch may slip again either when it is disengaged or when
the clutch torque is negative -> dynamic braking.
    """

    initial_engagement_fraction is Real
    torque_capacity is Real
    min_relative_slip_ratio is Real

    slip_velocity_output is Physics.Signals.RelativeVelocity1DOutput:
        source: this
        enabled: false
    torque_output is Physics.Signals.Torque1DOutput:
        source: this
        enabled: false
    engagement_fraction_input is Physics.Signals.FractionInput:
        source: this
    engagement_fraction_output is Physics.Signals.FractionOutput:
        source: this
        enabled: false

```

--------------------------------

### Transformations and Affine Properties of Matrix4x4 in OpenPLX

Source: https://openplx.org/documentation/0.17.8/Math/Matrix4x4

Includes methods for transposing a matrix, creating a copy, and extracting the translation and rotation components as if the matrix represented an affine transformation.

```openplx
fn transpose() -> Matrix4x4
    fn copy() -> Matrix4x4
    # The following two acts as if the matrix was an affine matrix with translation in the last column
    fn get_affine_translation() -> Vec3
    fn get_affine_rotation() -> Quat
```

--------------------------------

### RobotInput Signal Definition and Processing (OpenPLX)

Source: https://openplx.org/documentation/0.17.8/Robotics/Signals/RobotInput

Defines the RobotInput signal, inheriting from Physics.Signals.Input. It includes a docstring explaining its functionality, specifies a 'Composite' output type, and outlines the 'process' function which takes an InputSignal and returns an array of InputSignals.

```openplx
RobotInput is Physics.Signals.Input:
  .doc: """
A filter that accepts a RobotInputSignal and decomposes it into a RealInputSignal of the correct type for each target in targets.
targets contains the Signal Inputs to map to in order.
"""
    type: Physics.Signals.InputOutputType.Composite
    targets is Physics.Signals.Input[]: []
    fn process(signal: Physics.Signals.InputSignal) -> Physics.Signals.InputSignal[]
```

--------------------------------

### Define Physics3D Signals MateConnector Output Model

Source: https://openplx.org/documentation/0.17.8/Physics3D/Signals/MateConnector/Output

This code defines the base model for MateConnector Outputs in OpenPLX's Physics3D Signals module. It specifies the source as Physics3D.Charges.MateConnector and allows for an optional relative_to parameter, which can also be a MateConnector or the World.

```openplx
Output is Physics.Signals.Output:
    .doc: """
Base model for MateConnector Outputs
Emits a ValueOutputSignal
You may also specify a MateConnector as the relative_to parameter to get the value relative to that mate connector
"""
    source is Physics3D.Charges.MateConnector
    relative_to is Physics3D.Charges.MateConnector: Physics3D.Charges.World

```

--------------------------------

### OpenPLX LinearSpring Class Definition

Source: https://openplx.org/documentation/0.17.8/Physics3D/Interactions/LinearSpring

Defines the LinearSpring interaction in OpenPLX, inheriting from SpringInteraction1DOF and incorporating signal traits for force, position output, and position input. It specifies the initial position and output signals.

```openplx
LinearSpring is SpringInteraction1DOF:
    with Physics.Signals.Force1DOutputTrait
    with Physics.Signals.Position1DOutputTrait
    with Physics.Signals.Position1DInputTrait
    position is Real: 0.0

    force_output is Physics.Signals.Force1DOutput:
        enabled: false
        source: this

    target_position_output is Physics.Signals.Position1DOutput:
        enabled: false
        source: this

    target_position_input is Physics.Signals.Position1DInput:
        source: this
```

--------------------------------

### OpenPLX DefaultClearance Definition and Documentation

Source: https://openplx.org/documentation/0.17.8/Physics/Interactions/Clearance/DefaultClearance

Defines the DefaultClearance in OpenPLX, providing a detailed explanation of its purpose. This includes its role in defining space for movement in mates like hinges and prismatic joints, as well as the implications of too large or too small clearances in mechanical systems. The documentation is presented as a multi-line string within the OpenPLX code.

```openplx
DefaultClearance:
    .doc: """
    For mates like hinges, prismatics etc., or between contacting surfaces,
    clearance refers to the loose or extra space that exists which allows for some amount of movement.
    Often, this term is used in mechanical or manufacturing contexts. 
    For instance, a door hinge might have a clearance that allows it to move or swing more freely.
    Alternatively, if two objects are meant to fit snugly together but don't, the extra space between them would be considered a clearance.

    In a perfect world with perfect manufacturing, there would be no clearance as objects designed to interact would fit together perfectly.
    However, in reality, some infinitesimal clearance is often allowed for to ensure smooth operation or for tolerances in manufacturing.
    Too large clearances, however, can lead to instability or failure of a system.
    """

```

--------------------------------

### Acceleration3DOutput Signal Definition in OpenPLX

Source: https://openplx.org/documentation/0.17.8/Physics3D/Signals/MateConnector/Acceleration3DOutput

Defines the Acceleration3DOutput signal for OpenPLX's Physics3D module. It specifies the signal's type and provides documentation on its functionality, including the option to measure acceleration relative to a MateConnector. This definition is written in OpenPLX's domain-specific language.

```openplx
Acceleration3DOutput is Output:
    .doc: """Emits a ValueOutputSignal where the signal value is the directional acceleration of the source
You may also specify a MateConnector as the relative_to parameter to get the value relative to that mate connector
"""
    type: Physics.Signals.InputOutputType.Acceleration3D
```

--------------------------------

### Interaction Base Type Definition in OpenPLX

Source: https://openplx.org/documentation/0.17.8/Physics/Interactions/Interaction

Defines the base 'Interaction' type in OpenPLX, inheriting from BoolInputTrait and BoolOutputTrait. It includes properties for enabling interactions and managing charges, along with input and output signals for controlling and reporting the interaction's enabled state. The documentation string provides context on its use cases.

```OpenPLX
Interaction:
    with Physics.Signals.BoolInputTrait
    with Physics.Signals.BoolOutputTrait
    .doc: """
Base type for Interaction
Examples of interactions are force fields, hinges or static electricity
"""
    enabled is Bool: true
    charges is Physics.Charges.Charge[]

    enable_interaction_input is Physics.Signals.EnableInteractionInput:
        source: this
    interaction_enabled_output is Physics.Signals.InteractionEnabledOutput:
        source: this
        enabled: false

```

--------------------------------

### Define RobotInputSignal Class (OpenPLX)

Source: https://openplx.org/documentation/0.17.8/Robotics/Signals/RobotInputSignal

Defines the RobotInputSignal class, inheriting from Physics.Signals.InputSignal. It includes properties for real values and control events, along with static factory methods for creating instances from Real arrays or RealValue objects.

```openplx
RobotInputSignal is Physics.Signals.InputSignal:
    values is Physics.Signals.RealValue[]
    control_events is Bool[]
    # create() uses Real[] to make Python API easier to use, no wrapping in Value.Create needed
    static fn create(values: Real[], control_events: Bool[], target: Physics.Signals.Input) -> RobotInputSignal
    static fn from_values(values: Physics.Signals.RealValue[], control_events: Bool[], target: Physics.Signals.Input) -> RobotInputSignal
```

--------------------------------

### Define MateConnectorOutputTrait with Relative Positioning - OpenPLX

Source: https://openplx.org/documentation/0.17.8/Physics3D/Signals/MateConnector/MateConnectorOutputTrait

Defines the MateConnectorOutputTrait for handling mate connector outputs. It includes a 'relative_to' parameter that accepts a Physics3D.Charges.MateConnector to establish relative positioning. This trait is part of the Physics3D module.

```openplx
trait MateConnectorOutputTrait:
    .doc: """
Trait for MateConnector Outputs
relative_to      - You may specify a MateConnector as the relative_to parameter to get the value relative to that mate connector
"""
    relative_to is Physics3D.Charges.MateConnector: Physics3D.Charges.World
```

--------------------------------

### Define Torque3DOutput in OpenPLX

Source: https://openplx.org/documentation/0.17.8/Physics/Signals/Torque3DOutput

This snippet defines the Torque3DOutput, specifying its documentation string, type as Torque3D, and its source trait. It's intended for use with interactions where torque is unambiguously requested.

```openplx
Torque3DOutput is Output:
    .doc: """
A 3D Torque output given an interaction.
For interactions where it is unambiguous which torque is requested,
the output will give the current output value.
"""
    type: Physics.Signals.InputOutputType.Torque3D
    source is Torque3DOutputTrait
```
Tokens:
Raw