Open GriffinMack opened 4 years ago
What is the expected behavior when a GeoFence violation occurs?
Isn't this something defined at the PX4 level? I guess it's a bit like a failsafe: there are different possible behaviors, and you should be able to set the desired one as a PX4 param... But I never used that so I'm not sure.
I would be happy to update this with my working implementation.
That would be amazing, yes!
Yes, you possibly have your GF_ACTION set to "warning" in which case you should get a statustext but no actual helpful behaviour. The config is here: http://docs.px4.io/master/en/config/safety.html#geofence-failsafe
Note, I have played with this a bit and found that Return mode action works reliably, but I think some of the others maybe not so much on all vehicle type.
@hamishwillee Awesome, thanks! I’ll have to play around with some of those settings through QGC.
I don’t see the ability to set this behavior through MavSDK, do you know if this has been implemented?
@GriffinMack Yes, but not obviously. The geofence plugin supports uploading of the geofence and the action is set using parameters.
You might argue that the action is part of the Geofence behaviour, and should be part of the geofence plugin. The problem here is that the Geofence action is not part of the mavlink standard, and therefore to be compliant with the standard, it should not be part of the plugin - otherwise we'd be adding a flight-stack dependency.
@JonasVautherin @julianoes Is there anything we can do to help with this situation? Short term perhaps add a note in the Geofence plugin docs that the actual geofence action depends on the flight stack?
Long term, perhaps add some standard actions - return, hold, flight stack default etc etc? @julianoes You OK with me trying to add something for that into MAVLink?
We could set the param using the geofence plugin. That's what I would have done before MAVSDK was considered to only implement the "standard" and not PX4 specific things. :man_shrugging:
@julianoes Not my call, but I'd prefer to inject the standard behaviour into the standard if at all possible.
Would it make sense to follow the approach of MAV_CMD_NAV_FENCE_RETURN_POINT (which also isn't defined in MAVSDK and may not be implemented in PX4)?
ie define MAV_CMD_NAV_FENCE_ACTION
with param value that takes an enum with values as for GF_ACTION. This would be used if defined in the mission. Otherwise the system should use whatever it's defaults are (also use defaults if the selected option is invalid).
If this makes sense to you I'll propose it on MAVLink.
I don't find a fence return point intuitive. And to me a fence action is not something I want to think about when putting up the fence, or uploading a mission. To me it's configuration of the vehicle, and thus maybe not something to be specced by MAVLink.
@julianoes Yes-ish
the "ish" is because even though GF action is a vehicle setting, it is one that the GCS UI is going to want to expose, so would be great if we could standardise. As you know that means either making it something that is defined in a definition that the GCS can render without having to understand what the settings are (a'la camera information file), or standardise the setting through some other means - a command to set GF actions (say).
I will raise it in the mavlink call.
So is there any way to implement geofence with mavsdk as the mavsdk-python geofence example gives error to import point and polygon
@21shrinit: Did you use the last example here? @GriffinMack fixed the example 6 days ago, maybe that's what you need?
Yes I checked it geofence gets uploaded now . Now i have a new problem of configuring the behaviour of drone after geofence violation . I have opened a new issue here https://github.com/mavlink/MAVSDK-Python/issues/258
@21shrinit ok so we can close this?
Question: What is the expected behavior when a GeoFence violation occurs? On my px4_sitl simulation, I can see that my uploaded geofence was violated, but the drone continues past the fence.
Also, the example for GeoFence looks like it needs updating (Point and Polygon cannot be found using the current include). I would be happy to update this with my working implementation.