Instead of blocking the receiver thread while playing a tune we now copy
the tune to a buffer and check if we can play the next note on each
iteration of the receiver thread.
The buffer and tune object is only created on the heap if we receive a
tune to play once and doesn't use resources otherwise.
The old tune device interface is not working anymore and we need to
publish to uORB tune_control.
This solution is not optimal though because blocks the receiving thread.
- this fixes the case where the navigator publishes a loiter waypoint or any
waypoint which is too close to the vehicle.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- bring in PX4/ecl#795 "EKF: Improve covariance prediction stability"
- the ecl/EKF filter update period has changed from 8 ms to 10 ms
- change default integration period 4000 us -> 2500 us (aligns with new EKF filter update period)
The device path is needed to apply PWM limits on the motors that are not
used for FW flight (switch them off). With this parameter the device path can be set
to either IO or FMU, depending on whether the motors are on the IO or FMU port.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
HTE runs based on the position controller so, even if we whish to use
the estimate, it is only available in altitude and position modes.
Therefore, we need to always initialize the hoverThrottle using the hover
thrust parameter in case we fly in stabilized
Adjusting the tilt limit can lead to diverging position control
and should only be used by setting a sanity limit for the controller
and not to adjust during the descent phase of a Land or RTL.
Otherwise it leads to flyaways in important failsafe modes when
there's stronger disturbance e.g. wind.
The hover thrust estimator (HTE) starts to run after the first thrust
setpoint is published. Until then, the feedforward of the vertical
velocity controller was unitialized (= 0). This is now set to hover
thrust parameter until the estimate is available.
* commander: add check for VTOL airfame on fmu-v2
This adds a preflight check when a VTOL airframe is configured
on a fmu-v2 where VTOL is no longer included.
* commander: address code review comments
This is a corner case that happens when the user wants to command an
altitude change just after a takeoff. Takeoff doesn't set the current
lat and lon therefore the user had to change altitude twice to get it working.
The first time to set the current lat and lon and the second time to
actually change altitude.
Before this check we were free to fly outside of a geofence with a goto
command. With this check we ignore the command if the location of the goto
is outside the fence. If this is the case we send back a mavlink warning to
the ground station.
As some tiltrotor systems need a certain tilt angle of their motors in oder to spin up freely,
this commit introduces an additional parameter VT_TILT_SPINUP and sets the motor tilt to
this value if disarmed or within 1s since arming.
The spinup consists of 2 phases:
1st phase fixed tilt (duration hardcoded to 1s)
2nd phase transition from spinup tilt to multicopter tilt (hardcoded to 0.5s)
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
If the user disconnects USB we reboot the system to bring it back into a nominal condition before arming. Otherwise we would either have the USB stack running without a cable connected (code running for no reason, which is violating the principle of not running unnecessary code in aviation). Or we would not allow to arm at all if USB was ever connected, which can be confusing if the system is powered off a battery.
Before _was_landed was set to the same value as the current
_land_detector.landed, thus outside of the update condition,
_was_landed && !_land_detector.landed could never be true.
This affects setting the home position, which is now set upon arming AND
upon takeoff.
If arming and already !landed, _have_taken_off_since_arming will not be set
and thus auto-disarm after 10s will be triggered (with default config).
This can only happen due to quick state changes, as land detector generally
sets landed=true if !armed.
Julian Oes