search

gizatt / pydrake_kuka

MIT License
5 stars 5 forks source link

Question about URDF #5

Closed rickyduh closed 5 years ago

rickyduh commented 5 years ago

I am playing around with the kuka iiwa simulation and just swapping a UR10 urdf for the kuka-iiwa urdf. I currently have the following code.

tree = RigidBodyTree(FindResource("UR/urdf/ur10_robot.urdf"))

Assemble IK constraints

iiwa_urdf_path = os.path.join(pydrake.getDrakePath(), "manipulation", "models", "iiwa_description", "urdf", "iiwa14_polytope_collision.urdf") UR_urdf_path = FindResource("UR/urdf/ur10_robot.urdf")

rbt = RigidBodyTree() table_top_z_in_world = 0.736 + 0.057 / 2 robot_base_frame = RigidBodyFrame("robot_base_frame", rbt.world(), [0.0, 0, table_top_z_in_world], [0, 0, 0]) AddModelInstanceFromUrdfFile(UR_urdf_path, FloatingBaseType.kFixed, robot_base_frame, rbt)

print iiwa_urdf_path print UR_urdf_path

Whenever I use the UR urdf path, I get the following error:

RuntimeError: Error parsing file "/home/me/underactuated/src/UR/urdf/./meshes/ur10/collision/base.stl.obj" : WARN: Material file [ /home/me/src/UR/urdf/./meshes/ur10/collision/base.stl.obj.mtl ] not found. WARN: Failed to load material file(s). Use default material.

Do you know more about this?

rickyduh commented 5 years ago

Interestingly the error only comes up when I use FloatingBaseType.kFixed. See below:

File "UR_rigid_body.py", line 42, in AddModelInstanceFromUrdfFile(UR_urdf_path, FloatingBaseType.kFixed, robot_base_frame, rbt)

but if I take that line out of the code, it is able to compute the rigid body tree. However, when I add this line in

tree = RigidBodyTree(FindResource("UR/urdf/ur10_robot.urdf"), FloatingBaseType.kFixed)

whereby I specify that the rigid body tree should be fixed, it has the same issues.

rickyduh commented 5 years ago

Actually, I fixed it! There was a line at the top of all my obj files that caused this

gizatt commented 5 years ago

Glad to hear! There's some finer details and assumptions about where the materials attached to each .obj file are supposed to live that aren't super intuitive. Would you mind writing out what the solution was in a little more detail? Might be useful for reference in the future.

rickyduh commented 5 years ago

Of course!

So for some reason, all of my .obj files had this at the top: mtllib base.stl.obj.mtl

Perhaps, this line generates by default during conversion of an stl to an obj file. In order to get it to run, I had to comment out that section using vim.