[Documentation] [TitleIndex] [WordIndex

This page summarizes how the tf2 package was designed.

Design Overview

tf2.png

Design Goals

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.

A distributed system

Only transform data between coordinate frames at the time of use

Support queries on data which are timestamped at times other than the current time

Only have to know the name of the coordinate frame to work with data

The system doesn't need to know about the configuration before hand and can handle reconfiguring on the fly

Core is ROS agnostic

Thread Safe Interface

Multi-Robot Support

Native Datatype Interfaces

 template <class A, class B>
 void convert(const A& a, B& b)
 {
   fromMsg(toMsg(a), b);
 }

And as long as any datatype provides the methods msgType toMsg(datatype) and fromMsg(msgType, datatype) it can be automatically converted to any other datatype with the same methods defined and a matching msgType.

All tf2_ros interfaces can then be called with native type in and native type out. Note, the native type in and out do not need to match.

Known Limitations of tf

After using the current implementation there are a number of limitations which have become evident. Below are some of the most noticed ones.

tf_prefix is confusing and counterintuitive

The direction of the graph can be confusing

tf messages do not deal with low bandwidth networks well

tf doesn't keep a long history


2024-10-05 16:55