Hi Chris,

I'll quickly answer the simple questions and will get back to you on the remaining ones.

1) You ask if you can also use a constraint as parameter in the script and directly change constraint properties (stiffness... etc.).

Yes. That would work just fine.

Btw, nothing you do in the higher-level interfaces (extension, inputs/outputs/parameters, connections, etc.) can "confuse the solver". The solver takes all the properties you provide via the higher-level interfaces at every simulation step and steps all parts, constraints, vehicles, cables, earthmoving features etc. together in one, condensed physics step. This is accomplished by the dynamics module between extension pre and post steps.

2) 6DOF joint modeling:

The RPRO is a special constraint which has no "controllable" coordinates in the usual sense (meaning, a coordinate, as in a hinge, which you can set to free, locked or motorized).

It represents all 6 DOFs together via a desired relative angular velocity vector (3 DOFs) and a desired linear velocity vector (3 DOFs). It will impose these relative velocities between the two parts while maintaining the relative positions and integrating the relative positions according to the desired relative velocities (thus actuating the bodies relative to each other). Hence its name being a shorthand for "Relative-Position, Relative-Orientation" joint. It can be compared to a 2-body constraint with 6 controllable coordinates that all use the "lock control" mode.

And its parameters compare with the lock stiffness/damping, lock velocity and lock min and max forces. It is a positional constraint which models a spring-damper, producing force F = -k * dx + c * dv, with dx and dv position and velocity error. This is equivalent to how a coordinate in locked control mode behaves.

Note that a coordinate in motorized control mode behaves like a damper with force F = c * dv (with dv being the error between the coordinate velocity and the desired motor velocity) and the damping coefficient (c) defined by the inverse of the motor loss parameter (l), that is, c = 1/l.

Note that by modifying the min/max forces of the individual linear and angular components of the RPRO, you could activate or deactivate DOFs in this joint.

If that doesn't do the job for you, you can simply use the Motor Joint type, which models a single controllable coordinate between two bodies(a single DOF), and which can be made free, locked or motorized. This joint type is very efficient. It adds only one single constraint row to the solver.

Consequently, by using 6 Motor Joints you can very easily model a fully controllable 6DOF joint between two parts. This joint is very modular and allows you to model any composite joint made up of linear or angular DOFs.

If you would want to turn your **3lin_2rot **joint into a 6DOF joint, you could disable the one relaxable constraint equation of this joint (by enabling relaxation and then setting min and max forces to zero) and then adding a Motor Joint to replace the removed DOF.

I hope this answers your questions.

Cheers,

Daniel

Daniel,

Thanks for your detailed answer.

Just some additional notes:

Note 1:

You used: F = -k dx + c dv is there a sign difference between Dx and Dv ???

ADAMS does F = -k dx - c dv

Note 2:

In the attachment I added a plot with curves for a typical non-linear stiffness force i.e. for a spring with a progressive stiffness.

The plot shows the Stiffness force F(x) curve as well as the curve for stiffness dFdx(x).

Several times before I have made the error of replacing F(x) by the derivative dFdx(x) * x.

(which seems natural as Force is equal to X times stiffness).

My main message is that replacing F=F(x) by F = Q(x) * x requires a function Q(x) that is not the derivative dFdx(x). Hence my previous question about the current force value.

This is why I would prefer to have a function for F(x) and prescribe this directly in the constraint force.

(as discussed this works by controlling F_Max and F_Min so I have a working solution)

I admit, it seems like a bit of a detailed discussion, unless you really have to work with provided component supplier data curves.

Always interested in your remarks and feedback on this.

Kind regards,

Chris

Note 3:

Obviously, I am over-complicating things (and should read your post better).

All I have to do is

1) provide a function (or spline table) for F(x),

2) calculate a stiffness from F(x)/ Eps_Current and

3) let Vortex calculate the Force by F = C * Eps_Current again.

That seems to solve most issues in a minimum of code I guess.

Do you agree?

Regards,

Chris

Regarding your last post: Yes. That is it.

