Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 27

Thread: collada kinematics 1.5 test files

  1. #11
    Member
    Join Date
    Mar 2009
    Location
    Tokyo, Japan
    Posts
    88

    Re: collada kinematics 1.5 test files

    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:

    http://openrave.programmingvision.com/i ... ollada.tgz
    http://openrave.programmingvision.com/i ... ollada.tgz

    I posted the extensions above, but here is the link again:
    http://openrave.programmingvision.com/i ... ed:COLLADA

    I would be glad to help you get your robots to use these tags.
    Rosen Diankov
    Department of Mechano-Informatics, University of Tokyo
    http://openrave.org

  2. #12
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771

    Re: collada kinematics 1.5 test files

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

  3. #13
    Member
    Join Date
    Mar 2009
    Location
    Tokyo, Japan
    Posts
    88

    Re: collada kinematics 1.5 test files

    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

    thanks!
    Rosen Diankov
    Department of Mechano-Informatics, University of Tokyo
    http://openrave.org

  4. #14
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771

    Re: collada kinematics 1.5 test files

    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>.
    Code :
    	<library_articulated_systems id="asystems">
    		<articulated_system id="robot1_motion">
    			<motion>
    				<instance_articulated_system url="#robot1_kinematics">
    					<bind symbol="robot1_motion.kmodel1_inst">
    						<param ref="robot1_kinematics.kmodel1_inst"/>
    					</bind>
    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.
    Code :
    		<articulated_system id="robot1_kinematics">
    			<kinematics>
    				<instance_kinematics_model url="#kmodel1" sid="kmodel1_inst">
    					<bind symbol="robot1_kinematics.kmodel1_inst">
    						<SIDREF>robot1_kinematics/kmodel1_inst</SIDREF>
    					</bind>
    Can you explain your interpretation of this excerpt? Thanks.

  5. #15
    Member
    Join Date
    Mar 2009
    Location
    Tokyo, Japan
    Posts
    88

    Re: collada kinematics 1.5 test files

    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?

    Code :
             <kinematics>
                <instance_kinematics_model url="#kmodel1" sid="kmodel1_inst">
                   <newparam sid="robot1_kinematics.kmodel1_inst">
                      <SIDREF>robot1_kinematics/kmodel1_inst</SIDREF>
                   </newparam>

    Or do we need to change both to use newparam?
    thanks,
    Rosen Diankov
    Department of Mechano-Informatics, University of Tokyo
    http://openrave.org

  6. #16
    Member
    Join Date
    Mar 2009
    Location
    Tokyo, Japan
    Posts
    88

    Re: collada kinematics 1.5 test files

    hi marcus,

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

    thanks,
    Rosen Diankov
    Department of Mechano-Informatics, University of Tokyo
    http://openrave.org

  7. #17
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771

    Re: collada kinematics 1.5 test files

    Quote Originally Posted by rdiankov
    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?
    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).
    Quote Originally Posted by rdiankov
    In that case, changing to the following code would make the COLLADA file work?
    Code :
             <kinematics>
                <instance_kinematics_model url="#kmodel1" sid="kmodel1_inst">
                   <newparam sid="robot1_kinematics.kmodel1_inst">
                      <SIDREF>robot1_kinematics/kmodel1_inst</SIDREF>
                   </newparam>
    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.

  8. #18
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771

    Re: collada kinematics 1.5 test files

    Quote Originally Posted by rdiankov
    we updated the models (and exporter) as you suggested. are they any more problems you see?
    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:
    Code :
    	<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"/>
    				</bind>
    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.

  9. #19
    Member
    Join Date
    Mar 2009
    Location
    Tokyo, Japan
    Posts
    88

    Re: collada kinematics 1.5 test files

    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="">?

    thanks,
    Rosen Diankov
    Department of Mechano-Informatics, University of Tokyo
    http://openrave.org

  10. #20
    Member
    Join Date
    Mar 2009
    Location
    Tokyo, Japan
    Posts
    88

    Re: collada kinematics 1.5 test files

    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:

    <code>
    // 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);
    </code>

    Which implicitly first tests "./" before trying to resolve an ID. Are you saying that this is wrong?
    Rosen Diankov
    Department of Mechano-Informatics, University of Tokyo
    http://openrave.org

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •