I’ve come across two instances recently where suggested parameters were outside of the published range.
The first was from MavExplorer’s Magfit utility - it suggested an offset parameter that was outside the a parameter’s range published in the docs. When I tried to enter it, Mission Planner generated an out of range notice. (Thanks to MP, this is how I realized the suggested parameter was out of range.)
The second was among a set of suggested tuning parameters from a helpful contributor here.
As someone who’s written code in my past life, I can think of several possibilities that might occur if one were to input a parameter that were out of range. The possible outcomes could be anything from benign to catastrophic.
To play it safe, I’ll stay within the bounds of the published parameter ranges. But I’m curious if the ArduPilot development team enforces any uniform treatment of parameters outside of their published range.
These are just suggested parameter values and some are not up to date or relevant for all craft. One simple example is MOT_THST_HOVER with a noted range of 0.2 to 0.8. I have 3 quads with hover thrust well below 0.2 so of course I ignore the warning. I only use them to detect a possible Fat Finger input. They get “adjusted” from time to time with new releases. Using the latest beta release of MP is a good idea,
I do much the same as Dave. In some cases, the software needs an update (something I wish happened faster, but feature development has been extremely rapid lately, and the GCS has no choice but to lag that). In most cases, though, it’s nice to have a guiding warning, so I know when I’m taking more risk (or like Dave says - detecting a fat finger).
Thanks Dave for sharing your experience and suggestions.
As Open Source software, I’m concerned about how rules for exception handling are implemented. For example - its possible for values that are out of range are interrupted as null or zero values. Or a value out of range may cause a resulting internal calculated value to exceed the limits of the data type used for the result.
While I greatly appreciate anecdotal reports of success of using parameter values in excess of published ranges - I’d feel a lot more comfortable hearing from the development team on how exception handling is done.
There are two basic pitfalls I’m worried about. If an out of range parameter generates an arbitrary result within the flight controller software, I might mis-identify a problem in performance and waste time troubleshooting a problem where the root-cause is masked by a parameter that’s out of range and results in unpredictable behavior.
The other basic pitfall of course is that after hours of work on an airborne vehicle it ends up crashing.
It’s nice to know this generally isn’t the case. But as a newcomer to this field, all this seems worth investigating.
There probably isn’t a one-size-fits-all answer to your question. ArduPilot is very robust and generally handles errors well, but there is a lot of flexibility by design, hence allowing parameters outside the suggested ranges in many cases. I know that some functions have min/max checking to limit their input and/or output values (or raise “unhealthy” condition flags), but that isn’t necessarily universal.
For which parameter(s) are you considering using out of range values? Clarify that, and we can probably give you very specific answers.
As it happens, I probably have the exact set of experiences to be a bit paranoid about this. I spent a couple of decades doing software development - and have zero decades (only a few months) experience with ArduPilot.
So I have a gut feeling for how much can go wrong if input is unchecked. But no basis yet to just trust ArduPilot to take care of it anyway.
I first came across out of range parameters when MavExplorer’s Magfit option generated COMPASS_OFS_Z and COMPASS_OFS2_Z that were over 400 - which I recall is the upper limit of the range. I’ve switched to COMPASS_LEARN=1 so maybe it doesn’t matter any more. But if ArudCopter will properly function with a value of these parameters in the mid 400’s - I’d like to try it.
I also got a list of suggested parameters for tuning that had LOIT_BRK_ACCEL and LOIT_BRK_JERK both at “300” - both are out of range.
I’m not worried about the loiter parameters - it works fine with nearest value within the published range.
I appreciate the problem this presents to the ArduPilot developers. No doubt many of the programmatic options to cope with this issue have been kicked around. All have costs of time and effort associated - not to mention larger compiled code.
But as ArduPilot tries to migrate from the hobbyist and scientist arena and into the commercial and industrial world - it’s something that might make a difference.
There is another recent topic on mag fit values that I will try to find and link for you a little later. For the moment, you’ll have to trust me that the dev team mentioned that 400+ values are of little concern in the recent builds.
I suspect that the brake/jerk values would work without breaking anything (and can probably confirm that later as well), but I’m curious why you’d increase them so much?
The suggested brake/jerk parameters are close to what I’d been using - different by about 50. I just kept my parameters - loiter is working well for me.
For some reasons, the Z axis on my internal (Orange Cube) and external (Here-3) compasses are far from the expected value - hence the offset in the mid to high 400’s.
That’s to be expected. Many FC internal mags are not worth enabling. The are included in many so-called 9-axis IMU’s and are just along for the ride on many multirotor applications.