This adds support to handle INT32_MAX for COMMAND_INT.x/y by converting
it to NAN internally.
It also adds paranoid checks to prevent:
- NAN being used sent by a COMMAND_INT by mistake.
- INT32_MAX being used sent by a COMMAND_LONG by mistake.
e.g.:
WARN [mavlink] stream ADSB_VEHICLE not found
WARN [mavlink] stream GIMBAL_DEVICE_ATTITUDE_STATUS not found
WARN [mavlink] stream GIMBAL_MANAGER_STATUS not found
WARN [mavlink] stream GIMBAL_DEVICE_SET_ATTITUDE not found
WARN [mavlink] stream GPS2_RAW not found
WARN [mavlink] stream UTM_GLOBAL_POSITION not found
ERROR [mavlink] configure_streams_to_default() failed
The calibration is not found in HITL mode. Therefore, I suggest to
ignore this step and assume the calibration is fine.
This mostly fixes the preflight check indicator in QGC, arming was (for
some reason?) already possible.
The both results of ?: should be of same type, and some compilers give error
on this:
" implicit conversion from 'float' to 'double' to match other result of conditional"
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
This was only handled outside because FlightTaks lived in the
multicopter position controller which produces the data that was
needed but now it doesn't make sense anymore to handle this
subscription separately.
It's better to have it inside the base task to have the data available
on task activation sucht that e.g. Altitude mode can take over smoothly
from Position mode.
For any normal use case where a downwards velocity setpoint is set
this works exactly the same as before.
E.g. autonomous landing, landing in Altitude or Position mode
The advantage is that the very common case where a vehicle tries
to hold a constant altitude but fails to do so e.g. during a hard brake
with too much lift the resulting downwards velocity was interpreted
as descend intent and since the vehicle already struggled to hold altitude
with low thrust and was not moving fast anymore because it was braking
this lead to a lot more false positives on certain vehicle types.
The disadvantage is that not setting a downwards velocity setpoint but
just moving the position setpoint into the ground does not result in
land detection anymore. We do not use this method of landing anymore for
quite a while. It's not recommended and I wonder if there's some rare use
case like offboard where this is done.
We could add an additional case for the specific case to land with a
position setpoint only.
The tree stages used arbitrary 350, 250 300ms totally 900ms
So this changes it to each stage to a third of the parameter.
Default it is 1 second -> 333ms per stage.
It was used to make the vehicle needing to accept the waypoint after a VTOL transition in the new VTOL mode
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
If the GPS data is passed from companion computer, there may be inaccuracies
with timesync. This may cause time deltas to overflow.
Make the time delta calculation using floats directly, wich results in negative
numbers in case there are such inaccuracies.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Julian Oes