By limiting the force you can model some other interesting effects, though, like a cap on the spring, where the spring starts acting "plastically" once the force reserve is exceeded. We do exactly thiswhen you check the "plastic" option in a locked coordinate and provide a finite min and max force. The lock will then act elastically until the max or min force is reached and then it will update its resting point, dragging it behind the moving coordinate. This is identical to modeling plastic material deformations in an otherwise elastic medium - an elasto-plastic model, so to speak. We call this a "plastic lock". Check it out! You can set this option in any constraint that has a controllable coordinate in locked control mode.

And regarding the constitutive equation of the spring-damper:

You are right, of course. There is a sign error in my formula. The correct formula is obviously F = -k dx - c dv.

Hi Chris,

This looks super interesting!

There's always additional tools coming out with each new release -- let me talk to our developers and see how your requests mesh with our roadmap.

By the way, you can already have cameras that move with a part! Just add a connection container and connect the transforms of the part and the Camera extension. Or, if you need a more complex trajectory, you could also set up one of the new BSpline and attach a Camera to it.

Hi Chris,

Modulating constraint inputs in python script extensions, e.g., to model non-linear spring/damper behaviour is pretty simple.

Just add a python script extension and a connection container to your mechanism. Then add the necessary outputs (stiffness, damping...) to the script extension and, with the connection container, connect them to the constraint inputs you wish to modulate (e.g., lock stiffness of a prismatic joint or similar). In the pre_step function in your script, you modify the output value to your liking to approximate non-linear behaviour in a piecewise linear manner. The modified value will then be set in the constraint input, and this should do the job.

Watch out for issues related to too high time steps when changing stiffness at runtime. When making too aggressive changes, your constraint might get violated too much in this piecewise linear setting. If required, increase the simulation frame rate (thus lowering the timestep) in your application setup (.vxc) file.

Let me know if you need some help setting this up.

Cheers,

Daniel

That is a good point indeed.

Prescribing non-linear forces in a constraint using scripts is nice but leaves me with the following questions:

- You can indeed directly change the stiffness, but I assume the next force

F_Next will be F_Current + Stiffness * Curr_Delta_Deformation... **True ??**

- I am used to defining a spline function or equation for F_Non_Lin vs Curr_Defomation.

In Vortex you could use this as a force equation by setting the F_Max and F_Min of the constraint to have it

follow the Non-Linear force. **Correct ?**

- I am not sure though if it is required to define connectors between the outputs of the script,

and the inputs of constraint. (Newby Question)

Couldn't it work as well by defining the constraint as a parameter to the script and setting the constraint

input properties F_Min/F_Max / Stiffness directly in the script instead of by connecting?

Or would this confuse the solver ??

This would make the additional work in Vortex a lot cleaner in my model.

- Another issue I am trying to solve is to drive a dynamic part completely (6 DOF) using kinematic relations.

I created a test script that works on a **3lin_2rot** type joint.

The 5 joint DOF's get prescribed properly but how to set the 6th DOF?

I looked at the RPRO constraint but couldn't bake any cookies of the manual...

I do not want to add another dummy part to set the remaining DOF.

