feature request: yaw_degrees for imu quaternion

[Timple]

Or maybe just any quaternion you encounter?

The yaw_degrees feature is very convenient for the odometry so thanks for that already! :)

Or maybe even also 'roll_degrees' and 'pitch_degrees' as they might be insightful for an imu

[Timple]

Figured out how to do it 'manually' using the quaternionToYaw function and this tutorial:
https://vimeo.com/355538901

Feature request remains though

[facontidavide]

I need you to be a little more precise...

Based on the current architecture, I can "magically" create RPY data only from a specific ROS message type. In your case is

       sensor_msgs/Imu

right?

[Timple]

Our current usecase is sensor_msgs/Imu, so having a yaw_degrees there as you already do for odometry would be great.

---

But the more awesome and complete implementation would be to 'detect' the Quaternion msg even if it resides as part of another message (Imu/Odometry/etc).
That way all messages containing a quaternion can be displayed as follows:

.../orientation/x
.../orientation/y
.../orientation/z
.../orientation/w
.../orientation/roll
.../orientation/pitch
.../orientation/yaw

Where the latter three would be added for convenience since (most?) humans tend to think in euler angles rather than quaternions

Or perhaps:

.../orientation/roll_deg
.../orientation/pitch_deg
.../orientation/yaw_deg

[facontidavide]

i know this is what you were going to propose... :)

It is a PITA, but doable

[Timple]

If it was very easy I've would have send a PR instead of a feature request :)

Well if message types cannot be distilled, it might be pragmatically done by checking the fields.
If (and only if) an x,y,z,w field is present, lets add roll, pitch and yaw.

[facontidavide]

yes, it can be done introspecting this fields of the message... the parsing library is called ros_type_introspection for a reason :)

I just have no bandwidth for the time being to do this, I am horribly busy.

[facontidavide]

Done.

[Timple]

Works for imu message, thanks! 👯‍♂️