Question about Constraint types

SimTKcore exists as a separate project to provide 'one stop shopping' for SimTK Core software and support, although the software is actually developed as a set of interdependent projects. SimTK 1.0 was released in March 2008, SimTK 2.0 in December, 2009.
User avatar
Moon Ki Jung
Posts: 44
Joined: Wed Oct 24, 2007 2:56 am

Question about Constraint types

Post by Moon Ki Jung » Thu Feb 04, 2010 1:38 am

Hi,

I’d like to use SimBody to simulate a complex closed-loop system like the Bricard mechanism that constrains 6 bodies and 6 revolute joints.
Because SimBody’s concept of mobilizer and constraint, I should use 5 mobilizers and 1 constraint to create a closed-loop.
But there is no ‘Pin’ constraint in SimBody. So I can’t use 6 revolute joints.
Would you let me know why there is no ‘Pin’ constraint in SimBody?

Thanks for reading this question.

Best regards,
Moonki Jung

User avatar
Michael Sherman
Posts: 807
Joined: Fri Apr 01, 2005 6:05 pm

RE: Question about Constraint types

Post by Michael Sherman » Thu Feb 04, 2010 10:24 am

Hi, Moonki. The preferred method for building closed-loop systems in Simbody is to break loops by cutting a *body*, not by cutting a *joint*, and then using a Weld constraint to reassemble the body. This allows you to treat all the joints uniformly, ensuring that there is a generalized coordinate available for every joint dof.

Here's the procedure:
- pick the body to cut; let's call it "mybody". The best choice is a relatively massive body near the middle of the loop, although that doesn't usually matter much.
- build the loop in two chains out from ground, one terminating in mybody_A and the other in mybody_B. Each of those should be identical to the original mybody, but with 1/2 of the mass and 1/2 of the inertia (com is in the same place for both)
- add a Constraint::Weld between the body frames of mybody_A and mybody_B. When the weld constraint is satisfied, the combined mybody_A+mybody_B will have exactly the mass properties of the original mybody.

You can also break joints if you want, and I usually do that for ball joints because the generalized coordinates across a ball joint are just the orientation and it is just as easy to work with the orientation across a Constraint::Ball. But that's a special case -- other joints would require complicated constraints (five constraint equations in the case of a Pin, for example) and then would not yield convenient coordinates.

Please try the method I suggest above and let us know how it works.

Best regards,
Sherm

P.S. There is no capital "B" in "Simbody".

User avatar
Moon Ki Jung
Posts: 44
Joined: Wed Oct 24, 2007 2:56 am

RE: Question about Constraint types

Post by Moon Ki Jung » Thu Feb 04, 2010 10:57 am

Hi,

First, thanks very much for your kind reply.
I understood the method you proposed. It can be a good way to modeling a closed-loop system.

What I want to do is to model an assembly in CAD system and export their geometry information as ‘OBJ’ file format. And using those OBJ files I can add decoration to Body objects using ‘DecorativeMesh’ class objects. Here is an example of the four-bar links using Simbody:
http://docs.google.com/leaf?id=0B-t2k1X ... MGFl&hl=en

I think your method can be a nice method. But in my situation there may be some problems. First if a body has a complex geometry, then it may be difficult for me to break the body into two pieces that have same mass and inertia. And I should break its geometry OBJ file into two files.

Thanks very much again for your help and I’ll try the method you proposed.

Best regards,
Moonki

User avatar
Michael Sherman
Posts: 807
Joined: Fri Apr 01, 2005 6:05 pm

RE: Question about Constraint types

Post by Michael Sherman » Thu Feb 04, 2010 11:53 am

Hi, Moonki. There should be no problem with the OBJ files. The way to handle that is to think of one of the two half-bodies as the "main" body, and attach *all* the geometry to it. There is no need to split the geometry, only the mass properties.

So: calculate the full mass properties with the CAD package. Take the resulting mass and inertia *afterwards* and divide by two -- no need to divide up the geometry at all. Then when building the Simbody system, there will be two MobilizedBodies, each with 1/2 the mass properties. Attach *all* the decorative geometry to *one* of those bodies; leave the other one naked.

Regards,
Sherm

User avatar
Moon Ki Jung
Posts: 44
Joined: Wed Oct 24, 2007 2:56 am

RE: Redundant constraints in a closed-loop

Post by Moon Ki Jung » Fri Feb 05, 2010 9:08 am

Hi, Sherman.

By virtue of your advice, I could create a closed-loop by dividing a body object.

I modeled a bricard mechanism with 6 Pin Mobilizers and 1 Weld Constraint.
I didn’t set any gravity.

I set initial values of generalized coordinates. And I set an initial value of a generalized speed.

Then my mechanism in Simbody started to move. But when it approaches to a certain position, my program suddenly crashes.

