The previous boot configuration took at minimum one second to boot. This is in particular significant in tests when the system is often started and stopped
The test was testing the result of 3D float vector operations with binary equality of the floating point numbers, which is not a valid assumption to make for floating point math. This change switches to proper comparisons with float accuracy and compares vectors using the norm of their difference.
This is a check to protect a user from upload a mission which includes a
land_start marker as well as a RTL mission item.
This works around the problem that we experienced where the navigator
would switch to mission mode on RTL and start with land_start, and then
continue to the RTL item. At this point, navigator would send the
vehicle_command for RTL to commander which would deny it because it is
already in RTL mode. Thus navigator won't (re)set any items to actually
do RTL and it means the vehicle will just head to whatever setpoint it
received last.
A VTOL mission can also contain a fixedwing landing. Therefore, I think,
it makes sense to run the fixedwing checks as well, however, don't check
for a landing start necessarily.
by keeping only recursive topics in there. The rest is checked by looking
at previous _subscriptions.
Reduces stack size requirements when increasing MAX_TOPICS_NUM.
used back in time when no soothing was done to avoid large steps when
the estimator stops sending a maximum velocity (e.g.:GPS gained during
optical flow flight). Since smoothing is applied later, this is not
required anymore.
This fixes a corner case for VTOL RTL with RTL_TYPE 1.
RTL_TYPE 1 means that the VTOL skips all waypoints on RTL and jumps to
the land waypoint at the end.
During a mission in fixedwing mode it will continue to fly in fixedwing
mode and then do a transition before landing.
However, if RTL is engaged right at the moment of the front transition,
the transition waypoint is not inserted and the VTOL will try to land in
fixedwing mode at the mission land location.
This corner case is fixed in this patch by also considering the
"transition after takeoff" state.
Open the UART after adding the instance: mavlink_open_uart() might block,
and in that case the parent task waiting for mavlink to be started times
out.
And while waiting for the USB UART device to come up:
- check for _task_should_exit
- check for check_requested_subscriptions()
Side-effects when USB is not plugged in during boot:
- reduces boot duration by 100ms
- fixes duplicate instance name in 'top':
201 mavlink_if0 1 0.000 1328/ 2572 100 (100) w:sig 3
204 mavlink_if0 572 4.221 1632/ 2540 100 (100) w:sig 4
- 'mavlink stop-all' now stops the usb instance as well
Daniel Agar