* uORB orb_stat() and update(uint64_t *time, void *dst) are now obsolete and have been deleted
* mavlink messages add more advertised checks in streams get_size() check to improve data rate calculation across different scenarios
The mission logic depends in a number of locations on being able to calculate the direction from one waypoint to another. Missions that have waypoints that are in the same physical location do not make sense and need to be rejected (the GCS / SDK generating them needs to be fixed). By enforcing this we can work with a reasonable and simpler state machine while executing the mission.
A mission with zero elements is invalid but should not lead to a warning. Previously a fixed wing aircraft without a mission did emit warnings about a missing land item.
This enables the navigator to wait for a specific gate coordinate to pass orthogonally to the current trajectory. This is particularly helpful for payload / camera handling in missions and avoids a dependency of payload handling on navigation waypoints.
* MC_HTE: unitialize with hover_thrust parameter
* MC_HTE: constrain hover thrust setter between 0.1 and 0.9
* MC_HTE: integrate with land detector and velocity controller
* MCHoverThrustEstimator: Always publish an estimate even when not fusing measurements. This is required as the land detector and the position controller need to receive a hover thrust value.
* MC_HTE: use altitude agl threshold to start the estimator
local_position.z is relative to the origin of the EKF while dist_bottom
is above ground
Co-authored-by: bresch <brescianimathieu@gmail.com>
Running the sensors module out of the same WQ thread as the estimator, position, and attitude controllers is a bit safer and prevents potential priority and starvation issues. There is a very small increase in latency (~50 us) between sensors and ekf2 execution (on average). This also saves a little bit of memory (~ 3 kB) and cpu (~1-1.5% depending on the board).
The implementation before this change had two timeouts, a hard-coded
timeout of 0.5 seconds as well as a by param configurable timeout with
certain failsafe actions set.
This change aims to fix two problems:
1. The hard-coded offboard timeout can be triggered easily with sped up
lockstep simulation. Since i t is hard-coded it can't be adapted to
the speed factor.
2. The offboard signal can time out but no action will be taken just
yet. This means we end up in an in-between stage where no warning or
failsafe action has happened yet, even though certain flags are set
to a timeout state.
This patch aims to fix this by unifying the two timeouts to the existing
configurable param. The convoluted double timeout logic is replaced by a
simple hysteresis.
For anyone that has previously not changed the default timeout param (0),
the param will now be changed to 0.5 seconds which reflects the
previously hardcoded time. For anyone with a specific timeout
configured, the behaviour should remain the same.
Also, going forward, timeouts lower than 0.5 seconds should be possible.
When lockstep is enabled and LPE is not running, the
attitude_estimator_q needs to publish ekf2_timestamps in order to signal
to the simulator module that it has fully run.
This essentially fixes flying in lockstep when SYS_MC_EST_GROUP is 3.
This change is necessary to give the pilot the ability to switch VTOL state
even if for some reason no attitude sp are published anymore.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Daniel Agar