Ask Your Question
0

Bug in ros_comm: Topic Statistics rate under 0.016 Hz for some connections

asked 2019-02-20 15:47:42 -0500

wentz89 gravatar image

updated 2019-02-21 06:42:29 -0500

There is actually no question. I just observed a strange behavior of the topic statistics feature and opened a issue on the ros github page. The issue got closed with the recommendation to ask my "question" here.

So here we go:

I have a plot-tool to visualize the statistics datas from rosbags and it seems that for some topic-connections there are only 7 messages over 420 sec on the /statistics topic, but with a pretty large amount of evaluated datas. I know that the statistics calculation uses a dynamic window if to less datas are available. But a window of 60-70 secs and more than 6000 evaluated messages seem pretty strange.This happened with more than one Topic.

There is a plot that shows this behavior here: https://github.com/ros/ros_comm/issue...

In the picture one can see the data points when a new message on /statistics with information about this specific publisher-subscriber connection was recorded. In my opinion, however, this behavior (0.016 Hz for an update on /statistics) is unintentional and unwanted. Thats why i opened a issue.

To make it clear, the expected update rate for one publisher-subscriber - connection on the statistics topic is 1 Hz (thats what my datas show for most of the other connections).

edit retag flag offensive close merge delete

Comments

What is unexpected, the statistics data itself, or the publication rate of the /statistics topic?

ahendrix gravatar image ahendrix  ( 2019-02-20 23:30:05 -0500 )edit

The Data itself is doesn't matter. My only concern is the update rate. So for example: A topic connection with 3 Hz, sends a new message on statistics every 4 messages, so round about 1 Hz update rate. I just took a look on my data and the update rate for one connection is always about 1 Hz.

wentz89 gravatar image wentz89  ( 2019-02-21 00:54:42 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2019-02-21 02:49:02 -0500

wentz89 gravatar image

So I looked up the source code and there is a bug. The calculation of the publish_frequency:

// dynamic window resizing
if (stats.arrival_time_list.size() > static_cast<size_t>(max_elements) && pub_frequency_ * 2 <= max_window)
{
  pub_frequency_ *= 2;
}
if (stats.arrival_time_list.size() < static_cast<size_t>(min_elements) && pub_frequency_ / 2 >= min_window)
{
  pub_frequency_ /= 2;
}

So basically if there are more messages then max_elements increase the frequency or if there are less messages then min_elements decrease the frequency. This is fine.

And the decision if one should publish a new statistics message:

// should publish new statistics?
if (stats.last_publish + ros::Duration(pub_frequency_) < received_time)
{
...
}

I recognized that pub_frequency_ is a double value, which doesn't make sense. So a simple example:

stats.last_publish = 1

pub_frequency_ = 10

received_time = 2

Obviously in this case one should publish cause 1 second passed and our frequency is 10 Hz. But the if-statement evaluates to:

1 + 10 < 2 -> false

which means don't publish. So this line need to be changed to:

if (stats.last_publish + ros::Duration(1 / pub_frequency_) < received_time)

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2019-02-20 15:47:42 -0500

Seen: 84 times

Last updated: Feb 21 '19