PLEASE NOTE: - I’ve posted a reply below with an update. I’d mistakenly left RTL_SPEED=5 from a previous test - my copter was possibly performing RTL so slowly I couldn’t tell it was doing it.
Today I neglected to allow enough time for my copter to identify “home” before arming and flying a mission. The result was that the last mission command, RTL, did not function. And manually commanding RTL did not work either.
As far as I could tell from the docs, there isn’t a way to specify a pre-arm requirement that “home” be identified before arming. I usually check this from the Mavlink messages reported on YAAPU - today, I forgot to do this.
Digging into this I think I discovered a discrepancy between the docs and how Mission Planner defines the values for the parameter “arming_check”. I had it set to “1” - for all checks. The docs say “0” is the setting for all checks.
Could someone please verify this, and help me offer this as a documentation correction if it is indeed wrong?
Also - if there is a way to require that “home” is identified before arming - I’d appreciate the help in learning how.
I discovered that RTL_SPEED was set to 5 cm/sec from when I had been testing Smart RTL in tight spaces - so it’s possible that my copter was in fact performing a RTL - just so slowly that I couldn’t tell.
I’d still like to know if there is some sort of pre-arm check for having “home” identified - and if it’s something that’s automatic, or something to configure.
It is easy to leave the ALL bit set and wonder why your other settings are not taking effect.
The way to ensure a good home position before arming and launching is to set:
FENCE_ACTION,3
FENCE_ALT_MAX,50
FENCE_ENABLE,1
FENCE_RADIUS,100
FENCE_TYPE,3
and adjust altitude and radius to suit your local laws or sanity.
I know I’m trying your patience - I appreciate your dedication to supporting me.
I see now that the Mission Planner screen I attached in my post is referring to bits in the bit mask - not actual values. I should have been alert for that.
That still leaves my other question outstanding - is there a way to set a pre-arm check for “home” being identified.
If your bit mask technique is required, then the “ALL” option should be removed. If it stays in - it should work.
Your technique for using a fence is novel - but not useful.
Consider the person wading into ArduPilot for the first time. He or she should be able to rely on RTL as a failsafe. In fact - it’s typical that the failsafe in case of low battery level is to do RTL. There should be confidence that RTL will work.
In my case that prompted this thread, I had RTL_SPEED to a ridiculously low number - my bad. So I expect “home” may have been identified properly - I just couldn’t tell because I didn’t observe the copter moving towards home at such a slow speed.
I don’t know if it’s possible to arm before “home” is identified. If it can - then I think there ought to be an option to include it (or ignore it) in the pre-arm checks.
If you can’t arm before “home” is identified, I’d like to see information about it in the docs.
The problem with not setting the fence is you can still arm and take off without a good 3D GPS fix in some modes that dont require GPS. So setting the Fence means the GPS fix must be obtained before being able to arm in any mode.
Some recommend to start in Loiter mode to ensure you have a fix before changing into another mode if required, but setting the fence takes human error out of the equation.
It’s possible that Fence, or a “Home” arming check should be the default and you could submit an issue in Github for that. I always have the Fence set and it’s one of the default params I always load to a new build.
Home position could in theory be a pre-arm check, but fence achieves the same thing, with the added benefit of having the fence
The Initial Parameters calculator shows the fence settings as recommended, and you can easily select them, but it’s not mandatory.
EDIT: so yes, it takes a bit of reading through the doco to join all those dots into “you can arm and takeoff without a home position set in modes like Stabilise and Althold”
This could be improved to make that much more prominent, and include suggestions for being safer.
I’m just thinking about the new guy who hasn’t yet come to the chapter about using a fence.
In my years of software work, I always tried to anticipate failures - and try to make things fail gracefully, if possible.
In my opinion, it would be better for a default to exist that requires “home” to be set as a pre-arm check - and to require removing it in some cases where it is unnecessary. I understand that there are cases where you can’t require “home” to be identified before arming. It’s safer to have the person who can’t have it set try to figure out how to remove it, than have the person who needs it try to figure out how to set it - and know that it needs to be done.
Yes I agree with you.
I’ll see if I can modify the doco to point out the current situation better, and maybe we can submit an issue to add the Home Fix arming check - or make the Fence the default, which would be less obvious but safer.
Fence is disabled by default. There are other Fence parameters configured by default (action, radius, etc.) but they do nothing unless Fence is enabled. I just wait until I see the Origin Set and IMUx is Using GPS.
Yaapu also verbalizes that Home has been set - but it often comes before I get the Mavlink messages that the IMU’s are using GPS. I wait until the IMU’s are using GPS.
If I didn’t have Yaapu or a GCS with radio telemetry, I’d really need some sort of failsafe to protect me from arming before “home” was identified and set. Meanwhile - I just need to follow my own checklists more closely.
