Revision history [back]

My guess is that nodes work simultaneusly and sometimes extraction executes before applying image_proc.

I guess your guess is correct. :)

Probably rosbag is replaying the messages to fast, and one of the following nodes in your pipeline cannot process them fast enough, the internal queue of that node fills up and then messages are dropped.

You can easily test this theory by playing back the messages slower using the -r argument of rosbag play, for example rosbag play -r 0.1 .

-r FACTOR, --rate=FACTOR
                      multiply the publish rate by FACTOR

This is a known drawback of an asynchronous pub/sub framework like ROS, compared to things like ecto. But that was just a side remark, I think you're on the right track.

My guess is that nodes work simultaneusly and sometimes extraction executes before applying image_proc.

I guess your guess is correct. :)

Probably rosbag is replaying the messages to fast, and one of the following nodes in your pipeline cannot process them fast enough, the internal queue of that node fills up and then messages are dropped.

You can easily test this theory by playing back the messages slower using the -r argument of rosbag play, for example rosbag play -r 0.1 .

-r FACTOR, --rate=FACTOR
                      multiply the publish rate by FACTOR

This is a known drawback of an asynchronous pub/sub framework like ROS, compared to things like ecto. (which was made by the same people as ROS, by the way). But that was just a side remark, I think you're on the right track.

My guess is that nodes work simultaneusly and sometimes extraction executes before applying image_proc.

I guess your guess is correct. :)

Probably rosbag is replaying the messages to fast, and one of the following nodes in your pipeline cannot process them fast enough, the internal queue of that node fills up and then messages are dropped.

You can easily test this theory by playing back the messages slower using the -r argument of rosbag play, for example rosbag play -r 0.1 .

-r FACTOR, --rate=FACTOR
                      multiply the publish rate by FACTOR

This is a known drawback of an asynchronous pub/sub framework like ROS, compared to things like ecto (which was made by the same people as ROS, by the way). But that was just a don't get distracted by this side remark, I think you're on the right track.

My guess is that nodes work simultaneusly and sometimes extraction executes before applying image_proc.

I guess your guess is correct. :)

Probably rosbag is replaying the messages to too fast, and one of the following nodes in your pipeline cannot process them fast enough, the internal queue of that node fills up and then messages are dropped.

You can easily test this theory by playing back the messages slower using the -r argument of rosbag play, for example rosbag play -r 0.1 .

-r FACTOR, --rate=FACTOR
                      multiply the publish rate by FACTOR

This is a known drawback of an asynchronous pub/sub framework like ROS, compared to things like ecto (which was made by the same people as ROS, by the way). But don't get distracted by this side remark, I think you're on the right track.

My guess is that nodes work simultaneusly and sometimes extraction executes before applying image_proc.

I guess your guess is halfway correct. :)

Probably rosbag is replaying the messages too fast, and one of the following nodes in your pipeline cannot process them fast enough, the internal queue of that node fills up and then messages are dropped.

You can easily test this theory by playing back the messages slower using the -r argument of rosbag play, for example rosbag play -r 0.1 .

-r FACTOR, --rate=FACTOR
                      multiply the publish rate by FACTOR

This is a known drawback of an asynchronous pub/sub framework like ROS, compared to things like ecto (which was made by the same people as ROS, by the way). But don't get distracted by this side remark, I think you're on the right track.