similar project...

[facontidavide]

Hi,

it seems that we built exactly the same library twice and accidentally we are releasing them pretty much simultaneously...

https://github.com/facontidavide/ros_type_introspection

http://wiki.ros.org/ros_type_introspection

I believe it is not good for the ROS community to have so much ambiguity. Would you like to "join forces" and explore a way to leverage the best of our two implementations and see if we can "merge the two projects?

Regards

Davide

[pfankhauser]

Dear Davide,

Thanks for reaching out! This project was actually released back in May ;-) I think your idea is great to join forces in creating one powerful introspection tool. We have been using variant in production for quite a while and think the project is mature. Except for maintenance work, we currently do not have any plans for further development. In case you're missing features in variant, please let us know and we'll try to accommodate your requests.

Best,
Péter & Samuel

[facontidavide]

Hi,

I have tried to understand how to use the library looking at the unit tests. But there is something that is puzzling me a bit...

Looking at this tests https://github.com/ethz-asl/variant/blob/master/variant_topic_test/test/SerializerTest.cpp#L132

I can notice that getValue is a template that requires the type of the message to be extracted from the variant to be known at compilation time.

What should I do assuming that I can NOT include the header file <variant_msgs/Test.h>?

I really miss some more concise tutorials like these: http://wiki.ros.org/ros_type_introspection/Tutorials

I would like to make a direct comparison in terms of API and speed, if you agree.
For instance why don't we both create a rosbag-to-csv converter and we benchmark it against the same rosbags?

What do you think?

[kralf]

Hi Davide

You are absolutely right that a concise tutorial is missing from our side. The test you are referring to does not imply that the message type needs to be known at compile time. It just type-safely casts the variant into a Test message, showing that our implementation can deal with strong-typed sub-messages at any level of the tree defined by the message fields. This is a benefit of the templated approach with type erasure.

I had a quick look at your project. Your approach seems sound and valid, but uses slightly different concepts and programming patterns. I personally do not see a conflict between our projects, though in terms of originality, a quick comparison between our commit histories suggests that you should have performed a thorough search before starting to implement something that already existed and may have fitted your needs. Also, you did not seem to have troubles releasing your project. I take it that your code has been reviewed and accepted as-is. Did the maintainers ask you to disambiguate between our contributions?

If you want to see the code in action, please have a look at this project: https://github.com/ethz-asl/rqt_multiplot_plugin

In fact, our variant_topic_tools have been released as a requirement for and in conjunction with our rqt_multiplot_plugin. You already mention in your documentation the use-case of rqt_plot which employs Python introspection into ROS message types. The rqt_mulitplot_plugin is our solution to a performant plotting tool, written entirely in C++.

Concerning your plans to evaluate performances, you are welcome to carry on and publish the results if you see a motivation and need to do so. Maybe you will be able to provide hints for a more efficient implementation of our approach. Notice, however, that in our rqt_multiplot_plugin, we have already demonstrated to process type-erased messages at reasonably high frequencies. So from our experience, we never hit the limits of our implementation in this application scenario.

[facontidavide]

With no doubt our two projects can coexist and I agree that it is a pity that I didn't know in June that variant exist, otherwise I would have not implemented my own package.

I personally think that it is a pity that we have two separate project solving the same problem and that we don't do any comparative analysis of them, but I guess that your point is that we are scratching our own hitch and there is no need to do any further development...

I will do my benchmarks just for curiosity.

[facontidavide]

Just my two cents... don't want to make this thread too long. Actually you might want to close it ;)

1. Looking here it looks like you need to know the name of the fields in advance.
2. I do know that the previous issue can be solved iterating through the members of the Collection using Variant getMember(int index), but then the user must
   use recursion and a bunch of nested if() else and/or switch statements to access all of the field of a complex data structure.
3. Apparently the way Variant (and in particular BuiltinVariant) works is similar to boost::any, i.e. you can extract the value with getValue only if you know the exact type. If you use gtTypeInfo you still need a bunch of if() else statements.

So, unless I am missing something, the big difference in philosophy between our two libraries is that I gave for granted that the user wants (needs) the type hierarchy to be flattened in a vector of key/value, pairs, where value is always a builtin type, not a CollectionVariant.
On the other handt you use a data structure that is hierarchical and implement the same hierarchy of the original type.

Am I correct?

This is why I suggested the rosbag to CSV example. It shows how all of the builtin fields of a complex type are extracted.