Planning of Loops F2c V2 about fields2cover HOT 8 CLOSED

We realized that making the maximum curvature and its diff smaller remove many of the loops. So basically if a loop is detected, we compute the same turn with smaller curv and diff curv. Constants are values that worked fine for our setting. It would be awesome to have a better solution than this

from fields2cover.

No I think the PR doesn't need reversion, just refinement. I think the PR still works in many cases, and is better than what it was before.

from fields2cover.

Hi @vinnnyr, PR merged.

from fields2cover.

@Gonzalo-Mier Can you explain how that heurisitc for removing loops works?

Is there anything special about the contants used here?

    CC00_Dubins_State_Space ss(
        robot.getMaxCurv() / (1+0.05*n),
        robot.getMaxDiffCurv() / (1+0.2*n),
        discretization,
        true);

I am finding that I am still getting loops in certain situations, even with this patch merged in. I am having trouble tracking down if it's the heuristic, the max number of iterations, or the loop detection itself.

from fields2cover.

@Gonzalo-Mier Maybe I am mistaken, but I actually think we want to make the max diff larger every iteration of this loop.

Loops are caused by overconstraining the problem, but making the max allowed curvature diff smaller every iteration is adding more constraint. So I believe that we actually want

   CC00_Dubins_State_Space ss(
        robot.getMaxCurv() / (1+0.05*n),
        robot.getMaxDiffCurv() * (1+0.2*n),
        discretization,
        true);

Maybe in your case, the reduction of max curvature overpowered the affect of changing the max diff so you haven't seen this issue yet.

Do you agree?

from fields2cover.

Hi @vinnnyr,
As mention in the PR, the max sharpness is a constrain because the sharpness should not be higher than that. In cases where sharpness is not a constrain, we could use Dubins instead assuming that max sharpness is infinite.

from fields2cover.

Ok, good point. I see what you are saying. For applications in which the sharpness bound needs to absolutely respected then yes my proposal would be a bad change. I will think about this some more to see if there is something we can do to meet both use cases or figure out why I am seeing more loops than usual even with the original change merged in.

from fields2cover.

Probably because the routes require middle points to travel through the headlands, which create those loops. I have tried to search a good solution but couldn't find one yet.

Do you think I need to revert the PR then?

from fields2cover.