Running the vehicles we check the stack size doesn't grow too much by
enabling the DEBUG_STACK in the scheduler. Even on 64bit boards the
stack is consistent around 4k. Just to be a little conservative, let it
be a little bit more that that: 256kB.
Since we have RT prio and we call mlock(), the memory for the stack of
each thread is locked in memory. This means we are effectively taking
that much memory. The default stack size varies per distro, but it's
common to have 8MB for 64 bit boards and 4MB for 32 bit boards. Here is
the output of ps -L -o 'comm,rtprio,rss $(pidof arducopter-quad)', showing the
RSS of arducopter-quad before and after this change:
Before:
COMMAND RTPRIO RSS
arducopter-quad 12 46960
sched-timer 15 46960
sched-uart 14 46960
sched-rcin 13 46960
sched-tonealarm 11 46960
sched-io 10 46960
After:
COMMAND RTPRIO RSS
arducopter-quad 12 7320
sched-timer 15 7320
sched-uart 14 7320
sched-rcin 13 7320
sched-tonealarm 11 7320
sched-io 10 7320
allow vehicle code to compensate for thrust effectiveness changes due
to properties outside the scope of AP_Motors. This allows for
compensation in tiltrotors and tiltwings.
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.
We don't need all the comments in the array declaration and we can
inline its declaration in the function call. This makes it easier to
copy it to other places.
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.
Otherwise we would destroy PX4_I2C object after returning from
I2CDeviceManager::get_device(). Since this implementation is very
simple, just make PX4_I2C as an internal class and embed it into the
I2CDevice object.
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.
When the the variable in which we are saving the current sum is of
integral type we can use a much more optimized apply() method: instead
of looping the entire number of samples adding them up, we always keep
the current sum in a member. It also allows the caller to decide the
type it wants to use to get the average: this may be dictated by another
interface it uses or it may want to avoid the implicit truncate in the
return of apply().
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.
