See the description at RobotLocomotion/drake#19935.

This will probably become moot as of #44, but logging here for tracking anyway.

"... noticed that the spheres are offset from the main box primitive ..."

See RobotLocomotion/drake#18839 for details.

Transcribed from RobotLocomotion/drake#10704:

Follow-up from: RobotLocomotion/drake#10702

We should update the models to use an estimation from the mesh (if possible).

This may involve:

• Simplifying / separating the inertial estimation from the current //manipulation/util:meshlab_to_sdf binary (e.g. just give it an OBJ, and it'll give you an <inertial/> with no frame adjustment)
• Ensuring that the center of mass is accurate given the inertial adjustments.

In #48, we added a ur3e symlink to smooth over the transition. Around 2024-05-01, we can & should remove it again.

I noticed that the iiwa description GLTF files don't match the appearance of the real robots. I don't think this was the case for the old OBJ models (I might misremember).
I attached a meshcat screenshot of iiwa_description/sdf/iiwa7_no_collision.sdf and a real image. The real photo has bad lighting, but the obvious color differences are visible (some links are orange but should be gray). I can take a better photo if desirable.

I'd like to create and maintain tetrahedral meshes in VTK files for YCB objects.

1. Decimate the fine triangle meshes in existing Obj files to make temporary coarser triangle meshes.
2. Create tetrahedral meshes from coarse triangle meshes.
3. Fix tetrahedral meshes to remove tetrahedral elements with zero signed-distance gradients. (related Drake PR 19232)
4. Save into VTK files for compliant-hydroelastic objects and deformable objects.
5. Use them in Drake's new hydroelastic tutorials for non-convex compliant-hydroelastic meshes (TODO: companion Drake PR).

Per RobotLocomotion/drake#20935, we want nearly all of our models to use gltf (not obj) for visual meshes.

Note that proximity meshes (if any?) should not be converted to gltf.

All gltfs with png file should also have ktx2 textures available (gltf-used but not gltf-required).

This ticket will track the conversion process:

• allegro hand #62
• #58
• dishes #62
  • Waiting on #60
• franka_description #62
  • Converted, but they can be replaced by Anzu's as we see fit. If we do so, confirm with legal.
• #36
• jaco_description #62
• manipulation_station and realsense2_description #62
• pr2_description #62
  • This model is not used by Drake. The only testing required is just to run model_visualizer.
• skydio_2 #62
  • Just add the gltf for now (and switch this repo's urdf to cite it). Don't delete the obj yet -- we have a deprecated URDF file in Drake that will continue to refer to the obj until 2024-05-01.
• tri_homecart
• ur_description #62
  • Instead of converting the obj, should we just use the Anzu gltfs for this? (If yes, also need to run by TRI legal first.)
• veggies #62
  • Waiting on #60
  • Converted locally. Consider replacing it with Anzu gltfs.
• wsg_50_description #62
• #45

As part of our automated testing of this repository, we should check that all models can be loaded by the pydrake.multibody.parsing.Parser from latest stable release of Drake.

Essentially, that means copying the parse_test.py from Drake into here.

Hello I would like to use some of your models that are used inside the Drake project. The Drake project uses your newest commit, could you possibly tag that commit? I am unable to use un-tagged code.
Thanks,
Jack

I'm looking at the 010_potted_meat_can_textured model, where I converted the SDF into a URDF.

Files for reproduction

• 010_potted_meat_can_textured.zip

Problem

• Drake: When I view the URDF in the Drake visualizer, the visual and collision meshes are aligned.

  unzip 010_potted_meat_can_textured.zip -d files
  python3 -m pydrake.visualization.model_visualizer files/010_potted_meat_can_textured.urdf

  

  In Drake, visual and collision geometries are aligned

• Other tools: When using other open source tools to visualize the URDF, such as trimesh and a web URDF viewer, the two are not aligned:

  • To reproduce, drag all unzipped files into the web URDF viewer.
  

  In non-drake tools, visual and collision geometries are mis-aligned

See #33 (review) for details, at "FYI the model is flawed":

We stack a number of the mounting plates. However, we have a gap at the bottom of the stack, and an extra plate at the top that is actually intersecting the robot arm's base. The proximity geometry for this box (represented as a single box) is in the correct place.Looking at master, it's clear that's a defect that predates this PR.

The model for the mount stack does not lie on the Wz = 0 plane, it floats above it. Without a keypad, I'm somewhat hampered in my ability to use blender, but it appears to be floating about 0.15 cm above the plane. If the geometry were to be moved (either in the .bin file and moved, or by adding a translation to the node in the .gltf file), I believe the stack would be corrected.

We (will*) have some *.xacro files in this repository.

We ❤️ our users, so we won't make them figure out how to download and run Xacro. Instead, we'll commit the generated output files into our git repository, so that all of our models can be easily and immediately used downstream.

However, this presents a maintenance burden for our developers: anytime we change the *.xacro source files, we need to remember to refresh the generated outputs to keep them in sync. This can be easy to forget.

To prevent mistakes, we should have a GitHub Actions CI rule that cross-checks that all of the generated files are correctly up-to-date. If the check fails, it should refuse to allow the pull request to merge.

To help developers correct such mistakes, ideally we should also make it an easy process (single command) to refresh everything locally, so they can commit that and re-push.