Mavlink does not correctly forward messages that have the target_system or target_component routing fields in the message.
Some investigation revealed that the Mavlink::forward_message function is incorrectly utilizing the mavlink_msg_entry_t.target_system_ofs and mavlink_msg_entry_t.target_component_ofs fields. These offsets are intended to be used relative to the start of the message payload. But, as implemented, these offsets are incorrectly being used relative to the start of the message. This pull-request corrects that problem.
I also correctly made use of the mavlink_msg_entry_t.flags field to determine if a message contains a target_system or target component field. The previous check incorrectly assumed that they would always be non-zero if present.
Signed-off-by: Mark Owen <maowen801@gmail.com>
The file writer thread could get into a state where it blocked infinitely
on pthread_cond_wait() (or rather until the logging stops).
This is very rare and the following conditions must be met:
- the buffer is almost empty (<4KB filled), so that the writer thread does
not write anything.
- an fsync call is scheduled (happens once every second)
- the fsync call takes a long time (several 100ms), during which time the
complete log buffer fills up.
The main thread would then get into dropout state where it does not call
_writer.notify() anymore.
Notifying the writer thread on every loop update of the main thread fixes
that.
It does not increase resource usage.
* Add kdevelop to gitignore
* Add test stubs
* Rename px4_add_gtest to px4_add_unit_gtest
* Add infrastructure to run functional tests
* Add example tests with parameters and uorb messages
* Fix memory issues in destructors in uORB manager and CDev
* Add a more real-world test of the collision prevention
This new airspeed module does:
-runns an airspeed validator for every airspeed sensor present, which checks measurement validity and estimates an airspeed scale
-selects another airspeed sensor if for the current one a failure is detected
-estimates airspeed with groundspeed-windspeed if no valid airspeed sensor is present
-outputs airspeed_validated topic
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
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().
- if a channel receives an ack for a command, do not immediately remove the
command item from the send queue but wait until the next ack timeout occurs.
This gives other mavlink channels time to try to put identical commands into
the send queue.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- if we receive an ack for a command through a specific mavlink channel
then do not drop the corresponding command in the queue if this specific
mavlink channel did not issue the command. If we don't do this we can
end up in a situation where we associate an ack coming through a specific
mavlink channel to a command in the queue which was not requested by this mavlink channel.
Moreover, the actual command for which the ack was meant remains in the
queue and eventually triggers a timeout.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
Summary:
PX4 assumed that odometry orientation was a way to rotate data from parent frame to child frame, so to rotate child to parent, it was taking the inverse rotation of the odometry orientation,
but orientation rotates the parent frame to the child frame, whereas for data, it represents a rotation from child to parent; hence, the rotation inverse operations were removed.
Test Plan: Checked that vehicle_mocap_odometry and vehicle_local_position gave correct linear velocities. Also visualized px4 output twist in rviz.
