### 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> getInputs() const; ``` ```cpp std::unordered_map> 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 ``` -------------------------------- ### 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 ```