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
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:
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.
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
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?
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.
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.
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));
result = resolveImpl(*this);
Which implicitly first tests “./” before trying to resolve an ID. Are you saying that this is wrong?