Instead of using a timeout to resend a mission item, we should directly
send the mission request again. This is needed because we removed the
automatic resending which lead to troubles.
This is an attempt to fix mission upload and download with QGC on a
lossy link. The way it should work according to the protocol on
https://mavlink.io/en/protocol/mission.html is that in general
the ground station should be concerned about timeouts and
retransmission. This means the autopilot does not need to retransmit by
itself but just answer requests.
This seems like it would make the transfer less robust, however, it
actually resolves an edge case where QGC fails to make requests because
it gets spammed by the autopilot and keeps resetting the timeout.
ROI yaw control: configure yawing capability of mount in vmount parameters.
If configured that mount has no yaw control, vehicle will yaw towards ROI, irrespective of MIS_YAWMODE.
Vehicle will behave according to MIS_YAWMODE when there is no ROI.
or receiving a command that we need to handle. This makes sure that we
don't drop commands, when the output mode is set to mavlink (in that case
the input topic is rate-limited, and each input change results in a
vehicle_command publication, which results in queueing up orb items if we
get vehicle_commands from other sources too).
The way the broadcast IP is currently fetched is by sending an ioctl()
request. The limitation of this is that the broadcast address may not
be set on the network interface (more specifically, it is usually not
set in docker containers). In those cases, it results in the broadcast
address becoming 0.0.0.0, which is not valid [1].
This fix uses the network IP and the netmask to compute the directed
broadcast address. This should be more reliable, as both of those are
always set on the network interface.
[1]: https://tools.ietf.org/html/rfc1122, section 3.2.1.3 (a)
This fixes the case where a topic instance is already subscribed, and
advertised later. The subscriber will create the DeviceNode with default
priority, and the advertiser will just use the existing DeviceNode,
without updating to the requested priority.
This fixes the case where a new gimbal input gets lost in the output
throttling.
This is required because an input is potentially set only once and
then not computed again. In the failure case, control_data is set
to nullptr in subsequent calls and therefore not used for the output
calculation ever.
This resolves the case where a gimbal command assembled by
QGroundControl is rejected because the component id is set to 0 (for
all) and the component id of the vehicle is e.g. 1.
Align the way motor output is computed with the model used in the mixer generation script.
previous:
`out = (roll_gain*roll + pitch_gain*pitch + yaw_gain*yaw + thrust)*out_gain`
new:
`out = roll_gain*roll + pitch_gain*pitch + yaw_gain*yaw + thrust_gain*thrust`
which is the standard matrix*vector multiplication.
This commit has 0 effect on symmetric platforms (i.e. most) as thrust_gain==1 on these platforms.
On asymmetric platform --where some thrust_gain are lower than 1-- the previous formulation resulted in coupling between thrust and other axes.
fixes#8628
