[Feature] Roll Pitch Yaw Trust control update message proposition

[AlexisTM]

I do not like the fact that we need to send two messages to different topics to use the Roll Pitch Yaw Trust control. Indeed, this is one low-level control which needs precise delays, but we have to add synchronization for the topics.

Current system:

• ~setpoint_attitude/attitude (geometry_msgs/PoseStamped) Send attitude setpoint.
• ~setpoint_attitude/att_throttle (std_msgs/Float64) Send throttle value(0~1).

I would propose to fit it into one message; Following 3 propositions.

• Similar to hector_quadrotor and crazyflie_ros, geometry_msgs/Twist or geometry_msgs/TwistStamped: I do not like the feeling of using speeds.

linear.y: roll [e.g. -30 to 30 degrees]
linear.x: pitch [e.g. -30 to 30 degrees]
angular.z: yaw rate [e.g. -200 to 200 degrees/second]
linear.z: thrust [0 to 1]

• Updating the current attitude message and using geometry_msgs/PoseStamped only.

pose.orientation: orientation to achieve
position.z: thrust [0 to 1] # instead of the current thrust Float64 topic

• Similar to mav_control_rw, using custom message mav_msgs/RollPitchYawrateThrust

Header header
# We use the coordinate frames with the following convention:
#   x: forward
#   y: left
#   z: up

# rotation convention (z-y'-x''):
# yaw rotates around fixed frame's z axis
# pitch rotates around new y-axis (y')
# roll rotates around new x-axis (x'')

# This is a convenience-message to support that low-level (microcontroller-based) state
# estimators may not have knowledge about the absolute yaw.
# Roll- and pitch-angle should be specified in the header/frame_id frame
float64 roll                   # Roll angle [rad]
float64 pitch                  # Pitch angle  [rad]
float64 yaw_rate               # Yaw rate around z-axis [rad/s]

geometry_msgs/Vector3 thrust   # Thrust [N] expressed in the body frame.
                               # For a fixed-wing, usually the x-component is used.
                               # For a multi-rotor, usually the z-component is used.
                               # Set all un-used components to 0.

My preference is the last one, an explicit custom message which provides direct compatibility to the mav_control_rw package as well as other ethz-asl packages. While PoseStamped is an almost plug and play solution.

[TSC21]

If using different topics represents an issue, just use setpoint_raw. Also there is an open PR on setpoint_attitude to add support for mav_msgs/RollPitchYawThrust.

[AlexisTM]

@TSC21 I did not notice the PR. This is not relevant then, sorry :)

[vooon]

That PR: #966 (to keep link)