Possible incorrect naming convention for ros static transform

[michchinn]

I'm a part of a research group studying how we can statically detect common errors in ros transforms. In executing our tool on public Github repositories, we noticed two possible naming convention errors in one of your static transforms.

In lsd_slam/lsd_slam/launch/stereo_rviz.launch you include the following:

  <node pkg="tf" type="static_transform_publisher" name="camera_to_world"
  	args="0.0 0.0 0.0 0.5 -0.5 0.5 -0.5 world camera 100" >
  </node>

The two possible issues are:

1. When using a static_transform_publisher, the parent frame id precedes the child frame id [source]. Therefore this transform is from the world frame to the camera frame but its name indicates it is the other way around. This inconsistency of the name with the transform may lead to developer confusion, making it challenging for developers to maintain or integrate with this codebase.

2. The frame named "camera" should possibly be named "camera_optical."
   REP 103, which defines the ROS Standard Units of Measure and Coordinate Conventions says that the standard for any frame relative to a body is x forward, y left and z up (FLU). In contrast camera frames are often specified using x right, y down, z forward (RDF), and REP 103 recommends that frames with this convention have names suffixed with "_optical" to alleviate developer confusion, reduce bugs, and make it easier for developers to collaborate.
   In the above code sample, the rotation "0.5 -0.5 0.5 -0.5" orients "camera" as RDF (assuming world as FLU), but the frame name does not make this apparent since it lacks the "_optical" suffix. As a result, any code that makes an assumption about the orientation of "camera" may be incorrect and challenging to diagnose.

We would appreciate it if you could please describe any conventions around transforms which you follow in order to maintain consistency in the project, as well as if you would share your thoughts on how deviations from the standard may make code reuse and maintenance more challenging.

Thank you!