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

Herman Bruyninckx Herman.Bruyninckx at mech.kuleuven.be
Sat Sep 11 04:22:55 UTC 2010


On Sat, 11 Sep 2010, Wim Meeussen wrote:

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

What will be the exact definition of a "database"?

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

Both... This is not a light task, I know :-) But imagine the (not so
distant!) future, where my company has two PR2s, that have to work together
with a BlueBotics platform carrying two KUKA light-weight arms, and a
number of "intelligent" conveyor belts: it's this kind of "world model
database" that I want to (help) design, and the ID issue is only one of
them. Inter-framework integration is another issue (that is, not just
adding more ROS nodes to a ROS-only system, but adding ROS nodes to KUKA
nodes to BlueBotics nodes to ABB conveyor belt nodes!). The other issues
mentioned above also come into play in this scenario: how do the different
frameworks interchange time stamps? how do I keep the local versions of the
"world model" in each of the robot controllers in sync with the ones in the
"intelligent resources" in the world (e.g., the "workcell coordinator" that
has to make sure all the above-mentioned robots work together in a decent
way). You feel the need for _real_ standardization? I do! :-)

>> - how to add uncertainty to frames?
>
> We've been thinking about this, but never really found a nice way to
> do this. 
Me neither, I'm afraid... :-(

> Do you have any concrete suggestions on how to store
> uncertainties, and how they would be used when transforming sensor
> data between frames?

The only suggestions I have are more pragmatic than fundamentally correct.
In other words, I can only suggest some _concrete_ "PDF" (probability
density function) representations, that are not completely transferable one
into the other; for example:
- a 3D Gaussian on the origin of the frame, plus a 3D Gaussian on the
   "logarithm" of the orientation
- a 'sampled' version of any 6D coordinate representation for a frame
- "mixtures" of the above
   <http://en.wikipedia.org/wiki/Mixture_%28probability%29>
The important thing to 'get right' in the design is the abstract interface
to "frame with uncertainties": the set of operations (the "API") one wants
to do with frames need not reflect the fact that one works with frames that
have an uncertainty representation attached to them, and certainly not the
fact _which_ uncertainty representation that is. So, the good news is:
designing the API will not be too difficult (I hope), but the bad news is
that the "solvers" (= concrete implementations of the abstract API) will
require more attention. There will be _many_ different solvers (one for
each choice of uncertainty representation), and each solver will have
representation-specific properties to be configured.

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

Suggestion: make this "level-triggered events" and not "edge-triggered"
  <http://en.wikipedia.org/wiki/Edge_triggered_interrupt#Types_of_Interrupts>
because (i) "a specific time" will never be reached exactly so the value
should be given with a certain "tolerance", and (ii) there
should be some "memory" about how long the event of the
transform becoming available will remain "visible", since not all users of
the event will have been listening to the event at the time of sending it.
(E.g., listeners could be created as a reaction to such events.)

> And (ii) events when certain transforms have changed.

Same remarks as above: the "change" has to have a "tolerance" and a "memory".

> Based on these two events
> in the core tf library, you could implement any type of constraint
> checking outside of the core library.

I think you miss one fundamental other "event": a constraint can have
"softness", and subscribers to the event can be interested in (i) knowing
the current value of _how much_ the constraint is violated, and (ii)
getting events (as above) when specified levels of violation have been
reached. (The latter thing might result in the same solution as the
"tolerance" suggestion in the previous paragraphs...)

Herman


More information about the ros-users mailing list