- The parameter is shared with the manual mode's maximum horizontal thrust (renamed from OMNI_MAX_HOR_THR to OMNI_DFC_MAX_THR) defined in the mc_att_control module
- The definition for the OMNI_ATT_MODE moved from mc_pos_control module to mc_att_control
- The thrustToAttitude function now has additional omni_dfc_max_thrust parameter
- Test modules are fixed to call the new thrustToAttitude function appropriately
- The code is tested in Gazebo for both manual and (semi-)autonomous modes
- The goal is to use all the possible (set by the user) horizontal thrust first and then tilt if necessary, thus achieving minimum possible tilt.
- This is an implementation of the following paper for OMNI_ATT_MODE = 1:
"A Daisy-Chain Control Design for a Multirotor UAV with Direct Force Capabilities", M. Hamza and E.N. Johnson, 2017 AIAA GNC Conference
- Still need to define a parameter for the maximum direct force
- OMNI_MAX_HOR_THR parameter specifies the maximum horizontal thrust compared to the maximum possible thrust generated by the vehicle for an omnidirectional multirotor
- Some observations:
- It's still not as smooth as expected (or maybe I'm not a good pilot)
- Acceleration on the body X axis feels lower than the body Y axis (no idea why)
- Flight tested in Gazebo sim in both Manual and Autonomous modes
- The range for 3D-thrust in the 6-DOF multirotor mixer is changed to -1 to 1 now (fixed from 0 to 1)
- The Z thrust in the 6-DOF multirotor mixer is mapped to the Z-thrust command now (fixed from thrust command)
- The manual Z command in the rate controller maps to the negative Z-thrust (fixed from positive Z)
- The variable _thrust_body_sp in the rate controller renamed to _thrust_sp to be compatible with the older variable removed in the last commit
- The code tested in TakeOff, Manual, Hold, Position and Land modes on both tilted hex and iris
Accepting and working with 3D thrust commands now
- Tilt-Hex flies like a normal hex but with the new 6-dof mixer now (with some jitters)
- Some minor parameter changes in the hexa_x_tilt definition to make the simulated flight smoother
- landed, maybe_landed, or ground_contact required before the safety
button is able to disarm
- this reduces the risk of a faulty safety button triggering in regular
flight
- this is a new module for temperature compensation that consolidates the functionality previously handled in the sensors module (calculating runtime thermal corrections) and the events module (online thermal calibration)
- by collecting this functionality into a single module we can optionally disable it on systems where it's not used and save some flash (if disabled at build time) or memory (disabled at run time)
- ecl in PX4/Firmware (ac205456f93857f447595eb0005c954a78461778): 011b4c2e4e
- ecl current upstream: 950e75e484
- Changes: 011b4c2e4e...950e75e484
950e75e 2020-01-18 Matthias Grob - EKF_ringbuffer: minor missing space for style
26125c2 2020-01-17 kamilritz - Switch from jenkins to github actions
When having no velocity estimate the derivative was updated with zero.
When losing the velocity estimate this is fine since the resulting
derivative spike doesn't get used and acceleration is set to NAN.
But when regaining the velocity estimate the spike from zero to
the first estimated velocity gets used as acceleration in the position
controller and results in a twitch.
To solve this I use the derivative reset I introduced in pr #13522
commit b64abf48b211b66fbfc7a3b900adbbbdf0e2e14c
