Add Quaternion to RPY autofill for PX4

[lthoma5]

First of all, thank you for this amazing project and it's support for .ulg & .mcap files, it's truly been a game changer when debugging issues!

PX4 logs quaternions using WXYZ order with elements ending in .00, .01, .02 and .03 respectively. Some examples of these quaternions in .ulg files are vehicle_attitude/q.0X and vehicle_attitude_setpoint/q_d.0X, matching on the .0X part.

This quaternion format is unfortunately not compatible with the drag & drop autofill feature of the Quaternion to RPY toolbox. This PR adds autofill for these quaterions, so you only need to drag one of the elements into the tool to visualize them.

[facontidavide]

I am ok approving this, ut can you please provide an example file?

[lthoma5]

The current .ulg file in datatsamples (https://github.com/facontidavide/PlotJuggler/blob/main/datasamples/sample.ulg.zip) has an attitude quaternion that should work for testing the autofill behavior - see below. Let me know if you need any other example files and I'll be happy to provide them.

[facontidavide]

so, what I am worried about is that I am using a relatively ambiguous standard (numbers instead of letters) from PX4 to modify another plugin that is NOt related directly to this toolbox...

Numbers are more ambiguous because we can not now if another plugin will use the order XYZW ,instead of WXYZ.

[lthoma5]

Good point! I think the easiest "solution" to this problem would be to offload the responsibility to the user. If they drag the .00 element into the W field of the tool, it assumes it's WXYZ order and if he .00 element is dragged into the X field of the tool, it assumes it's XYZW order. Right now, the tool will only work if the .00 is dragged into the W field, but if you agree this is an acceptable solution, I can add support for numbered XYZW as well.

The alternative would be to update the .ulg parser to detect known PX4 quaternion types/fields, and to store them as qw/qx/qy/qz instead of the current numbered system. Happy to give this a shot, but I suspect that this might break existing code/scripts/presets that rely on the quaternion order.

Another related point is that these numbered WXYZ quaternions also show up in ROS2 bags if a user uses the PX4 uXRCE-DDS or Zenoh integrations - here they are stored in yet another array format: q[X] as subkeys of q[] (also in WXYZ order; one such ROS topic is /fmu/out/vehicle_attitude). Autocomplete support for this scheme could be added to the numbered parser, but producing detecting PX4 quaternions inside of the rosbag parsers seems like an overreach.

In any case, I'd love to hear your thoughts - this is ultimately more of a niche nice-to-have feature, so I'm open to other approaches/can maintain this as my own internal version if it doesn't fit into the bigger picture.