this makes debugging devices much easier. You can even write a
primitive SPI or I2C device driver over mavlink.
Support for this is in the devop MAVProxy module
RC_Channel: To nullptr from NULL.
AC_Fence: To nullptr from NULL.
AC_Avoidance: To nullptr from NULL.
AC_PrecLand: To nullptr from NULL.
DataFlash: To nullptr from NULL.
SITL: To nullptr from NULL.
GCS_MAVLink: To nullptr from NULL.
DataFlash: To nullptr from NULL.
AP_Compass: To nullptr from NULL.
Global: To nullptr from NULL.
Global: To nullptr from NULL.
The problem with reporting the mission index, is that the mission index will be walked
forward until its referring to a nav target, which means that if a DO_ command was
requested, the requesting mavlink device had no way to validate the command was
accepted, it would have to make a infrence from it's copy of the mission
In GCS_MAVLINK::stream_trigger(), chan_is_streaming would be checked
with a bitwise OR, instead of a bitwise AND. This way, the condition
would always be true if chan_is_streaming were to be non-zero.
this ensures we give some buffer space for parameter fetch when we are
low on buffer space
we reserve 100 bytes for 2 seconds after a param fetch fails due to
low buffer space
This has no side effects, but since all implementations were basically
the same, move the implementation to GCS_Common and the only part that
adjusts the rate based on which which stream to each individual
GCS_MAVLINK implementation.
This header is used by waf to contain the generated version macros,
particularly using the git hash. For waf it's better to be in a separate
header since it then can keep track of changes on it a trigger
recompilation.
For the make build system, a dummy ap_version.h file has been added in
the missing/ folder so both implementations can co-exist.