- handle saving the mag bias per sensor (across all estimator instances using that mag) in sensors/vehicle_magnetometer
- this is now saving back to the actual mag calibration CAL_MAGn_OFF{X,Y,Z}
- ekf2 reset mag mag bias on any magnetometer or calibration change
- use Kalman filter scheme to update stored mag bias parameters using all available bias estimates for that sensor
Co-authored-by: Paul Riseborough <gncsolns@gmail.com>
The case when acceleration setpoints were being passed in offboard mode was triggering control_climbrate_mode. This prevented the vehicle from taking off, since it made the vehicle skip the rampup phase of the takeoff
This commit fixes this by handling the case properly
- main motors are the ones which are meant to be used as propulsion in fw mode
- alternate motors are the ones usually meant to be switched off in fw mode
Signed-off-by: RomanBapst <bapstroman@gmail.com>
Do not use LOITER_TO_ALT for rotary wing mode as it would then always climb to
at least MIS_LTRMIN_ALT, even if current clib altitude is below
(e.g. RTL immediately after take off)
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- especially when there are strong winds it's better to just go straight
to the landing point instead of trying to follow the planned path
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- if vtol and in rotary wing mode then don't execute the mission landing
because it's designed to be flow as a fixed wing
- if vtol and in rotary wing mode and mission land is available then fly directly
to landing point and don't go home!
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- this fixes a race condition which happens when an RTL is triggered
during the final approach of a mission landing. In that case the mission inactive
method is never called.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- previously the decision of being on a landing pattern was taken by just
looking at the current mission index. However, even if the current mission
index indicates a landing pattern the vehicle could be at an arbitrary location, far
from being established on the pattern.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
NAV_CMD_LOITER_TO_ALT
- this allows vtol to track the loiter circle during the transition instead
of trying to fly to the landing position
Signed-off-by: RomanBapst <bapstroman@gmail.com>
This adds the option to limit the rate of change (slew rate) of an output that's mixed by a simple mixer.
To enable it, a positive number has to be added at the end (6th number) of the output scaler line of the mixer,
specifying the min rise time of this output.
E.g. O: 10000 10000 0 -10000 10000 20000 for a rise time of 2s, resp. a max slew rate of 0.5s^-1.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- the purpose is to ensure that every WorkItem (and WorkItems scheduled
by WorkItems) is allowed to run to completion every step
- per workqueue register a lockstep component whenever a work item is
added (if not already registered)
- once the work queue is empty unregister component
- this caused the navigator to use the next waypoint (after the vtol takeoff item)
to be used as target during the transition. If the altitude of that waypoint
was much higher than the takeoff altitude then there were FOH effects
after the transition which caused the vehicle to first descend before
climbing again.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
This commit increases the send thread stack size and changes the thread affinity of the lockstep clocking topic. It also improves verbosity in case error states occur.
- log all estimator (ekf2) flags as separate booleans in a new dedicated low rate message (only publishes at 1 Hz or immediately on any change)
- this is a bit verbose, but it avoids the duplicate bit definitions we currently have across PX4 msgs, ecl analysis script, flight review, and many other custom tools and it's much easier for casual log review in FlightPlot, PlotJuggler, csv, etc
- for compatibility I've left estimator_status filter_fault_flags, innovation_check_flags, and solution_status_flags in place, but they can gradually be removed as tooling is updated
Co-authored-by: Mathieu Bresciani <brescianimathieu@gmail.com>
