ardupilot
ardupilot copied to clipboard
Arming: add parameter and check for runaway missions
Checks if the first waypoint is too far during arming checks. Adds a parameter MIS_MAX_WP_DIST to control maximum distance. This prevents accidental runaway from old/incorrect missions. Should close #1348, and is related to #14534
Most code is from #13308, so I kept @rishabsingh3003 as commit author. If the way I did this is inadequate in any way, please let me know.
is this functionality not covered by FENCE? I think it is....just set a tincan fence, a couple of params.....however, a single param would be easier to setup
I understand the problem, this has happened to me. To the point made by @Hwurzburg, it is just as easy to forget and leave an old/wrong fence in place. Just a thought - rather than baking this into the C++ code, how about a LUA script?
is this functionality not covered by FENCE? I think it is....just set a tincan fence, a couple of params.....however, a single param would be easier to setup
As @timtuxworth said, a fence could be left over from another mission or not enabled. Another problem is that, even with a correct fence, the mission would start and fly until it hits the border, which can be frustrating.
Just a thought - rather than baking this into the C++ code, how about a LUA script?
What would be the advantage? I'm not too familiar with AP scripting (nor LUA scripting in general)
Tin can fence (not Poly) is home based....it SHOULD be left enabled for this functionality...it follows the vehicle and is set centered on home...takes setting only two params from defaults....you can make it 30 to 10000 meters around...by definition no arming check is required....no code, just takes setting two param instead of one...if the mission is old and is outside the fence, it wont go into AUTO sounds like this problem is already solved with present code....this just reduces the parm set from two to one
it wont go into AUTO
It currently will, and fly until it breaches the fence.
We could update so that it does work as you describe. But I think using fences is quite limiting, if you want to run long thin missions you would need a big radius on your circle fence, possibly so large that it does not catch this case. I think its fine to want to run long missions and just require that the first point is near take off.
Just a thought - rather than baking this into the C++ code, how about a LUA script?
What would be the advantage? I'm not too familiar with AP scripting (nor LUA scripting in general)
You can easily tweak your own implementation of the rules you think make sense for you if it's a LUA script, as scripts can be maintained/updated without flashing new firmware (or kept if new firmware comes along).
Test infinite-loop missions in autotest
I've put some suggestions for naming but they're not blockers..