The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
Thanks for all the feedback. There's definitely always space for improvement in the documentation and tutorials. You have a bunch of good ideas for how to improve them. If you'd like to extend the tutorials that would be great. Adding some more background information is always good to do.
And for the tutorials on how to transform datatypes that would probably make sense to be added in an additional tutorial in the series for both Python and C++.
Here's some answers to your more specific design questions.
Clearly the various back-ends provide other functionality that is useful. What does one back-end do that another does not? Why would I want to chose one over another?
The most common reason to choose one backend over another is that you're integrating a codebase that's already using one of the the backends. And it's designed to be extendable to a custom backend if you have another implementation that you're using.
It is hard to understand why, having created a geometry_msgs/PoseStamped, upon which the rest of ROS common libraries depends, should one have to convert it to a tf2_geometry_msg/PoseStamped, or further into some other library's message type. All this data type conversion seems hugely inefficient and largely unnecessary unless you want to support all those other libraries (which most people probably don't need and can implement themselves if they do). Why was the choice made to completely redefine the geometry messages within tf2 rather than reusing the already defined ones and creating this incompatibility with the rest of ROS?
It's not necessary to convert any datatypes. With the templated API and the multiple available backends the user never needs to explicitly convert. (Note that there is no tf2_geometry_msgs datatypes.) The geometry_msgs datatypes are just messages, and consequently do not have any methods etc that are available. The tf2 datatypes that I think you are referring to are an integrated linear math backend that's used internally and can be used by the user, but is designed to not be needed for the users code. And it's recommended to use one of the full linear math libraries instead.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
