Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copter: pre-arm check warning that fence is enabled and GPS quality bad if arming in non-GPS mode #3220

Closed
Manubarret opened this issue Nov 24, 2015 · 25 comments

Comments

@Manubarret
Copy link

As reported by Nick here: http://diydrones.com/xn/detail/705844:Comment:2099629
ARMING_CHECK = 0 does not override other checks.

I made these tests with ARMING_CHECK=0 and Stabilize mode, with PosHold listed in available flight modes.
No GPS fix, GeoFence enabled: arming impossible
No GPS fix, GeoFence disabled: arming OK

3D fix, 4sats, Geofence disabled : arming OK
3D fix, 4sats, GeoFence enabled: arming impossible: need more satelittes.

Maybe arming check procedure could be a bit more consistent?

@rmackay9
Copy link
Contributor

At the moment, if the circular fence is enabled, we require a good GPS lock in order to take-off even if ARMING_CHECK is zero. If we simply remove that requirement then you can imagine the case where the user takes off flies 300m and then get GPS lock, the home location is set at that 300m distance from home, the user then tries to return to the real take-off location and the fence triggers and RTLs them back to that far-away location.
The obvious solution would be to not enable the fence if the user takes off without GPS lock, but then we run the risk of the user thinking the fence was enabled (because he/she enabled it) but it's not actually functional.
So you can see the solution to this request is not super obvious.

@Manubarret
Copy link
Author

I understand it well. Maybe you could just disable GeoFence if Arming_check is zero? And add a critical message saying that arming check is zero to warn user that it is not recommended.

Regarding normal use, it is a good point to check GPS fix. I do not see any good reason why an user would disable Arming_Check and want to use GeoFence. In my case, I just wanted to run motors, and I find this parameter useful to override everything for testing things, rather than finding all possible parameters that have an effect on Arming_Check. I believe that behavior on 3.2.1 was good for this.

@R-Lefebvre
Copy link
Contributor

I think it would be better if we keep the current logic, but simply add an arming failure reason "PreArm: Geofence enabled but no GPS fix" or something like that. Then require the user to disable the geofence to arm.

I'd rather simply communicate the problem to cover the edge case such as yours, rather than remove protections from everybody else.

@har28
Copy link

har28 commented Nov 26, 2015

Hallo guys i use pixhawk with neo M8N gps module on a tarot X6 frame. I would like to ask you why i can't arm while i have enable the geofence? This happened once yesterday while pixhawk had gps 3d fix hdop 1.4 and 9 sats inside my house. A day before yesterday i could arm normally while geofence was enabled. One more thing to mention is that yesterday was a stormy day and my gps 3d fix was established after 20 minutes and before dissamble the geofence there was a message on my hud screen gps horiz error. Please any information it will be very helpful thanks in advance.

@lvale
Copy link
Member

lvale commented Nov 26, 2015

@har28
Atmospheric propagation might be the reason, better check your location kindex.
https://play.google.com/store/apps/details?id=info.kijk.Kmonitor

https://en.wikipedia.org/wiki/K-index

screen shot 2015-11-26 at 14 24 29

@har28
Copy link

har28 commented Nov 26, 2015

Thank you Ivale i will check it out for sure

@rmackay9
Copy link
Contributor

@har28, this question is quiet off topic and really belongs in the support forum. In any case, it's likely because you're inside and the GPS quality isn't good. We check not only the hdop and num sats but also the vehicle's apparently velocity and a couple of other things. The specific reason it's failing should be reported on the HUD I think.

@rmackay9 rmackay9 changed the title Copter: ARMING_CHECK vs GEOFENCE Copter: pre-arm check warning that fence is enabled and GPS quality bad if arming in non-GPS mode Nov 27, 2015
@rmackay9
Copy link
Contributor

I've updated the subject line more in line with what I think Rob has suggested.

By the way, to test the motors there's a built in motor test. It's on the wiki somewhere.. and appears in the MP's optional hardware section (an odd place perhaps).

@MR444
Copy link

MR444 commented Dec 20, 2016

Hi, I still cannot disable arming_check when GeoFence is active in copter 3.4. I would like to be able to take off without GPS fix but would like to have geofence anyway, so that zero point of fence is where it has first GPS fix when I am already in the air. Is it not possible?

Could you at least add this information to ardupilot page? http://ardupilot.org/copter/docs/prearm_safety_check.html

@rmackay9
Copy link
Contributor

