COLLADA 1.5 kinematics


We are developing a robot system simulator based in OpenRAVE.

Does anybody send me an example of a COLLADA 1.5 model with kinematics joints?

Best regards, :smiley:

Gustavo Puche.

Some hard and some simple stuff attached :wink:
Start with simple.dae and finish with ir663.dae
Good luck and don’t hesitate to ask if something is unclear.

A lot of thanks Sebastian for your colaboration. :stuck_out_tongue:

Best regards,

Gus :wink:

The collada namespace and version of each of these files is:

<COLLADA xmlns=“” version=“1.4.1”>

both are different from the COLLADA 1.5 implementation of collada dom 2.2:


is there any examples with articulated_system?


The reason I make a point about the namespace and version is that collada-dom 1.5 fails to open it completely because the checks fail. How were these files generated and were they really tested?

The samples were tested against an intermediate version of the DOM that did not evaluate the XSD version. We will upload the corrected samples again. It should be sufficient to change 1.4.1 to 1.5.

I have a question regarding the format of bind_kinematics_model that is a little unclear in the specification.

Imagine that you have the following code:

<instance_kinematics_scene url="#kinScene">
<bind_kinematics_model node=“Product.1_0”>

My question is how to search for “kinmodel.0” (declared in <param>) in “kinScene”. The specification says:

“The parameter of the kinematics model that is defined in the
instantiated kinematics scene. See main entry in Core.”

The spec says that we have to look for a <newparam> tag whose sid is “kinmodel.0”. The question is, where to look for the newparam.

kinScene is a kinematics_scene declared in library_kinematics_scenes. kinScene also holds an array of <instance_kinematics_model> tags, therefore the possibilities for the search are:

  • the entire scope of the collada document
  • the entire scope of “kinScene” and all its children
  • only in the scope of every <instance_kinematics_model>

Currently I’ve implemented the 3rd option because that’s what the files Sebastian sent show, but that might not be the end of the story.

thank you,

The real question would be:

How can <bind_kinematics_model> be resolved into the correct <instance_kinematics_model>? Are there any automatic methods in collada-dom to do this? Right now it is a pain to check both <param> and <SIDREF> tags and call the appropriate methods.

I have another question:

In simple.dae, I’m trying to resolve the SIDREF in a newparam, which is supposed to point to a joint axis in <kinematics_model>

	<library_kinematics_scenes id="libkinscenes">
		<kinematics_scene id="libkinscenes.kinScene">
			<instance_kinematics_model url="#kinmodel.0" sid="inst_kinmodel.0">
				<newparam sid="libkinscenes.kinScene_libkinscenes.kinScene_inst_kinmodel.0_joint_1_axis0">

I’m using the newparam element as the reference element in the resolution action. In collada-dom this looks like:

daeSidRef("libkinscenes.kinScene/inst_kinmodel.0/joint_1/axis0", [pointer of newparam]).resolve().elt

However, it is failing to resolve. I’m guessing the resolution is failing to follow the url of the real kinematics_model, which is also failing to follow the url of <instance_joint>? Here is the relevant XML:

	<library_kinematics_models id="libkinmodels">
		<kinematics_model id="kinmodel.0" name="Mechanism.1">
				<instance_joint url="#joint_1" sid="joint_1"/>

I’ll try stepping into the code to find the real reason, but suggestions on how to really resolve SIDs in this case would be really helpful.


After more analysis i fixed the collada-dom problem by adding the addition url resolution into daeSIDResolver.cpp… this feels like a hack that i shouldn’t be doing, and no where in the spec does it say that urls should be followed when resolving SIDs. Which begs the question, are the files that were submitted on this forum consistent with the collada 1.5 spec?


sorry for the delay answering your question.

  1. The parameter of the <bind_kinematics_model> points to the SID of the parameter of the kinematics scene. In the example given it refers itself to an SID path (“libkinscenes.kinScene/inst_kinmodel.0/joint_1/axis0”).

  2. In the past the SIDResolver was able to solve this path. Looking in the current code, it seems there is something missing to resolve this path.

