robot_state_publisher fixed frames 0.5s ahead

asked 2014-08-12 07:34:24 -0500

955 ●67 ●83 ●98

updated 2014-08-12 07:36:09 -0500

Hi guys,

The robot_state_publisher has 2 different mechanisms for publishing moving and fixed frames. Moving frames are published on joint_states callback.

Does anyone know why robot_state_publisher publishes the fixed frames using a timer independent from the joint_states subscriber and ahead of 0.5 seconds?

Could not find any valid reason whether from the internet or the code...

Thanks ;)

answered 2014-08-12 11:30:59 -0500

dornhege

31395 ●134 ●284 ●498

updated 2014-08-12 11:32:24 -0500

Note: This is a conjecture on my part.

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)
Usually this makes some waitForTransform constructs necessary, even for fixed transforms, which do not change (TF didn't know this difference at first)
Fixed frames are fixed. Therefore they do not change. Hence it is correct to assign any time (e.g. +0.5s) to them.
When querying transform data for fixed frames for current data, the TF listener already has data from now + 0.5s and 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.

edit flag offensive delete link

Comments

Wow, if it is that it is super fiddly! As you would never be in a position to really tell which sample you interpolate from... Keep in mind that fixed frames are fixed with respect to their parent, not with respect to the world, hence if their parent move over time (wrt the world), they also do.

arennuit ( 2014-08-13 00:27:37 -0500 )edit

This is not a problem. Only the fixed transform would be send predated this way.

dornhege ( 2014-08-13 03:53:53 -0500 )edit

In this case, the following will happen: 1. moving frames are sent at t1, 2. fixed frames are sent at t2 + 0.5 (computed by composing with moving frames at t1), 3. moving frames are sent at t3 < t2 + 0.5, 4. now frames are read. Then when the reading is performed, the fixed position wrt to

arennuit ( 2014-08-13 04:22:58 -0500 )edit

the world are computed out of the composition of parent moving frames at t1. Hence they are wrong.

arennuit ( 2014-08-13 04:23:01 -0500 )edit

I don't understand what you are doing there, but this doesn't seem correct. Can you give a concrete example, e.g. with /odom -> /base_link -> /laser, where you think something goes wrong?

dornhege ( 2014-08-13 04:28:46 -0500 )edit

Ok I update the question in a few minutes

arennuit ( 2014-08-13 04:35:10 -0500 )edit

While writing an edit for further explanations I realized that you are actually right: at step 4 the computation of the position of the fixed frames wrt to the world uses moving frames at t2 and not t1 and interpolates the fixed frames (which does not do anything as they are constant).

arennuit ( 2014-08-13 04:50:37 -0500 )edit

Thanks for provoking these thoughts ;)

arennuit ( 2014-08-13 04:50:42 -0500 )edit

add a comment

Comments