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.