If logger is started very early, orb_exists() will fail for a lot of
topics, they will be advertised within the next few seconds.
Logger already dynamically adds subscriptions during logging, but if we
do that before as well, we'll avoid any delays and having to subscribe
to a lot of topics all at once.
To keep track of the configured interval, we store it as negative file
descriptor, until we do the subscription.
This frees up a considerable amount of file descriptors in most use-cases.
Existing users of orb_exists:
- logger (dynamic subscribe to multi-instances)
- mavlink (orb subscription)
- sdlog2
- preflightcheck (check for home_position)
- wait_for_topic shell command (it's not used)
- orb_group_count() (sensors: dynamic sensor addition)
All use-cases benefit from the changed semantics: they are really only
interested if there is a publisher, not another subscriber.
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.