This commit changes old trone driver into a generic
TeraRanger driver that supports both TeraRanger One
and TeraRanger Evo.
As a part of the change a new parameter was created
SENS_EN_TRANGER that allows to specify the following
modes of operation:
0 - sensors disabled
1 - autodetect sensors
2 - use TeraRanger One rangefinder
3 - use TeraRanger Evo rangefinder
Signed-off-by: Mateusz Sadowski <msadowski90@gmail.com>
This fixes (or at least works around) a race condition where the
`status_flags.condition_local_position_valid` is still `false` but the
`status_flags.condition_global_position_valid` is already `true`.
The way to reproduce it is t:
1. Poll home position to check if home is initialized
2. Send arm and takeoff command as soon as home is initialized
Then arming will succeed but takeoff will fail because there is a check
for `status_flags.condition_local_position_valid` in
`main_state_transition()` to enter TAKEOFF.
param save is an expensive operation that can take several 100ms. And
previously it was possible that a param_get() caller was blocked on a
save operation. If this happened due to a param change notification,
important modules, such as sensors, could have been blocked for a longer
period (and affecting the flight performance).
With this patch, this situation is not possible anymore, because a param
save now uses the reader lock and a separate file lock.
However it is still possible that a param_set() needs to wait for a save
operation, thus blocking for a longer time. param_set() thus needs to be
avoided in important modules when the system is armed.
In the case of mavlink it works, since it does not affect the flight if
the mavlink receiver is blocked over a longer time. It is only problematic
if a joystick is used as input or in offboard control.
The magnetomer raw values were not being rotated in the same direction as
the scaled values. This meant that if the rotation was set to ROTATION_NONE,
the raw values and scaled values were off by 180 degrees.
