Ask Your Question
0

Problem mixing lidar bag with live tf

asked 2015-05-06 11:42:33 -0500

charles.fox gravatar image

updated 2015-05-06 16:43:29 -0500

During development, I am trying to replay lidar data from a bag file and combine it with simulated new robot positions, generated during the simulation run. The lidar data I recorded a few weeks ago, and the simulated positions are computed on the fly by a controller and command based odometry nodes.

However there is some problem with tf occuring, and causing assemble_scans to give no output. Assemble_scans works fine when I replay tf's recorded inside the bag together with the lidar; but not when I filter them out of the bag file and play my live versions. (I'm running in simtime mode.)

Further info: I'm on ROS Indigo on Ubuntu and using Python; I have use_sim_time true set and am using --clock. There are no error messages displayed by laser_assemble or anything else, it just sits there doing nothing (giving empty data when called as a service.) After 20s I get this warning message,

WARN 1430939127.391484409, 1429541092.395955176: MessageFilter target=map : Dropped 100.00% of messages so far. Please turn the ros.laser_assembler.message_notifier rosconsole logger to DEBUG for more information.

But I'm not sure how to change this DEBUG setting ?

Some experiments I did,

1 I filtered scan and tf into a new bag file, to remove any potential confusion from other messages; laser_assemble works with this bag replayed wit --clock.

2 I filtered scan and tf into separate bags, and played them via a single rosbag node with --clock, laser_assemble works

3 I filtered scan and tf into separate bag files and replay them with two separate rosbag nodes, both with --clock. This gives back in time errors (as expected)

4 As (3) but with --clock set only on the scan bag player and not on the tf bag player; laser_assemble works fine.

Case 4 is interesting as its most similar to the original failure mode, as I understand it the tf bag player will take its time stamps from ros::time rather than from its own bag file, as would be the case for the live tf posts.

So it seems there is some different between tf publications that are created by bag files and those that are created live? The nearest discussion I found -- from 2012 -- was here, http://answers.ros.org/question/11477... which AFAICT is about the opposite problem, restamping bagged tf's so they look like they are happening in real time. (I'm the other way, I want real time tf's to look like sim times.)

Please let me know if there are any additional log files I could read and post here to get more info too, or any ideas what else could be going wrong here?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2015-05-06 12:57:25 -0500

Playing back the bag with --clock, and setting the parameter use_sim_time to true may fix the problem (see Clock for more info). Without more info, this will be hard to debug. It would be helpful if you could update your question with any error messages you are seeing.

edit flag offensive delete link more

Comments

I found the problem, the laser_assemble xml example is remapping the points into the "map" frame, so I need to publish a tf from odom to map as well as base_link to odom. As it happened there was one of these in my bag file, but not in my live tf broadcaster.

charles.fox gravatar image charles.fox  ( 2015-05-06 16:45:40 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2015-05-06 11:42:33 -0500

Seen: 572 times

Last updated: May 06 '15