(as I expect models where I have to drive 50 parts in total (i.e. comparing to ADAMS)

Is there a way to add one single additional Motion to complete the 6 DOF?

I.e. with a 3Lin_2Rot constraint rotated over 90 degrees primary axis?

or would this confuse the solver?

Thanks for the very useful discussion. Using One MB code definitely doesn't mean you can run them all obviously.

Kind regards,

Chris

Hi Chris,

Here are the answers to your remaining questions.

*You ask: "You can indeed directly change the stiffness, but I assume the next force F_Next will be F_Current + Stiffness * Curr_Delta_Deformation... True ??"*

In the Vortex solver there is no force carried over between steps. So F_Next will not depend on F_Current.

The inputs to the Vortex solver are positions, velocities, user provided or gravitational forces and the constraint parameters (stiffness, damping, loss etc.).

The force in Vortex for a positional visco-elastic constraint, like a locked coordinate (which uses stiffness and damping coefficients as parameters), is determined by the solver using a regularized kinematic constraint in a semi-implicit numerical integration of the Newton-Euler equations.

In a nutshell, the Vortex solver will calculate a lock constraint force which follows the Kelvin-Voigt model and will correspond to the expected force (F = -k dx + c dv) after every time step (of course, ignoring any errors that would enter the time integration by an inappropriately high timestep).

In other words, if you provide a given stiffness and damping before the step, the solver will calculate constraint forces, new positions and velocities such that after the step, the force corresponds to F = -k dx + c dv, with dx and dv calculated using positions and velocities AFTER the step.

You can now choose new stiffness and damping parameters for the next step. This allows for example to model a non-linear spring represented with a piecewise linear force to spring extension relationship. In every simulation step, the force will be a linear function of the spring extension. Obviously, care has to be taken when updating the spring stiffness, not to introduce force jumps.

We use this approach to model soft ground / tire interactions for example. Here, the theory of the tire model itself provides the soil reaction force that should be applied to the wheel. Rather than adding the soil reaction force to the tire as an external force (which would not be stable with the high simulation time steps usually chosen in real-time simulations, e.g., 1/60s), we model the soil response in every step as elastic by using an equivalent spring with a stiffness chosen such that with the present tire/soil penetration depth the desired soil reaction force is applied via the spring constraint by the solver (i.e. k = F_desired / penetration_current).

For more information you can look at the Vortex Theory Guide. In this document, I am explaining the numerical approach taken by our solver in section 2.

See here:

Vortex Theory Guide in online documentation

Vortex Theory Guide (link to pdf)

In short, the kinematic constraint equations of a joint relate the generalized velocities of the jointed bodies (6 component vector of linear and angular velocities) via the constraint's Jacobian matrix. A target velocity can be imposed in the constraint equation which allows modeling motors, and the equations can be relaxed through introduction of regularization parameters (in the document denoted by phi and gamma). For a positional constraint type (e.g., locked coordinate), these regularization parameters are mapped in the Vortex formulation to stiffness and damping coefficients.

*You ask: "I am used to defining a spline function or equation for F_Non_Lin vs Curr_Defomation.
In Vortex you could use this as a force equation by setting the F_Max and F_Min of the constraint to have it follow the Non-Linear force. Correct?"*

Yes, that is correct. This and the idea of changing the stiffness coefficient in every step (see explanation above).

I hope these answers will help you in your process. Let me know if something is not clear.

Cheers,

Daniel

## Chris Verheul

Hey Guys,

We at Sayfield (www.sayfield.nl) are intending to use Vortex for a range of Engineering based real-time and VR based simulations.

Actually, we are doing this from a model translator that we are developing from MSC ADAMS models.

In the coming months, we intend to be able to export a large range of ADAMS models in a two-clicks approach to a Vortex simulation.

Currently, we are getting used to the Vortex

way of workingand trying to figure out the best method to store an ADAMS export into Vortex Mechanism/Scenes etc. etc.In this process, we expect to develop and/or need a lot of additional tools and scripts to do the

typical ADAMS workinside Vortex.Examples of this are:

- Using Python scripts to create non-linear spring-damper behavior from a range of methods (i.e. formula based or spline file based).

- Driving many (or all) parts in a Vortex model from predefined simulations done by external models. This to verify Vortex results, or to drive a minimization scheme to fit Vortex results to results of other solvers. Driving parts will be a requirement that we need to do as efficient and user-friendly as possible.

- Several types of extra model output such as a large set of xy-plots or automated simulation signal export to allow comparison to external models.

- A range of model manipulators to 'push and pull' models to test and tweak stiffness, damping, friction and/or overall model stability. Typically we expect to create some controller driven objects comparable to the mouse spring test functionality.

- Same thing for a range of smart cameras, i.e. moving along with parts etc etc..

- In general, we are looking for functionality inside Vortex that allows us to add macros and utilities to\manipulate and/or extend existing models. If you have already found or developed a way to do this, we'll be interested to find out how this can be done.

Ergo,

If you guys already have

Vortex Model and Script Goodiesdefined and are willing to share it, that would be brilliant. Definitely, we will be willing to share stuff like this in some kind of platform. I guess CM-Labs would not mind being that platform (or is this already implemented Marc- Alexandre?)Kind regards, and hope to hear from you.

Chris Verheul

PS: If you are interested in learning why and how we export MSC ADAMS models to Vortex and what we intend to do with this for, feel free to contact us. In this project, we are closely cooperating with the guys at CM-Labs so we may organize a webinar when we feel we are ready for it.

1 person likes this idea