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.
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
if _ftp_on is true, message_buffer was created and read, but it was
actually never written to, so this is not needed. It can only ever be
written to if _forwarding_on is true.
This will initialize those structs with zero in all fields not set
and all fields set will only be change once to the final value not
wasting CPU time zeroing it.
This will guarantee that no non-unitialized structs will have
a trash value on from_external causing it to be sent to the
MAVLink channel without need it.
The previous approach was checking system id and component id but it
will not work in 100% of cases as external devices can send MAVLink
message with the right system id but with broadcast component id.
The message handling was not obeying action focused messages and high-rate messages properly before. With this change update rates track the desired rates closely. Critical high-rate messages such as ADS-B are queued additionally to guarantee that all received packets are being correctly forwarded.
This adds a class to allow for retransmission of outgoing commands.
The sent commands are kept in a timestamped list to check if they are
acked as required by the mavlink protocol.
If they are not acked within a timeout, they can be retransmitted.
This allows the ground control station or any other communication partner to query the supported versions. The key aspect is to send the response in MAVLink 2 framing to test the link with a MAVLink 2 framed message.
This speeds up parameter loading. Slow links like telemetry are unaffected,
since the mavlink loop runs only with ~100Hz.
Tested on various links, like:
- telemetry link
- pixracer WiFi
- pixracer USB
- SITL
Vasily Evseenko