Instead of using a timeout to resend a mission item, we should directly
send the mission request again. This is needed because we removed the
automatic resending which lead to troubles.
This is an attempt to fix mission upload and download with QGC on a
lossy link. The way it should work according to the protocol on
https://mavlink.io/en/protocol/mission.html is that in general
the ground station should be concerned about timeouts and
retransmission. This means the autopilot does not need to retransmit by
itself but just answer requests.
This seems like it would make the transfer less robust, however, it
actually resolves an edge case where QGC fails to make requests because
it gets spammed by the autopilot and keeps resetting the timeout.
The way the broadcast IP is currently fetched is by sending an ioctl()
request. The limitation of this is that the broadcast address may not
be set on the network interface (more specifically, it is usually not
set in docker containers). In those cases, it results in the broadcast
address becoming 0.0.0.0, which is not valid [1].
This fix uses the network IP and the netmask to compute the directed
broadcast address. This should be more reliable, as both of those are
always set on the network interface.
[1]: https://tools.ietf.org/html/rfc1122, section 3.2.1.3 (a)
The debug messages are too verbose to be run in a production vehicle and inherently were something that should only be run in SITL / debug sessions on hardware. Switching the flag to the PX4_DEBUG() macro does not only make this more explicit, but also saves a lot of flash space that otherwise was consumed by the strings.
No functional change, but this avoids numerical issues in the check routine. Since the routine will tend to false positives, we will tend to send more param updates than required in case of numerical noise of the float representation. This is desired, as we prefer to send two updates rather than not sending one.
Parameters can change not just based on GCS request, but also due to internal code or requests by a different valid connected control authority such a cloud service. This change ensures that all connected systems get updated via MAVLink asynchronously.
Most of the incompatitbilities are luckily similar to the darwin build.
- New target OS __PX4_CYGWIN added because in other build environments on Windows defines will very likely be completely different
- added all necessary exeptions to the defines
- disabled priorities completely because on Windows they are defined 1-32 and with all the arbitrary +40 -40 priority settings there were a lot of problems
not only did some threads/"virtual tasks" not start because of out of bound priorities but also the resulting scheduling was totally random and inadequate
with default priorities it ran toally fine during my first tests, should be rethought when windows is used onboard in the future
Paul Riseborough