A 32bit float has 23bits for the mantissa, which is a bit more than 7 digits.
Since you already use 3 digits to represent the part to the left of the decimal point, that leaves about 4 digits for the rest..
So in the worst case of 180deg you have a resolution of only ~3m!
With 1e7deg 32bit int you get ~1cm resolution.
addresses first part of #984 (at least for the rotorcraft version, fixedwing version still converts to LLA float in between...)
[rotorcraft] force MODE_STARTUP instead of KILL until ahrs is aligned
- Go to MODE_STARTUP (which defaults to AP_MODE_KILL) instead of AP_MODE_KILL as long as the ahrs is not aligned.
- Remove AUTOPILOT_DISABLE_AHRS_KILL from all example airframes (but kept the functionality for now).
MODE_STARTUP is set to AP_MODE_NAV for the autonomous (without RC) ARDrone2.
Without AUTOPILOT_DISABLE_AHRS_KILL it will force MODE_STARTUP until the ahrs is aligned,
but still not allow to turn on the motors (as that also checks for ahrs_is_aligned).
This closes#964 (as long as you don't have AUTOPILOT_DISABLE_AHRS_KILL defined).
- Go to MODE_STARTUP (which defaults to AP_MODE_KILL) instead of AP_MODE_KILL as long as the ahrs is not aligned.
- Remove AUTOPILOT_DISABLE_AHRS_KILL from all example airframes (but kept the functionality for now).
MODE_STARTUP is set to AP_MODE_NAV for the autonomous (without RC) ARDrone2.
Without AUTOPILOT_DISABLE_AHRS_KILL it will force MODE_STARTUP until the ahrs is aligned,
but still not allow to turn on the motors (as that also checks for ahrs_is_aligned).
As far as I can see this should solve #964 as long as you don't have AUTOPILOT_DISABLE_AHRS_KILL defined.
using [libtap](https://github.com/zorgnax/libtap) to create a [TAP](http://testanything.org) (TestAnythingProtocol) producer.
You can also run the test (if already compiled) with prove:
```
prove --exec '' tests/math/test_pprz_math.run
```
Since the simple i2c driver for linux does busy waiting on i2c_submit (and not queue a new transaction),
setting the transaction status to done at the end (with a new transcaction in between) will set the status
of the wrong transaction...
Did not seem happen with the other i2c implementations (lpc21, stm32) so far, but since they add the transaction
to the queue which is handled in the I2C ISR, it could also happen there (race condition).
closes#960
[peripherals] mpuxxxx: use gcc pragma to ignore cast-qual warnings
The buffer is volatile, since filled from ISR...
But we know it's ok to use it here so we silence the warning.
Also there is a bug in some gcc version that incorrectly reports this as
peripherals/mpu60x0_spi.c:118:33: warning: cast discards '__attribute__((noreturn))' qualifier from pointer target type [-Wcast-qual]
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
uart_event was added as a weak function with #951, but it is not provided in simulators.
The compiler (correctly) fills in a zero and the simulator segfaults.
For now simply fix it by not calling uart_event in simulators.
The buffer is volatile, since filled from ISR...
But we know it's ok to use it here so we silence the warning.
Also there is a bug in some gcc version that incorrectly reports this as
peripherals/mpu60x0_spi.c:118:33: warning: cast discards '__attribute__((noreturn))' qualifier from pointer target type [-Wcast-qual]
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
Felix Ruess
Gautier Hattenberger
Freek van Tienen
dewagter