- cmake NuttX build wrapper compile in place instead of copying source tree to build directory
- slightly faster skipping necessary copying (depending on system)
- allows debugging in place
- easier to work directly in NuttX following official documentation
- simplifies overall build which should make it easier to resolve any remaining NuttX dependency issues in the build system
- the downside is switching back and forth between different builds always require rebuilding NuttX, but I think this is worth the improved developer experience
- also no longer builds px4io and bootloader in every single build, for most users these rarely change and we're wasting a lot of build time
The current practice of adding topics to the default set isn't scalable,
as it affects all setups.
By making sure topics are advertised on init, logger can just discard
topics that don't exist. This does not work for all topics, so topics are
specifically marked as optional. It can be extended to more topics later
on though.
This reduces the list of topics by ~35 on a pixracer configured as quad,
and reduces RAM usage by ~1KB.
- numerically the cutoff frequency not being smaller than 1% of the
sample frequency is probably a better choice, but we're mostly filtering
16 bit data now stored in 32 bit float
Add interface functions for fetching latency buckets and counters and use
those in perf_counter.cpp. This cleans up the usage of perf counters, when variables defined in hrt_drv are not referenced directly from perf.
This also enables implementing kernel-userspace interface for those for
nuttx protected/kernel build.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
CA: fix saturation computation
Since the CA matrix is normalized, the same scale applied to be used when using the effectiveness matrix
MCRateControl: use control_allocator_status to get saturation info
The arming button required some refactoring in order to support to
toggle arm/disarm using the vehicle_command. Otherwise manual_control
would have to subscribe to the arming topic and we would spread out the
logic again, and risk race conditions.
* ekf2: make publishing of learned accel biases more robust
* ekf2: reset accel bias if calibration updated
* msg: add separate accel and gyro calibration counters
* ekf2: use separate accel and gyro calibration counters
* ekf2: rework logic to reset biases when calibration counters increment
* sensors: add saving of learned accel biases
* ekf2: generalized saving accel/gyro/mag in flight sensor calibration
* boards: holybro kakutef7 disable systemcmds/perf and systemcmds/top to save flash
Co-authored-by: Paul Riseborough <gncsolns@gmail.com>
- mavlink/mavlink is now directly included as a submodule instead of the generated mavlink/c_library_v2
- this also switches to mavlink development.xml by default
- added ability to specify maximum acceleration constraint for height rate setpoint
- added support for locking altitude setpoint when in height rate control
mode and height rate input is zero
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- bit of clean up
- add GPS failsafe mode auto_altitude, that will keep current altitude with a fixed-bank angle
for some time, then switches to auto_descend that will descend with constant sink rate
of 0.5m/s
- params controlling GPS failsafe are not FW params: NAV_GPSF_R --> FW_GPSF_R and
NAV_GPSF_LT --> FW_GPSF_LT
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
There is logic in L1 that prevents the vehicle from trying to achieve
an impossible loiter entry (e.g. due to wind). That check makes the
vehicle track the loiter center if the tangential velocity is in the wrong
direction while loitering. After the vehicle flies through the center, it can
then turn the other way around to join the loiter.
This check is though too sensitive if it purely checks for the wrong direction,
and it can end in delayed loiter entry for no reason.
This commit increases the threshold to 2m/s of tangential velocity
in the wrong direction to trigger the check.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
The situation where this would be desired is unclear, plus it's basically
the same as setting ASPD_SC_P_NOISE to a very small value.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Do no longer use tas_innovation from wind estimator and test ratio, but calculate
the innovation based on wind estimate, TAS measurement (including currently applied scale)
and ground velocity. Use innovations directly to trigger failure.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Thomas