ardupilot
ardupilot copied to clipboard
ArduPilot
Scripted Arming Checks
This adds a Lua Applet for scripted arming checks. Each check can be set as mandatory (generates a prearm fail), warning (displays a message, but allows arming) or disabled by setting a parameter.
There is a set of standard checks that I find useful, of course new ones can be added. Any suggestions appreciated.
This is designed to get around the controversy that often arises about adding arming checks to c++. To some people particular checks are essential, while to others they are unnecessary or annoying.
This works for plane, copter and rover for now, but as a base could easily be extended to other vehicles.
Thanks for this, just one thing, I guess this is Plane specific? If "yes", could the script be renamed to be prefixed with "plane-"?
Well I am hoping to simply extend it to do other vehicles, rather than having different scripts. I'm expecting there will be a lot of common checks. That's my theory anyway.
Hi @timtuxworth,
OK great, if it's meant to work on all vehicles, could you test this by running it on Copter (and perhaps Rover if you have time)? I suspect the calls to get the Q_ENABLE parameter will mean the script errors out on copter
Hi @timtuxworth,
OK great, if it's meant to work on all vehicles, could you test this by running it on Copter (and perhaps Rover if you have time)? I suspect the calls to get the Q_ENABLE parameter will mean the script errors out on copter
Done! And fixed because yes you were right there were a couple of errors. Now works with at least Plane, Copter, Rover. There are 4 checks common to all and 6 common between Plane and Copter.
Oh @peterbarker this is failing FRSky SPort autotest which has nothing to do with the changes in this PR. Can you help with that?
This is a very interesting pattern @timtuxworth !
I think that might be the most "meta" Lua I've seen in ArduPilot. Perhaps a bit overkill just to check for the arming checks, but very scalable.
10:51 AM]Peter Barker: Sorry, not a quick merge from me. We're supposed to hold applets to a reasonably high standard, and I think a little more polishing would be a good idea in that one. It's the sort of thing that partners are going to want to customise, so getting the structure just a little bit better is warranted IMO. Someone else may disagree and just merge it, of course.
I think this is now "good" - @peterbarker I've removed the dynamic generation of parameter keys.
It's failing a couple of checks, but I can't see that they are down to my code, can you help me to understand if it's something I've done?
This seems to be failing a MultiGPS test in Copter @rmackay9 - I'm pretty sure I didn't change this but of course I could be wrong. I wonder if you could take a look?
What does it mean "this job failed" with no details @peterbarker ?
Wish I know. Vexing when it happens. I haven't noticed it until recently, so maybe a change on github?