How to connect the kinematic_model an visual node the right way?

I’m in the process of writing an COLLADA 1.5 conform importer.

When it comes to kinematics I’m not 100% sure how to implement them the right way. I could not find the answer in the specs though.

I have a couple of sample COLLADA Files from different exporters, that seem to expect different behavior in terms of how to bind visual nodes to joints.

One requires the axis to return the relative matrix thus combining multiple axes in the visual scenes explicitly

<node id="_9.1_8" name="_9">
 <matrix>1 -3.33067e-016 2.77556e-017 -5.59407e-010 -7.21645e-016 1 -2.68879e-007 0.000269281 8.32667e-017 2.68879e-007 1 7.92702e-005 0 0 0 1</matrix>
 <matrix>1 3.33067e-016 -2.77555e-017 5.59407e-010 7.21645e-016 1 2.68879e-007 -0.000269281 -8.32669e-017 -2.68879e-007 1 -7.92701e-005 0 0 -0 1</matrix>
 <matrix>1 0 0 0 0 1 0 -1.38778e-014 0 0 1 8 0 0 0 1</matrix>
 <rotate sid="joint_0_axis0">-0 -0 -1 0</rotate>
 <matrix>1 -0 0 -0 -0 1 -0 1.38778e-014 0 -0 1 -8 -0 0 -0 1</matrix>
 <matrix>1 0 0 357 0 1 0 -500 0 0 1 1045 0 0 0 1</matrix>
 <rotate sid="joint_1_axis0">-1 1.22125e-015 -6.60792e-018 0</rotate>
 <matrix>1 -0 0 -357 -0 1 -0 500 0 -0 1 -1045 -0 0 -0 1</matrix>
 <matrix>1 0 0 -385.5 0 1 0 -294.817 0 0 1 1001.5 0 0 0 1</matrix>
 <translate sid="joint_4_axis0">1 -1.11022e-015 7.59048e-017</translate>
 <rotate sid="joint_4_axis1">1 -1.11022e-015 7.59048e-017 0</rotate>
 <matrix>1 -0 0 385.5 -0 1 -0 294.817 0 -0 1 -1001.5 -0 0 -0 1</matrix>
 <matrix>1 -3.33067e-016 2.77556e-017 -5.59407e-010 -7.21645e-016 1 -2.68879e-007 0.000269281 8.32667e-017 2.68879e-007 1 7.92702e-005 0 0 0 1</matrix>
  <instance_geometry url="#geo8">[...]

In order to achieve the desired position, multiple references to axes are joint together and transformed by matrices.

The other export needs the absolute value of the axis to work. Therefore the kinematic_model has to be calculated and the result passed to the visual node.

<node id="link_265706" name="link_RigidBody(2)">
    <rotate sid="joint_1_axis">1 0 0 0</rotate>
    <node id="265816" name="model1">
        <matrix>1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 10.000000 0.000000 0.000000 0.000000 1.000000</matrix>
        <instance_node url="model1_6547.dae#model" />
    </node>
</node>
<node id="link_316919" name="link_RigidBody(3)">
    <rotate sid="joint_2_axis">1 0 0 0</rotate>
    <node id="179605" name="model1">
        <matrix>1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 35.000000 0.000000 0.000000 0.000000 1.000000</matrix>
        <instance_node url="model1_6547.dae#model" />
    </node>
</node>[...]

The kinematic_model of the two nodes is nested. ink_RigidBody(3) is a child of ink_RigidBody(2). Therefore joint_2_axis expects the absolute matrix including the transformation to joint_1_axis.

How is the expected behavior? Calculating the kinematics_model and using the absolute Matrices or not calculating the kinematics_model and combining multiple axes values in the visual scene?

I think your best bet for finding someone who can answer your question is to see if there is a forum for OpenRAVE, since that project I believe is doing the most with 1.5, and IK specifically. It’s very possible that no one knows, and the exporters are both wrong, or both right. Exporters/importers of all stripes for all formats have a tendency to be absolute crap. I wish I could answer your question. I don’t have experience with IK yet.

Thanks Mick.
This is a good example of a fire and forget specification.
I feel like nobody really cares how to implement it. The only benefit of an open format is the interoperability, which is not provided by an unclear spec and no support.

Yes. It’s certainly not met my expectations either. I am practically faced with inventing COLLADA–creating the first realistic reference implementation that is–right now. I thought after 10yrs it’d be mature. Anyway, I think, if thanks only to myself, by this time next year, the fate of COLLADA is going to be looking much better.

I think after I get the old COLLADA-DOM into top shipshape, the Blender people will have no excuse to not take COLLADA seriously, and if someone that knows its codebase gets it (Blender) working hand-in-hand with COLLADA-DOM there will be a lot more interest in COLLADA. I am also working toward a DAE native modeling/XML-browser suite that will be called Daedalus. It’s actually a very interesting methodology. I think slowly but surely people will find uses for ColladaDOM 3 that will have a very far reaching impact. Because C++ could just use a really good XML-like databinding/light-DOM framework. COLLADA has appeal to 3-D and robotics, and so that makes it sexy. It could be an XML Schema renaissance before I’m done with it.

[QUOTE=username;40413]Thanks Mick.
This is a good example of a fire and forget specification.
I feel like nobody really cares how to implement it. The only benefit of an open format is the interoperability, which is not provided by an unclear spec and no support.[/QUOTE]

PS: I read this the first time as “fire and forget forum post”. Thinking you were referring to your late reply. 1.5 clears a lot up, but most people in the real-time 3-D world who use COLLADA for anything (I’m unconvinced anyone uses it for much) use 1.4.

I don’t think a new specification or version is appropriate under the circumstances. There’s no reason to invest time in a new version if there is not a significant reaction in terms of developing software for working with COLLADA files/streams and meeting the objectives described by the specification. I think it certainly needs revision, but that people need to first demonstrate that we are deserving of a revision. You can go a long way to make COLLADA practical with or without an ideal specification. So far no one has. It’s not so much a failing on the part of COLLADA or its progenitors, as much as it’s a failing of society and the professional classes especially.

Thanks. I’ve lost count of how many months I’ve been working on it. (The better part of the year.) I just finished the last C++ file today for the first round of tests, and just have to add one more system to the PHP generator, and for the first time it will be able to be built and run. It’s interesting working for months on a library that can’t be built/run. It’s all in the head. For some reason I’ve had a string of projects like that the last two or three years. They always go off without a hitch.

It’s a much, much better library now. It’s shaping up to something you can really have confidence in. It may even be unique for what it does. I don’t know. If so, it may have far reaching implications for XML/C++ in general.

EDITED: I’m pretty sure I just replied to a spambot! Anyway, the information is still there. (The bot seems to have copied one sentence from an earlier post.)