daeElement* findWithDots(daeElement* container,
const string& s,
const string& profile,
daeElement* (finder)(daeElement, const string&, const string&),
list<string>& remainingPart) {

	// begin
	if ( strncmp( container-&gt;getElementName(), "instance_", 9 ) == 0 ) {
		daeURI *uri = (daeURI*)container-&gt;getAttributeValue("url");
		if ( uri != NULL && uri-&gt;getElement() != NULL ) {
			daeElement *e = findWithDots( uri-&gt;getElement(), s, profile, finder, remainingPart );
			if ( e != NULL ) {
				//found it
				return e;
	// end

	// First see if the whole thing resolves correctly
	if (daeElement* result = finder(container, s, profile))
		return result;

With this it should be possible to resolve those SID paths.
For me it is not a hack, because resolving a path like “libkinscenes.kinScene/inst_kinmodel.0” leads me to the <kinematics_model> element. So why not go further from here?

3.I am happy to see other people implementing kinematics of COLLADA. So, whenever I can help you, just ask.



thanks that works much better!

now that i’m getting farther in parsing the format, i have questions about how the kinematics coordinate systems are synchronized with the node coordinate systems.

The <attachment_X> tags determine the kinematics coordinate system because they specify the relative transformations between each of the joints. So given joint values, we can compute the coordinate systems of each of these ‘kinematic’ links.

Now the problem is to attach the correct geometry to these ‘kinematic’ links from the visual scene hierarchy of <node> tags. However, the <node> hierarchy has its own way of determining geometry coordinate systems. The only thing that binds the kinematics from the nodes is the initial kinmodel-node reference in <bind_kinematics_model> and the joint axes specified in <bind_joint_axis>. Here I’m assuming that the origin of the kinematic model starts at the origin of the referenced node.

Anyway, the joint axes bindings take the form of binding a kinematic joint to a node transformation, and this is where I’m getting confused. If a joint changes its value, does that mean the node transformation changes accordingly and the node hierarchy structure is preserved? For example, if the parent of a node moves in the x by 2 during runtime, does that mean that all its child elements are moved by 2. If so, then we have a small conflict since the kinematic transformation hierarchy might not agree with the node transformation hierarchy.

The underlying questions here are:

  • does the kinematic hierarchy take precedence over the node hierarchy?
  • how can i determine the correct transform of the geometry to attach to each kinematic coordinate system?

Also is the attachment_full joint attribute is always a pointer to instance_joint or can it also be joint?


We now have an initial implementation of kinematics in OpenRAVE. You should be able to load dae files by

openrave myfile.dae

This doesn’t support the articulated_system tags yet (mostly because we have no examples to test with)

I ended up giving each link in the robot the coordinate system associate with the kinematics module. The node transformations were only used to get the geometry transformed correctly within each link. This scheme works for all but the kr360.dae file, we’re still investigating why.

Correct, kr360 can be opened just fine. I’m still worried about the fact that collada does not constrain the kinematics transformations to be the same as the node (visual scene) transformations…


the hierarchy of the kinematics model and the geometry model do not have to match. At least you can define a kinematics scene without any representation just for calculating. That’s why the combination of kinematics and geometry is done in the scene.
This seems to be confusing, but in fact robotics systems like DELMIA or Robcad work that way.

Looking at the sample simple.dae, you can see that the node hierarchy is flat.

|-upper arm

But the kinematics model is a tree.
|- hand

in the scene element you can see that the value of the joint is mapped to transformation “joint_1_axis0” of the node “Product2.1_1” and of the node “Product3.1_2”. So, the geometric model would move correctly.
The advantage is, you can map a kinematics model on any geometric model as long the count of links matches.

Hope this helps


An articulated system is useful to add more properties to a kinematics system. These properties are important for describing a behaviour of an industrie robot.
We differ between to kinds of articulated systems:

  1. relating to kinamtics aspects:
  • these properties can define which joints of a model are active or passive. This important if you have a closed loop to define which joint drives and which follows.
  • You have the possibility to look single joints that they can’t move.
  • You can define an index for a joint. this index is used in robot programs to define the place of the joint in the joint vector when solving the problem.
  • You can define additional limits to a joint. The limits defined in the joint element are so called hard limits. This is a physical limit. The additional or “soft” limits are limits that may appear using a joint in a kinmatics model. That’s why a soft limit can be described by a formula, too.
  1. relating to dynamic aspects:
    Here can define if a single joints should be limitated in its speed, accelaration or jerk.



the kr360 is an example of a kinematics model with a closed loop. The kinematics model is defined with attachment_start and attachment_end elements. May be that could be the problem. In the kr150 sample the closed loop is described with formulas, so that could be the reason why the kr360 example doesn’t work.


Here is a kr360 robot with articulated systems(kinmetaice & motion).



Hi Steffen,

Thank you for the reply, the reasons you pointed out is exactly why we want to use articulated systems over kinematics to describe robots. We’ll try to get the new kr360 model working. The reason it wasn’t working before was because of a bug in the way we were handling transformations, this is fixed now.

I understand how the node and kinematics hierarchies work, what bothers me is that the visual scene can move in a completely different way inconsistent with the kinematics model. This means that it is not possible to attach a rigid geometry to each kinematics link, which overly complicates our simple representation of a robot. Just out of curiosity, what is the application of such flexibility?


That allows us to paint a robot green, red, yellow or to represent it with a BREP, a simplified or a detailed level of geometry. The idea is to model the kinematic once and attach it to multiple geometric representations of the robot. Another usecase is to completly skip the geometrical part…

I know it makes things even more complicated but it resembles in a way current simulation tools work and gives us far more flexiblity :wink: