../../Tools/Replay/Replay.cpp: In member function ‘FILE* Replay::xfopen(const char*, const char*)’:
../../Tools/Replay/Replay.cpp:485:60: warning: declaration of ‘filename’ shadows a member of ‘Replay’ [-Wshadow]
FILE *Replay::xfopen(const char *filename, const char *mode)
^
Accept a 0 exit status, or a status >127 (indicating a signal
caused the process to exit) as success.
The original intent of ignoring the exit status was that
the python executable was segfaulting after successfully
building headers.
Recently builds have been failing because people have not been
doing recursive submodule updates, and the mavlink header generation
has failed. Since we are ignoring the error the build rumbles on
and fails later with a failed #include.
This patch tightens our ignoring of a bad exit status to just
signals.
Note that the waf build system does the same check.
When the accel calibration fails leave the previous values saved but set them to defaults (scale default is ones, not zeros) and notify the GCS
This fixes an arithmetic exception when doing a second accel cal after the first one failed
this allows enable/disable of fast sampling per IMU, making
experimentation easier.
It also fixes the fast sampling to always average over 8 samples, and
fixes the 9250 to use the correct accumulator when not doing fast
sampling
it is inconvenient to modify locations.txt in the source, because this
will lead to the file being constantly marked as modified by git (and
potentially included in pull requests by accident).
this commit adds support for a user-maintained list of locations.
This file lives by default in
`$XDG_CONFIG_DIR/ardupilot/locations.txt` (aka
`$HOME/.config/ardupilot/locations.txt`), but may also be specified in
the `ARDUPILOT_LOCATIONS` environment variable.
Remove a lot of cases where @Values and @Bitmask were encoding the same
information. @Value should only be used with @Bitmask when it is being
used to present a series of reasonable defaults that is some hybrid of
the @Bitmask fields. Enumerating each bit as 1, 2, 4, 8 is of no value.
the datasheet says that if you get back zero in an ADC read that the
next value can be corrupt. I have seen this happen on the FMUv1,
leading to bad altitude readings
