Signed-off-by: RomanBapst <bapstroman@gmail.com>
commander: support orbit mode for fixed wings
Signed-off-by: RomanBapst <bapstroman@gmail.com>
FwPositionControl: publish orbit status
Signed-off-by: RomanBapst <bapstroman@gmail.com>
commander:reject orbit mode while doing a vtol transition
Signed-off-by: RomanBapst <bapstroman@gmail.com>
FixedWingPositionControl: explicitly cast waypoint for Orbit status
FixedwingPositionControl: fill missing orbit_status fields
navigator_main: handle reposition/orbit corner cases
- set orbit rotation direction correctly
- send mavlink message when orbit is rejected
FixedWingPositionControl: correctly report rotation direction in orbit_status
navigator: hack to not break orbit while doing altitude changes
Signed-off-by: RomanBapst <bapstroman@gmail.com>
navigator: set cruise throttle for orbit command
Signed-off-by: RomanBapst <bapstroman@gmail.com>
The situation where this would be desired is unclear, plus it's basically
the same as setting ASPD_SC_P_NOISE to a very small value.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Do no longer use tas_innovation from wind estimator and test ratio, but calculate
the innovation based on wind estimate, TAS measurement (including currently applied scale)
and ground velocity. Use innovations directly to trigger failure.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
As the purpose of this wind estimator is to (mainly) catch airspeed failures,
we don't value estimator stability as much as the reliability to catch
actual sensor issues, and thus do not reset the filter (as this may hide
a real issue with the sensor)
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- run airspeed scale estimation always, not in dedicated mode
- add option to apply scale automatically, with extra feasibility check
- add airspeed scale for all 3 possible airspeed instances
- clean up parameters
- add check for data stuck (non-changing airspeed data)
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Not accepting the waypoint causes the vehicle to perform a sharp turn after passing
the land waypoint and this causes worse unexected behavior.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
When the change in velocity is exactly the same on several axes, the T1
of the recumputed trajectories after time sync was set to 0 because it
was skipping both if and else if.
This fixes the case where oneshot was enabled with multi-instance pwm_out,
triggering oneshot updates too close to each other and as a result could
lead to spinning motors while disarmed.
The defaults changed in the previous commit for per-channel params,
so we make sure that the overall params are still used as long as the
per-channel params are default.
This happened with multi-instance, when the second instance did not load
a mixer. Then the first instance would always return false in
update_pwm_out_state, and continuously call up_pwm_servo_arm.
This led to irregular pulses, e.g. with an output set to fixed 1500us, I
saw pulses of e.g. 1800us occationally (they were in a range of
[1500-2100]).
