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
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.
We currently check examples are buildable with waf which doesn't need
the libraries to be specified in a make.inc file. Having the makefiles
there is misleading since people try to build and realize the build is
broken.
- reorder and document members.
- remove tentative of vertical alignement
- like was done for accumulated values, move the calibration
values to a struct
This converts MS56XX to use the thread started by SPI/I2C instead of
using the timer thread. This also fixes a possible starvation of the
main thread:
1) INS driver registers itself to be sampled on timer thread
2) MS56XX registers itself to be sampled on timer thread
3) Main thread waits for a sample from INS with
ins.wait_for_sample()
4) timer thread is waiting on update from MS56XX and consequently
the main thread is waiting on an I2C/SPI transfer
Besides this starvation there's another one due to reuse of the timer
lock in order to pump values from the timer thread to the main thread. A
call to the update() method when we have a sample available would need
to wait on any other driver holding the timer lock.
Now there's a lock just to pass the new values from the bus thread to
the main thread with a very tiny critical region, not waiting on any
bus transfers and/or syscalls.
Instead of a couple seconds, make it about 15sec. This makes TECS happy by not glitching the height demand as much. When applied too fast the TECS height demand causes a large single oscillation as it chases the filter lag.
Instead of depending on the frequency accumulate() is called, use
AverageIntegralFilter with 10 samples. The data obtained by BMP085 is
too noisy with any value of OVERSAMPLING so use twice the number of
samples as currently used. Besides that now we are sure there's always
10 samples used in the average.
The temperature readings is not subject to white noise so there's no
point in averaging its reading. Moreover since for a normal 50Hz
accumulate() / 10Hz update() it would read temperature only once per
update(), it's pointless to keep averaging and introducing rounding
error.
The temperature doesn't need to be checked as frequent as pressure, too.
The datasheet even suggests on section 3.3, page 10 to enable standard
mode and read the temperature at 1Hz. Here we reduce it to 2Hz
(considering the accumulate() function being called at 50Hz).
If we don't have EOC pin and assuming the accumulate() function is
called at 50Hz (or higher) we would take very few samples to accumulate
before the update is called. That's because since we have to wait 26ms
to get a sample and we calling accumulate() every 20ms, half of the
times it will return without getting anything. So we will
be using 2 or 3 samples only to average.
If we don't have EOC, use OVERSAMPLING=2 which gives us more noise, but
that we can filter out by using measurements to average. When we have
EOC we don't need it because most of the time the conversion will take
less than 20ms: I'm getting 16ms on most of them while bench-testing.
Andrew Tridgell
murata
Peter Barker
Mathieu OTHACEHE
Lucas De Marchi
Andy Little
Tom Pittenger
Don Gagne
Gustavo Jose de Sousa
Julien BERAUD
Jonathan Challinger