The only downside is that it needs to update on the TaskInfo object which means
since htat updates periodically this code runs more often that really needed since
the modules only start at first. However, leaving that connection out means it
misses the initial set of modules.
1. If a flight mode switch allows autotune and autotune module not running
2. If airframe is a multirotor and either manual is available or a stabilization mode uses "none"
This new UAVO serves principally to log data for future comparison with
onboard estimation techniques.
Conflicts:
ground/openpilotgcs/src/plugins/hitl/il2simulator.cpp
ground/openpilotgcs/src/plugins/hitl/simulator.h
Previously, when unconnected, only the flighttelemetrystats
UAVO was Tx'd. All other UAVOs were inhibited. This led to
zero telemetry data when the connection to the GCS was gone.
This precluded getting useful telemetry from a receive-only
station.
This commit changes two main areas.
First, UAVO updates are now allowed regardless of the "connected"
state between the GCS/FC.
Second, it makes both the flighttelemetrystats and gcstelemetrystats
UAVOs un-acked. This prevents these objects from blocking all
other UAVOs while they wait for their ack. This is OK since the
real "connection" negotiation happens via the states exchanged in
the Status field of these UAVOs.
This removes the detailed output of the GCS build by
default so that warnings and errors become more evident.
Full output can be enabled by adding "V=1" to the make
command line. Same mechanism as is used for the firmware
builds.
are downloaded
In the case of a flaky connection this will render telemetry mostly masked
from the activities. However, it ensures that all the information is present
after a connection.
Some compromise is probably needed for using this in the field, such as a
tiered system:
1. Physical channel open (no idea about reception)
2. Link estabilished (at least some reception)
3. Full telemetry established (all objects synced up)
We allow sending objects that don't create a transaction while waiting for one
to complete. However, this was overriding the pending transaction information
(when there wasn't a new transaction) and masking the transaction completed
message.
Note: I think this logical error can occur on the GCS side and might explain the
"transaction completed when not expected" messages.
