Tailsitter VTOLs very occasionally gets stuck with zero roll and pitch angle in multicopter mode after
a forward transition command is issued.
This very rare behavior is triggered by the following events:
1> a forward transition is triggered either in auto or manual mode.
2> in the vtol_att_control main loop, if multicopter and fixed wing attitude setpoints are not updated, transition state is not updated
3> the commander changes the vehicle status to transition mode.
4> multicopter pos controller initiated Transition flight task. This results in zero roll and pitch setpoint due to zero acceleration setpoint
5> now vtol_att_control executes and updates the transition state. Specifically, _q_trans_start and _q_trans_sp are set with zero roll and pitch sp
6> tilt is evaluated to be NaN, despite _q_trans_sp being normalized. This happens for 25% of all yaw angles when using float datatype. This can be
verified using the matrix library
7> once tilt is evaluated to be NaN, _q_trans_sp is never updated again and is stuck in this state for ever.
This has been fixed by constraining the cos(tilt) within +1 to -1 range
Further, _q_trans_start and _q_trans_sp are immedietly initialized after a transition event is triggered.
- parameter updates can be quite expensive because they trigger nearly all modules to reload all of their parameters immediately
- limit modules from updating faster than once per second
This sets the throttle of the Multicopter actuators to the throttle stick position
while in Stabilized, Acro or Manual mode.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- 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>
- split out switches from manual_control_setpoint into new message manual_control_switches
- manual_control_switches published at minimal rate (~ 1 Hz) or immediately on change
- simple switch debounce in rc_update (2 consecutive identical decodes required)
- manual_control_switches logged at full rate rather than sampled at (5-10% of messages logged)
- manual_control_setpoint publish at minimal rate unless changing
- commander handle landing gear switch for manual modes
- processing of mode_slot and mode_switch is now split so we only do one or the other (not both)
- a future step will be to finally drop mode_switch and accompanying switches entirely
Co-authored-by: Matthias Grob <maetugr@gmail.com>
- this is to prevent vtol_att_control running at absurdly high rates (kilohertz) from every single actuator controls publication from both the multicopter and fixed wing controllers
- I don't really like this solution, but it works for now until there are larger VTOL architectural changes in place
- create common uORB::PublicationBase
- uORB::PublicationQueued types are now type aliases
- ORB_PRIO use enum type everywhere to avoid accidental misuse
- PX4Accelerometer/PX4Gyroscope/etc driver libs explicitly advertise on construction, unadvertise on destruction. This is a workaround for any potential issues that might appear when accel/gyro cdev and uORB indexing doesn't align.
* VTOL type: add new parameter VT_FWD_TRHUST_EN for customizing pusher/tilt assist
Depending on the setting of this param, the pusher assist is:
-completely disabled (default)
-enabled in pos, alt and auto mode (except LAND)
-enabled in pos, alt and auto mode if above MPC_LAND_ALT1
-enabled in pos, alt and auto mode if above MPC_LAND_ALT2
-enabled in pos, alt and auto mode
(before it was always disabled in LAND mode)
-change default of VT_FWD_THRUST_SC from 0 to 0.7
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
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>
Beat Küng