collada kinematics 1.5 test files

We’ve been trying to gather as many collada kinematics 1.5 test files, but unfortunately they are very difficult to find on the net. In the past we’ve used the Simple.dae, Weldinggun.dae, KR-150.dae, and KR360.dae files, but they do not test a lot of the new kinematics functionality. It would be really great to have more files using articulated systems and composition of robot parts to a whole robot. We would also like to create a unit test set for kinematics.

any help would be appreciated in helping us write a solid collada reader/writer
thank you,

Hello Rosen,

we have many 1.5 files with included kinematics - I’ll take a look which of them we can distribute freely.


Some more samples are available from


hi sebastian,

thanks! please keep more coming.

also, are we free in uploading these models in our own public repositories?


You’re free to share the files under the Creative Commons Attributtion 3.0 Unported license.


Here is youBot collada model. It is a test version, not finished yet. … matics.dae

awesome! opening the file as is produced a small error at
line 995: should be <rotate>?

beyond that, everything was good.

sebastian: how long do you think it would take to send more models?


i forgot to mention that the newest openrave verison (r1835) supports the articulated_system tags and other custom robot information.

we’re maintain a wiki here for it: … ed:COLLADA

if you can use the articulated_system tag and inside it define a manipulator, then you should be able to start using the youBot robot with the openrave planning system right away. here’s a simple barretthand example:

(these sample files are going to be in openrave eventually, so the above url will not be valid for long)

anyway, i can help with any problems.

Interesting. I will check that. Do you also have any models to share (expect for PR2 an COB3 which are in OpenRAVE)?
>>sebastian: how long do you think it would take to send more models?

I think it is better, if we post all available models here.

hi alexey,

In the past couple of weeks, we went through several major upgrades on the collada parsers for OpenRAVE and ROS. The result is that the pr2 model can now be exported as instance_articulated_system along with extra “manipulator” tags.

I’m attaching two robot examples: … ollada.tgz … ollada.tgz

I posted the extensions above, but here is the link again: … ed:COLLADA

I would be glad to help you get your robots to use these tags.

Perhaps you can post your extensions in the COLLADA Extensions Directory?

Hi marcus,

Yes, we are planning to eventually put the extensions up on the official site. Before we can start advertising this functionality, we would like to test on as many collada kinematics samples as possible, hence the reason for this thread ;0)

we learn a new thing about collada everyday, so there’s still much to learn in getting a correct parser, and more complex test files will greatly help with this


I have a question regarding your exported documents.

Here you declare a bind to parameter that is supposed to be, according to the 1.5 spec, declared by a <newparam>.

	<library_articulated_systems id="asystems">
		<articulated_system id="robot1_motion">
				<instance_articulated_system url="#robot1_kinematics">
					<bind symbol="robot1_motion.kmodel1_inst">
						<param ref="robot1_kinematics.kmodel1_inst"/>

Yet here you declare a bind to the current object, i.e. the kinematics model instance. I don’t think this should resolve the previous bind attempt.

		<articulated_system id="robot1_kinematics">
				<instance_kinematics_model url="#kmodel1" sid="kmodel1_inst">
					<bind symbol="robot1_kinematics.kmodel1_inst">

Can you explain your interpretation of this excerpt? Thanks.

hi marcus,

thanks for pointing out these problems. From the “instance_articulated_system bindings” thread, it is clear that we’ve been confused about the usage of bind and newparam. Clearly there are cases when you can use both.

My interpretation of the above code was that bind creates a new symbolic name, which is then referenced by another bind. From your comments on the previous thread, you are basically saying that you cannot reference a reference? You can only reference a parameter?

In that case, changing to the following code would make the COLLADA file work?

            <instance_kinematics_model url="#kmodel1" sid="kmodel1_inst">
               <newparam sid="robot1_kinematics.kmodel1_inst">

Or do we need to change both to use newparam?

hi marcus,

we updated the models (and exporter) as you suggested. are they any more problems you see?


Right. According to the spec, a <bind><param> references a <newparam> and not anything else. In particular the symbol attribute is not an SID so it can’t be referenced in the document (only in the run-time).

That looks right to me.

Use <newparam> to build up your data model within the document. Use <bind> to define symbols for each instance in your run-time.

Yes. The values for the <param> ref attribute are supposed to be sidref_type. In your export they do not appear to be complete, for example:

	<library_kinematics_scenes id="kscenes">
		<kinematics_scene id="kscene" name="OpenRAVE Kinematics Scene">
			<instance_articulated_system sid="robot1_motion_inst" url="#robot1_motion" name="BarrettWAM">
				<bind symbol="kscene.kmodel1_inst">
					<param ref="robot1_motion.kmodel1_inst"/>

I don’t see how those binds can resolve with the values you have exported. The value should be either ref="./robot1_motion.kmodel1_inst" or ref=“kscene/robot1_motion_inst/robot1_motion.kmodel1_inst” or ref=“robot1_motion/robot1_motion.kmodel1_inst” … these all refer to the declaration of the <newparam> in the document. I think the first one, a relative address, is closest to your intention.

In fact, I think you need to double check all of your usages of <SIDREF> as well. How are you currently resolving these? Seems like you have implemented an implied “./” for the first part of the syntax as specified in chapter 3 of the spec.

After re-reading the collada spec, it seems that we might have misunderstood param (reference). So it resolves as a regular SIDREF? If that’s the case, why does <bind> have both

<param> and <SIDREF> tags?

Can you send a working example using <param ref="">?


By the way, we’re using collada-dom, and I’ve posted several bug reports about its SID referencing implementation…

Anyway, in the daeSidRef::resolve() method, there is this comment:

// Try to resolve as an effect-style sid ref by prepending “./” to the sid ref.
// If that fails, try resolving as an animation-style sid ref, where the first part is an ID.
result = resolveImpl(daeSidRef(string("./") + sidRef, refElt, profile));
if (!result.elt)
result = resolveImpl(*this);

Which implicitly first tests “./” before trying to resolve an ID. Are you saying that this is wrong?