Open dave992 opened 4 years ago
@dave992: could you perhaps also specify what version of Noether you are seeing this with (ie: commit hash)?
Both PC's I encountered this issue on were using version 47d74720252bc724e540e9819be61bba2718758f.
@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.
@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.
We were also thinking it may be using some uninitialised memory somewhere. Especially the screenshot in the bottom-right made me suspicious.
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
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.
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.
Using different meshes also results in similar behavior.
To reproduce (It may take several tries to produce different results):
roslaunch noether_examples surface_raster_planner_demo.launch
This was run on Ubuntu 18.04/ROS Melodic with VTK 7.1.1 and PCL 1.9.1.