What is lateral FOV in yaml file?

[PhilipAmadasun]

What does the lateral feild of view mean exactly in the coverage_planner.yaml file? WHat is the unit? is it in meters? does it mean sensing range? Or more the area around the robot whcih it can sense at any given time? for instance if the sensing range is 0.84m, then lateral FOV is pi* 0.84^2(if 360 view)? what are the units of the lateral FOV value?

[PhilipAmadasun]

I would also like to know why sometimes pressing Enter to publish polygon does nothing alot of the time. I get no warning in teminal, just nothing happens when I try to publish polygon. I already set polygon from rviz to True, in the yaml file.

[rikba]

Hey, the FOV alpha is in radians.

The distance between two sweeps calculates as

The height z is given by the polygon input.

If you want to give the distance between sweeps directly, you can select the line sensor model and set the distance lateral_footprint directly.
https://github.com/ethz-asl/polygon_coverage_planning/blob/master/polygon_coverage_ros/cfg/coverage_planner.yaml#L10
https://github.com/ethz-asl/polygon_coverage_planning/blob/master/polygon_coverage_ros/cfg/coverage_planner.yaml#L12

[rikba]

I would also like to know why sometimes pressing Enter to publish polygon does nothing alot of the time. I get no warning in teminal, just nothing happens when I try to publish polygon. I already set polygon from rviz to True, in the yaml file.

But the path appears after a while? If the polygon is very complicated it takes some time to pre-compute the decomposition and possible paths. I took this issue to a new conversation #83

[PhilipAmadasun]

@rikba This doesn't fully answer my question, so I'll expound. I will assume the parts of the image I circled are the sensors?.

If this is the case, then I need to know how exactly the sensor FOV affects the path planner. Before that, let me mae sure I know what the "sweep" is in this context. Is the sweep the red lines(cell decompositions) in the image below or the green lines(The path trajectory)?

If the "sweep" is the green line, how does the sensor FOV affect the green line spacing? I have an image below to illustrate the top view I have in my head.

[PhilipAmadasun]

think basically, The alpha on the lateral feild of view, what is the area of projection when it hits the ground(the projection being the red circle in the last image)

I would also like to know how to make the delta zero, as in if I wish to not have the two rays intersect(the rays from the illustration you provided).

[rikba]

Yes, you are correct. Green is the sweep. The spacing between two sweeps is a function of the distance to the surface and FOV. For example, a large field of view will cause your sweeps to be far apart. A large distance will also cause your sweeps to be far apart.

If you don't want overlap you can set lateral_overlap to zero.

But also note you do not have to use this "FOV" sensor model. You can also directly define the distance between the sweeps by setting

sensor_model_type: 0 # [0: Line, 1: Frustum]
lateral_overlap: 0.0
lateral_footprint: 33.0 # Only for line sensor model.

For 33.0m distance between the sweeps.

[rikba]

Also note: This coverage planner is purely 2D. There is no way to have an adaptive sweep distance, e.g., with varying terrain.

[PhilipAmadasun]

Does the eng goal matter in you algorithm? What I mean is, if I choose a specific start location for two trials, but choose two different end goals for the two respective trials for the same map, does the coverage time remain the same?

…

On Fri, Nov 25, 2022 at 7:46 AM Rik Baehnemann ***@***.***> wrote: Also note: This coverage planner is purely 2D. There is no way to have an adaptive sweep distance, e.g., with varying terrain. — Reply to this email directly, view it on GitHub <#82 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AND3KDTRD2ROFNUWL74VKJLWKDNOJANCNFSM6AAAAAARTNQBHA> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[rikba]

No, it can be different. The coverage path algorithm will (most likely) end the last sweep close to where your goal point is set.

[PhilipAmadasun]

@rikba DO all boustrophedon methods require setting goal positions?

[rikba]

No, you can also compute the path without start and goal.

In this implementation you would have to change the way the solver is called.
At the moment it adds the additional start and goal to the optimization problem. You could probably code it to skip this step.

See
https://github.com/ethz-asl/polygon_coverage_planning/blob/master/polygon_coverage_ros/include/polygon_coverage_ros/coverage_planner.h#L151
https://github.com/ethz-asl/polygon_coverage_planning/blob/master/polygon_coverage_planners/src/planners/polygon_stripmap_planner.cc#L79
https://github.com/ethz-asl/polygon_coverage_planning/blob/master/polygon_coverage_planners/src/graphs/sweep_plan_graph.cc#L517-L521

[PhilipAmadasun]

I have tested several start and goal positions on the saem map and the coverage times aren't far apart. I'll just use average coverage time I think.

…

On Tue, Dec 6, 2022 at 3:54 AM Rik Baehnemann ***@***.***> wrote: No, you can also compute the path without start and goal. In this implementation you would have to change the way the solver is called. At the moment it adds the additional start and goal to the optimization problem. You could probably code it to skip this step. See https://github.com/ethz-asl/polygon_coverage_planning/blob/master/polygon_coverage_ros/include/polygon_coverage_ros/coverage_planner.h#L151 https://github.com/ethz-asl/polygon_coverage_planning/blob/master/polygon_coverage_planners/src/planners/polygon_stripmap_planner.cc#L79 https://github.com/ethz-asl/polygon_coverage_planning/blob/master/polygon_coverage_planners/src/graphs/sweep_plan_graph.cc#L517-L521 — Reply to this email directly, view it on GitHub <#82 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AND3KDXOF7EQ222MZHLBQUTWL4SP3ANCNFSM6AAAAAARTNQBHA> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[GigabyteZX1]

No, you can also compute the path without start and goal.

In this implementation you would have to change the way the solver is called. At the moment it adds the additional start and goal to the optimization problem. You could probably code it to skip this step.

See https://github.com/ethz-asl/polygon_coverage_planning/blob/master/polygon_coverage_ros/include/polygon_coverage_ros/coverage_planner.h#L151 https://github.com/ethz-asl/polygon_coverage_planning/blob/master/polygon_coverage_planners/src/planners/polygon_stripmap_planner.cc#L79 https://github.com/ethz-asl/polygon_coverage_planning/blob/master/polygon_coverage_planners/src/graphs/sweep_plan_graph.cc#L517-L521

Hey, if possible can you please let me know what specific changes should i make for removing this start and end goal dependecy?