Copter: Set home on Arming vs in air without prior 3D lock

[jason4short]

When flying before 3d Lock is achieved, it is possible to get 3D lock in the air. The GPS position is most likely not accurate enough to store and could be miles away from the actual position.

If the user RTL's or enters failsafe the copter will fly away.

The user should receive notification home is not set on the GCS and the craft should loiter instead of RTL if home is not set by arming. Any other reasonable alternative fallback approaches are welcome in the comments.

The goal here is to be defensive against user error and not blaming the user.
Jason

[rmackay9]

So a possible solution to the bad home position might be:
If in the air when we achieve GPS lock, put the position through more rigorous checks before setting it as the home position. This could include ensuring there are no GPS glitches for X consecutive seconds (maybe 3 to 5 seconds).

Our default behaviour when we can't enter RTL for whatever reason is to go into LAND mode. Many people do not like LAND mode especially without a few seconds of warning because it gives them less time to recover. So I like the Loiter idea (and I think man others would too) but we would need to switch to LAND eventually at least in cases of a radio failsafe induced RTL.

[jason4short]

Mostly I see a new IRIS user flying without GPS lock, getting lock with a bad location, and somehow triggering failsafe which looks then looks like a flyaway since home is not at the launch point.

Does setting home via Mavlink work?

On Mar 17, 2014, at 6:22 PM, Randy Mackay notifications@github.com wrote:

So a possible solution to the bad home position might be:
If in the air when we achieve GPS lock, put the position through more rigorous checks before setting it as the home position. This could include ensuring there are no GPS glitches for X consecutive seconds (maybe 3 to 5 seconds).

Our default behaviour when we can't enter RTL for whatever reason is to go into LAND mode. Many people do not like LAND mode especially without a few seconds of warning because it gives them less time to recover. So I like the Loiter idea (and I think man others would too) but we would need to switch to LAND eventually at least in cases of a radio failsafe induced RTL.

—
Reply to this email directly or view it on GitHub.

[rmackay9]

Setting home via Mavlink only partially works. It sets the home position (which is now owned by the AHRS lib) but it's missing the call to inertial nav to reset it's home position. RTL uses the hardcoded (0,0,0) position as home so it will still fly to the original GPS location instead of the updated home position.

[BangorSkis]

I agree that getting a 3D Lock mid-air could rapidly turn into a bad day for someone.

I've never explicitly tried to take off / arm before 3D Lock, so I'm not entirely sure of how likely this scenario is. http://copter.ardupilot.com/wiki/prearm_safety_check/ states that GPS Lock is required for arming in Loiter, although I could swear I've tried to arm indoors in Stabilize on the bench and failed the "Bad GPS Pos" pre-arm check at some point along the way......

Could making GPS Lock and a good HDOP a requirement to arm, across all modes by default, address the concern? (This could be disabled via ARMING_CHECK if desired by the more advanced user?)

[jason4short]

I think it happens a LOT. And it will happen a lot more now that quads are going more mainstream.
Arming without GPS access is pretty important. You may want to fly indoors. Or sometimes I fly around until I get lock, then return home to re-arm and set a proper home location.
I wonder how many times this has happened to users who now think the AP is flakey?
Jason

On Mar 17, 2014, at 8:40 PM, Ian Ray notifications@github.com wrote:

I agree that getting a 3D Lock mid-air could rapidly turn into a bad day for someone.

I've never explicitly tried to take off / arm before 3D Lock, so I'm not entirely sure of how likely this scenario is. http://copter.ardupilot.com/wiki/prearm_safety_check/ states that GPS Lock is required for arming in Loiter, although I could swear I've tried to arm indoors in Stabilize on the bench and failed the "Bad GPS Pos" pre-arm check at some point along the way......

Could making GPS Lock and a good HDOP a requirement to arm, across all modes by default, address the concern? (This could be disabled via ARMING_CHECK if desired by the more advanced user?)

—
Reply to this email directly or view it on GitHub.

[billbonney]

I think you could come up with lots of options when lock is acquired in the air, with thing like fixed RTL and rally points. But this is adding complexity than you are thinking of avoiding.

The keep it simple solution is that you cannot take off until you have a quality GPS lock to be able to set home. (in any mode)

I do think that loiter then followed by Land/RTL is a less abrupt failsafe behaviour for new customers. (This could be controlled by a variable time parameter for others who wish to have more immediacy)

Bill

On Mar 17, 2014, at 20:43 , jason4short notifications@github.com wrote:

I think it happens a LOT. And it will happen a lot more now that quads are going more mainstream.
Arming without GPS access is pretty important. You may want to fly indoors. Or sometimes I fly around until I get lock, then return home to re-arm and set a proper home location.
I wonder how many times this has happened to users who now think the AP is flakey?
Jason

On Mar 17, 2014, at 8:40 PM, Ian Ray notifications@github.com wrote:

I agree that getting a 3D Lock mid-air could rapidly turn into a bad day for someone.

I've never explicitly tried to take off / arm before 3D Lock, so I'm not entirely sure of how likely this scenario is. http://copter.ardupilot.com/wiki/prearm_safety_check/ states that GPS Lock is required for arming in Loiter, although I could swear I've tried to arm indoors in Stabilize on the bench and failed the "Bad GPS Pos" pre-arm check at some point along the way......

Could making GPS Lock and a good HDOP a requirement to arm, across all modes by default, address the concern? (This could be disabled via ARMING_CHECK if desired by the more advanced user?)

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

