search

ros-industrial / noether

Tool path planning and surface segmenter
124 stars 45 forks source link

Fix plane slice planner #136

Closed marip8 closed 3 years ago

marip8 commented 3 years ago

This PR corrects the calculation of the cutting plane for the plane slice planner. This was partially addressed in #118, but I don't think I looked at the effect of the rotation offset parameter. I think this issue is not very obvious if the smallest principal axis of the mesh is closely aligned to the Z-axis, but for meshes with arbitrary coordinate frames it becomes a large issue.

The solution implemented in this PR is to use principal component analysis (rather than VTK's objected oriented bounding box method) to get the direction of the cutting and rotation planes. These vectors are then used directly to cut the mesh, rather than transforming the mesh such that it's centroid is at the origin, cutting, then transforming the points back.

Test case: mesh with arbitrary origin

mesh_with_arbitrary_origin

Current State

Rotation = 0

image

Rotation = 1.75

image

Solution

Rotation = 0

image

Rotation = 1.75

image

marip8 commented 3 years ago

@DavidMerzJr can you test this with one of your meshes to see if it's correct?

Levi-Armstrong commented 3 years ago

It looks good to me. The only concern I have, is I vaguely remember @Jmeyer1292 ran into accuracy issues with PCA because it was using floats instead of doubles, and not sure if it was addressed. Does this sound familiar?

marip8 commented 3 years ago

I don't remember any issues with PCA in the past. Errors caused by floats vs. doubles seems a little fishy; the math probably breaks down when all 2 or more principal axes are the same size (i.e. covariance matrix is not full rank), but that seems like a fairly unlikely edge case. Maybe doubles help with this situation by giving more precision, but I wouldn't expect to encounter issues for 99+% of uses cases

Levi-Armstrong commented 3 years ago

I found a reference here. The issue is these algorithms take a large number of floats and reduce it to a small set of data. The loss in precision due to multiplying two float becomes significant and was causing significant error in the fitting of the plane. This same issue would be present in PCA if they use floats internally for the math. I will look to see if they are using floats or doubles.

Levi-Armstrong commented 3 years ago

It looks like they use floats internally. Not much can be done as part of this PR but with large point clouds (dense mesh) we have seen errors of around 5 degrees.

marip8 commented 3 years ago

@Levi-Armstrong I wrote a simple unit test to find out if floating point precision is really a concern for PCA:

Method:

Results: The root mean square difference between float and double PCA eigenvectors was ~1.0e-6 and the per value difference was less than 1.0e-5 for all tests.

I don't think floating point precision is really an issue for PCA, especially for the scale of meshes we will be working with. I think the referenced issue might have been caused by some other type of calculation, especially since that reference isn't even performing PCA

marip8 commented 3 years ago

This PR was tested and verified by @colin-lewis-19