Rosbag play very slow (and CPU load 100 percent)

Question

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?

---

Originally posted by michikarg on ROS Answers with karma: 2108 on 2012-09-13

Post score: 2

Answer 1

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.

---

Originally posted by Thomas with karma: 4478 on 2012-09-14

This answer was NOT ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by michikarg on 2012-09-14:
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...

Comment by Thomas on 2012-09-14:
Oh yeah, did not parse this number correctly. Sorry about that.

Answer 2

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.

---

Originally posted by michikarg with karma: 2108 on 2012-09-14

This answer was ACCEPTED on the original site

Post score: 3