- if a channel receives an ack for a command, do not immediately remove the
command item from the send queue but wait until the next ack timeout occurs.
This gives other mavlink channels time to try to put identical commands into
the send queue.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- if we receive an ack for a command through a specific mavlink channel
then do not drop the corresponding command in the queue if this specific
mavlink channel did not issue the command. If we don't do this we can
end up in a situation where we associate an ack coming through a specific
mavlink channel to a command in the queue which was not requested by this mavlink channel.
Moreover, the actual command for which the ack was meant remains in the
queue and eventually triggers a timeout.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
This adds a class to allow for retransmission of outgoing commands.
The sent commands are kept in a timestamped list to check if they are
acked as required by the mavlink protocol.
If they are not acked within a timeout, they can be retransmitted.