Geofence issues

[garfieldG]

Describe the bug Hi,

While playing with the geofence on sitl I encountered few issues regarding it :

1. Altitude - while on geofence failsafe trigger hold mode I tried to change the altitude to be above the allowed geofence max altitude. The first time trying to do so it warned me about the altitude geofence and didn't go as high as I wanted it to, but then when I tried to give a new altitude command to go above the allowed max altitude it did reach my desired altitude, although it shouldn't.
2. I tried to breach the geofence and in geofence, none mode fly to a waypoint after the max geofence radius, later I switched back to geofence hold mode, and the mc flow back to a waypoint inside the allowed radius, as it should. The problem was when I did it all the same when the altitude of the mc was above the allowed max altitude, the stayed in it's waypoint outside the allowed radius and didn't fly back to the allowed radius.
3. Although the geofence mode was none, trying to upload a mission with a waypoint above the max radius failed due to geofence violation in one of the mission waypoints.

To Reproduce Steps to reproduce the behavior: first issue :

1. Change geofence mode to hold, the max altitude to 50m (can be something else) and the max radius to 30m (can be something else).
2. Change altitude to 60m. It should stop ascending a little above 50m and warn about geofence violation.
3. Change altitude to 60m. It should get to 60m while warning about geofence violation second issue :
4. Change geofence mode to none.
5. Fly to a waypoint outside the max radius.
6. Switch the geofence mode to hold.
7. see the error.

third issue :

1. change geofence mode to none.
2. try to upload a mission with one of its waypoints outside the max radius.
3. mission check will fail due to geofence violation in one of the waypoints.

Expected behavior first issue : mc shouldn't go above the allowed altitude. second issue : mc should return to the allowed radius. third issue : mission should be accepted.

Drone (please complete the following information):

• px4 master.
• gzebo (iris model, empty word).
• qgc version v4.1.1.

[garfieldG]

@bresch Hi, maybe you can help

[garfieldG]

anything new?

[RomanBapst]

@garfieldG Hi, the fix for the vertical geofence is this one here: https://github.com/PX4/PX4-Autopilot/pull/17566

Some checks did not pass so I rebased on master and pushed gain, should be merged soon. Can you please retest with that one?

[RomanBapst]

@garfieldG

Change geofence mode to none. Fly to a waypoint outside the max radius. Switch the geofence mode to hold. see the error.

I don't think this is an error, it's just not supported this way. If you have geofence deactivated and you fly outside of the geofence you cannot expect the system to bring you back into the geofence. In some cases this might actually be dangerous and not expected. If you want to use a geofence, just have it enabled always.

[garfieldG]

I think it's an error as long you can change the gf action, otherwise the action should be set once and after that you shouldn't be able to change it

[junwoo091400]

Recent report on Geofence not working properly from here:

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.

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/standard-vtol-in-mc-mode-geofence-ceiling-violation-28-meters-below-configured-ceiling/29638/1