[ros-users] Design decisions behind libTF...?

[Herman Bruyninckx]

>>  I am interested in knowing what exactly was behind the _design_ of the tf
>>  library, but all that I can find is
>>  <https://code.ros.org/trac/wg-ros-pkg/browser/pkg/trunk/libTF/doc/libTF_Manual.tex?rev=175>
>>  This is basically a document about the library's features and how to use
>>  it, but is there somewhere else more information about _why_ libTF was made
>>  the way it is...?

> You're right there was not much documentation on the design of tf.  I have
> gone through some of my notes and consolidated them onto the wiki at
> http://www.ros.org/wiki/tf/Design  linked from the tf page.

Thanks!!!

> If you have any specific questions please let me know. Or if there are
> parts which are unclear or you would like more information also please let
> me know.

Here are already some "preliminary" comments:

- "The high level goal was to allow developers and users not to have to
   worry about which coordinate frame any specific data is stored in."
   I do not fully understand what this goal is, and why it is a useful goal
   to have in the first place. Let me try to make myself a bit more clear:
   what if I _do_ want to worry about how and where my data is stored, since
   that will have a major effect on the "Quality of Service" (timing,
   latency, concurrent access (im)possibilities,...) of how I can use the
   data.

- "Everything is broadcast and reassembled at end consumer points. There
   can be multiple data sources for tf information. Data is not required to
   be synchronized by using interpolation. Data can arrive out of order."
   This serves only one particular use case, I think. I would prefer to have
   a more decoupled implementation, where the storage of the information is
   separated from how it is synchronized or used or distributed; I also need
   the use case where there is (in my whole, distributed system) only one
   single "owner" of specific data about the world, in order to be able to
   guarantee the 'atomicity' of some actions.
   The more decoupled approach still allows to serve the use case you
   mention, but also many other use cases.

- "Only transform data between coordinate frames at the time of use. Value:
   Efficiency, both computational, bandwidth, and simplicity."
   I am so sure about that! I have use cases where my 'data server' could
   do some calculations already _before_ I need them, so as to be able to
   serve them to me at exactly the right moment. "Planning" in its broad
   meaning of the word is such a use case. Implementation-wise, this could
   (I do not say "should"!) be done by something not unlike the "stored
   procedure" functionality that one finds in databases
    <http://en.wikipedia.org/wiki/Stored_procedure>
   together with a "to be ready by hh:mm:ss:xx" scheduling request.

- The previous remarks are all about the separation of the "4Cs" (which is
   my pet software design guideline): to try to separate the Computation, the
   Communication, the Configuration and the Coordination that take place in
   components. (BTW, this is something that ROS is rather bad at... I can
   show you dozens of "horror stories" in (core) ROS packages where all 4Cs
   are coupled in horrible ways.)

- "Only have to know the name of the coordinate frame to work with data
    Implementation: Use string frame_ids as unique identifiers."
   Using (wordlwide unique) IDs is very fine with me, but one should not
   impose to use only _string_ IDs. In addition, a standard has to be
   "imposed" about how one can guarantee that IDs are indeed unique.

- "Thread Safe Interface
    Values: Can be used in a multithreaded program.
    Implementation: Mutexes around data storage for each frame."
    Making visible use of mutexes makes things less portable, in general.
    Not only because there other means of guaranteeing atomic access to data
    than mutexes; Orocos/RTT has implemented some, with the "lockfree"
    access mode as a major feature to support efficiency and transparancy;
    it separates the Computation (operations on the data) from the Coordination
    (access to the data).


> We're currently in active discussions about ways to improve the next
> generation of the library and are getting ready to experiment with new
> approaches.   I have also started putting together the roadmap for geometry
> 2.0 which we will starting to actively work on soon.  See
> http://www.ros.org/wiki/geometry/Roadmap
> 
> If you, or anyone else, have any suggestions or design criterion requests
> also feel free to ask.  We appreciate any feedback, and right now is a good
> time for geometry as we start thinking about the next evolution targeted
> for diamondback.

Within the context of Orocos, we are at a similar "let's critically look at
our code again" phase, and we hope we can provide you with concrete and
constructive suggestions to improve the things we have in common. (And
that's a lot :-))

Some major things on our roadmap (driven by multiple use cases), in the
context of "tf":
- how to add uncertainty to frames?
- how to allow frames to be combined into "trajectories"?
- how to generate events when relative/absolute constraints between frames
   are violated/reached/broken/....?
- how to allow "multiple levels of detail" representations?

But don't hold your breath about our envisaged contributiosn, since we all
have an overly busy period the coming weeks... :-(

Best regards,

Herman