Revision history [back]

Note: This is a conjecture on my part.

1. When you use TF, usually you query a transform for your data's time. Often this is current data, e.g. from now. If you query the transform for current data it is likely to fail, as the TF data has not arrived, yet. (It will under the hood in a short time, though)
2. Usually this makes some waitForTransform constructs necessary, even for fixed transforms, which do not change (TF didn't know this difference at first)
3. Fixed frames are fixed. Therefore they do not change. Hence it is correct to assign any time (e.g. +0.5s) to them.
4. When querying transform data for fixed frames for current data, the TF listener already has data from now + 0.5s and before. Therefore it can interpolate between the transforms and immediately give an answer without waiting.

Note: This is a conjecture on my part.

1. When you use TF, usually you query a transform for your data's time. Often this is current data, e.g. from now. If you query the transform for current data it is likely to fail, as the TF data has not arrived, yet. (It will under the hood in a short time, though)
2. Usually this makes some waitForTransform constructs necessary, even for fixed transforms, which do not change (TF didn't know this difference at first)
3. Fixed frames are fixed. Therefore they do not change. Hence it is correct to assign any time (e.g. +0.5s) to them.
4. When querying transform data for fixed frames for current data, the TF listener already has data from now + 0.5s and before. before (because it was send with time stamps 0.5s in the future). Therefore it can interpolate between the transforms and immediately give an answer without waiting.