Rosbag play very slow (and CPU load 100 percent)

rosbag
play

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

michikarg
2108 ●19 ●37 ●52 http://hcai.in.tum.de/...

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

add a comment

3

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

michikarg
2108 ●19 ●37 ●52 http://hcai.in.tum.de/...

Seems like this is a known problem ( http://ros-users.122217.n3.nabble.com/Problems-with-rosbags-in-Electric-on-Oneiric-td3465949.html ) 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

add a comment

1

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

Thomas

4478 ●39 ●58 ●84 http://thomas.moulard.net/

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:

Modify rosbag to first load the whole file in memory and write data back from the memory copy.
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

Comments

1

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...