Instead of only keeping track of the sequence ID of specific "supported"
components, we now keep track of any sysid/compid of an incoming
message. Before this change, unknown components (such as jMAVSim) would
completely screw up the mavlink message stats and create confusion (at
least in my case).
With this change we currently keep track of up to 8 other components.
Once we reach the limit, we will print a warning.
Without these fields the pre-arm check would complain and fail.
Also, the voltage is adjusted to be at around 70% rather than 30% which
would almost start to trigger warnings.
- if distance to the ground is available then hysteresis times will be increased
by a factor of 3 if vehicle is higher than 1m above ground
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- no warning if accel is disabled
- threshold increased 100 -> 1000 (only warn if severe ongoing clipping)
- more generic warning message (vehicle isn't necessarily in air flying)
For the sake of efficiency (at 8 kHz) all filtering is performed on the raw data before the calibration and rotation is applied to only the final output. As a result we have to be a bit more careful when switching between sensors or in cases where the gyro scale factor changes (eg icm42688p 20 bit data rescaled to fit in int16 output).
This entire feature only has an impact if the last mode set
a huge acceleration and we have to take over as smooth as possible.
But it's stil lworth fixing.
Tailsitter VTOLs very occasionally gets stuck with zero roll and pitch angle in multicopter mode after
a forward transition command is issued.
This very rare behavior is triggered by the following events:
1> a forward transition is triggered either in auto or manual mode.
2> in the vtol_att_control main loop, if multicopter and fixed wing attitude setpoints are not updated, transition state is not updated
3> the commander changes the vehicle status to transition mode.
4> multicopter pos controller initiated Transition flight task. This results in zero roll and pitch setpoint due to zero acceleration setpoint
5> now vtol_att_control executes and updates the transition state. Specifically, _q_trans_start and _q_trans_sp are set with zero roll and pitch sp
6> tilt is evaluated to be NaN, despite _q_trans_sp being normalized. This happens for 25% of all yaw angles when using float datatype. This can be
verified using the matrix library
7> once tilt is evaluated to be NaN, _q_trans_sp is never updated again and is stuck in this state for ever.
This has been fixed by constraining the cos(tilt) within +1 to -1 range
Further, _q_trans_start and _q_trans_sp are immedietly initialized after a transition event is triggered.