this fixes a bug in how default file values are handled that affects
any common sub-objects. When we had a default value for something like
SERVO12_FUNCTION then configured_in_defaults_file() would return true
for SERVO1_FUNCTION as it shares a common default value pointer
this changes the implementation to use the object pointer instead
RC_Channel: To nullptr from NULL.
AC_Fence: To nullptr from NULL.
AC_Avoidance: To nullptr from NULL.
AC_PrecLand: To nullptr from NULL.
DataFlash: To nullptr from NULL.
SITL: To nullptr from NULL.
GCS_MAVLink: To nullptr from NULL.
DataFlash: To nullptr from NULL.
AP_Compass: To nullptr from NULL.
Global: To nullptr from NULL.
Global: To nullptr from NULL.
/home/travis/build/ArduPilot/ardupilot/libraries/AP_Param/AP_Param.h:542:22: warning: using floating point absolute value function 'fabsf' when argument is of integer type [-Wabsolute-value]
bool force = fabsf(_value - v) < FLT_EPSILON;
if we load an element other than the X element of a Vector3f via
MAVLink then the value reported back to the GCS would be at the wrong
offset in memory. This led to some very confusing results for users
This commit changes the way libraries headers are included in source files:
- If the header is in the same directory the source belongs to, so the
notation '#include ""' is used with the path relative to the directory
containing the source.
- If the header is outside the directory containing the source, then we use
the notation '#include <>' with the path relative to libraries folder.
Some of the advantages of such approach:
- Only one search path for libraries headers.
- OSs like Windows may have a better lookup time.
this allows a HAL_PARAM_DEFAULTS_PATH to be specified for a build to
override the default parameters for a build. This is useful to build a
firmware that has different default parameters
This bug affected parameters where the defaults are overridden in the
object constructor. For example, a PID object may have a default value
for PID_D of 0.0, but have a constructor based default of 0.2. If the
user tries to set the value to exactly 0.0, then the set wouldn't happen,
as the value matches the value in the object default var_info[]
table.
This change ensures we force a save to eeprom if the value is changing
from the current value, regardless of the var_info[] default.
Thanks to Tom Coyle for finding this bug!
Andrew Tridgell
Lucas De Marchi
Peter Barker
Francisco Ferreira
murata
Mathieu OTHACEHE
Andy Little
Ricardo de Almeida Gonzaga
Randy Mackay
Jonathan Challinger
Grant Morphett
Gustavo Jose de Sousa
tcr3dr
Tom Pittenger
Andrew Tridgell