@MR444,
It's technically possible but I'm worried about people losing their copters if we allowed this. Some people would think that the vehicle is protected by the fence when it's actually not (at least at the beginning of the flight). Also there's the issue that if the user is using a polygon fence, the vehicle might immediately RTL as soon as it gets GPS lock (if the vehicle is outside the polygon). Anyway, it's open source so people are welcome to change the code themselves and I'll entertain pull-requests from other developers if they want to take on this item.

@R-Lefebvre
Copy link
Contributor

Please don't allow this.

Currently, enabling Fence is the only way to prevent copters from taking off in a non-GPS mode without a GPS lock. This function is mandatory for many users to protect themselves. I'm still seeing instances of "professionals" taking off in Stabilize or Alt Hold without a GPS lock, and then complaining that the system won't enter Auto.

@lvale
Copy link
Member

lvale commented Dec 30, 2016

@rmackay9 I agree with @R-Lefebvre

@R-Lefebvre
Copy link
Contributor

If there was another alternative, then I have no problem with this change. But as it is now, this is a safety-critical hack to protect people from improper operation.

@MR444
Copy link

MR444 commented Dec 30, 2016

I don´t need geo fence. I know airspence around me and I can see flight distance and altitude on OSD. But I would like to use Geofence as something like a fly-away protection. For that it does not matter if I get GPS lock when I am already in the air. So something like an fly away protection would be nice.

@peterbarker
Copy link
Contributor

@R-Lefebvre What's the correct, non-hacky fix? We should create an issue specifically for that, referencing this issue. I would imagine it is another arming check bit, "ARMING_CHECK_3DFIX" or similar.

@R-Lefebvre
Copy link
Contributor

@peterbarker Yes, some sort of Pre-Arm Check would be good.

Though I'm not sure the actual Pre-Arm Check should be used. The existing Pre-Arm Checks tend to be safety critical items, and we encourage all users to leave this set to '1' which means all checks enabled.

Some people will want GPS enforcement, some will not. So this would result in many people having to change their ARMING_CHECKS value to something other than 1, leading to confusion.

IMO, there should be another parameter which would be opt-in prearm checks, which would be in addition to the existing opt-out safety pre-arm checks.

Make sense?

All this being said, I think this has been discussed before and declined for some reason. So will see what Randy says.

@rmackay9
Copy link
Contributor

rmackay9 commented Jan 2, 2017

I think we've covered a few different items in the discussion above but in any case, I agree with what Rob has suggested:

  • improve the pre-arm check messages to clarify why we think we need GPS lock (because fence is enabled or something else)
  • improve the pre-arm check messages to clarify that it's not technically GPS lock we need but rather a good position estimate
  • add a pre-arm check for users that want to always have a good position before taking off even in manual modes like AltHold and Stabilize.

The solution for this particular issue is actually the 2nd one listed above.

@peterbarker
Copy link
Contributor

I believe 2 of the three points in this PR have been covered.

The proposed pre-arm check would seem to solve the third.

@shortstheory
Copy link

shortstheory commented Mar 15, 2018

Hey guys, I'll be taking this issue as well.

Is there still some contention for which method should be implemented?

@rmackay9
Copy link
Contributor

@shortstheory, great!!

@peterbarker
Copy link
Contributor

* improve the pre-arm check messages to clarify why we think we need GPS lock (because fence is enabled or something else)

These have been clarified.

* improve the pre-arm check messages to clarify that it's not technically GPS lock we need but rather a good position estimate

That was done.

* add a pre-arm check for users that want to always have a good position before taking off even in manual modes like AltHold and Stabilize.

I haven't seen a compelling argument as to why enabling a circular fence isn't sufficient for this purpose.

I propose we close this issue - we don't need extra code to solve this AFAICS.

@shortstheory
Copy link

I have lost track of this issue after all these years, and I don't think I'll be working on this soon either!

@rmackay9
Copy link
Contributor

ok, thanks @shortstheory for the feedback.

@hooperdev
Copy link

This is incredibly annoying with AirSim. I don't care if my copter crashes, just warn me if it is likely to.

@Bimby
Copy link

Bimby commented Oct 24, 2021

How about a parm called I_am_flying_indoors_skip_the_GPS_GEO_FENCE_checks ?? I am working on a project where the drone only flies indoors (warehouse) and doesn't have a GPS sensor connected anyway. So I can never get a GPS lock.

For safety in this situation, you can have it land immediately if it does get a GPS lock - because it isn't allowed outside.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants