The purpose of applyNametransform about ros_babel_fish_benchmarks HOT 8 OPEN

Hey,

no worries. Be pedantic, it's also a benchmark of your library and should be fair!
However, I'd argue that just containing the information is not enough.
It also has to be accessible, i.e., if I know the path of a value in the message, I should be able to access it without having to do any parsing myself. Is that the case?

Maybe we should change the benchmarks to perform cheap operations on the message, to make it more comparable?

from ros_babel_fish_benchmarks.

RTI was created to serve as a parser for PlotJuggler. Therefore, it is important for me to extract pairs of key values, where the keys looks like this

"robot_pose/position/x" 
"robot_pose/position/y" 
"robot_pose/position/z"
"robot_pose/orientation/x"
"robot_pose/orientation/y"
"robot_pose/orientation/z"
"robot_pose/orientation/w"

I understand that you prefer to access the information in a different way.

A fair way to compare is if we try to answer the same question like: given a geometry_msgs/Pose, how much time do I need to get the position and the quaternion?

Note that to get this information in RTI, you don't need to invoke applyNameTransform (actually it would be worse if you try to parse renamed_values).

from ros_babel_fish_benchmarks.

As I said before, it would be possible for me to create a data structure that looks more like yours (in terms of hierarchical access). I don't do it because:

• I don't need it
• I know it iterating through it would be slower, and in my use case I always iterate through it.

But I could do it... that would make the comparison fairer.

from ros_babel_fish_benchmarks.

A fair way to compare is if we try to answer the same question like: given a geometry_msgs/Pose, how much time do I need to get the position and the quaternion?

I was thinking of operations such as the sum of the elements but that would work too.
Alternatively, or additionally, I could also add a function that creates a list of the paths in the message.
You shouldn't have to change anything in your code just for the purpose of this benchmark.

from ros_babel_fish_benchmarks.

I am ok with a sum all the numerical values.

You don't need applyNameTransform. But that would give an unfair advantage to RTI, this time :)

I think we need to know what we are accessing, i.e. the fields you really care about is important.

from ros_babel_fish_benchmarks.

Let me get a bit philosophical here: the schema in a ROS message (any serialized message with a schema, really, think ProtoBuffer) has a semantic meaning. Whenever we create a schema-less parser like ours, the semantic is stripped away.
We just know the name of the fields and the hierarchical relationship between them.

Like schema-less JSON or XML.

This is intrinsic in the problem we are trying to solve. The human might have an intuition of what a field called "position/x" means, but no the machine,

This is fine for GUI, where there is a "human in the loop" that make an interpretation of the string based on assumptions (he/she add the semantic).

The question therefore is: creating the name of the field in a "human readable" way is an intrinsic step or not?

In your application you might consider more convenient a hierarchical access, in my applications I consider more convenient a flat access. That is fine.

But the equivalent for you of applyNameTransform is something that you do in your GUI. Does it make sense?

from ros_babel_fish_benchmarks.

Furthermore, the awesome thing about applyNametransform are the RenaminRules, that allow the creation of more convenient names. look at this TF example, where messages are mixed together, because of the very nature of TF

Whit renaming rules, I can demultiplex these messages:

Note that these are EXACTLY the same raw ROS messages.

Sample rosbag can be found here: https://github.com/facontidavide/PlotJuggler/blob/master/datasamples/example.bag

from ros_babel_fish_benchmarks.

I created this branch that add much more information about the hierarchy to the FlatMessage.

https://github.com/facontidavide/ros_type_introspection/tree/add_extra_type_information

from ros_babel_fish_benchmarks.