if you have a mission item for engine control with delayed start at
height and the engine is already running them it would put the ICE
subsystem into a state where it would no longer start the engine
It was actually 2 bugs:
- an engine control to do a height delayed start should be ignored if
the engine is already running. This prevents an engine control to
start the engine from stopping the engine
- a start_chan high should always try to start the engine
immediately, even if in the wait state
we need to tell the IO firmware that a byte was consumed when we first
detect a protocol as otherwise the next bad byte on DSM will lock us
on the DSM port
this fixes an issue where when you lose R/C input on IOMCU that you
may not regain it when R/C comes back.
The issue stems from us still processing the DSM uart when we are
using the SD3 "SBUS" uart for RC input, and still doing the switch of
the SD3 config every 2 seconds.
When we are not searching for a new protocol we should not be changing
UART config
this fixes a pre-arm failure "GPS 1 failing configuration checks" on
non-M10 GPS modules, including AP_Periph
it also adds the ublox unconfigured msgs to the DroneCAN GNSS.Status
errors field for easier diagnosis of this type of issue in the future
remove any discrepancy which has crept in over the last few seconds
this also ensures that relative_altitude is updated, and copes with
the EKF refusing the resetHeightDatum call
if the IOMCU resets twice in quick succession then the code that
restores the safety state while flying can fail, leading to the
aircraft trying to continue flying with safety on
This results from two issues:
- a race in handling the last_safety_off variable
- the fact that plane sets the soft_armed state based on safety state
Failing due to being out of time meant we wouldn't incremement the counter, even though we'd emitted the item.
it is important we try to send something, so move this check to be after we increment whichever counter we are using.
RemoteID modules are required to set EMERGENCY status on uncontrolled
descent or crash. This fixes our implementation to do that, either via
existing vehicle crash checking code or via a parachute release
this fixes a regression from 4.2 to 4.3.
previously we automatically set the diagnoals to 1,1,1 if they were
0,0,0. We don't do that any more. I was helping a user who had copied
an old config with 0,0,0 for diagonals and did not understand two
things:
- the compass did not work in 4.3
- large vehicle mag cal didn't work