I’d very appreciated if you could allow your valuable time to check my code.
I uploaded a zip file that contains a cpp file and two obj files for geometry.
Here is the link for the zip file:
http://docs.google.com/leaf?id=0B-t2k1X ... M2U2&hl=en

I’d like to know whether Simbody can handle with a closed-loop system that has redundancy like this.

Best regards,
Moonki

P.S) In debug mode for development, could I get detail reason or errors when Simbody application may crash?


User avatar
Michael Sherman
Posts: 807
Joined: Fri Apr 01, 2005 6:05 pm

RE: Redundant constraints in a closed-loop

Post by Michael Sherman » Fri Feb 05, 2010 4:41 pm

Hi, Moonki. I ran the model you sent and it looks very nice! I can't help you debug it without the source code for the program you used to run it, but I can answer your questions:
1) Yes, Simbody works fine with redundant constaints. Of course in those cases the reaction forces are indeterminate but the motion is still unambiguously determined. Simbody calculates a least squares reaction in those cases.
1a) On the other hand if you build a mechanism that has indeterminate motion in real life (like a 4-bar linkage with equal length bars) there is a singular configuration that can cause lockup or high reaction forces. This will at best cause the integrator to slow down at the bifurcation point.
1b) Your mechanism seemed to pass through a bifurcation point just fine and then stopped later. What integrator are you using? You should be using the RungeKuttaMersonIntegrator.

2) Yes, you are likely to get much better information using the Debug libraries.

If you send the source code for your mechanism I will be happy to take a look at it.

Q: What version of SimTK are you using? And what integrator?

Regards,
Sherm

User avatar
Moon Ki Jung
Posts: 44
Joined: Wed Oct 24, 2007 2:56 am

RE: Redundant constraints in a closed-loop

Post by Moon Ki Jung » Fri Feb 05, 2010 6:23 pm

Hi, Sherman.

I use Microsoft Visual Studio 2005 Professional Edition English version with Service Pack1. I compressed the whole project folder as a zip file. You can download it here:
http://docs.google.com/leaf?id=0B-t2k1X ... MGNi&hl=en

As you can see in my source code ‘Bricard.cpp’, I used RungeKuttaMersonIntegrator.
And I used the latest version of SimTK 2.0.

Thank you very much for your kind help.

Best regards,
Moonki

User avatar
Michael Sherman
Posts: 807
Joined: Fri Apr 01, 2005 6:05 pm

RE: Redundant constraints in a closed-loop

Post by Michael Sherman » Sat Feb 06, 2010 1:42 pm

Hi, Moonki. I took a quick look at the Bricard mechanism and saw the integrator take a suspiciously large step size, possibly indicating some kind of bug in the step size selection. I will investigate further. Meanwhile, a simple workaround is to add the line
integ.setMaximumStepSize(.1);
Then it seems to work fine.

By the way, you can write .5*Inertia(...), you don't have to modify the individual elements.

Please try the above workaround and let me know if that fixes the problem. Once I find the actual problem I'll post again.

Regards,
Sherm

User avatar
Moon Ki Jung
Posts: 44
Joined: Wed Oct 24, 2007 2:56 am

RE: Problem solved and an additional question

Post by Moon Ki Jung » Sat Feb 06, 2010 6:44 pm

Hi, Sherman.

According to your advice, I added a code like ‘integ.setMaximumStepSize(0.1)’ and now it works very well!

I appreciate your great help by which the problem could be solved.

By the way, I’d like to ask you one more question.
I’d like to simulate this mechanism under two conditions
① Zero gravity
② An impulsive torque should be applied to one of Mobilizers at the beginning of the simulation

By these two conditions, this mechanism is conservative system. Since gravity is zero, the mechanism’s total energy should be same as total kinetic energy. So I’d make a plot of kinetic energy versus time.

To do this, I’d like to know how I can apply impulsive torque to one of Mobilizers during limited time span. Please let me know how I can do that.

Best regards and thanks very much again,
Moonki

User avatar
Michael Sherman
Posts: 807
Joined: Fri Apr 01, 2005 6:05 pm

RE: Problem solved and an additional question

Post by Michael Sherman » Sat Feb 06, 2010 10:51 pm

There are several ways to do what you want. If I understand correctly, you are really looking for a set of initial velocities that satisfy the constraints. Once having set those, the system should conserve energy.

An easy way to do that would be to run a short simulation with a mobility torque on, then use the resulting velocities as the initial conditions for a second simulation. You could also put a Constraint::PrescribedMotion on one of the mobilities, then all the velocities will be calculated to satisfy the constraints at t=0 in the simulation. After that you can disable the constraint.

To do it exactly as you described, you need to write a (very simple) Custom Force (see the Advanced Programming Guide on the SimTKcore Documents page). Then you would write the force to be on for 0 < t < t_impulse and off afterwards.

Those are a few ideas; let me know if you need anything more specific.

Best regards,
Sherm

POST REPLY