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

[Wim Meeussen]

>   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.

Every sensor measurement has a 'stamp' that specifies where the
measurement comes from. So if you care, you have all the information
there. Tf only uses this stamp to transform measurements into
different frames, tf does not force you to ignore this stamp.


>   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 current implementation does not support this very easily. The
upcoming version however will have good support for this type of
setup. Basically instead of having a 'database' for each consumer of
the data, it will be possible to share a database between multiple
consumers. and if you want, you can only create a single database that
is used by all consumers.


>   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.

You talk about 'real standardization' for the IDs, can you elaborate a
bit more on that? Do you mean we should agree on a system to name
frames, or are you talking about something more involved that would
also affect the implementation of IDs?


> - how to add uncertainty to frames?

We've been thinking about this, but never really found a nice way to
do this. Do you have any concrete suggestions on how to store
uncertainties, and how they would be used when transforming sensor
data between frames?


> - how to generate events when relative/absolute constraints between frames
>   are violated/reached/broken/....?

For the next tf, we had two types of events in mind: (i) events when a
specific transforms become available at a specific time. E.g. fire an
event when tf can transform between frame A and B at time t. And (ii)
events when certain transforms have changed. Based on these two events
in the core tf library, you could implement any type of constraint
checking outside of the core library.

Wim

-- 
--
Wim Meeussen
Willow Garage Inc.
<http://www.willowgarage.com)