Subscriber can't keep up

asked 2016-11-10 20:36:57 -0500

rschwieb
11 ●1 ●1 ●2

updated 2016-11-11 05:48:42 -0500

I have a rosbag of ~270 Image messages over the course of 9 seconds, and a subscriber that catches them, does a little processing, and publishes a different message.

I had the feeling the subscriber was definitely not keeping up with incoming messages, so I wrote in a little logging to tally what work was actually being done. Each time I run, the count of "jobs finished processing" never gets above 25. I paused and stepped through the rosbag play, and going (comparatively) slowly this way I was able to get 50+ messages before I stopped the test.

I thought it might be an issue with the queues too small, but I set the queue sizes on my Subscriber and the --queue flag on the rosbag play both to 300, so I think that should entirely eliminate the problem if that is it. (It just occurred to me that maybe the maximum is lower than I think, maybe the default 100 is max? Still I would expect at least 100 successful runs, if that many were queued up somewhere.)

What else should I be looking for? Thanks for your advice.

answered 2016-11-11 08:32:33 -0500

Felix Endres

6468 ●28 ●57 ●93 http://www.informatik....

Some questions and suggestions:

Are you subscribing directly, or do you use something like message_filters?
Have you tried slowing down the playback, e.g., rosbag play -r0.1?
What does rostopic hz /your-img-topic print?
What does rostopic echo /your-img-topic/header/seq print?
Can you provide a minimal example?
In C++ at least, you could use the rosbag API, if all you want is lossless bagfile processing

edit flag offensive delete link

Comments

Just FYI, rosbag also has a Python API

jarvisschultz ( 2016-11-11 10:16:53 -0500 )edit

@FelixWhat does rostopic hz /your-img-topic print? While the databag is playing back, I get a sequence of messages like this: "average rate: 30.047\n min: 0.003s max: 0.063s std dev: 0.01161s window: 248"

rschwieb ( 2016-11-11 20:05:22 -0500 )edit

@Felixwhat does rostopic echo ... print? I get a sequence of 270 integers.

rschwieb ( 2016-11-11 20:07:04 -0500 )edit

@Felix using the -r0.1, i was able to see the messages for 226 of the messages. I think that must mean with a little more slowing down then the subscriber would see and process everything! I think I'm supposed to be able to handle full playback speed, though.

rschwieb ( 2016-11-11 20:15:52 -0500 )edit

This is an evaluation of sorts, so I shouldn't disclose any of the code, and I think it's probably a requirement that this can handle full playback speed. (The evaluator said if I ran into a problem like this it would be OK to ask a generic question here on answers.ros.)

rschwieb ( 2016-11-11 20:18:59 -0500 )edit

I'll do whatever I can to clarify the description, though.

rschwieb ( 2016-11-11 20:19:25 -0500 )edit

Have you measured the runtime of your processing of the images?

NEngelhard ( 2016-11-12 06:58:47 -0500 )edit

@NEngelhard By using time() measurements at the ends of the callback the does the processing, it looks like the routine takes around 0.4 seconds. So it's not surprising that the subscriber gets behind, I just can't figure out why the extra queue space can't keep everything from slipping away.

rschwieb ( 2016-11-12 10:43:28 -0500 )edit

see more comments

1 Answer

Comments

Question Tools

Stats

Related questions

Subscriber can't keep up edit

1 Answer

Comments

Question Tools

Stats

Related questions

Subscriber can't keep up