arming_state_changed was not set in all places where an arming transition
occurred, for example when calling arm_disarm() from auto-disarm.
We did not notice because the state is published with at least 5 Hz already.
The size in g_per_item_size[item] is the real struct size
+ DM_SECTOR_HDR_SIZE bytes of header and the backend functions were
not taking in care it. So a call to dm_write() with more bytes than
the real struct is allowed, causing corruption in the header of the
next item.
Kudos to jeonghwan-lee for finding it. https://github.com/PX4/Firmware/issues/7927
There was and extra "nuttx" dir:
cp: cannot stat '/home/lucas/p/dronecode/PX4/Firmware/build/aerofc-v1_default/NuttX/nuttx/nuttx/.config': No such file or directory
FAILED: NuttX/CMakeFiles/menuconfig
And the board fixup being executed from the wrong working directory:
nuttx-configs/aerofc-v1/nsh/defconfig
fatal: Path 'nuttx-configs/aerofc-v1/nsh/defconfig' does not exist in 'HEAD'
- initialize rc lost with true
- refactor for simpler downstream code-plugin
- allow for the addition of different binding commands
- fix st24 RC lost logic
The config mode uses high rates for many streams, leading to high CPU usage
(9-10% for the mavlink sender). The normal mode contains almost the same
set of messages but at lower rates.
This reduces the CPU load on a Pixracer by 3-4%.
This change limits all mission items to the maximum flight altitude. The mission will still be executed and flown,
but the vehicle will never exceed the mission altitude. This ensures the vehicle can always reach the mission
items. Wether or not the entire mission should be rejected if it falls outside of the fenced area is enforced
in the mission feasibility checker function.
This commit is an attempt to fix a race condition happening on takeoff
between the land detector and the multicopter position controller.
Previously, an auto-takeoff leads to the following events:
1. A takeoff setpoint is given.
2. The thrust setpoint spikes because we don't enter smooth takeoff yet.
3. The land detector detects a takeoff because of the high thrust.
4. The position controller sees the landed state transition and
initiates the smooth takeoff. Thrust goes back down.
5. Depending on control gains the takeoff is successful or fails
if the smoothing takes too long which causes thrust to be too low, so
the land detector detects land again.
The two obvious problems with this are:
- The intermittent spike.
- The failed takeoff because of the smoothing leads to a delay..
With this change, the logic for a takeoff detection is moved from the
land detector to the position controller.
The events are now:
1. A takeoff setpoint is given.
2. The position controller detects the takeoff setpoint and initiates
the smooth takeoff.
3. As thrust ramps up, the land detector detects the take off.
In the same way, we now detect the intent to takeoff in manual,
altitude, control, position control in the position controller instead
of in the land detector.
