origin: Support degrees in `rpy`

[eacousineau]

To parallel #13 / #123:

It'd be nice if users could also specify rpy in degrees, either via an explicitly separate field, rpy_deg, or via some unit specification that is local to that tag.

I always get sad when I see URDFs or SDFs that have varying degrees of precision of pi / {4,2,3} etc., when that could be much more easily captured via degrees.

I also get sad when there's math via xacro or some other text processing, and most of that math involves ${np.pi / 180 * <degrees>}.

\cc @scpeters @clalancette

(TBH, I'd personally love to see this as part of SDF as well - but will post that directly as an sdformat issue.)

[gavanderhoorn]

I also get sad when there's math via xacro or some other text processing, and most of that math involves ${np.pi / 180 * <degrees>}.

Not saying having support for degrees isn't worthwhile, but with the Jade+ xacro and Python support, using degrees is as simple as: ${radians(123)}.

Nothing to be sad about I'd think, and also no repetition of pi/180*<degrees>.

[eacousineau]

While ${radians(123)} is def. an improvement, I still get sad when xacro gets pulled in to simplify math (and maybe some simple frame concatenation). I'd see xacro as necessary for very model-intrinsic permutations or automation (e.g. complex control statements), but less so for specifying measurements against reference points with easy-to-interpret values.

I always want to turn a simple model file into a xacro to get those math-y benefits, but it feels like that's a band-aid in lieu of a better answer... (definitely the most practical answer for the time being, though! I am just a tad picky, though :P)

[gavanderhoorn]

Off-topic, but: personally I never use plain urdf. All my robot models are .xacros, if only for the fact that plain urdf is non-composible (and I tend to get a bit sad when models aren't composible). That reduces the threshold for using ${..} for things significantly.