Bug report

Required Info:

• Operating System:
  • any
• Installation type:
  • binaries
• Version or commit hash:
  • Foxy patch 1
• DDS implementation:
  • any
• Client library (if applicable):
  • N/A

Steps to reproduce issue

run the following:

# ros2 run tf2_ros static_transform_publisher
A command line utility for manually sending a transform.
Usage: static_transform_publisher x y z qx qy qz qw frame_id child_frame_id
OR
Usage: static_transform_publisher x y z yaw pitch roll frame_id child_frame_id
# ros2 run tf2_ros static_transform_publisher 0 0 0  0.1 0 0 map child_yaw

Expected behavior

child frame is rotated in yaw:

# ros2 run tf2_ros tf2_echo map child_yaw
At time 0.0
- Translation: [0.000, 0.000, 0.000]
- Rotation: in Quaternion [0.000, 0.000, 0.050, 0.999]
...

Actual behavior

child frame is rotated in roll:

# ros2 run tf2_ros tf2_echo map child_yaw
At time 0.0
- Translation: [0.000, 0.000, 0.000]
- Rotation: in Quaternion [0.050, 0.000, 0.000, 0.999]
...

Additional information

The problem is in the change in command line argument order, introduced in #182, specifically this line
I'd be happy to do a PR, however I'm unsure what the actual argument order should be:

• The ROS2 tf2 tutorial has the [roll, pitch, yaw] argument order.
• The tool itself advertises [yaw, pitch, roll] source
• The static_transform_publisher in classical ROS uses the [yaw pitch roll] sequence ROS wiki

I'm leaning towards keeping [yaw pitch roll] and reversing the change in order introduced in #182

To be clear, this only refers to the order of the command line arguments. The rotation sequence is always body fixed yaw, followed by pitch, followed by roll or equivalently fixed axis roll, followed by pitch, followed by yaw.

Lastly, I discovered this bug after update from Eloquent to Foxy. (My static transforms were suddenly all wrong and my robot attempted suicide). I suggest to document this change in command line argument order in the Foxy release notes.