This enables flow control on CDCACM for the NuttX boards which fixes a
problem where HITL would stall.
The stall could happen if the hardware would be a bit too slow in
keeping up with the incoming messages. Often, this happened on arming
because the logger would take some time to log all parameters right at
the beginning.
The stall would then not recover due to NuttX bug where the rx interrupt
would not be restored correctly and instead only a slower watchdog would
release the next read. This watchdog takes 200ms which means it's hard
to impossible to get out of the situation without restarting sim and/or
PX4. For more information about the issue, see:
apache/incubator-nuttx#3633
As a workaround, until that bug is fixed, and because it makes sense
anyway, I propose to enable FLOWCONTROL for the serial via USB.
- camera_trigger module always publishes the camera_trigger msg (independent of the camera feedback)
- Use camera_trigger msg and set the feedback flag
- Subscribing modules determine if the message is relevant based on the feedback message
On Nuttx we have an additional check whether the directory is accessible
to check if we are trying to write to storage that is not on the SD
card. This returns the FileProtected error whereas on Linux this just
ends up being a FileNotFound.
The ifdefs around this issue are not pretty but the alternatives of
either removing the tests for /bogus folders, or removing the additional
check on the NuttX side don't seem better either.
In commit 462b572172 the reading operation
on the PX4 side was changed to only read as many bytes as requested
rather than however many fit in the payload data.
This caused the unit tests to fail which this commit here aims to fix.
What is confusing about MAVLink FTP is that there is a size field which
generally signals how many bytes of the payload data are used/set.
However, in the case of a read requst, the size field is used to
indicate how many bytes should be read. The payload data is empty in
that case though.
This case was, from how I understand it, not implemented/tested in the
unit tests and now failed. In order to implement it I had to change a
few things:
- Change _setup_ftp_msg and _send_receive_msg so that the params contain
a data length rather than the size field. The size field itself needs
to be set outside of these methods using payload->size.
- Since we test files smaller, equal, and bigger than one payload data
length, I implemented that we send multiple read requests until we
have the whole file and not just the first part.
- Additionally, I saw a lot of uninitialized warnings in valgrind, and
got rid of them by adding a few zero initializations.
The current practice of adding topics to the default set isn't scalable,
as it affects all setups.
By making sure topics are advertised on init, logger can just discard
topics that don't exist. This does not work for all topics, so topics are
specifically marked as optional. It can be extended to more topics later
on though.
This reduces the list of topics by ~35 on a pixracer configured as quad,
and reduces RAM usage by ~1KB.
The _MAV_PAYLOAD macro casts the value to a char*. Some compilers treat
char as signed, so we were getting negative system and component ids
if the id was >= 128. This caused later comparisons to fail which
resulted in messages not being forwarded.
- mavlink/mavlink is now directly included as a submodule instead of the generated mavlink/c_library_v2
- this also switches to mavlink development.xml by default
The SERIAL_CONTROL MAVLink message now contains a target_system and
target_component field that we should check.
Without this we might be answering to a command on the network that is
meant for another system.
Beat Küng