Motion: Joint Based

Description

Translational motions may be defined on Translational and Cylindrical joints. Rotational motions may be defined on Revolute and Cylindrical joints.

You define an expression for the motion characteristics. The expression may be used to define displacement, velocity, or acceleration. The expression is usually a function of time. See Comment 8 if you want to make the motion expression dependent on system states.

In the above, I is the i_marker_id of the joint and J to the j_marker_id. The software defines the state dependent term in the equations and you define the expression, the type of motion, and the joint on which the input is to be provided.

For a translational motion, the z-axis of j_marker_id defines the direction of positive motion. The origin of i_marker_id moves along this line. At zero displacement, the origins of the two markers are coincident.

For a rotational motion, i_marker_id rotates about the common z-axis. A positive motion results in counter clockwise rotation.

A reaction force is associated with each Motion_Joint. This reaction force tells the system the force or torque that is needed to apply the requested motion.

When the expression is a function of time, energy is either added to or removed from the system. Motion inputs may be considered as linear or rotational motors with infinite force or torque capacity.

The expression that you supply may be specified using either a MotionSolve expression or a user defined subroutine.

Format

<Motion_Joint
       id            = "integer"
     [ label         = "string" ]       
       joint_id      = "integer"
       motion_type   = { "R" | "T" }
   {   
       val_type      = "D"
       
       val_type      = "V"
       ic_disp       = "real"
       
       val_type      = "A"
       ic_disp       = "real"
       ic_vel        = "real"
   }
   {   
       type          = "EXPRESSION"
       expr          = "motionsolve_expression" >
   
       | type        = "USERSUB"
       usrsub_dll_name         = "valid_path_name"
       usrsub_param_string     = "USER( [[par_1 [, ...][,par_n]] )"
       usrsub_fnc_name         = "custome_fnc_name" >

       | type        = "USERSUB"
       script_name             = valid_path_name
       interpreter             = "PYTHON" | "MATLAB"
       usrsub_param_string     = "USER( [[par_1 [, ...][,par_n]] )"
       usrsub_fnc_name         = "custom_fnc_name" >   
   } 
</Motion_Joint> 

Attributes

id

Element identification number (integer>0). This number is unique among all Motion_Joint elements.

label

The name of the Motion_Joint element.

joint_id

Specifies the ID of the joint at which the motion input is applied.

motion_type

Specifies the type of motion that is to be applied. Motion types may be translational ("T") or rotational ("R"). Specify either "T" or "R". Note that motions on translation joints are always of type "T". Motions on revolute joints are always of type "R". Motions on cylindrical joints may be of either type, but not both.

val_type

Specifies whether the motion applies a displacement input (D), a velocity input (V), or an acceleration input (A). You must select one value from "D", "V", or "A".

ic_disp

Specifies the displacement initial condition that is required when val_type = "V" or val_type = "A".

ic_vel

Specifies the velocity initial condition that is required when val_type = "A".

type

Select either "EXPRESSION" or "USERSUB". Specifies how the motion is defined. The EXPRESSION option specifies that the motion value is a MotionSolve expression that can be evaluated at run-time. The USERSUB option indicates that the value of the motion value is specified in a user defined subroutine. The parameters "usrsub_param_string" and "usrsub_dll_name" are used to provide more information about the user defined subroutine.

expr

Defines an expression that defines the motion value. Use this parameter only when type = EXPRESSION. Any valid run-time MotionSolve expression can be provided as input.

usrsub_dll_name

Specifies the path and name of the DLL or shared library containing the user subroutine. MotionSolve uses this information to load the user subroutine MOTSUB in the DLL at run time.

usrsub_param_string

The list of parameters that are passed from the data file to the user defined MOTSUB. Use this keyword only when type = USERSUB is selected.

usrsub_fnc_name

Specifies an alternative name for the user subroutine MOTSUB.

script_name

Specifies the path and name of the user written script that contains the routine specified by usrsub_fnc_name.

interpreter

Specifies the interpreted language that the user script is written in. Valid choices are MATLAB or PYTHON.

Example

The first example shows how experimental data may be fed into the system as motion input.

Automotive vehicle handling simulations are often performed using semi-analytical simulation techniques. A vehicle to be tested is instrumented with sensors to measure the steering wheel angle while it is being driven. The vehicle is driven on the proving grounds. The driver may perform a variety of maneuvers simulating real-life steering situations. This data is collected as a function of time.

