bluerobotics / cockpit

An intuitive and customizable cross-platform ground control station for remote vehicles of all types.
https://blueos.cloud/cockpit/docs
Other
72 stars 22 forks source link

frontend: survey generation ignores concavity #1422

Open ES-Alexander opened 1 month ago

ES-Alexander commented 1 month ago

Current behaviour

Current survey generation generates paths straight through regions outside the survey polygon in concave regions:

Screenshot 2024-10-23 at 1 56 25 AM

Problematically:

  1. Concave regions in a survey polygon would typically be considered as "no fly" zones, so driving straight through them could pose risks/dangers to the vehicle and/or operator
  2. It's unintuitive from a UX standpoint, because if the user wanted that region surveyed they wouldn't have excluded it from the polygon
  3. If the concave region is large, driving through it can substantially increase the survey time and energy usage, which is inefficient (and potentially expensive) for the operator

It's sometimes possible to work around the issue by changing the survey orientation, or creating multiple separate survey polygons if necessary, but there's no feedback to the user that there's a problem other than their own judgement from seeing the path going where they didn't intend it to.

Path generation is also completely cooked if the polygon has self-intersections:

Screenshot 2024-10-23 at 1 52 38 AM

but that's at least not behaviour we expect to support.

Expected or desired behaviour

Ideally valid polygons should generate valid paths, and invalid polygons/paths should provide warnings to the user (e.g. turning red, and potentially asking for extra confirmation before performing generation).

One possible validity check would be to determine whether the path goes outside the polygon borders (perhaps with a warning about reorienting the path or creating multiple polygons instead), although ideally the generation would be designed in such a way that that doesn't happen to start with.

It is likely worth adding a validity check for polygon self-intersection.

Prerequisites

ES-Alexander commented 1 month ago

In case it's relevant / of interest, I was playing with some vaguely related stuff a little while ago, which may indicate some other potential failure cases, generation algorithms, and possible future expansions / improvement ideas :-)

rafaellehmkuhl commented 3 weeks ago

I agree concavity thing is a problem, but I'm curious on how could we handle that. Maybe just warning the user?

ES-Alexander commented 1 week ago

I'm curious on how could we handle that.

This video discusses some potentially viable approaches in terms of algorithms, although I'm sure we can also find others that are intended for similar purposes (including ones extra relevant to ours).

For simple concavity we could also maybe try a few different survey angles to see if any avoid the issue.

Maybe just warning the user?

That definitely seems like a good starting point 👍 Users should be able to see that the path goes outside the polygon beyond just the turns, but it's also possible to check for automatically, and could be used to warn the user to make sure their path is not going somewhere problematic.

FWIW, QGC has the same issue, and I don't believe it provides a warning about it.

QGroundControl survey generation failure for concave polygon
rafaellehmkuhl commented 1 week ago

FWIW, QGC has the same issue, and I don't believe it provides a warning about it.

Yup. That was my reference when I started the survey implementation.

When I saw that they, which has polygon surveys for more than 10 years, didn't solve this problem, I understood it was not worth dealing with on the first PR.

PS: nice video.