and remove the px4_ prefix, except for px4_config.h.
command to update includes:
for k in app.h atomic.h cli.h console_buffer.h defines.h getopt.h i2c.h init.h log.h micro_hal.h module.h module_params.h param.h param_macros.h posix.h sem.h sem.hpp shmem.h shutdown.h tasks.h time.h workqueue.h; do for i in $(grep -rl 'include <px4_'$k src platforms boards); do sed -i 's/#include <px4_'$k'/#include <px4_platform_common\/'$k/ $i; done; done
for in $(grep -rl 'include <px4_config.h' src platforms boards); do sed -i 's/#include <px4_config.h/#include <px4_platform_common\/px4_config.h'/ $i; done
Transitional headers for submodules are added (px4_{defines,log,time}.h)
Without lockstep the actual monotonic clock of the host computer is
used. Therefore, this time is likely much more than 20 seconds and the
check if the boot complete happened in time will fail immediately.
Therefore, it probably makes more sense to count the time from the first
mavlink creation.
This fixes the regression where we saw this in SITL:
ERROR [mavlink] system boot did not complete in 20 seconds
The reason was that the stream subscription requests were not checked
because the while loop was not running yet because mavlink was not
booted completely.
By moving the stream subscription requests into a function we can run
them even if we don't run the rest of the loop.
Break out Mavlink class constructor logic into set_instance() and set_channel() methods. and add const specifiers and default arguments to Mavlink::mavlink_open_uart().
hash check and heartbeat forwarding
- hash check disabling: for systems where a companion link forwards messages
to QGC (e.g. via LTE) parameter streaming will be stopped as soon as QGC
sends the request to stop the stream. If the companion side for some reason
still requires the stream to be active we need to disable QGC from stopping
the stream. Normally dronekit should be responsible for filtering out the
request from QGC but apparently this is not possible.
- disable heartbeat forwarding: dronekit does seem to get confused if
heartbeats from another system other than the autopilot get forwarded to it.
Example: Sending messages from QGC via the autopilot to dronekit running on
companion computer.
Signed-off-by: Roman <bapstroman@gmail.com>
This is a more generic solution for 532a97041, and also enables it for
vehicle_command_ack's.
In addition it avoids using a timestamp for subscription update checking,
because it does not work well together with orb queuing.
Allow enabling/disabling transmitting data from all mavlink instances
with a specific mode/type. When disabled the instance can still receive
data. The uORB message used is the vehicle_command and uses the following
parameter:
param1: Specifies the mode/type of the instances to enable/disable transmitting
param2: Boolean to indicate if transmitting should be enabled or disabled
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.
Beat Küng