Closed srsidd closed 2 weeks ago
I think your assessment is correct. Some additional context: the PlaneSliceRasterPlanner
class existed prior to the refactor of this repository. In the previous state, the cut direction was hard-coded to always be perpendicular to the longest principal axis, so the approach of estimating the number of planes using the PCA max extent made sense. It also technically works in the current implementation, but it can be overly conservative as you noted.
When we introduced the concepts of the DirectionGenerator
and OriginGenerator
during the refactor, we didn't do a particularly thorough job of porting this planner to use those concepts efficiently. You'll notice the origin generator is also completely ignored in the current implementation. As such, I think the plane slice planner needs a few changes to fully support all of the features provided by the architecture refactor:
RasterPlanner
base class (or possibly the DirectionGenerator
) for generating rasters bidirectionally (i.e., in the direction provided by the DirectionGenerator
and the negation of that vector)
PlaneSliceRasterPlanner
currently hacks this by offsetting the start position from the centroid by half of the max extent.I also don't think we're using VTK very efficiently in the current implementation of this planner, but it would be a separate effort to try to improve that
Thanks for the response @marip8 , I can look into some of these changes you mentioned but it will take me a little bit to get to.
One question that comes up right away is regarding the origin generator - How does this work? I'm assuming I should be able to get the mesh bounds from the vtkSmartPointer<vtkPolyData>& mesh_data_
object. But how does the origin get defined with respect to the mesh? Are we assuming a frame of reference of some sort?
But how does the origin get defined with respect to the mesh? Are we assuming a frame of reference of some sort?
The frame of reference is the mesh frame. The interface for the origin generator is defined here. The idea is that given only a mesh, the user decides where the rasters should start relative to the mesh origin. Our implementations currently include creating the origin at:
Closing; addressed by #255, #257. Feel free to re-open if this does not solve this issue fully
I'm following the implementation for the planar raster planner and it looks like PCA is used to find the longest vector of the mesh, and the
cut_direction
is then to create rasters evenly spaced by theline_spacing_
parameter.I have a use case where this does not seem right. The mesh I'm using is a rectangle, and I want the segments generated along the longest edge like this -![image](https://github.com/ros-industrial/noether/assets/10639113/649a7513-e4dd-4af5-b3a1-b1af540a54d4)
The cut direction is being specified with a
FixedDirectionGenerator
. Going over the code, we generate amax_extent
from the length of the principle axes. However, this seems incorrect, as this would generate a vector along X-axis (From the above pic), but the cut_direction is specifying that we generate raster segments along the Y-axis.Tracing the code further, it seems like we loop through the number of planes and make cuts at
start_loc * i * line_spacing
. Considering the shape of this mesh, even a small line_spacing covers the entire mesh with a few raster segments. Why are we looping through the longest edge and trying to generate cuts / planes at locations that are outside the mesh? If I reduce myline_spacing_
, the number of planes go up drastically, compared to the number of segments that cover the mesh.To me, this seems like a bug and we should not be creating planes by longest PCA vector, but the direction specified by the
cut_direction
.Would appreciate any feedback / advice on if my thought process is right here.