Thread: Re: [simspark-devel] ODE Composite bodies

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hey Sander,

(I copied the simspark-devel list, I hope you don't mind)

On Feb 6, 2008, at 1:15 AM, Sander van Dijk wrote:

>
> After reading your mail (forwarded to the rest of the team by Mart)  
> I looked into using composite bodies in ODE. I took the  
> TransformCollider from Markus from the Simspark CVS

You're fast! Sorry, if I had known you'd start to work on that right  
away, I would have given some more information that Markus gave me  
about the TransformColliders back when he first implemented them. But  
of course I'm more than happy that you did start the work :-)

Let me first give you the information I found in an old email from  
Markus. Here's what he wrote:

The class TransformCollider implements the ODE concept of transform  
geoms (necessary for composite objects). A Collider object which is  
linked below an instance of this class in the hierarchy will  
automatically be associated with this TransformCollider. Only one  
Collider is allowed to be associated with one TransformCollider in  
this way.

The TransformCollider changes two things:

- the CollisionHandler must not be linked in below the Collider, but  
below the TransformCollider
- the method "SetPosition" of a Collider will change the  position of  
the collision primitives relative to the TransformCollider

The construction of a composite object is done just like in the  
"normal" case:

- all the nodes are linked into the hierarchy below a common  
Transform node.
- the objects that are visible (rendered on screen) might be placed  
with additional Transform nodes
- after that, as usual, we link in a Body node; the mass and the  
center of mass might have to be adjusted
- now we link in the Colliders; in case we want to offset them for a  
composite object, they are linked in as a child of a TransformCollider

Here is an example for a body composed of a sphere and a box:

(Transform
   (Transform
     (SetLocalPos ...)
     (Box)
   )
   (Transform
     (SetLocalPos ...)
     (Sphere)
   )
   (Body)
   (TransformCollider
     (BoxCollider
       (SetPosition ...)
     )
     (ContactJointHandler ...)
   )
   (TransformCollider
     (SphereCollider
       (SetPosition ...)
     )
     (ContactJointHandler ...)
   )
)

Markus also wrote that he only tested the implementation with simple  
examples and that he wasn't 100% sure it was complete and suitable  
for modeling more complex structures. Unfortunately, I never really  
had time to test the implementation myself. It seems to me that at  
least the automatic adjustment of the masses and center of mass could  
be added as an improvement (see e.g. [1] for the general principle).

> and implemented the missing methods to actually encapsulate a  
> geometry in the transform geometry.

Hmm, I haven't looked at the code yet (sorry, pretty busy at the  
moment), but if I understand Markus' explanations above, the geometry  
should stay with the Collider class (which will be placed below the  
TransformCollider as a child node). I might be wrong though, maybe it  
was still missing ;-)

> I also changed Collider::OnLink to encapsulate colliders that have  
> a transform collider as their parent into it.

I'm not sure if I understand this. Do you mean, you changed the code  
of the Collider class so that it does what Markus described above for  
the code of the Collider class in the simspark repository (associate  
with a TransformCollider instance parent)?

> The new files and a patch with this code are attached.
>

Great, thanks a bunch! I really appreciate your work on this :-)  
Seems like we can finally get rid of the hacks used in the Soccerbot  
RSG file and have better robot models (with complex shapes) that  
cause a lot less trouble for the ODE solver :-D I'll have a look into  
the patch as soon as I can (which will probably not be before the  
weekend :-/).

> If I understand the system correctly, with this it is possible to  
> include something like the following in an RSG file to create a  
> composite body:
>
> -----------------------------------
>   (nd Body
>       ...
>   )
>
>   (nd BoxCollider
>             (setBoxLengths (eval 0.5 * $lenX) (eval 0.5 * $lenY)  
> (eval 0.5 * $lenZ))
>   )
>
>   (nd TransformCollider
>        (nd BoxCollider
>             (setBoxLengths (eval 0.5 * $lenX) (eval 0.5 * $lenY)  
> (eval 0.5 * $lenZ))
>             (setPosition 0 0 (eval 0.75 * $lenZ))
>        )
> -----------------------------------
>

I'm not completely sure whether this is correct. In your example,  
there is one Collider directly below the Body and another one below a  
TransformCollider. If the Body is to be modeled as a composite  
object, I think all of the Colliders will have to be placed below a  
TransformCollider node.

> I am not sure whether the implementation is correct, or pretty (for  
> instance that collider.cpp now includes transformcollider.h and  
> some boost stuff I'm unfamiliar with) :-)

I'll have a look, but don't worry too much about not being pretty for  
now. We can take care of beautification after it works ;-)

> And I haven't really tested yet if it actually works, but wanted to  
> make sure I was on the right way.

I think you are, but please check my comments above.

> I will try to construct a soccerbot with a single composite torso  
> later.

Cool :-P

>
> Referring some other testing:
> - I use ODE 0.9 with double precision myself. I unfortunately don't  
> see much change in simulation speed and amount of LCP errors

OK, I guess it really is a design flaw in our robot.

>
> - I generate LCP errors by making an agent slap his hand against  
> his thigh. This error disapears when I use a single block for it's  
> torso, like the 0.55 bot. So this gives hope for using composite  
> bodies

Yes, very much so :-)

>
> - The error also disapears when reducing the maximum motor force.  
> However, I haven't found a value yest that is low enough to prevent  
> the errors but high enough to give the agent enough strength to get  
> itself up.

The motor strength should be limited, not only for the sake of  
simulation stability, but also for more realism (to prevent excessive  
jumping and somersaults ;-) ).

>
> - I have tried using dWorldQuickStep instead of dWorldStep to  
> advance simulation, however this destabalizes the agent, making it  
> look like a bag of potatoes :-). The ODE manual predicts this for  
> complex robot systems [1].
>

Thanks for trying though.

> I'll let you know when I make more progress.
>

Great! Please keep up the good work!

Cheers,
Joschka

[1] http://opende.sourceforge.net/mediawiki-1.6.10/index.php/ 
HOWTO_composite_objects

P.S.: if you think it'll help, I can send you some code for a "pure"  
ODE version of the HOAP-2 inspired robot I did way back before I  
started to implement it in simspark. It uses compound bodies, so it  
might be helpful as a reference. Let me know.