Ask Your Question

Rosbag play very slow (and CPU load 100 percent)

asked 2012-09-13 23:51:17 -0500

michikarg gravatar image

Hey guys,

i recently recorded some Kinect Motion tracking data using rosbag record and am now playing it using rosbay play (I'm on Ubuntu Oneiric and ROS Fuerte). But it plays really slow (feels like approx. 1/10 th realtime and CPU usage of one core goes up to 100 %) although I only recorded tf (returned from openni_tracker) and one string message:

$ rosbag info day1_cereals.bag 
path:        day1_cereals.bag
version:     2.0
duration:    2:18s (138s)
start:       Aug 29 2012 11:34:24.88 (1346232864.88)
end:         Aug 29 2012 11:36:43.07 (1346233003.07)
size:        300.0 MB
messages:    78576
compression: none [204/204 chunks]
types:       std_msgs/String [992ce8a1687cec8c8bd883ec73ca41d1]
             tf/tfMessage    [94810edda583a504dfda3829e70d7eec]
topics:      /object_detections    1085 msgs    : std_msgs/String (1085 connections)
             /tf                  77491 msgs    : tf/tfMessage    (77491 connections)

Is this performance normal? I would think that it should perform way faster (i use an I7 2,3 Ghz Quadcore)... The number of TF transforms is below 50 (output of openni_tracker plus camera frames plus some object detections). Did someone experience similar issues?

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2012-09-14 04:31:27 -0500

michikarg gravatar image

Seems like this is a known problem ( ) which is the result of the creation of one connection per message.

However the problem doesn't appear any more after running a rosbag fix on the bagfiles.

edit flag offensive delete link more

answered 2012-09-14 04:30:45 -0500

Thomas gravatar image

updated 2012-09-14 04:31:29 -0500

This is perfectly understandable. You have 300Mb in 2:18s, i.e. ~138Mb/s to achieve real-time. It is likely to be more that your hard-drive maximum bandwidth even if you consider that you are the only process accessing to the disk... (the story differs although if you have an SSD).

It explains why rosbag can publish clock information and be setup to replay data slowly so that your disk can keep up with the data that must be accessed (see -r and --clock). The most practicable solution is to simulate your whole graph at a slower rate. If all your nodes uses the ROS time API and are designed to send data at a particular frequency (which is good so you can double check that your nodes run correctly without putting too much pressure on the CPU), it should be totally transparent.

If you really want to achieve real-time, then you have two options:

  1. Modify rosbag to first load the whole file in memory and write data back from the memory copy.
  2. Use Linux tricks such as mounting a dedicated partition where data is stored directly in the memory (see ramfs or tmpfs) to achieve faster access to the rosbag file.
edit flag offensive delete link more



Thanks for your help, but its actually 138s (see number in parentheses) so this should be (and after rosbag fix is) doable in realtime... but I guess the output of rosbag info is wrong in this case, there should be "min" instead of "s" after the first duration number...

michikarg gravatar imagemichikarg ( 2012-09-14 04:36:09 -0500 )edit

Oh yeah, did not parse this number correctly. Sorry about that.

Thomas gravatar imageThomas ( 2012-09-14 06:12:29 -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


Asked: 2012-09-13 23:51:17 -0500

Seen: 1,311 times

Last updated: Sep 14 '12