Joint question (combining 3 joints into a new one)

[Keyan]

Hi,

i have the following problem:

for an experiment, i plan to couple two cars by a spring. to picture it, imagine one car standing still, and the second car cycling around the first, with increasing radius. the spring-force should increase with increasing radius, and the spring force needs to be a parameter in the joint configuration.

my first approach would be to combine 2 hinge joints, with a slider joint, creating a new one, which consists of all three, as the slider needs to be rotatable in both cars.

the question is, is this the best way to tackle the problem?

cheers,
keyan

[Bruce Veazie]

First of all, ODE joints are attached to 2 bodies or to 1 body and "space."
Joints can't be joined to another joint, so you may have to have an "extra"
body or two between the cars.

It seems you already have a little familiarity with joints. I've never
joined multiple joints in the way you've described, but it appears you want
the second car to be able to move relative to the first car with 3 degrees
of freedom - 1) rotate about (for instance) a fixed vertical axis of the
first car (swinging around like a sling), 2) rotate about the second car's
axis which points from the second car to the first car, and 3) move linearly
closer to and away from the first car.

One approach may be to join the first car to an intermediate body with a
piston oriented vertically to the first car. That would allow the
intermediate body to rotate about the vertical axis. Maintain the
intermediate body's position relative to the first car by fixing the
intermediate body's position before each timestep, to prevent it from moving
vertically.

Join the intermediate body to the second car with a piston (rather than a
slider). The second piston will allow the second car to rotate about one of
its own axes *and* to move toward and away from the intermediate body (and
the first car).

Once the intermediate body and second car are joined by a piston, you can
monitor the relative positions of those two bodies with
dJointGetPistonPosition(pistonJointID). Apply a "restoring" force to the
second car along the piston's axis proportional to that position to simulate
the spring force. That is, force-on-second-car = -k*position.

Alternatively, join the intermediate body to the first car with a Hinge2,
permitting the intermediate body to both rotation about the vertical axis
(Axis1) and rotate about a horizontal axis (Axis2.) Join the intermediate
body to the second car with a slider and monitor the slider position to
simulate a spring as described above.

Bruce

> --
>
> You received this message because you are subscribed to the Google Groups
> "ode-users" group.
> To post to this group, send email to ode-...@googlegroups.com.
> To unsubscribe from this group, send email to
> ode-users+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/ode-users?hl=en.
>
>
>
>

[Bruce Veazie]

Another suggestion: would a ball-and-socket work as well? That could be done
without an intermediate body.

Bruce
----- Original Message -----
From: "Keyan" <key...@googlemail.com>
To: <ode-...@googlegroups.com>
Sent: Thursday, November 26, 2009 6:35 AM
Subject: [ode-users] Joint question (combining 3 joints into a new one)

[Daniel K. O.]

Bruce Veazie escreveu:

> Another suggestion: would a ball-and-socket work as well? That could be done
> without an intermediate body.

Or maybe just compute the spring force by hand. It would be faster than
using joints.

From the description it's not clear to me if this would be enough
(maybe an illustration of the intended apparatus would help).


--
Daniel K. O.
"The only way to succeed is to build success yourself"

[Keyan]

hi,

first of all, thanks for the answers. i had thought about introducing 2 intermediate and non-visible objects, such that the cars would connect to these objects via hinges, and the two objects would be connected by a slider (as suggested). i think that's the fastest solution, but no the nicest, as it introduces extra bodies/geoms, which are not otherwise required, but produce extra computational effort. i need to run long simulations, and would like to as efficient as possible.

i uploaded a sketch of the setting to:

http://www.pulsschlag.net/robot_experiment.jpg

the red circles are the axis of the hinge-joints, and the red line shows the connecting spring. the cars are drawn as circles. think of them as objects that can move in any direction and rotation (similar to holonomic drive robots).

pistons are new to me, but i will have a look.

what i was basically thinking of, was write a new joint, that combines 3 joints, just as the hinge2 joint combines two hinge joints. but i am not sure how much effort that is. that is why i asked here first, if there is a "best way" to proceed. i have no experience in ode-source code. up to now, i am only an ode-user.

cheers,
keyan

[Bill Sellers]

Writing a new joint is computationally the best way. As long as you
can come up with a formula that defines the position of one body with
respect to the other and you can generate a sensible error signal then
it is possible to do. It's sadly not quite as straightforward as it
could be. I've never managed to get further than modifying some of the
existing joints to get slightly different behaviour. There are quite a
few bits of the code that I just have no idea what they are for -
whether they are just hints to the solver or vitally important for the
stability of the system. So for example does it matter if SureMaxInfo
is just set to zero (or 6) if you are not quite sure how many degrees
of freedom are being removed? And you need to know what a Jacobian is
(best description I've seen is in the manual for the Matlab
Optimization Toolbox):

http://www.mathworks.com/access/helpdesk/help/toolbox/optim/ug/brhkghv-3.html

There is also a PDF called joints.pdf written by Russell Smith that
gives quite a good description of theory.

