When wind is already estimated, we don't reset the states using airspeed
data, so it could be that the fusion fails if the airspeed isn't
consistent with the filter (test ratio > 1). In this case, don't start
the fusion.
When wind isn't already estimated, the wind states are reset using
airspeed so the fusion can start regardless of the current test ratio.
- As it is always only used for the vehicle command ack message
- It was a duplicate, hence making it error prone for maintainment
- The uORB message comments were updated to make the relationship with
the MAVLink message / enum definitions clear
split the fusion process into:
1. updateAirspeed: computes innov, innov_var, obs_var, ...
2. fuseAirspeed: uses data computed in 1. to generate K, H and fuse the
observation
from 300 ms to 60 seconds, to give enough time for the user to configure
the vehicle in the mean time.
This is needed especially when the battery cell count setting is wrong
(when it should be 3, but set to 4 for example), since then whenever you
boot the vehicle, it will shutdown after 300 ms, which leaves the user
puzzled as to exactly what's happening. And it also prevented the user
from changing the Parameter since it's shutting down so quickly.
60 second window is intended to be a reasonable time that will allow the
user to figure out what's going on (via checking the battery level on
QGC, etc) but also not deep discharge the battery to a dangerous level.
- this allows landing gear to retract automatically when doing a takeoff
and the vehicle is considered high enough
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- 4096 of 3 hex digits each for rev and ver is enough.
#defines used in SPI versions do not be long format, use use the macro
- Board provides a prefix and the formatting is sized and built in
- No need for funky board_get_base_eeprom_mtd_manifest interface
Original mft is used where the abstraction is done with the MFT interface
Co-authored-by: David Sidrane <David.Sidrane@Nscdg.com>
If the capture GPIO is exposed to a signal with high frequency changes, a lot of
interrupts are scheduled and the handling of these call can worst-case
starve flight critical processes leading to a loss of control. Since camera capture
is not flight critical, we now give up the capture
functionality and stop the interrupts to prevent the starvation of other processes.
If the PPS GPIO is exposed to a signal with high frequency changes, a lot of
interrupts are scheduled and the handling of these calls can worst-case
starve flight critical processes leading to a loss of
control. Since PPS is not flight critical, we now give up the PPS
functionality and stop the interrupts to prevent the starvation of other processes.
Remove the entire external yaw handler, dynamic memory allocation,
pointer passing logic. Directly instanciate the weather vane instance
in the flight tasks that support it.
- remove internal accumulation and publish every valid raw sample synchronized with sensor
- store timestamp_sample from motion interrupt
- improve timing requirements from datasheet (minimum delays after register read/write)
- remove internal accumulation and publish every valid raw sample synchronized with sensor
- store timestamp_sample from motion interrupt
- improve timing requirements from datasheet (minimum delays after register read/write)
bresch