Do really all autonomous modes require Global Position?

I’m currently working on a drone that is flying indoors only using optical flow in addition to the onboard sensors. Because of this I only have local position information, which is enough for position mode.

Recently I stumbled across a section in the docs about Vision and MoCap which explains how to get global position when only local position is available. There it says that all autonomous modes of PX4 would require global position. Now from my flight tests so far I know that I can use at least Takeoff and Land mode, which both belong to the autonomous flight modes. On the other hand, Hold mode doesn’t seem to work, which I found out when testing the RC loss failsafe, where my drone landed immediately.
Furthermore, the docs say Land mode requires global position as well, but so far I was able to use it, at least during failsafe situations. Or is that an edge case?

And what’s about the other autonomous flight modes? I saw that not all pages specifically mention that global position is required, sometimes they just say that GPS is required.

Apples and oranges. Indoors Px4 is using an ESTIMATE of its position based on ONE geographic point. The EKF uses this estimate along with accelerometer data compass heading, and optical flow data to determine where it is in 3D space. Position mode is opertional because the aircraft is drifting due to motor imbalance, air frame imbalance, and wind currents. Autonomus flight is totally different because the aircraft is in flight. A GPS is required to provide the EKF with real time position data for NAVIGATION.

Thanks, but I know about all this already. Maybe I have to phrase it a little differently too.

Description for Land Mode: This mode requires a valid global position estimate (from GPS or inferred from a local position).
Description for Takeoff Mode: This mode requires a good position estimate (e.g. from GPS).

Both are autonomous modes, but only one specifically mentions the need for a global position estimate. From my test flights I know that I can use the Takeoff Mode, despite the global position being invalid the whole time.
Land Mode definitely works as well in case of a failsafe event. Hold Mode on the other hand does not work, despite being a part of the failsafe routine.

I’m just wondering if these are exceptions or just edge cases and if there are more special cases.

1 Like

OK, so the original text " (from GPS or inferred from a local position)." was added following a discussion on how to have missions when you only have a local position. I then queried “the experts” to check if the same rule applied for all the other auto modes since I have always been told that all auto modes need a global position estimate.

So the fact it is missing from Takeoff is an omission - I meant to add the text and I must have missed it.

You shouldn’t be able to arm if you have position, unless you are directly commanding takeoff in the PX4 shell say. Is that correct @sfuhrer - you must have a global position to arm and takeoff in an auto mode ? What about hold mode? What happens if you try to hold when you have no position?

1 Like

@hamishwillee Thanks for clearing that up. So far I haven’t tried to arm in Takeoff mode directly, but I can try that soon and see what I get, if that helps.

I’d say Hold mode definitely requires a global position. At least during failsafe the hold time (e.g. set by COM_FAIL_ACT_T) is skipped. This can also be verified using the failsafe state machine.
Regarding this, I’m still wondering if Land mode will activate when I actively switch to this mode. During failsafe the Land mode definitely gets used.

If you could test takeoff that would be great. I’m having trouble forcing the simulator to fail GPS [Bug] System Failure Injection (gps) not working · Issue #22296 · PX4/PX4-Autopilot · GitHub

Today I finally had some time to do a quick test.
Flight Log: https://review.px4.io/plot_app?log=68cc690b-ef94-4f75-af11-9dbc0c94eebe

First I tried to arm in Takeoff mode directly, which was denied (switch to a manual mode first). After that I switched to position mode, armed my drone and then switched to Takeoff mode. The drone took off as expected. During steady hover I switched back to position mode and then after a short time to Land mode. As you can see in the plots, it all worked as expected. The position defiations occur because I was flying with a safety rope attached to it.

So it seems like at least Takeoff and Land can be used without a global position. But in order to use Takeoff, I need to arm while in a manual mode.

Did you try with the latest of the main branch? If not I recommend you to do so. GNSS denied flying is not something that I expect to work flawlessly out of the box on any PX4 release, and when raising issues it’s always best to be based on the latest development branch.
Specifically for the “Takeoff not possible” case of yours: it sounds like something I fixed with Navigator: remove _can_loiter_at_sp and _need_takeoff by sfuhrer · Pull Request #20908 · PX4/PX4-Autopilot · GitHub.

PS you can simulate flying without GNSS in SITL: make px4_sitl_default gazebo_iris_opt_flow I recommend that for logic checks.

