tf scope and goals
Eric and Tully
- Let end-users transform data from one frame on the robot into another easily and correctly
- 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
- 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
- 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
- Using Bullet for 3d math library looks like the right choice.
Time-caching and parenting architecture.