Open fmauch opened 1 week ago
High-level question: would it perhaps be better to have the hardware interface offer a quaternion instead of an Euler angle triplet?
That would seem cleaner to me, in the sense of it being more of an N-to-1
mathematical abstraction.
While they aren't necessarily very human friendly, quaternions have definite benefits mathematically, and making it the responsibility of the hardware interface/driver to convert whatever internal orientation representation it uses to this 'intermediary representation' would seem to make sense.
High-level question: would it perhaps be better to have the hardware interface offer a quaternion instead of an Euler angle triplet?
That would seem cleaner to me, in the sense of it being more of an
N-to-1
mathematical abstraction.While they aren't necessarily very human friendly, quaternions have definite benefits mathematically, and making it the responsibility of the hardware interface/driver to convert whatever internal orientation representation it uses to this 'intermediary representation' would seem to make sense.
I was discussing that with @RobertWilbrandt, as well and I would agree. But I think that's a question to discuss once the PR on ros2_controllers is there.
Oh, just noticed #856 actually does it that way.
I don't have any strong opinions on this - Going through REP 103 i went through the options and preferred RPY because the values cannot represent any invalid state (while i would expect that a quaternion should be normalized). From an application point of view i agree, so i changed the representation in pose_broadcaster now.
This uses the PoseBroadcaster currently written by @RobertWilbrandt. As he wants to contribute that to ros2_controllers, this will stay in a draft state until it is merged upstream.