Yes, I did the tests with recent main branches. The test from my last response is based on a main branch from 1st November.
Regarding the Takeoff, I can just not arm my drone while having Takeoff mode selected, which is correct according to the docs. When I arm in Position mode and then switch to Takeoff, everything works fine.
If I get it right, the PR you linked is primarily or only handling takeoffs related to missions, which I don’t use.

The only thing I’m trying to get my head around is the thing with landing. After my initial post I read the docs again carefully. It says that during failsafe, Land Mode only requires altitude information. So this is clear to me now.
However, during my last test I was able to use Land mode without a failsafe condition and without having a valid global position. According to the docs this shouldn’t be possible.

Can you link the place in the docs where that’s mentioned? Land mode is an autonomous mode, and as such it needs a valid position estimate.
The mode that doesn’t require position is called Descend mode (which is the default failsafe mode for when you lose position estimation in autonomous modes).

It’s listed in the “Note” box at the top: Land Mode (Multicopter) | PX4 User Guide (main)

In a failsafe the mode only requires altitude (typically a barometer is built into the flight controller).

There it also mentions that Land mode normally requires a valid global position.

@sfuhrer So that’s “in a failsafe”. I would expect that to be true - since you need to be able to land safely without position if you have to - right?

W.r.t. failsafes and takeoffs my understanding is that arming checks reflect the current mode, so you can always switch to a mode but you can’t then arm. So for takeoff you should be able to switch to the mode that doesn’t require position and then switch to takeoff.

This is a change w.r.t. previous versions, where you couldn’t switch to the mode if you didn’t have the requirements to use it.

But I am not sure what happens if you are armed and you takeoff without position. It might failsafe, but Failsafe State Machine Simulation | PX4 User Guide (main) seems to indicate it won’t

It won’t allow you to arm if a mode requirement isn’t met.

The default behavior for losing the position estimate in any auto mode is to failsafe to Descend mode, where you then indeed only need a baro.
I would remove that line from the docs, I don’t think it’s helpful. Update land.md - remove unhelpful reference to failsafe by sfuhrer · Pull Request #2864 · PX4/PX4-user_guide · GitHub

1 Like

@sfuhrer So when I fly without GPS and switch to Land mode using the flight mode switch, does it automatically switch to descend mode instead?

I think it even prevents you from changing the mode to any mode that requires GPS. But if you would be in Land mode and you lose GPS, then you activate the failsafe (Descend).

That’s the thing, it doesn’t prevent me from doing so, in the case of Land mode. I only use optical flow (Ark Flow module), thus have no global position information, which is also confirmed by the global_position_invalid flag. But I am still able to actively switch to Land mode using the flight mode switch. That’s mainly where the initial question originated from.
Here is a flight log to confirm this: https://review.px4.io/plot_app?log=68cc690b-ef94-4f75-af11-9dbc0c94eebe

Yeah because you have a valid local position, that’s enough for Land mode.

That’s then probably the main confusion of our discussion: Land mode only requires local position: https://github.com/PX4/PX4-Autopilot/blob/44d1003f8e4d1c1ed1d8c7a3d6f8f623b43a8fe4/src/modules/commander/ModeUtil/mode_requirements.cpp#L137-L142
The same for Takeoff.
Let’s adapt the docs.

1 Like

Okay, thanks for the confirmation. This was indeed the reason for my confusion. The file you linked is also really helpful.

If I see it correctly, then Orbit mode also doesn’t require global position? (Docs say it is required)

Besides all that, from my point of view it would make sense to update the individual doc pages, to express the requirements in terms of global and local position, to make it consistent. Some just say that GPS is reuired, which in same cases can mean either of both.

Correct, Orbit also doesn’t require it.

PR for docs changes: Local vs global position requirements by sfuhrer · Pull Request #2872 · PX4/PX4-user_guide · GitHub

1 Like

@sfuhrer Would it be more correct to say that the “all autonomous modes require a valid position estimate (either local or global)” (except on failsafe)?

The inference of the current changes is that you require local position. But my understanding from this is that either global or local position will do right?

So it is more that for autonomous modes:

  • if you lose your position estimate, local or global, you’ll failsafe, possibly landing in descend.
  • You can only switch into a mode that requires a position estimate if you have a position estimate.

It is not clear to me if we should be differentiating global/local at all.