This fixes the initialization for Linux boards using the PX4Flow module.
The problem is that after the conversion to use I2CDevice we now need to
use I2CDeviceManager, which is statically constructed after the vehicle
object.
So, if we try to call hal.i2c_mgr->get_device(), it will call the
get_device() method before the constructor is called and receive a
SIGSEGV:
Program received signal SIGSEGV, Segmentation fault.
0x000b06c0 in OpticalFlow::OpticalFlow (this=0x140914 <copter+4980>, ahrs=...)
at ../../libraries/AP_OpticalFlow/OpticalFlow.cpp:54
54 ../../libraries/AP_OpticalFlow/OpticalFlow.cpp: No such file or directory.
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.
