Geofence Altitude Premature Trigger and Overshoot Loop

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!

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.


  • 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.

1 Like

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

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?

Hi there,

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.

I will post a link to this in Geofence issues · Issue #16679 · PX4/PX4-Autopilot · GitHub

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.

1 Like

Woudl you be able to join this weeks dev call on at UTC? I would be happy to bring this up so that we can discuss this.

Or, maybe if you are inclined so, you can create a PR?

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.

Oh no, sorry! Forgot to put date and time. It will be on August 10th, 3pm UTC. The schedule is here: Weekly Dev Call | PX4 User Guide

This will be our meeting note:

FYI, it seems like the “Position * interval” math error you mentioned doesn’t exist in the codebase:

Maybe you had it modified by mistake? Could you check the commit history and check who changed it?

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!

Kind Regards,