Hi,
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,
Gustavo Puche.
Hi,
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,
Gustavo Puche.
Some hard and some simple stuff attached
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.
Best regards,
Gus
The collada namespace and version of each of these files is:
<COLLADA xmlns=āCOLLADA 1.4 Schemaā version=ā1.4.1ā>
both are different from the COLLADA 1.5 implementation of collada dom 2.2:
namespace=āCOLLADA 1.5 Schemaā
version=ā1.5.0ā
is there any examples with articulated_system?
thanks!
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ā>
<param>kinmodel.0</param>
</bind_kinematics_model>
</instance_kinematics_scene>
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:
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">
<SIDREF>libkinscenes.kinScene/inst_kinmodel.0/joint_1/axis0</SIDREF>
</newparam>
</instance_kinematics_model>
</kinematics_scene>
</library_kinematics_scenes>
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">
<technique_common>
<instance_joint url="#joint_1" sid="joint_1"/>
</technique_common>
</kinematics_model>
</library_kinematics_models>
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.
thanks,
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?
Hi,
sorry for the delay answering your question.
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ā).
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) {
remainingPart.clear();
// begin
if ( strncmp( container->getElementName(), "instance_", 9 ) == 0 ) {
daeURI *uri = (daeURI*)container->getAttributeValue("url");
if ( uri != NULL && uri->getElement() != NULL ) {
daeElement *e = findWithDots( uri->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.
Regards
Steffen
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:
Also is the attachment_full joint attribute is always a pointer to instance_joint or can it also be joint?
thanks,
rosen,
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ā¦
Hi,
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.
-root
|-upper arm
|-forearm
|-hand
But the kinematics model is a tree.
-upperarm
|-forearm
|- 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
Steffen
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:
Regards
Steffen
HI
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.
Regards
Steffen
Here is a kr360 robot with articulated systems(kinmetaice & motion).
www.netallied.de/tmp/kr360.zip
Regards
Steffen
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?
thanks,
rosen,
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
Sebastian