- vehicle_angular_velocity and vehicle_angular_acceleration are produced together from the same input data, consumed together, and share the the same metadata (timestamps)
- individually these topics each have 16 bytes of metadata (2 timestamps) for 12 bytes of data (x,y,z float32)
During the whole flight, if the difference between the yaw estimate from
EKF2 and the emergency estimator is large and that the GNSS velocity
fusion is failing continuously, immediately reset to the emergency yaw
estimate.
- with Ekf::initialiseFilter() resetting _time_last_hagl_fuse the terrain estimate was technically valid regardless of any range or flow data availability and as a result optical flow fusion is able to start and stay active
- only consider terrain estimate valid based on control status flags and recent fusion
The CameraFeedback module used only the vehicle attitude for the camera orientation so far. With this change, the gimbal_device_attitude_status is used to compute the global camera orientation when a gimbal is used.
In this case it did not cause any problems.
Fixes a compiler warning:
/src/modules/commander/HealthAndArmingChecks/HealthAndArmingChecks.cpp:39:21: error: member ‘HealthAndArmingChecks::_failsafe_flags’ is used uninitialized [-Werror=uninitialized]
39 | _reporter(_failsafe_flags)
| ^~~~~~~~~~~~~~~
* simulator_mavlink: Add basic vio failure injection
Signed-off-by: Paul Frivold <paul@kefrobotics.com>
* simulator_mavlink: Rm failure not supported warning
Failures commands are also handled in other files,
so warning here could be confusing.
Signed-off-by: Paul Frivold <paul@kefrobotics.com>
Signed-off-by: Paul Frivold <paul@kefrobotics.com>
previous change in logic to hold after mission clear also broke rtl, as non-mission takeoff still published a mission result which allowed entering the mission finished condition and always changing state to loiter (ignoring rtl). new logic only switches navigation states if mission is finish and the nav state is explicitly in takeoff state, or in mission state
once the rampup starts. The rampup requires a valid vertical velocity setpoint.
The corner case is:
- We are before takeoff and amending the setpoint to be 0,0,100 acceleration
in order to idle
- The rampup starts BUT the setpoint is not yet overwritten by the trajectory
setpoint topic
- The idle setpoint gets amended to not contain a feed-forward vertical
acceleration because the rampup is velocity based
- The result is a brief invalid 0,0,NAN acceleration setpoint
- That invalid setpoint gets overridden by a failsafe that holds zero velocity
- Zero velocity leads to applying ~hover thrust briefly
- buffer at least 2 samples for the IMU output predictor buffers
- dropping below 2 becomes problematic for the minimum observation
interval calculation and the vertical output buffer trapezoidal
integration
- preflight mag bias estimate is in the vehicle body frame and removed from the raw mag data after it's rotated, calibrated, etc
- in flight mag bias (from ekf2) is in the vehicle body frame, but stored as a sensor frame offset immediately
* Enable motor controls for fixed wing mode in tailsitters
This commit enable motor controls in fixed wing mode for tailsitters
This is needed for enabling quad tailsitters
* VTOL: differential thrust in FW: adapt params to be generic for all axes
Until now only suppoted on yaw axis. Not to be supported also on Roll and Pitch.
- VT_FW_DIFTHR_EN: make bitmask for all three axes independently. First bit is Yaw,
sucht that existing meaning of VT_FW_DIFTHR_EN doesn't change.
- VT_FW_DIFTHR_SC: rename to VT_FW_DIFTHR_S_Y and add same params for roll (_R) and
pitch (_P).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* Integrate differential control bits to three axis control
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
It's enough that the setpoints and the unallocated values are logged, from these
the allocated values can be calculated if required.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
It's very important that the in descend detection is always
at a strictly higher velocity than the vertical movement check.
This combination is basically used to check for vertical downwards
velocity tracking. Desired descend, no movement -> ground
If in descend threshold is lower than vertical movement it is
by definition even with perfect tracking the case that with
any velocity between the two thresholds there is no movement
even though a descend is commanded.
See first fix of this problem #7831e39b38ba96
I don't see where this is necessary. During takeoff, the maybe landed flag should
only get cleared once system is about to takeoff, and thus well after the spool up
is complete (for which the higher thresholds are meant in this case).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Don't consider these params for vertical speed threshold,
and instead increase the default for LNDMC_Z_VEL_MAX and
use solely that one. Makes the land detector outcome more
predictable and its interal logic simpler, while the new
default tuning is resulting in about the same vz threshold
as before.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Daniel Agar