-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Latest_time policy may in some case refrain from publishing for an aribitrarily long period #131
Comments
This was discussed in the issue triage meeting, and the conclusion was that we don't have anyone to look into this at the moment, but it would be helpful (for others that might help with this issue) if there was a simple isolated example, e.g. a bag file and some sample code to reproduce the issue. For now we will leave it here, but if you update this with more information it will be triaged again in the future. Also as a note, please copy-paste text, rather than posting pictures of text. Thanks! |
@wjwwood can you put |
Thank you for paying attention to my issue. Below I provide my code that generates the result I described above.
|
@wjwwood @fujitatomoya I have reproduced the issue, and I would like to try to fix it if no one else is already looking at it. |
The latest_time filter only publishes when the arriving message comes from the pivot sensor.
if (valid_rate && (i == find_pivot(now)) && is_full()) {
publish();
}
However, if all sensors sample at a gradually decreasing frequencies, i.e., each new message always arrives later than before, they may all fails to match the pivot (because new message arrives and decrease its frequency, pivot is thus changed). When this happens, the filter may not publishing for an extended, or even infinite period, despite all sensors functioning properly.
Here is an example. There are 2 sensors, initally with the same frequency. Starting from a time, both sensors' frequencies begin to decrease. Then pivot will change whenever a new message arrives, so that no pivot match, and thus no publishing will occur. Image below is the log of this example.
This impairs the usability of this policy. Because each time sensors decrease frequencies together, even if only for a small decreasing period in the fluctuation, the policy may refrain from publishing until the decreasing stops. The pubishing frequency is thus below the highest frequency among sensors, which does not meet the expectation for this policy.
To address this issue, it might be better to compulsely publish whenever current period has exceeded the pivot's frequency, i.e., use
t_last
to store last publishing time:int p = find_pivot(now);
if (valid_rate && ( (i == p) || (now - t_last).seconds() >= 1 / rates_[p].hz) ) && is_full()) {
publish();
t_last = now;'
}`With this modification, the publishing frequency is guaranteed to approach the pivot's frequency.
The text was updated successfully, but these errors were encountered: