- 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
- 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)
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 b64abf48b2
This caused bad altitude control performance when enabling
terrain following. It even leads to complete vertical control
instability in case dist_bottom is inaccurate.
Relying on the estimator states is the way to go instead of
silently using one altitude source as state.
- split out integrated data into new standalone messages (sensor_accel_integrated and sensor_gyro_integrated)
- publish sensor_gyro at full rate and remove sensor_gyro_control
- limit sensor status publications to 10 Hz
- remove unused accel/gyro raw ADC fields
- add device IDs to sensor_bias and sensor_correction
- vehicle_angular_velocity/vehicle_acceleration: check device ids before using bias and corrections
* Treat UAVS diffrently from manned aviation
* Added fake_traffic testing functionality,
* Added NAV_TRAFF_AVOID Hold and Landmode
* Added Behavior: HOLD Position to collision avoidance mode and implemented Landmode to collision avoidance.
Boards where no Hardware GUID is defined will send 0 as GUID.
Right now collision avoidance for more than one FMU without Hardware GUID is not possible.
We should consider adding a randomly generated HW GUID as a placeholder for legacy Boards
The bulk of this change was tightly coupled and needed to be deleted in one pass. Some of the smaller changes were things that broke as a result of the initial purge and subsequently fixed by further eradicating unnecessary platform differences. Finally, I deleted any dead code I came across in the related files I touched while going through everything.
- DriverFramework (src/lib/DriverFramework submodule) completely removed
- added dspal submodule in qurt platform (was brought in via DriverFramework)
- all df wrapper drivers removed
- all boards using df wrapper drivers updated to use in tree equivalents
- unused empty arch/board.h on posix and qurt removed
- unused IOCTLs removed (pub block, priv, etc)
- Integrator delete methods only used from df wrapper drivers
- commander: sensor calibration use "NuttX version" everywhere for now
- sensors: update to px4_{open, read, close} instead of DevMgr wrapper (adc open for analog differential pressure)
- battery_status: update to px4_{open, read, close} instead of DevMgr wrapper (adc open for analog differential pressure)
- cdev cleanup conflicting typedefs and names with actual OS (pollevent_t, etc)
- load_mon and top remove from linux boards (unused)
- delete unused PX4_MAIN_FUNCTION
- delete unused getreg32 macro
- delete unused SIOCDEVPRIVATE define
- named each platform tasks consistently
- posix list_devices and list_topics removed (list_files now shows all virtual files)
Azarakhsh Keipour