MC Geofence violation not easy to resolve

[tops4u]

Describe problem solved by the proposed feature
When a Geofence is violated the Vehicle will enter Hold Mode (if configured accordingly). It is not possible to back out of the violation by reversing the flight path, since the Flight Mode has changed automatically. This is not as most Users will perceive the function "Hold" on Geofence Violation, as all known Consumer Products would allow to reverse the flight path in order to resolve the Geofence violation.
The only resolution option is to switch to a Manual Flight Mode (Stabilized) and reverse. As Geofences sometimes act as maximum Distance keepers, the Drone might not be easy to recognize and therefore Switching to a Manual Mode for not so experienced Pilots who might already be stressed by the sudden Mode Switch, could crash the vehicle.

This is the current behaviour as of PX4 1.9

Describe your preferred solution
Instead of Switching to a different Flight Mode, I would assume that the PosCtl Controller would switch to Position Hold Mode and not allow further progress, as long as the commanded Flight Vector would continue to further violate the Geofence. When Pilot Input Vector points away from the Geofence the PosHold Controller shall allow the movement by switching to velocity control and therefore resolve the Geofence situation.

--> This is IMHO the normal Behaviour of most (Consumer?) Drones.

This is a duplicate of #9789 as it was automatically Closed by the Bot.

[tops4u]

Just to note, by switching from a PosCtl Flight Mode selection to another combination which also enables PosCtl the currenty logic shortly allows the PosCtl Controller to take over. With this, it is possible to violate the Geofence further. In the Example below it was possible to exceed the Geofence by 20m (120m above Start point, despite Geofence ceiling being set to 100m). As I first did not understand what is happening as the Aircraft also performed various uncommanded Yaw Movements (this should be addressed with 1.9.1 though).

Link to log: https://logs.px4.io/plot_app?log=dca11486-c01f-4f20-b364-c8e87852325f

[MaEtUgR]

I think the goal of #12057 was to solve this problem.
JFYI @bresch

[tops4u]

I guess #12057 did not make it into 1.9.0? I',m going to try 1.9.1 then.

[bresch]

I agree that a nicer solution would be to simulate a virtual wall similarly to the "Collision prevention" logic. However, the Geofence logic is currently implemented in Navigator and has only access to the fence geometry and the current position of the vehicle: it's a high level class that return a true/false result.

To have that "virtual wall" behavior, we would need to re-implement the logic in a library used in the FlightTasks that have access to stick inputs. Furthermore, since the geofence can be made from any arbitrary polygon and circle checking for the collision is a smart and efficient way will require some effort.

[tops4u]

I was afraid, that the solution might be somewhat more complicated as soon as it comes to random Geofence Polygons instead of the simple cylindrical Geofence. However I think on the long run in order not to confuse or scare the Pilot, a smoother solution should be found.

How shall we proceed with this?

[bresch]

@tops4u I see a simple solution that could be implemented without changing the architecture: The navigator continuously stores the current position if in the fence, drives back to that last position as soon as the fence is violated and give the control back to the pilot. This is kind of a "Mario Kart" approach and is the easiest minimal change I see to create that virtual wall without moving the whole logic to FlightTask.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.