- in a lot of cases this won't really matter, although you can see it in logs (especially with things like vehicle_at_rest), but it's something we might as well do properly
Co-authored-by: Mathieu Bresciani <brescianimathieu@gmail.com>
Fixes a regression from 8bae4e5c0e29f70d5d1d2427ffdef97092be939c, where
the orbit flight task wasn't an extra task (flight_tasks_to_add) anymore
and therefore the command handling wasn't generated.
There was a race condition that could cause several outcomes. The most severe
was that flight_mode_manager gets the command, switches to orbit and then
in the next iteration switches back because commander did not change
nav_state yet. When commander then switches, flight_mode_manager would still
be in the old mode.
This is prevented by storing the command (allowing it to arrive before or
after mode switch), and then apply it after the switch happens.
- 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>
