Hi, we’ve come across a bug which results in a number of issues with the altitude limit in the Geofence.
In summary, an altitude breach violation can trigger unexpectedly, causing the drone to ascend to an inappropriate set-point. This breach violation will continuously trigger, causing the drone to climb even higher, unless you are aware of it’s behaviour. Below is a more in-depth explanation of trigger cases.
This can be very jarring for the remote pilot and I could easily see this leading to an incident either by uncontrolled drone behaviour or by the remote pilot panicking.
I’ve got the appropriate logs and am more than happy to share them if desired.
Any help here would be greatly appreciated!
Summary
When approaching the Geofence height, PX4 triggers the breach violation significantly prematurely (~5-10m below parameter). This will continuously re-trigger whilst setting incorrect HOLD (LOITER) altitudes.
Detailed
If Geofence is set (for example) to 30m, a breach violation actually triggers at ~24m.
Range sensor (downwards facing LIDAR) set to provide altitude and shows 24m.
The drone enters LOITER mode but the set-point is several metres above the drone; an unexpected and non-RP controlled ascension occurs.
If the RP gives any stick input without switching modes, the breach violation re-triggers with a higher LOITER set-point, causing the drone to climb further.
If the RP changes to POSITION mode and fails to return to the permitted Geofence zone in one motion (i.e if segmented consecutive steps are attempted), the breach violation re-triggers with a higher LOITER set-point, causing the drone to climb further.
If the RP initiates RTL, the breach violation re-triggers. Re-initiation of RTL overwrites the breach violation and is carried out successfully.
If the drone continues to climb (intentionally or by compiled breach violations), an altitude will be reached where the breach violation is no longer triggered.
Example, when Geofence = 30m, at altitudes above 35m the RP can fly uninterrupted.
Returning below 35m will re-trigger the breach violation.
On the image below, you can see LOITER continuously being triggered which creates a set-point higher than the drone causing it to ascend further. You can also see that this only occurs within a ~5-10m band of altitude around the Geofence ceiling. Here, the Geofence altitude was set to 5m, but the LOITER action was triggered when the Distance Sensor (downward facing LIDAR) read 0.5m.
Further inspection of the PX4 firmware shows that the vertical braking distance is calculated incorrectly. Whilst the drone is stationary, the braking distance is output as ~5m.
This is what’s leading to both the Geofence being triggered prematurely (as it influences the prediction as to whether or not the drone will move outside the fence on its current path) and the LOITER altitude setpoint being incorrect.
For reference, it’s in geofence_breach_avoidance.cpp
GeofenceBreachAvoidance::computeVerticalBrakingDistanceMultirotor()
EDIT: I believe I’ve come to the conclusion that there was a double addition of altitude and that the vertical braking distance instead wants to be calculated with (the first multiplication was an addition):
predictor.getCurrentPosition() * (GEOFENCE_CHECK_INTERVAL_US / 1e6f) * _velocity_hor_abs;
What are your thoughts?
any updates on that issue? Please post that issue also at Issues · PX4/PX4-Autopilot · GitHub to get more attention.
I had the same behaviour leading to a premature activation of the geofence.
Hey sorry I completely missed your reply, yes we went and modified the behaviour ourselves so that the geofence is triggered based on the UAV’s current position, not its predicted position (current position + calculated braking distance).
This leads to the UAV still overshooting slightly past the geofence, but we find it’s a more intuitive, robust and consistent interpretation of the geofence which doesn’t catch you off-guard and also eliminates the retriggering where it continues to climb higher.
Happy to talk you through our implementation in more detail if it helps, or so you can do something similar yourself.
Hi, I realise this is a bit stale now, but I think I have a fairly comprehensive understanding of the issue and I’m happy to discuss it in more detail if it helps any of the dev team implement an official fix.
We’ve implemented our own workaround in the meantime though so should be okay for us for now.
Thanks!
I’d be more than happy to depending on when it is, what time and date would it be?
Sorry, tried to reply by email a couple days ago without realising it was from a noreply account.
Yeah I realised that wasn’t actually an issue but just never updated this post again! Glad you spotted it as well.
I won’t be able to make this week’s dev call as we’ve got quite a lot on at the moment, but would be happy to bring this up when I’m next able to join if that still helps (although feel free to cover the topic without me if you want to crack on with it). Apologies!