The experimental data is "cleaned" to remove noise and high frequency content. Next, a vehicle model suitable for vehicle handling studies is created in MotionSolve. The experimental data is modeled as a SPLINE in MotionSolve and it is provided as steering input to the analytical model of the vehicle. During the simulation vehicle behavior necessary for evaluating handling are collected.

The steering input, after being "cleaned", might look as shown in Figure 1:

Figure 1. Experimentally measured steering input

The Motion_Joint for the steering input would like this:

<Motion_Joint
     id                  = "1"
     joint_id            = "301"
     motion_type         = "R"
     val_type            = "D"
     type                = "EXPRESSION"
     expr                = "CUBSPL(Time, 0, 301001)" >
</Motion_Marker>

The second example demonstrates how you may specify the motion of a worm and wheel mechanism using a Motion_Joint. The image below illustrates the mechanism.

Figure 2. A worm wheel mechanism

The worm gear is driven by a motor at a constant rate of 200 revolutions per second. Due to the gearing ratio, the wheel turns slowly relatively to the worm. This is a speed reduction system ideally forming part of a drive or lifting device. Constraint_Joint 101 defines a revolute joint between the worm gear shaft and the housing. A Motion_Joint on this revolute joint simulates the motor. The motion definition would look as follows:

<Motion_Joint
     id                  = "2"
     joint_id            = "101"
     motion_type         = "R"
     val_type            = "D"
     type                = "EXPRESSION"
     expr                = "200*2*PI*Time" >
</Motion_Joint>

Comments

1. Three constraints are added for each Motion_Joint: one in the displacement domain, the second in the velocity domain and the third in the acceleration domain.
   • When a displacement constraint is specified, the velocity and acceleration constraints are obtained by analytically differentiating the displacement constraints.
   • When a velocity constraint is specified by the user, the displacement constraint is obtained by numerically integrating the velocity constraint and the acceleration constraint by analytically differentiating the velocity constraint.
   • When an acceleration constraint is specified, the velocity constraint is obtained by numerically integrating the acceleration constraint, and the displacement constraint by numerically integrating the velocity constraint.
2. Differentiation tends to amplify any noise in the input signal. It is therefore important to ensure that all expressions and experimental data provided as input be smooth. More precisely, they must have continuous first and second time derivatives. Avoid the AKISPL() interpolation method when interpolating experimental data. AKISPL()does not calculate good first and second derivatives. Use CUBSPL() instead.
3. Integration tends to decrease the noise in an input signal. Therefore, it is a good idea to use velocity inputs when providing interpolated experimental or tabular data as motion input expressions.
4. Define your curve with as few points as possible. Excessively large number of interpolation points in a cubic curve makes its first derivative "jumpy", and its second derivative "extremely jumpy", even though the curve itself may look smooth.
5. Make sure that the initial velocity of the motion matches the initial velocities of the bodies that it affects. For example, if your mechanism simulation starts from an initial static state, then you should make sure that the input motion has zero initial velocity. The motion input overrides body and joint initial velocities if they are in conflict.
6. If you decide to use velocity inputs, be aware that the position is satisfied only to the integration error specified in the Param_Transient element. Likewise for acceleration inputs, the velocity and position are only satisfied to the integration error specified. Therefore, you may see some drift from the analytical solution. This is a limitation of any scheme based on numerical integration.
7. It is useful to take a look at the reaction force/torque time histories due to the motion constraint. It tells you how much force/torque is needed to achieve the given motion. You should ascertain whether or not this is realistic. Furthermore, it sometimes makes better physical sense to replace the motion with applied forces coupled with control laws. Remember that motion in a dynamic analysis is treated as a "hard" constraint with no room for compliance.
8. Motions can be defined as a function of either time or other states when using the DSTIFF integrator.

   However, if VSTIFF, MSTIFF or ABAM are used, then the motions may only be functions of time. To define the motions as a function of state, you must apply a time lag to the system data you are requesting and then smooth it as discussed below.

   • Assume that a Motion_Joint is used to apply a displacement that is based on the sensed radial velocity between two Reference_Markers 100 and 200 . Then, you must code the user subroutine to implement the following:

     EXPR(T_k+1) = VR(100,200) evaluated at T_k,

     T_k+1- T_k is the sampling period for the system.

     Note that EXPR(T_k+1) is constant. However it changes whenever the velocity VR() is sampled. This implementation is not adequate because the sampled values are not continuous. You must fit a curve through the previously sampled values and extrapolate the curve to provide a smooth value. This is shown symbolically below:

     EXPR(Tk+1) = CUBIC(VR(100,200)|Tk, VR(100,200)|Tk-1, VR(100,200)|Tk-2)