Re: [simspark-devel] collecting bugs

[Markus R. <rol...@un...>]

Hi Joschka,

Joschka Boedecker schrieb:
> 1) The "no-hierarchies bug"
> 
> You cornered this bug that prevents the correct construction of  
> hierarchies in the scene graph last year. It had the effect that all  
> but the last body in a hierarchy in a scene description were set to  
> the origin, no matter what. I think it had something to do with the  
> Transform class, but I can't remember correctly. Did you ever get  
> around fixing this one?

yes, I already changed this in the simspark CVS but not yet in the 
soccer3d CVS (I forgot to add it to the list of differences I posted 
recently).

The original scene graph design does not support nested bodies in the 
sense that there must be no body node in the chain of parent nodes of 
any given body node.

The problem is a follows: After each physics step the scene graph is 
updatetd to reflect the new position of each ODE body. This is done in 
Body::PostPhysicsUpdateInternal() that calls SetWorldTransform() of the 
parent node. This call is chained upwards in the hierarchy until the 
SetWorldTransform() of a transform node is called.

In the current soccer3d implementation the given transform matrix is 
taken and all parent nodes are set to the identity matrix (via the same 
upchain mechanism). As the scene graph is updated bottom up (see 
BaseNode::PostPhysicsUpdate()) only the last body in each parent chain 
is updated correctly (every other body is forced to the origin).

In the simspark implementation I fixed the 
Transform::SetWorldTransform() to multiply the new given world transform 
with the inverse of the parents world transform, to calculae the 
necessary 'delta' as the new local transform matrix. It therefore no 
longer needs to reset the parent to the origin. In my tests with the 
RosiML importer this worked ok. The new SetWorldTransform() depends on 
the full matrix inversion that is added to the salt::Matrix() class.

> 2) The RosiML importer
> 
> I remember you pointed out there were still problems with the importer  
> concerning composite bodies and some kind of macros. Could you give a  
> brief explanation of these problems in case someone is willing to work  
> on it?

I implemented the RosiML importer using only some example files and an 
XML schema that lacked the semantics of the nodes. Simple demo files 
(i.e. block worlds and basic joint setups) work correctly but I was 
unable to fully parse the more complex robot files (e.g. aibos).

The shapes (i.e. 3d meshes and textures) as well as the basic joint 
setup seem to work but the more subtle details like the correct mass 
center, joint stops, motor setup etc. are still lacking.

I'll try to look into it again to come up with a more precise 
description of it's current state... ;)

cheers,
Markus