Non-uniform padding of non-convex, long meshes

[ana-GT]

I noticed that when applying a padding factor to non-convex, long-in-one dimension meshes, such as the table pictured below, the padding applied to the vertices is not uniform, since it is applied along the vector joining the mesh center and the vertex being padded. Any advice on how to make the padding more accurate for this kind of meshes?

Test case example: I have a robot arm on top of the table depicted below and want to add padding of 10 cm to the table to avoid the robot hand to collide during pick and place, meaning that I'd expect to have the table's top, for instance, "grow up" 10 cm (besides "growing in the X and Y directions as well).

In reality, when I apply padding to the table, what I get is that the table top grows in X ~9cm, whereas in Y and Z it grows only ~3cm.

[pbeeson]

If padding is set like you say above, this also means object like boxes that are open on top will get bigger with padding, but the inside walls pf the bin/box will also get further from the center, meaning that padding a non-convex polygon could result in a mesh that doesn't even intersect the original mesh.

I always assumed "padding" was like a "dilate" operation that fattened the mesh, so the box walls would just fatten up.

[pbeeson]

Looking at shapes.cpp, you are correct. Padding is in fact essentially doing what I always thought/knew scaling was doing, in that is pushes all vertices away from the centroid. It seems like what you want is to find the normal for the centroid of the triangles in the mesh and then move the vertices so that the triangular centroids move by the padding amount along that normal.

[bmagyar]

Agree and it has been like this since the days of arm_navigation. I think may of us would appreciate a fix for this.
@ana-GT would you be up for submitting a pull request if you figure out a way to solve this?

[pbeeson]

@ana-GT and I discussed offline. She’s working on a method similar to Blender’s shrink/fatten, which is what this should be. Instead the current is equivalent to Blender’s push/pull which is less useful.

…

On Thu, Feb 1, 2018 at 3:35 AM Bence Magyar ***@***.***> wrote: Agree and it has been like this since the days of arm_navigation. I think may of us would appreciate a fix for this. @ana-GT <https://github.com/ana-gt> would you be up for submitting a pull request if you figure out a way to solve this? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADrfxnq5Q1mLFMPCClbc0cCl5bM74_Fyks5tQYVHgaJpZM4RzD0b> .

[ana-GT]

Hi @bmagyar ! As @pbeeson said, an easy way to improve the padding effect would be to apply it along the vertices normals (Blender's approach). We created a fork and are experimenting a bit. I'll let you know soon if we get some good results.

PS.- So far, the first thing to improve is the vertex normal calculation procedure: geometric_shapes calculates vertices normals as the average of the triangle normals, whereas for padding purposes, it seems that a weighted average is more appropriate in order to get uniform, regular normals.

[ana-GT]

@bmagyar : Seems we got some good results. In our fork we tested a couple of fixes for the padding effect:

1. Changed the computeVertexNormals(). The original version performed an average of the faces' normals per each vertex. We changed this to be a weighted average using the vertices' angles. There is more than one way to calculate the weights, but we chose this one as it is easy to implement and seems a common choice in the community.
2. Change the padding function: The original version uses a "radial" padding approach, where the object grows along a line joining the centroid of the object and the vertex being padded. We choose to grow the vertex along its normal, which produces - we think - results more akin to what we'd expect (and results in which the padding is more uniform across the whole surface).

Below are some images showing some comparison tests results (padding ranging from 5 or 10 cm). In each image the leftmost mesh is the original mesh, the one at the middle is the padded version using the original geometric_shapes' padding function and the rightmost mesh is the padded mesh obtained using our modified padding + normal vertex computation.

In case you want to try out the results on your own, you can clone our fork and use the test_scaling.launch file. Just replace the mesh argument with any local mesh you want to test. The result will be 3 meshes (which will be stored in the geometric_shapes/launch folder) such as the ones shown in the images below (original_mesh, padded_mesh and new_padded_mesh)

d985b238.png)

[ana-GT]

PS.- A couple of comments about the padding update:

1. I tested the padded meshes' output it with our collision-free software. There does not seem to be any issues. The only oddity I noticed was a ROS_INFO message from FCL: "eigen: too many iterations in Jacobi transform".
2. Our padding version produces a more realistic effect (i.e. the object actually "fattens"); however, it still has limitations: For our tabletop example, a padding of 10 cm produces an actual padding on the top surface of ~7cm. This is better than the original ~3cm but still not quite 10 cm.
3. Our padding approach has a more uniform effect across the mesh's surface. However, for objects with complex geometry (i.e. the bin in the previous comment's image), you can see that the mesh appearance changes with respect to the original. In fact, due to the fattening, some faces/edges in the padded mesh might intersect (i.e. walls growing into one another at a corner edge). This so far does not seem to be a problem for collision detection (as far as I have tested) but only a aesthetic one.

I am not sending a pull request yet since I'd like to hear your comments on the 3 points mentioned above. Also, our fork would need a bit of cleanup first (erase the testing code/launch file, erase the old padding function kept for testing comparison purposes).

[BryceStevenWilley]

@ana-GT Is there any chance you're willing to open a PR for this? Point 1 seems to be related to some bug, but we can try to fix that before merging. I'd be okay with Point 2, given it's still an improvement, and point 3 should be okay as well (maybe some mesh cleanup can be done later if desired). Overall I see this as a net positive.

[peci1]

Anybody interested in this issue might want to chime in to #127 where we're seeking a better new definition of padding.