I changed the parameters so that it only generates one raster to better show the issue.

What is the behavior that you are expecting from this tool path planner? Are you wanting circular paths that traverse around the perimeter of the cylinder at different heights, or do you want the same type of coverage pattern shown above, just in a different orientation?

I want circular paths that traverse around the perimeter. The piece is a cylinder, so trajectories shown above actually go through the inside of the piece.

noether in general was not necessarily designed to handle closed or watertight shapes like this, so I'm not surprised you're seeing this error. Most of the planners are written with the assumption that you're working with a single open flat-ish surface. The reason the paths come out like this is due to the RasterOrganizationModifier which assumes that each line in the tool path segment has a relatively straight line direction (as in a regular planar raster) and attempts to sort the points by their projected distance along that average direction. This is not the case for the cylinder where each tool path segment in the "raster" is actually a circle, hence the behavior you see.

To fix this, we would need to create a new tool path modifier which sorts the points in a tool path segment in a circular fashion based on some criteria (e.g., choose points greedily by distance to previous point, etc.). Then you could apply this new modifier behind the plane slice planner in a tool path planner pipeline to produce the results you are looking for

@marip8 AFAIK the plane_slicer_rastering_generator_demo.launch does not use the RasterOrganizationModifier (see this section of code). That is why I was wondering were this sorting behaviour could be coming from.

AFAIK the plane_slicer_rastering_generator_demo.launch does not use the RasterOrganizationModifier

It actually does. If you dig down deep enough:

• plane_slicer_rastering_generator_demo.launch launches a tool path planning server
  • The tool path planner server creates an instance of a tool_path_planner::PlaneSlicerRasterGenerator
    • tool_path_planner::PlaneSliceRasterGenerator is now just a wrapper for noether::PlaneSliceRasterPlanner until we deprecate and remove it
      • noether::PlaneSliceRasterPlanner inherits from noether::RasterPlanner
        • noether::RasterPlanner forces the output tool path to be run through a noether::RasterOrganizationModifier

This example is a bit convoluted, but that's why the reorganization is happening. Ultimately our goal is to replace tool_path_planner and some other packages with noether_tpp and simplify the examples, but we haven't had time to progress that far yet

Okay, thanks I got a bit lost there. Now I can at least try to modify it myself to suit my needs.

Let me know if you need any more clarification or help implementing my suggestion from above if you end up creating a new tool path modifier. I would be happy to review and accept it as a contribution to the repository if don't mind making it open-source

Just commenting out the RasterOrganizationModifier seems to work fine for my use case.