Agilus support pkgs: moveit shows links 2 and 4 in collision when they really aren't

[gavanderhoorn]

As per subject.

Probably caused by the collision mesh for link_2 being too coarse.

Keeping the 'hole' in link_2 would already be an improvement.

[mat-l]

I recognized the same issue. Using kr6r700sixx.

[gavanderhoorn]

@mat-l: I'd be more surprised if you hadn't ;)

We'll have to update the collision model for link_2 to resolve this.

[BrettHemes]

As a FYI, I just disable collisions between these two links in all of my moveit configs; I believe that the true geometries (along with the controller limits) physically result in a "never in collision" relationship. There are potential package maintenance concerns from doing this but as a quick fix it works perfectly.

[BrettHemes]

By the way, the same issue exists between links 4 and 6 on the r700sixx.

So the "holes" on link_2 AND link_4 are problematic (for all variants?). A quick workaround is to disable them in the srdf either manually or through the moveit config setup assistant but as gavanderhoorn suggested the better fix is to fix the collision meshes so they agree with the actual link geometry.

[BrettHemes]

@gavanderhoorn, do you want to update the issue title to reflect the broader issue scope?

[gavanderhoorn]

I've updated the issue title. It's indeed a problem with more than just the r900sixx.

Disabling the link pair is a work-around.

Using something like v-hacd or gaschler/bounding-mesh to generate better collision meshes has my preference.

[BrettHemes]

I did some work on the issue this morning and made some progress but wanted to get your feedback on the results. I tried both of @gavanderhoorn 's suggestions from above. I had some issues getting the approximate decomposition in the bounding-mesh library to work (see issues there) so I ended up using the v-hacd Blender add-on. I performed decompositions for both the r700 and r900, links 2 and 4 and you can see the results in my fork here (use the revision slider in the commits to see the collision mesh changes.

They aren't perfect, but are a big improvement in accuracy (especially with respect to file size). There are a bunch of settings to tweak that aren't well documented. I managed to get what I think are good results with nice small file sizes (much more and the files sizes start to take off rather quickly).

With the settings turned up all the way you get a really good decomposition at just over 1MB/mesh. This is approaching the original stl model size and doesn't offer much in terms of collision detection speed-up.

Aside: I also updated links 2 and 4 to dae for the r700 and will merge that when convenient.

[BrettHemes]

The author of bounding-mesh replied quickly with a workaround for the issue I was having. If I have time later I will try that again (that lib has a max error parameter that seems to be more meaningful than v-hacd's)

Edit: but I still think ultimately, due to the geometries at play, it will end up being a trade-off between joint motion range and collision mesh file size with this approach.

[BrettHemes]

OK, update! I got the code working from gaschler/bounding-mesh. And the results are really good (better than v-hacd)! I ran the bounding convex decomposition on the links with a variety of voxels settings. I ended up at 2,000,000 which took ~10 minutes per part to run on a nice desktop but gives good results for what we need. The 'hole' in the joints is nicely modeled and the file sizes are on the order of 50 KB (super small, especially compared to the 1+MB meshes in the r900sixx currently).

I have the new meshes in a separate fork BrettHemes/kuka_experimental/kr6_agilus_fixes_gaschler.

Can someone review these? I am comfortable merging at this point based on any feedback.

[cschindlbeck]

Thanks for your effort, i will run the algorithm for the kr10r1100 links respecively and report soon

[cschindlbeck]

So, we generated new collision meshes with Boundingmesh for the KR10R1100, see my fork at 2aeaedd1547dfc18447772f45d70c33bf00afd31

It does seem to work for me, how do you want me to review yours?

[gavanderhoorn]

@cschindlbeck: how are your experiences so far with your new collision meshes? I noticed that you replaced all the collision meshes. Was that intended (ie: did you have a problem with any of the other links, besided 2 and 4)?

[gavanderhoorn]

76 was merged, so for the KR 6 models this should be fixed, but the KR 10 has the same problem, so keeping this open for now.

@cschindlbeck: would you be interested in contributing the link_2 and link_4 meshes you have in your branch? Have you also generated yours with --voxels 2000000?

[cschindlbeck]

@gavanderhoorn
I generated every mesh to be consistent. There was no problem.

I generated mine with the --voxels 2000000 option.

You want me to open a pull request?

[BrettHemes]

You want me to open a pull request?

@cschindlbeck, yes please!

[cschindlbeck]

See 2aeaedd1547dfc18447772f45d70c33bf00afd31

[cschindlbeck]

Oh ok, that is why i got warnings when starting RVIZ haha! I tested the meshes and everything looks good without throwing warnings/erros, thanks for the effort!

[gavanderhoorn]

I believe we rectified this in all Agilus packages.

The collision meshes haven't improved wrt aesthetics, but at least they now represent the visual geometry better.

Please re-open if some model still exhibits the issue described in the OP.