Set home position already with less accuracy

[MaEtUgR]

Describe problem solved by the proposed feature
Users want to deploy the drone as quick as possible.
For a lot of use cases the GPS initialization is a bottleneck.
The autopilot requires high GPS accuracy for reliable operation based on GPS data.
The home position is set before takeoff but does not require as much accuracy.

People have to either wait for high accuracy GPS checks to pass for a home position or have no home position if they take off in altitude mode or based on optical flow.

Describe your preferred solution
Set home position already earlier from valid but less accurate global position data and correct it while still on the ground.

@bresch already tried to achieve this with minimal changes but it failed with certain conditions relying on home position to check if accurate GPS for navigation is available. @dagar raised interest for this topic in yesterdays dev call (See estimation section of https://discuss.px4.io/t/px4-dev-call-september-23-2020/18608)

Additional context
We should dig out the patch of the first attempt and possibly with the help of @dagar fix the conditions such that it works.

[dagar]

Cases that immediately come to mind.

• raw GPS only (no valid local or global position estimate yet)
• local position estimate valid, but not global
• global position estimate available, but still not within commander HOME eph/epv requirements

If depends on exactly what we're trying to accomplish, but I could imagine a solution where we use whatever's available and then update incrementally.

• set HOME immediately from raw GPS (respecting COM_HOME_H_T)
  • set HOME x, y, z to NAN or a local valid flag
• if disarmed HOME is able to update if any of these inputs change/improve
• if you takeoff with HOME set from raw GPS then local position becomes valid in air we need to compute HOME local position and update
• handle local position xy and z resets

Related side note, we currently spend something like an extra 5-10 seconds at bootup from the gps driver scanning different protocols and baud rates. We could "latch" these parameters the first time it successfully finds something. This also avoids the gps driver continuously allocating/freeing each GpsDriver it scans.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.