AP_Stats: Only reset statistics if the user explicitly sets AP_Stats_…

[amilcarlucas]

…RESET parameter to zero.

This allows users to load parameter files (in MP, MAVProxy or any other GCS) without
accidentally reseting the statistics, because the AP_STATS_RESET value contained in
the parameter file will be ignored (unless it is zero and it is usually not zero).
The other statistics parameters are read-only, and the GCS should be clever enough to not set those.
Some documentation improvements

A side effect is that if AP_STATS_RESET != 0 the GCS will probably retry setting the AP_STATS_RESET parameter a couple of times without success and will give up with a timeout or something like that. But that is OK I think. Better than accidentally reseting the stats just because a new parameter file got loaded.

[magicrub]

this looks like it changes the default behavior from resetting to not resetting. Is that the default behavior we want?

[amilcarlucas]

Any updates ?

[amilcarlucas]

I still think this is useful, but I will close this one if nobody else feels it is an improvement.

[peterbarker]

@amilcarlucas It was done this way originally so that if the vehicle never had an idea of Unix epoch time (e.g. no GPS and no times sent from GCS), then you could still set a reasonable number in here from the GCS doing the reset.

[amilcarlucas]

@amilcarlucas for the reasons described above, I like this change and have it on my local branch. Should we bring this up in the dev meeting?

[rmackay9]

I like how we're adding "Statistics" to the param descriptions. I think in general all parameter descriptions should, if possible, start with the feature or library name.

[peterbarker]

I'm going to have another look at this.

tridge pointed out we probably are overflowing this number ATM, so we'll move to minutes in this field...

[amilcarlucas]

The change to minutes is scope creeping and should be done with a future PR.

[khancyr]

@amilcarlucas @peterbarker This one is not a bad change, it would need a rebase.... I think it is safe change to merge to prevent unexpected reset of statistics. But I don't think that the removal of the @readonly flag is usefull
@peterbarker I failed to see how you can the usage of reset can change the time correctly

[amilcarlucas]

If you can write to it, it is no longer read_only. Should I change it?

[khancyr]

The readonly flag is abused here as notSettable. You could send some value but they won't be settled

[amilcarlucas]

Did the requested changes

[peterbarker]

@amilcarlucas we've recently come down hard on someone for doing the same "magic parameter" thing that I did in the original stats stuff - resetting one parameter chains on to doing others. I'm pretty sure for consistency we should probably move away from magic parameters - and if we're going to do that should probably not change things twice :-)

I propose we add something to an existing mav-command-long message that clears the onboard flight statistics. This can work in parallel with the existing clear code - which people currently expect.

Now - if we can decide where to add it, that would be great! Remembering we also need to get that mavlink change upstream....

Maybe adding a bit to param7 in MAV_CMD_PREFLIGHT_CALIBRATION which, if set, clears the flight statistics?

[davidbuzz]

@peterbarker - "Maybe adding a bit to param7 in MAV_CMD_PREFLIGHT_CALIBRATION which, if set, clears the flight statistics?" - are you suggesting that this PR should be closed in favour of a different one that does thius alternativeive..?

[davidbuzz]

nudge

[amilcarlucas]

Rebased once more. This has been lingering since 6 and a half years.