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 was added to enable a Pixhawk to be used as an RC input for e.g.
SITL. As far as we're aware of that's not really used. However, sending
this can cause issues if multiple Pixhawks are in the same network.
Also, is uses up some of the MAVLink bandwidth.
Therefore, it's probably best to remove that feature for now.
-moved rc.mavlink to the boards optional rc additions (now it's called rc.board_mavlink) to handle board specific mavlink needs (mavlink over usb, ethernet, additional streams, etc.)
-mavlink module will be responsible to usb defaults, therefore less args are needed to be passed to mavlink module if one wants to use mavlink over usb.
-the way to check if connection is usb is by it's designated variable and not by config mode.
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.
When we send a command to any sysid or any compid, we need to match an
ack from a specific sysid or compid. If we don't do that, we keep
sending retransmissions and eventually time out.
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>
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.
Julian Oes