- 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 fix is necessary because usually uORB structs get initialized with
all zeros and then get filled with the fields that are actually in use.
* The number 0 for the mode slot was already commanding to switch to the
mode in slot one even though for example the joystick input via mavlink
does not use this mechanism at all.
- vehicle will fly less aggressive
- it does not make sense to set the lower acceleration limit to something
that exceeds gravity if most of the vehicles do not support reverse thrust
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- we have set the maximum yaw-rate MC_YAWRATE_MAX to 200 degrees and it
makes senses to leave a bit of margin between what the user can demand
and what the limits of the vehicle are
Signed-off-by: RomanBapst <bapstroman@gmail.com>
This fixes the terrifying case where the drone disarms in-air just
because it receives a MAVLink disarm command. We now check param2 for a
magic number which enforces arming/disarming.
This is added to the mavlink protocol in:
https://github.com/mavlink/mavlink/pull/1162
- MPC_MANTHR_MIN is used as minimum throttle in attitude control mode when
the vehicle is in air. This is useful to retain some control around roll and
pitch axis if airmode is not enabled and the user demands zero throttle.
However, when the vehicle is landed there is not need to keep the throttle
at a higher value than zero.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
It doesn't affect fixed wing flying anymore. I disabled it for the
deltaquad since I presume @sanderux prefers to have the feature disabled
even when flying in multicopter mode.
AAs discussed in the devcall this functionality is only useful for
rotary-wing (multicopter) flying since it's a big safety hazard to
accidentally bring a fixed wing out of an auto mode e.g. a mission
and fly away in a straight line or into an obstacle.
the vehicle yaws towards the next waypoint before accelerating. This is
required for drones with front vision and aerodynamic multicopters such
as standard vtol planes or highspeed multirotors.
