New pose proposal (#252)

[aaronchongth]

🎉 New feature

Related to #252

Summary

• Adding specific translation and rotation elements to pose.
• rotation can be read according to its type attribute, rpy_degrees, rpy_radians, and q_wxyz.

Technically values and child elements are not supposed to live side-by-side, and there was no precedent of this use case. After some experimentation, I have found a workaround using the feature #542, to find out whether the translation and rotation elements were explicitly set.

This branch requires

• Copy spec 1.8 to 1.9 #568
• adding element default check #542

With the intention of deprecating the old //pose descriptions, this proposal parses the poses by hierarchy, whereby whenever a translation or rotation child element is present, even if a value is specified, it will be ignored, for example,

<pose>
  1 2 3 4 5 6
  <translation></translation>
<pose>

In this case, where the translation child element is present, it is treated as an indication to use the new pose proposal, therefore using the default xyz values of (0, 0, 0) for translation, while failing to find a rotation child element also uses the default values, which are rpy of (0, 0, 0).

Alternatively, we could opt for overriding just the translation in this example, while leaving the rpy components to be (4, 5, 6).

Test it

source install/setup.bash
./build/sdformat12/test/integration/INTEGRATION_pose_1_9_sdf

Checklist

• Signed all commits for DCO
• Added tests
• Added example and/or tutorial
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Code check passed (In source directory, run sh tools/code_check.sh)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review
  another open pull request
  to support the maintainers

Note to maintainers: Remember to use Squash-Merge

[scpeters]

I would be careful using pitch values of 90 degrees in an example since that is a singularity

[scpeters]

I would be careful using euler angles larger than pi/2 in an example because I believe they will be truncated internally when loaded and then show a different value when printed out again. For example, using the quaternion_*_euler executables in the ign-math examples:

$ ./quaternion_from_euler 1 2 3
Converting Euler angles:
 roll   1.000000 radians
 pitch  2.000000 radians
 yaw    3.000000 radians

 roll     57.295780 degrees
 pitch   114.591559 degrees
 yaw     171.887339 degrees

to Quaternion
 W  0.435953
 X -0.718287
 Y  0.310622
 Z  0.444435

to Rotation matrix
    0.411982  -0.833738  -0.367630
   -0.058727  -0.426918   0.902382
   -0.909297  -0.350175  -0.224845

then converting the quaternion back to Euler:

$ ./quaternion_to_euler 0.435953 -0.718287 0.310622 0.444435
Normalizing Quaternion components:
  W 0.435953
  X -0.718287
  Y 0.310622
  Z 0.444435
to
  W 0.435953
  X -0.718287
  Y 0.310622
  Z 0.444435

Converting to Euler angles
 roll  -2.141591 radians
 pitch  1.141592 radians
 yaw   -0.141591 radians

 roll  -122.704130 degrees
 pitch  65.408409 degrees
 yaw   -8.112557 degrees

to Rotation matrix
    0.411983  -0.833737  -0.367631
   -0.058726  -0.426918   0.902382
   -0.909297  -0.350176  -0.224845

the rotation matrices are the same, but it results in different Euler angles

[scpeters]

same as above about radians above pi/2

[EricCousineau-TRI]

Per VC, this is closed in lieu of minimal version, #589