# need to wait for a heartbeat to arrive as then mavutil will
# select the correct set of messages for us to receive in
# self.mav.messages. You can actually recieve messages with
# recv_match and those will not be in self.mav.messages until
# you do this!
Also, wait_heartbeat ignores heartbeats from e.g. MAVProxy
This highlights the fact that fetching rally points using the mission
item protocol does some when you're talking mavlink1 doesn't work out
well.
# so this looks a bit odd; the other end isn't sending
# mavlink2 so can't fill in the extension here.
It was observed from a log of a failed CI test that the ACK from
clearing the rally items took 6 wallclock seconds to arrive.
We were not waiting for that ACK to arrive before sending the request
for the mission item count, but if it has taken more than six seconds
for the ACK to arrive it is reasonable to assume that MISSION_COUNT
could very well take more than the 10 seconds we allow for it.
If we drain the mav before sending the request for the mission count we
should remove any signficiant timing problem due to a backlog of mavlnk
messages, but the amount of traffic here is problematic.
Also drain in lots of other places where we might be spending way too
long parsing messages.
MAVProxy's output is read by autotest via pexpect.
SITL's output is read by MAVProxy.
If we don't read MAVProxy's stdout then it doesn't read SITL and
everything stops.
Also, since we need to drain pexpects as part of reboot, and applying
parameter files requires rebooting... we need to append the expect
objects to the global list before we apply parameter files. So move
that call.
Peter Barker
Justin Clift
yaapu
bnsgeyer
dorovl
Rishabh Singh
Andy Piper
Pierre Kancir
Pierre Kancir
andresrcdev
auturgy
Andrew Tridgell
Iampete1
bugobliterator