Instead of just checking whether the first waypoint is too far away from
home it makes sense to also check between waypoints.
This can prevent
- flyaways due to user errors, or
- catch the corner case where a takeoff waypoint is added to a mission
and therefore the first waypoint is not too far away, however, the
subsequent waypoints are still too far away.
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
- initialize rc lost with true
- refactor for simpler downstream code-plugin
- allow for the addition of different binding commands
- fix st24 RC lost logic
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.
Julian Oes