The minimum version for gcc was supposed to be 4.9 for any platform.
However our build instructions are outdated. Remove the problematic
parts that use the sparse-endian.h header while we don't fix the setup
for windows.
- Correctly sort includes and add missing AP_Math.h
- Use anonymous struct for trim_registers in _load_trim_values,
renaming its members so they don't start with underscore
- Don't change _dig* values when we failed to read from sensor
- Add some blank lines
- Make _dig_* members be inside a _dig struct
- Use constrain_int32 instead of if/else chain
- s/time_us/time_usec/
- Construct raw_field with a single constructor in _update()
- Add missing copyright notice
- Group methods together in declaration
In addition:
- bbbmini, navio and navio2 can force HMC5843 backend to
be external.
- there was a typo in the backend name that's now fixed:
AK8953 vs AK8963
Minlure has an onboard compass (HMC5883L) as slave of MPU-6000, but also
allows the use of an external HMC5883L compass, which should be
connected to the lure's I2C port.
That rotation is done because of the "arrow" pointing the sensor direction in
3DR GPS+Compass kit (which isn't natural to the sensor orientation, by the
way). Thus, do that rotation only for external HMC5883L compasses.
That rotation is set for AP_COMPASS_TYPE_HMC5883L, because it's usually
the compass from 3DR GPS+Compass kit, which has an arrow pointing the
"correct" direction. That rotation should be done before rotate_field()
as it represents the "standard" position for the kit.
This patch also makes published values consistent with respect to rotation.
Before this, raw fields used in calibration were published with a
rotation different from the filtered field when _product_id is
AP_COMPASS_TYPE_HMC5883L.
And to the detection probe() method. That way we don't need to use a board
`#ifdef` inside the class code. Additionally, we make raspilot board use it.
Initialization was also changed a little bit so we don't try to
initialize 25 times. We rather use the same methods as in the
AP_InertialSensor drivers.
Also move up the call to is_zero() in read_raw so we don't set
_mag_[x|y|z] in case of failure.
These are not used. The only place where raw fields are used are in the
compass calibrator and we don't need to store them.
Additionally remove duplicated documentation about the meaning of the
functions to avoid them getting out of sync.
We still need the BusDriver (in some places called SerialBus) interface
since this driver can also be used on an AuxiliaryBus and that has a
different interface.
- Capitalize and rename constants
- Make clear what gain is applied in calibration and what is the
"normal" gain
- Make the separation between HMC5883L and HMC5843 explicit when it
makes sense to improve readability
- Remove spurious delay in calibrate function
We still need the BusDriver (in some places called SerialBus) interface
since this driver can also be used on an AuxiliaryBus and that has a
different interface.
Besides the usual conversion some more improvements:
- Use generic function to convert endianness
- Minor cleanups
- Reorder per-board ifdefs in compass instantiation: distinguish when
there's a default compass to when it should probe other compasses
In file included from /home/lucas/p/dronecode/ardupilot/libraries/AP_Compass/Compass.h:6:
/home/lucas/p/dronecode/ardupilot/libraries/AP_Compass/CompassCalibrator.h:86:5: warning: struct 'param_t' was previously declared as a class [-Wmismatched-tags]
struct param_t _params;
^
/home/lucas/p/dronecode/ardupilot/libraries/AP_Compass/CompassCalibrator.h:44:11: note: previous use is here
class param_t {
^
/home/lucas/p/dronecode/ardupilot/libraries/AP_Compass/CompassCalibrator.h:86:5: note: did you mean class here?
struct param_t _params;
^~~~~~
Not having data ready during initialization is normal. Don't print error
message since it can mislead people to think the compass was not
initialized successfully.
This is the only driver doing this, using the system_initializing() from
scheduler to log selectively. Remove the check together with removal of
unused wrapper methods to semaphore.
Most of AP_Progmem is already gone so we can stop including it in most
of the places. The only places that need it are the ones using
pgm_read_*() APIs.
In some cases the header needed to be added in the .cpp since it was
removed from the .h to reduce scope. In those cases the headers were
also reordered.
Now variables don't have to be declared with PROGMEM anymore, so remove
them. This was automated with:
git grep -l -z PROGMEM | xargs -0 sed -i 's/ PROGMEM / /g'
git grep -l -z PROGMEM | xargs -0 sed -i 's/PROGMEM//g'
The 2 commands were done so we don't leave behind spurious spaces.
AVR-specific places were not changed.
The PSTR is already define as a NOP for all supported platforms. It's
only needed for AVR so here we remove all the uses throughout the
codebase.
This was automated with a simple python script so it also converts
places which spans to multiple lines, removing the matching parentheses.
AVR-specific places were not changed.
For all supported boards the maximum number of instances is 3. The
number of HIL_COMPASSES was already defined as 2 instead of 3, so this
is left as before.
We don't support HAL_CPU_CLASS <= HAL_CPU_CLASS_16 anymore. This makes
COMPASS_MAX_INSTANCES and COMPASS_MAX_BACKEND constant for all supported
boards.
Instead of requiring every program to specify the HAL related modules,
let the build system do it (in practice everything we compiled depended
on HAL anyway). This allow including only the necessary files in the
compilation.
The switching between different AP_HAL was happening by giving different
definitions of AP_HAL_BOARD_DRIVER, and the programs would use it to
instantiate.
A program or library code would have to explicitly include (and depend)
on the concrete implementation of the HAL, even when using it only via
interface.
The proposed change move this dependency to be link time. There is a
AP_HAL::get_HAL() function that is used by the client code. Each
implementation of HAL provides its own definition of this function,
returning the appropriate concrete instance.
Since this replaces the job of AP_HAL_BOARD_DRIVER, the definition was
removed.
The static variables for PX4 and VRBRAIN were named differently to avoid
shadowing the extern symbol 'hal'.
offset parameter units are milligauss
User settable parameters should have a User category defined. Those that should never be set by a user should not have this.
The function rotate_field() can change the values axes and the function
correct_field() applies offsets (which are already in milligauss). Thus any
sensitivity adjustment must be done for two reasons:
(1) The offsets must be applied to the values already in milligauss;
(2) The factory sensitivity adjustment values are per axis, if any rotation
that switches axes is applied, that'll mess with the adjustment.
Experiments showed that before this patch the length of the mag field reported
quite different from the expected. After this patch, the same experiments
showed reasonable values.
This is part of the transition to make all mag field values be used in
milligauss. Additionally the value of _gain_multiple is adapted to the new way
we're using it and corrected accordingly to the datasheets.
The use of _gain_multiple is not necessary because the values of
expected_{x,yz} and _mag_{x,y,z} are both in sensor raw unit (i.e., lsbs).
That wasn't fixed before in order not to make APM users to recalibrate their
compasses.
the previous approach assumed a 1:1 mapping between compass backends
and compass instances, which isn't true on PX4.
It also only setup milligauss offsets on a set_and_save call, which is
not the only way offsets change
this adds a milligauss_ratio per instance, which is considerably
simpler
AK8963 is configured in 16-bit ADC mode which implies sensitivity of 0.15 uT/LSb. Knowing this fact we can convert the measurements to the proper units. The change will make users recalibrate their compasses.
From now on there's a pair get_field_milligauss() and
get_offsets_milligauss() that can make the transition to the common
units across all compasses easier.
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.
increase iterations to get good results from LM
better check for convergence, comparison with initial fitness is a better way to determine if convergence occurs, if fitness has not improved compared to initial fitness it means optimiser has failed.
Like was done to inertial AK8963 and inertial sensor move the decision
regarding the I2C bus to the caller. We don't allow changing the address
because apparently HMC5843 doesn't support different addresses.
Changing only the bus could be more easily done but this prepares the
ground for using HMC5843 on an AuxiliarBus.
The need for a more generic abstraction is evidenced by this commit: a
"SerialBus" in AP_HAL would be a nice addition rather than letting each
driver to provide its own. However the methods are a little bit
different from what we have in AK8963. It's safer to do the simple
conversion now and later on to add the abstraction changing everybody to
use it.
read() calls accumulate() which takes the lock by itself so we must
release it like we were doing before 669ae26 ("AP_Compass: encapsulated
calibration in HMC").
Just like was done for inertial sensor, different detect() functions
might need different arguments and passing a pointer to function here is
cumbersome. For example, it forces to have a method like "detect_i2c2"
rather than allowing hal.i2c2 to be passed as parameter.
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.
In case of error or zeroed data, the i2c semaphore wasn't given.
It happened at first startup on Bebop and caused a failure:
"PANIC: failed to take _bus->sem 100 times in a row..."
No need to repeat the same comments on 3 different places. Instead add a
single comment to explain how start_measurements() and read_raw() are
related.
Don't use a state machine in AK8963: the start_measurements() method
should be called only once. Even if there's a magnetic sensor overflow
the only thing we should do is to discard the new data.
This also moves the _collect_samples() method to be inside _update()
since it's the only place it should be called from, the one running on
the timer thread.
We need to check the AK8963's id before anything else Here we are
reordering the calls to _calibrate() and _check_id(). After that we
don't need to read and write again the AK8963_CNTL1 register.
While at it do some renames as well:
- _configure() -> _setup_mode(): since now there's a
_bus->configure() it became confusing what actually it's
doing.
- make error messages say what we were actually trying to do but
couldn't. Also remove PSTR since this is linux-only.
- start_conversion() -> start_measurements(): We are instructing the
bus to start to get the samples, not to tell the chip to start an
analog->digital conversion like in other sensors.
The MPUREG_PWR_MGMT_1 defines were used when we cared about the MPU9250
initialization code. Now all initialization is done by the MPU9250 class
itself, so remove these defines.
Also remove AK8983_SELFTEST_MAGNETIC_FIELD_ON that is never used and let
the defines always with 2 bytes to improve readability.
Similar code was added in the read_raw() implementation for each bus.
Add a new POD struct read_raw to contain the registers from the AK8963
and use it instead as argument.
Uses reimplemented AK8963 driver. There's also no need trying to detect this
compass twice. Actually, it might even be bad, because the current code can
allocate an AK8963 object twice.
_copy_to_frontend function takes care of abstracting
this code from the driver. For now the function takes
care of the offset and rotation that is common.
Otherwise, get_field() will return NaNs after once every few calls to
read() during compassmot on PX4 platforms, which causes compassmot to fail.
This is a quick hack around the deeper issue, which could be something
like the PX4 mag driver experiencing starvation and skipping mag reports,
buffer overrun or something else that causes mag reports to be dropped.
Or perhaps we should never expect in the first place that we will always
receive at least one mag report between calls to read().
this is prompted by a user log showing NaN compass offsets, resulting
in a crash. The patch ensures we never end up with NaN offsets, and
also constrains the offsets to a reasonable limit
the first couple of values after we enter strap mode may be low, but
just above our 0.7 threshold. We now discard the first two values to
prevent these affecting the average.
Also added some commented out debug code and a comment on the scaling
of the calibration code
a saturated compass is now marked unhealthy, rather than causing the
code to spin waiting for a valid sample. This fixes a problem with
strong magnets causing the main flight loop to stop
- Define float versions of math functions to the double versions
on AVR (eg. #define sinf sin).
- These macros appear to be missing in older versions of avr-libs.
- Include AP_Math.h rather than math.h to get these definitions.
- Allows use of hardware floating point on the Cortex-M4.
- Added "f" suffix to floating point literals.
- Call floating point versions of stdlib math functions.
* I mostly went through with grep and added an #include <AP_Param.h> below
every #include <AP_Common.h>. Not all of these example sketches might
strictly need AP_Param.
the new AHRS code doesn't use calculate() and the compass.heading
attribute. Instead it works on the raw magnetometer vector. This
change removes the internal calculate state from the compass object
and instead adds calculate_heading() for use by older code that
doesn't go via AHRS.
This significantly reduces the calculation involved in compass updates
The null offsets enable/disable code is also removed, as it is not
needed now that compass offsets are not linked to the AHRS state.
when this is 1 (which is the default), we will get the declination
automatically via the AP_Declination library
when it is 0 we will use the value configured by the user
This adds a large amount of noise robustness to the compass offset
learning algorithm, at a cost of 120 bytes of memory. The changes are
based on a long discussion with Bill Premerlani.
this seems to work much better than the old algorithm, converging
faster and more accurately. Even better, it has no linkage to DCM, so
no possibility of nasty feedback effects
This will set the declination based on lat/lon if the user has
not yet saved one to the EEPROM, OR if they have specified via the
config parameter that they want it to overwrite the declination every
3D fix.
Signed-off-by: Andrew Tridgell <tridge@samba.org>
these allow you to control if the compass should be used for yaw and
if it should learn its offsets. This is useful for locking in compass
offsets once they are confirmed to be good, and for learning offsets
without using them in flights.
The default is to behave the same as previously, which is
COMPASS_LEARN=1 and COMPASS_USE=1
Since the magnetometer offsets are not available through the MAVLink parameter interface (since they are an AP_Var vector) this little feature allows them to be reset from the CLI. Useful if you somehow get bad offsets or if you change magnetometer. If you have a bad set of large offset values I have seen issues with the nulling algorithm have trouble converging to the proper values. I have never seen it have trouble converging from 0/0/0, so this could be a useful feature from time to time.
This is a fix for an interesting bug when a DCM matrix reset was added to the ground start. This bug only showed up if (A) a ground start were performed after an air start or due to use of the "Calibrate Gryo" action, (B) if the current orientation were sufficiently different from 0/0/0, and (C.) if the particular magnetometer had sufficiently large offsets. Why did resetting the DCM matrix to 0/0/0 pitch/roll/yaw at ground start cause a bug? The magnetometer offset nulling determines the proper offsets for the magnetometer by comparing the observed change in the magnetic field vector with the expected change due to rotation as calculated from the rotation in the DCM matrix. This comparison is made at 10Hz, and then filtered with a weight based on the amount of rotation to estimate the offsets. Normally it would take considerable time at normal in-flight rotation rates for the offset estimate to converge.
If a DCM matrix reset occurs when the offset nulling algorithm is up and running, the algorithm sees the DCM reset as a instantaneous rotation, however the magnetic field vector did not change at all. Under certain conditions the algorithm would interpret this as indicating that the offset(s) should be very large. Since the "rotation" could also have been large the filter weighting would be large and it was possible for a large erroneous estimate of the offset(s) to be made based on this single (bad) data point.
To fix this bug methods were added to the compass object to start and stop the offset nulling algorithm. Further, when the algorithm is started, it is set up to get fresh samples. The DCM matrix reset method now calls these new methods to stop the offset nulling before resetting the matrix, and resume after the matrix has been reset.
this changes the calibration code to require at least 5 good reads
from the compass during initialisation. The calibration is taken as
the average of the 5 values.
This also fixes the expected values for the 3 axes for the 5883 to
match reality.
We also save a bit of code space by adding a common rotate_for_5883L()
routine.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@3087 f9c3cf11-9bcb-44bc-f272-b75c42450872
this adds a 50ms delay after setting the compass gains before reading
the compass. Added as paranoia after some strange results on a 5843
git-svn-id: https://arducopter.googlecode.com/svn/trunk@3070 f9c3cf11-9bcb-44bc-f272-b75c42450872
we were looking for the wrong regA value
Thanks to Chris for the debugging help! (and happy birthday!)
git-svn-id: https://arducopter.googlecode.com/svn/trunk@2828 f9c3cf11-9bcb-44bc-f272-b75c42450872
this adds error checking to all operations on the compass, to ensure
that we don't accept invalid data
This also fixes the calibration values for the 5883L to match the
recommended values in the spec
git-svn-id: https://arducopter.googlecode.com/svn/trunk@2815 f9c3cf11-9bcb-44bc-f272-b75c42450872
this fixes a compass initialisation bug where if the first value from
the compass isn't in the right range we would set bad calibration
scaling factors.
This also changes the maximum acceptable calibration values to 2000,
which is needed for the 5883 compass
pair-programmed-with: Randy Mackay
git-svn-id: https://arducopter.googlecode.com/svn/trunk@2718 f9c3cf11-9bcb-44bc-f272-b75c42450872