- 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)
- sitl_gazebo in PX4/Firmware (635ceccfdb9cf6bdd56ccfed5acb66d947959d50): a5b33417f7
- sitl_gazebo current upstream: 2f4b32723c
- Changes: a5b33417f7...2f4b32723c
2f4b327 2019-10-21 Martina Rivizzigno - typhoon sonar fix rotation such that the reported orientation metches the gazebo model
7db52d7 2019-10-18 Martina Rivizzigno - typhoon_h480: rotate sonar such that is forward facing
- 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
This should prevent debconf from asking questions during install.
Presumably, the exported env variable DEBIAN_FRONTEND is not taken into
account in a sudo command, hence we need to add it every time.
As far as I know these dependencies are only ever required when doing
analysis in ECL. At that point developers should be confident to add
what is required.
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
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
- this provides some extra space when the FIFO transfers don't align perfectly
- I've also made an effort to keep the different drivers (icm20602, icm20608g, ism330ldc) in sync so we can factor out the common portions later once we've confident in the pattern.
* 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
