Inconsistent generated toolpaths using surface_raster_planner_demo.launch

[dave992]

Based on my understanding of Noether, it should generate a toolpath in a deterministic way. Therefore recalculating the toolpath should always return the same result.

When running the surface_raster_planner_demo.launch the results vary, here are some screenshots of what I mean:

The 'main' toolpaths seem to be recalculated correctly, but some additional clusters seem to appear/disappear on different runs.

• The top left image shows an additional group of (purple) markers on the edge on the bottom middle part of the mesh. Furthermore, an additional path is generated left from the hole in the mesh, between the top and bottom paths (blue/purple markers) . This additional middle path is not perpendicular to the surface.
• The top right image shows again the additional group of (purple) markers on the edge on the bottom middle part of the mesh, but this time in a different orientation than the previous image. Additionally, there is group of markers on the bottom right corner of the mesh, which can be hard to see as the markers are not that big and also colored red (as the mesh).
• The bottom left image shows the generated toolpath as I would expect.
• The bottom right image shows a single large arrow. The mesh itself and the expected toolpaths are visible at the base of the arrow but this can be somewhat hard to see as a result of the scale difference.

Using different meshes also results in similar behavior.

To reproduce (It may take several tries to produce different results):

1. roslaunch noether_examples surface_raster_planner_demo.launch
2. Close window or kill process
3. Repeat

This was run on Ubuntu 18.04/ROS Melodic with VTK 7.1.1 and PCL 1.9.1.

[gavanderhoorn]

@dave992: could you perhaps also specify what version of Noether you are seeing this with (ie: commit hash)?

[dave992]

Both PC's I encountered this issue on were using version 47d74720252bc724e540e9819be61bba2718758f.

[gavanderhoorn]

@Levi-Armstrong: is this something you've ran into perhaps?

We're willing to debug this ourselves, just looking to avoid spending effort in case it's a known issue.

[Levi-Armstrong]

@jrgnicho @DavidMerzJr @drchrislewis you all probably have used it the most. Do you have any insights into what they are experiencing? My first thoughts are it should be, at least for the first raster, but then it does some offsetting to create equal surface distance lines which may not be deterministic.

[gavanderhoorn]

We were also thinking it may be using some uninitialised memory somewhere. Especially the screenshot in the bottom-right made me suspicious.

[mpowelson]

We were also thinking it may be using some uninitialised memory somewhere. Especially the screenshot in the bottom-right made me suspicious.

I remember thinking the same thing wrid19 when we had some unit tests that would pass on one run and fail the next if run repeatedly. Probably unrelated, but here is the issue