Currently installing MAVProxy pulls pymavlink in as a dependency, so we
end up running whatever MAVProxy's master branch is pointing to
(currently pymavlink>=2.3.3).
ardupilot master can reference a pymavlink commit which is not part of
whatever MAVProxy's master branch is pointing to, so we end up with
failures like this in autotest:
fly.ArduCopter:
Mount (Test Camera/Antenna Mount) ('module' object has no attribute 'MAV_CMD_DO_SET_ROI_SYSID') (see /mnt/volume_nyc3_01/autotest/APM/buildlogs/ArduCopter-Mount.txt)
FixedYawCalibration (Test Fixed Yaw Calibration) ('module' object has no attribute 'MAV_CMD_FIXED_MAG_CAL_YAW') (see /mnt/volume_nyc3_01/autotest/APM/buildlogs/ArduCopter-FixedYawCalibration.txt)
If we install pymavlink after installing MAVProxy we should end up with
the pymavlink messages generated from the messages in our mavlink
subdirectory, rather that the pymavlink messages shipped as part of the
pymavlink pip release.
This is where the library is expecting to find the scripts directory.
The existing setup assumes that autotest has been run from the root
directory - that's not always the case. For example, the autotest
server starts everything one-up from the root directory.
recv_match's result is not iterable; it just gives you a single message.
printing the stacktrace when assigning to ex is tradition - we tend to
lose the stack traces otherwise
rebooting sitl is usually required if the context we've just popped had
a reboot in it (usually indicating a reboot-required parameter was set).
So I added a reboot after the context pop.
This should fix parameter building on the Windows CI autotest.
We allow empty lines between @Param blocks and the parameter (and, in
fact, require it before multi-entry @GROUPINFOs like vectors).
The regex wasn't taking into account Windows will have \r\n on that empty
line rather than just \n
These are just terrible defines to have in a header which can be
included into random files. These symbols can confuse construction of
enumerations, for example.