http://www.ode.org/joints.pdf

There's a bit of a gap between the theory and the practice though -
and it would have changed since the document was written anyway. The
new joints layout makes things a little simpler and there's some extra
information in joints.h and some of the other source files. It all
goes a little fast for me though - I'd really appreciate a slower
walkthough since actually writing new joints is something we should
encourage. They are actually extremely flexible and there are lots of
things that people want to do that could be better achieved using
custom joints. I want to restrict a line to be always inside a convex
polyline for example - the best way is to create a joint that does
that but I'll probably end up fiddling with trimesh collisions because
that's what's available. I'd find point on plane useful too...
Someday :->

Cheers
Bill

[Daniel K. O.]

Bill Sellers escreveu:

> stability of the system. So for example does it matter if SureMaxInfo
> is just set to zero (or 6) if you are not quite sure how many degrees
> of freedom are being removed?

Blame Oleh for that one.

> There is also a PDF called joints.pdf written by Russell Smith that
> gives quite a good description of theory.
>
> http://www.ode.org/joints.pdf

There's also Russel's chapter [*] on Game Gems 4, which is easier to
follow, with some nice illustrations. Also see Erleben's thesis, section
4.7 (assuming you are good enough at calculus to follow it up).

> goes a little fast for me though - I'd really appreciate a slower
> walkthough since actually writing new joints is something we should
> encourage. They are actually extremely flexible and there are lots of
> things that people want to do that could be better achieved using
> custom joints.

Then see [*], he guides the reader through the creation of a couple of
joints, including a "pulley" joint, not available on ODE itself.

> I want to restrict a line to be always inside a convex
> polyline for example - the best way is to create a joint that does
> that but I'll probably end up fiddling with trimesh collisions because
> that's what's available. I'd find point on plane useful too...
> Someday :->

You mean "point to be always inside a convex polyline"? Again, [*] shows
how to constraint a body to move along a specified line.

[Oleh Derevenko]

I'll improve the comment to clarify that question, sorry.
To make the long story short, that information is used for memory
reservation for calculation. That means it must ALWAYS be not less than the
value of "m" the info can generate for current joint state. Another
requirement is that the value should be provided very quickly, without the
excessive calculations.
So, if you are unable to quickly predict the maximal value of `m' you can
return (which is the case for most joint types) just return the maximum for
current joint type in general. If you can be sure your `m' will be smaller,
you can save a bit of memory from being reserved for calculations by
returning that smaller value.

[Daniel K. O.]

Keyan escreveu:

> first of all, thanks for the answers. i had thought about introducing
> 2 intermediate and non-visible objects, such that the cars would
> connect to these objects via hinges, and the two objects would be
> connected by a slider (as suggested). i think that's the fastest
> solution, but no the nicest, as it introduces extra bodies/geoms,
> which are not otherwise required, but produce extra computational
> effort. i need to run long simulations, and would like to as
> efficient as possible.

There's also opportunity for extra instability; if you make the
intermediate bodies' masses too small (as to not affect the "real"
bodies too much) you might have numerical problems.

> i uploaded a sketch of the setting to:
>
> http://www.pulsschlag.net/robot_experiment.jpg
>
> the red circles are the axis of the hinge-joints, and the red line
> shows the connecting spring. the cars are drawn as circles. think of
> them as objects that can move in any direction and rotation (similar
> to holonomic drive robots).

It seems to me that you need 2 angular constraints (as provided by
AMotors) and something similar to a ball and socket constraint, just to
keep the anchors at a specific, fixed distance. I can help you with the
constraint equations, if you can come up with a meaningful name for this
joint. ;-)

[Daniel K. O.]

Oleh Derevenko escreveu:

> So, if you are unable to quickly predict the maximal value of `m' you can
> return (which is the case for most joint types) just return the maximum for
> current joint type in general. If you can be sure your `m' will be smaller,
> you can save a bit of memory from being reserved for calculations by
> returning that smaller value.

If there's a default behavior why not have a default implementation in
the base class that always return the maximum?

[Oleh Derevenko]

Whith such a default implementation available nobody would ever ask why is
it for. ;)

Oleh Derevenko
-- Skype with underscore

----- Original Message -----
From: "Daniel K. O." <danielk...@gmail.com>
To: <ode-...@googlegroups.com>
Sent: Monday, November 30, 2009 7:23 PM
Subject: Re: [ode-users] Joint question (combining 3 joints into a new one)

[Keyan]

thanks for the high response. i will give the pdf a try, and for sure come back to this list with tons of questions :)

cheers,
keyan

[Bill Sellers]

>>
>
> You mean "point to be always inside a convex polyline"? Again, [*]
> shows
> how to constraint a body to move along a specified line.

Nope. I want the line to rattle around inside a closed polyline. Think
of on irregular ring sliding on a rope. Actually I suspect generic
polyline, polyline collisions would do the trick but I suspect closing
one would make defining inside and outside easier.

Cheers
Bill