0
$\begingroup$

Rosanswers logo

Hi everybody,

My setup : Ubuntu 12.10, ROS Groovy, laptop with i7 CPU, and 6GB of RAM.

My goal : from a rosbag, being able to write certain transforms (currently, the ones from the openni_tracker (a modified version)) into a txt file, with timestamps.

My problem : based on the tf tutorial on a TfListener, I listened to tf, and tried to write only the part interesting me. Moreover, all the frame I want to write are not always published.

My code snipet si something like that :

In main,

  • initialize the ros node
  • create the Tf Listener
  • while the node is ok

for all the possible users I am looking to

if listener.canTransform,

time_of_my_user = ros::Time::now();

for all joints

waitforTransform(time_of_my_user),lookupTransform(time_of_my_user), Write in a txt file

The problem is that I am missing a LOT of transforms. I was thinking it might be because my loops doesn't go fast enought. Thus I tried, when playing the bag file, to use the option "-r 0.1". But in this case, I don't have anything written at all.

May someone enlighten me of his/her knowledge about tf, as I am quite sure I am missing something (maybe about the lookupTransform ?). Or give me another solution in order to be able to write a list of transformations into a txt file (I was maybe thinking about a subscriber to tf ?)...

If needed, I can provide the exact code.

Thanks in advance, Bests regards,

Steph


Originally posted by Stephane.M on ROS Answers with karma: 1304 on 2013-03-13

Post score: 0

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

(I was maybe thinking about a subscriber to tf ?)

That would be my suggestion and should be the easiest way to do it. If you are using multiple waitForTransform in a serial fashion, i would guess, that you will miss all messages published in the meantime, until the desired transform arrives.

Think about the following case: Transforms are published in order of a, b, c, a, b, c, ... You start with waitForTransform(c) -> you will miss a, b and finaly get c. Next you wait for b and miss one a transform. After that you will listen for a, but miss another c in the meantime.

Hope my understanding of this matter is correct, cant give you any guaranty. ;)


Originally posted by Ben_S with karma: 2510 on 2013-03-13

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by Stephane.M on 2013-03-13:
Yes, I though about the fact of "missing", so I removed the "waitForTransform". But even if it was filling my txt file with incoherent data (I mean that c was having the same values as a and b), I did not have that much more data. However, I guess the Subscriber would be a better way. Thanks :-)

Comment by Stephane.M on 2013-03-13:
But I have a last questio nfor you then : In my case, except from the waitForTransform, what is the main difference between listener and subscriber ? I guess it is linked to the callBack function, but my knowledge in that matter is quite poor, thus my understanding poorer... Thanks in advance !

Comment by Ben_S on 2013-03-13:
I think the transform listener processes all the tf messages in the background and does some internal caching and processing, that allows you to lookup particluar transforms at any given timestamp (within the caching period). A subscriber lets you do all the work for yourself. :)

Comment by Stephane.M on 2013-03-13:
Ok, I though in the same way. But thus any idea why in my case the subscriber would be "faster" than the listener ? (In fact I was starting to program with the subscriber when I told myself : no the listener should be better for tf...)

Comment by Ben_S on 2013-03-13:
With a custom subscriber you will get every tf message exactly once. No need to manually test for specific transforms. I dont think that the listener allows you to access single messages. So you have to do some sampling with very high frequencies to not miss any messages.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.