# urdf to collada for OpenRave does not work

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:

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: .

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:

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

<joint name="shoulder_pan_joint" type="revolute">
<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 close merge delete

Having same issue, any luck?

( 2021-05-18 03:37:50 -0600 )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.

( 2021-05-20 01:21:15 -0600 )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.

( 2021-05-20 01:47:07 -0600 )edit

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

( 2021-05-20 10:00:46 -0600 )edit

Sort by » oldest newest most voted

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()
solver = IKFastSolver(kinbody,kinbody)
solver.maxcasedepth = options.maxcasedepth
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()
solver = IKFastSolver(kinbody,kinbody)
solver.maxcasedepth = options.maxcasedepth
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.

more

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.

( 2021-05-31 08:20:49 -0600 )edit