and remove the px4_ prefix, except for px4_config.h.
command to update includes:
for k in app.h atomic.h cli.h console_buffer.h defines.h getopt.h i2c.h init.h log.h micro_hal.h module.h module_params.h param.h param_macros.h posix.h sem.h sem.hpp shmem.h shutdown.h tasks.h time.h workqueue.h; do for i in $(grep -rl 'include <px4_'$k src platforms boards); do sed -i 's/#include <px4_'$k'/#include <px4_platform_common\/'$k/ $i; done; done
for in $(grep -rl 'include <px4_config.h' src platforms boards); do sed -i 's/#include <px4_config.h/#include <px4_platform_common\/px4_config.h'/ $i; done
Transitional headers for submodules are added (px4_{defines,log,time}.h)
This adds a flight task to catch the case where we want to do an
emergency descent without GPS but only a baro.
Previously, this would lead to the navigator land class being called
without position estimates which then made the flight tasks fail and
react with a flight task failsafe. This however meant that landed was
never detected and a couple of confusing error messages.
This applies if NAV_RCL_ACT is set to 3 "land".
added and using circuit_breaker_enabled_by_val() where possible instead of circuit_breaker_enabled() which search for cbrk parameters by name, which is extensive process.
Condition to enter the prearmed state, an intermediate state between disarmed and armed
* in which non-throttling actuators are active.
*
* @value 0 Disabled
* @value 1 Safety button
* @value 2 Always
* the large 20% margin is no longer appropriate now that nearly all work in the system is
scheduled (moved out of ISRs) and represented in the load percentage
* closes https://github.com/PX4/Firmware/issues/12753
This allows to bypass preflight and prearm checks.
During development there are regular cases where I just want to arm the
board/vehicle no matter what, and the preflight checks are guaranteed to
fail (e.g. sensors uncalibrated, inconsistent, powered via USB, etc.).
Allowing an easy and quick way to arm (assuming you know what you are
doing) helps to speed up development considerably and is less frustrating.
* This fix is necessary because usually uORB structs get initialized with
all zeros and then get filled with the fields that are actually in use.
* The number 0 for the mode slot was already commanding to switch to the
mode in slot one even though for example the joystick input via mavlink
does not use this mechanism at all.
This fixes the terrifying case where the drone disarms in-air just
because it receives a MAVLink disarm command. We now check param2 for a
magic number which enforces arming/disarming.
This is added to the mavlink protocol in:
https://github.com/mavlink/mavlink/pull/1162
AAs discussed in the devcall this functionality is only useful for
rotary-wing (multicopter) flying since it's a big safety hazard to
accidentally bring a fixed wing out of an auto mode e.g. a mission
and fly away in a straight line or into an obstacle.
