# tf scope and goals

Eric and Tully

## Fundamental goals

- Let end-users transform data from one frame on the robot into another easily and correctly
- point-clouds
- positions (e.g. detected objects)
- 3d poses (e.g. localized 3d objects)
- orientations (e.g. keep glass upright)

- Unify error-prone transform math into one location, so it can be correct and tested
- Support easy distribution of transform data (primarily robot kinematics and localization data)
- Encourage single data-type use for geometric primitives

## Requirements

- Ease of use. tf MUST be accessible to people without significant transform experience. It must be much easier to use correctly than to use wrong.
- Correctness. Everything implemented in tf must be completely correct. It is better to not implement features than to have untested or untrusted features.
- Interpolation and extrapolation behavior must be clearly defined and not have gotchas.

- Performance. tf shouldn't be unnecessarily slow, but performance is not the primary concern.
- Published transform rates will be at absolute maximum 30 transforms / ms. In reality they will probably be 30 transforms / 10ms.
- For highest-rate requests, users will get transforms and then repeatedly apply them.
- The worst-case request use case we know if is the visualization, which will be 30 requests / 10ms.

## Structure / components

### 3d math library

base geometric primitives

- 3d vector
- 3d point?
- quaternion / orientation
- full 3d transform / pose (vector + orientation)

basic mathematic operations

- 3d vector/point addition, subtraction, scaling, identity, projection, dot, cross, interpolation, norm, normalize, distance, distance^2
- quaternion/quaternion multiplication, imports, exports, interpolation, angular distance, normalize
- transform: composition, inversion, set/get orientation and translation
- apply rotations to vectors, points, orientations(q*q), transforms
- apply transforms to vectors, points, orientations, transforms(composition)
- apply vector translation to transforms

possible mathematical operations

- skew-symmetric, cubic/quadratic interpolation
- quaternion sampling

design decisions

- member or external functions - external and polymorphic
- class names - vector3
- visibility of internal implementation
- making quaternion visible externally
- is normalization required?
- is "knowing quaternions" required?

- semantic differences
- vector vs point - only issue is applying transforms. Can be resolved by transformPoint and transformVector.
- rotation vs orientation - just have quaternion.
- transformation vs pose

- integration with ROS messages

Possibilities

- Nocturnal
- Ogre
- Irrlicht
- Bullet

Conclusion:

- Using Bullet for 3d math library looks like the right choice.

### Transform graph

Time-caching and parenting architecture.