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.
This commit adds Roll Pitch Yawrate Thrust (RPYrT) setpoint control to the
PX4 stack, enabling the UAV to follow specific yawrates sent from
offboard. It also introduces individual body_rate flags, along the
lines of mavros.
Tested on a MoCap enabled flight arena in KTH Royal Institute of
Technology, Stockholm. The MAV receives RPYrT setpoints from an
external PID controller to stabilize around position setpoints.
The UAV is also externally disturbed to assess the stability to
external unmodeled events.
Fixed Kabir comments.
Removed deprecated ignore_bodyrate.
Fixed integration test.
Daniel Agar