It is possible to either set the keyfile locations in board configuration or
with the same environment variables as before.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
This is more logical place for the "backend" implementation than
directly under platform.
This also allows making other implementations as "real" drivers, as well as proper configuration via Kconfigs
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
- 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.
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
- remove GPS failsafe mode
- for VTOL: transition to hover in Descend (unless NAV_FORCE_VT is not set)
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This fixes the case where oneshot was enabled with multi-instance pwm_out,
triggering oneshot updates too close to each other and as a result could
lead to spinning motors while disarmed.
The defaults changed in the previous commit for per-channel params,
so we make sure that the overall params are still used as long as the
per-channel params are default.
This happened with multi-instance, when the second instance did not load
a mixer. Then the first instance would always return false in
update_pwm_out_state, and continuously call up_pwm_servo_arm.
This led to irregular pulses, e.g. with an output set to fixed 1500us, I
saw pulses of e.g. 1800us occationally (they were in a range of
[1500-2100]).
Jukka Laitinen