ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

urdf to collada for OpenRave does not work

asked 2021-04-02 14:00:16 -0500

Gates gravatar image

updated 2021-04-24 02:49:03 -0500

miura gravatar image

I am using OpenRave for UR5e fastIK calculation. Since I need to load collada file, I am converting the ur5e xacro files in ur_e_description package by following these steps:

  • xacro to urdf: xacro ur5e_robot.urdf.xacro >

  • urdf to collada: rosrun collada_urdf urdf_to_collada ur5e.urdf ur5e.dae

And then I use this file in the OpenRave simulation. The result is like that: image description

The calculated end effector pose looks right, though.

Tee_pose:
position: x: 0.8171999999999516   y: 0.23289999995927044   z: 0.0627999999522314
orientation: x: 0.7071067811865479   y: 0.707106781186547   z: -6.905298555182071e-11   w: 7.266121038185247e-11

I have spent lots of time figuring out why such a thing happens; is it during the conversion from xacro to urdf or the urdf into collada. Then I tried to load the produced collada (ur5e.dae) into moveit_setup_assistant, it loads without any issue: image description.

Interestingly, I can manipulate the robot in OpenRave by setting DOF values. However, I cannot produce any ikmodel since (I suppose) the produced urdf/collada file is broken. When I check the produced urdf (from xacro) I saw some interesting values. For instance for shoulder_pan_joint the DH parameters are like that: image description

Yet the corresponding part of the urdf, there is pi rotation in yaw direction (not pi/2):

<joint name="shoulder_pan_joint" type="revolute">
    <parent link="base_link"/>
    <child link="shoulder_link"/>
    <origin rpy="0 0 3.14159265359" xyz="0 0 0.1625"/>
    <axis xyz="0 0 1"/>
    <limit effort="150.0" lower="-6.28318530718" upper="6.28318530718" velocity="3.14"/>
    <dynamics damping="0.0" friction="0.0"/>
</joint>

Does anyone know why such behaviour occur? What is it about and how to solve it?

edit retag flag offensive close merge delete

Comments

Having same issue, any luck?

utsavrai gravatar image utsavrai  ( 2021-05-18 03:37:50 -0500 )edit

Yes and no, I haven't solved this specific problem but I loaded another urdf file (not directly from Universal Robots ROS package). My guess is that some parametrized values or included xacros are not properly loaded in OpenRAVE, but I am not sure. The working urdf does not contain those complex features.

Gates gravatar image Gates  ( 2021-05-20 01:21:15 -0500 )edit

If you just want to generate IK solver C++ output file then I will suggest to use your generated collada only since it is correct and only throughs warning which are due to some incorrect transpency values set during the conversion.

utsavrai gravatar image utsavrai  ( 2021-05-20 01:47:07 -0500 )edit

No, I also needed to simulate in openrave. Therefore, I changed into a non-parametrized urdf.

Gates gravatar image Gates  ( 2021-05-20 10:00:46 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted
1

answered 2021-05-20 01:54:30 -0500

utsavrai gravatar image

To generate IKFast solver C++ output file use the same generated collada file in following command -

pythonopenrave-config --python-dir/openravepy/_openravepy_/ikfast.py --robot=<myrobot_name>.dae --iktype=transform6d --baselink=1 --eelink=8 --savefile=<ikfast_output_path>

Whereas this results into segmentation fault and to generate the C++ output file regardless the segfault you will have to change the last block of code in ikfast.py file

solvefn=IKFastSolver.GetSolvers()[options.iktype.lower()]
if options.robot is not None:
    try:
        env=openravepy.Environment()
        kinbody=env.ReadRobotXMLFile(options.robot)
        env.Add(kinbody)
        solver = IKFastSolver(kinbody,kinbody)
        solver.maxcasedepth = options.maxcasedepth
        chaintree = solver.generateIkSolver(options.baselink,options.eelink,options.freeindices,solvefn=solvefn)
        code=solver.writeIkSolver(chaintree,lang=options.lang)
    finally:
        openravepy.RaveDestroy()

if len(code) > 0:
    with open(options.savefile,'w') as f:
        f.write(code)

to

solvefn=IKFastSolver.GetSolvers()[options.iktype.lower()]
if options.robot is not None:
    try:
        env=openravepy.Environment()
        kinbody=env.ReadRobotXMLFile(options.robot)
        env.Add(kinbody)
        solver = IKFastSolver(kinbody,kinbody)
        solver.maxcasedepth = options.maxcasedepth
        chaintree = solver.generateIkSolver(options.baselink,options.eelink,options.freeindices,solvefn=solvefn)
        code=solver.writeIkSolver(chaintree,lang=options.lang)
        if len(code) > 0:
            with open(options.savefile,'w') as f:
                f.write(code)
    finally:
        openravepy.RaveDestroy()

this bypasses the segfault and generates the desired ik solver file.

edit flag offensive delete link more

Comments

This is a really nice way around and I will definitely give it a try, thank you. The thing which I couldn't figure out yet is how this will help the OpenRAVE simulation to "fix" the robot view. I assumed that the robot appearance was based on the robot model (*.dae) for so long. However, it looks like the solver was the problem. I couldn't make the connection, honestly.

Gates gravatar image Gates  ( 2021-05-31 08:20:49 -0500 )edit
0

answered 2022-08-12 03:52:02 -0500

billnava gravatar image

updated 2022-08-12 17:11:58 -0500

This is because link transformations in the URDF does not have any effect in the visualization. One solution until this is fixed in the openrave is to use tools like mesh mixer to shift the STL/OBJ files' transformation so that all the link transformations in the URDF are zero. This will help to fix this view problem.

edit flag offensive delete link more

Question Tools

2 followers

Stats

Asked: 2021-04-02 14:00:16 -0500

Seen: 424 times

Last updated: Aug 12 '22