[britdavis]

Seems reasonable to me to:

• home is not set if arming w/o GPS lock
• no GPS modes are available during flight if no home is set

[rmackay9]

Here's a video of a DJI user who has problems because he took off without a GPS lock and then could not (or was afraid to) engage RTL. https://www.youtube.com/watch?v=FCHPR031J9o

I'm just pointing out that by making it easier for users to get into the air, we're removing some of the failsafes that will keep them out of trouble or more incidents like this will occur.

[jason4short]

If he had a proper GCS he would have had complete control of the vehicle. He could of set Home via the GCS and commanded his $15K drone without an ounce of worry. Shame on him!

[roque-canales]

Let me give you my view of the problem and fix. This only concerns me, and I like to share with you to try to make arducopter safer.

I think that the best when arming without gps lock, is to disable RTL and always switch to:
OR Land mode but only inertial positioning, without using GPS.
OR Alt-hold.

We must not forget that if we started without GPS is that we may be in indor or in a difficult area, invoke RTL will cause I think a crash or fly away.

Also GPS Lock is not good, the best is to use only HDOP.

Arducopter take GPS positions even if GPS HDOP GOOD is not reached, this is a problem.

whether for AHRS or EKF, do not take into account the data of GPS sensor if HDOP GOOD no reach set accuracy.

[squilter]

Maybe the following: The Drone will only arm if
A) Good GPS lock
-OR-
B) In "Indoor Mode" (Which doesn't exist yet. See #702 and #1152 )

[jschall]

Is fixing this issue still a 3.2 target?

[R-Lefebvre]

Isn't this solved with the GPS HDOP Pre-Arm check?

It seems to me the only way this problem could occur now is if the pre-arm check is turned off?

One problem that we can't solve in the program is that, if they were to take off and fly without GPS lock, and then the lock comes in the air, even if the GPS position indication is perfect, there's a good chance that the Home location that gets set is not actually home, but... just wherever the Copter happens to be at that moment. So it will still RTL to somewhere other than the real launch point. In most cases, this will be fine, but not always. The only robust solution, is to prevent flying before GPS lock is achieved.

Since this is a GPS aided flight system, and many of our users cannot fly without GPS assistance, it doesn't make sense to allow them to take off before they have achieved a good GPS lock?

[magicrub]

Since we know if the home is set or not would it be very hard to not set
the home if already in flight and then not allow any GPS related modes
while home is not set.
On Mar 18, 2015 10:06 AM, "Robert Lefebvre" notifications@github.com
wrote:

Isn't this solved with the GPS HDOP Pre-Arm check?

It seems to me the only way this problem could occur now is if the pre-arm
check is turned off?

One problem that we can't solve in the program is that, if they were to
take off and fly without GPS lock, and then the lock comes in the air, even
if the GPS position indication is perfect, there's a good chance that the
Home location that gets set is not actually home, but... just wherever the
Copter happens to be at that moment. So it will still RTL to somewhere
other than the real launch point. In most cases, this will be fine, but not
always. The only robust solution, is to prevent flying before GPS lock is
achieved.

Since this is a GPS aided flight system, and many of our users cannot fly
without GPS assistance, it doesn't make sense to allow them to take off
before they have achieved a good GPS lock?

—
Reply to this email directly or view it on GitHub
#910 (comment).

[rmackay9]

pushed to AC3.4.
AC3.3 has a few improvements which largely resolve this:

1. the EKF is responsible for determining when the location is good before home is set so it's less likely that it will be a long way off.
2. the GCS can set the home location so it could warn the user

What's missing is:
3. the autopilot will still return and land at whatever location was captured as home (during flight). This should be changed so it doesn't land (unless it really must because of low battery).
4. the autopilot needs to send a message to the GCS when the origin is set so it knows it's a good time to ask the user to set home.

[Hands0n]

Randy,
In the case of 4. would/could the notification appear on the Telemetry so any FPV fliers get the warning message also? I think this would be a good thing.

[furynick]

Recently encountered this problem in 3.3.3 (see #3782).
Here is my thought about this issue.

There's two situation to take into account, first the RTL behaviour, second the GPS flight modes.

1. The RTL should only be available if a correct home position was recorded, it could be at arming when hdop is safe or manually by GCS. In this case the home should only be recorder when in Loiter/Pos Hold and stick centered.
2. GPS flight modes should only be available when hdop is safe, if a lock is acquired after takeoff this didn't invalidate all GPS features.

When FENCE_ENABLE=1 and FENCE_TYPE=2 or 3 the PreArm safety check prevent this issue.

I'm sorry to be unable to submit a patch, I haven't enough skill and time to do it.

[rmackay9]

Item 4 from above is now resolved, "4. the autopilot needs to send a message to the GCS when the origin is set so it knows it's a good time to ask the user to set home."
In Copter-3.4's commands.cpp file you can see these two lines which send the home to the ground station.

// send new home location to GCS
GCS_MAVLINK::send_home_all(loc);

So perhaps this issue is now mostly resolved, but pushing to AC3.5 in any case.

[Naterater]

The home point should only be set if the HDOP is better than a number (maybe 1.5?) HDOP is a good indicator of horizontal accuracy, unlike the first position reading.

[auturgy]

HDOP doesn’t mean as much as you might think, but as Randy states above this is now linked to the ekf setting an origin, and reported to the user.