-
Notifications
You must be signed in to change notification settings - Fork 7
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
Add ability to specify start & end times for reading #31
base: master
Are you sure you want to change the base?
Add ability to specify start & end times for reading #31
Conversation
e0a7844
to
58eea82
Compare
return getMessages(topics, start_time_ns, end_time_ns); | ||
} | ||
|
||
View View::getMessages(const std::vector<std::string> &topics, std::chrono::nanoseconds start_time, std::chrono::nanoseconds end_time) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might make sense to operate on the data with ros_time_t
and have that as the argument to the function, but then provide an easy to use constructor for ros_time_t
from std::chrono::nanoseconds
.
|
||
int with_time_boundaries_count = 0; | ||
for (const auto &message : view_.getMessages(all_topics, start_time_ns, end_time_ns)) { | ||
with_time_boundaries_count++; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also likely assert that the timestamp of the message is greater than or equal to the start time, and less than the end_time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liamembark we can't actually - this isn't true. Maybe you can suggest how we can document what is happening:
This compares chunks and not actual messages. So it is entirely possible (and happens in this case) that if i say give me messages between t=5 and t=11, we get messages from t=4 to t=12 because those are the chunks that encompass those messages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nvm see below
TEST_F(ViewTest, MessagesBetweenTimestamps) { | ||
std::chrono::nanoseconds start_time_ns {view_.getStartTime().to_nsec()}; | ||
std::chrono::nanoseconds end_time_ns {view_.getEndTime().to_nsec()}; | ||
start_time_ns += std::chrono::seconds{1}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you also add a end_time_ns?
@@ -185,9 +191,10 @@ View View::getMessages(const std::vector<std::string> &topics) { | |||
|
|||
for (const auto &connection_record : bag->topic_connection_map_.at(topic)) { | |||
for (const auto &block : connection_record->blocks) { | |||
bag_wrappers_[bag]->chunks_to_parse.emplace(block.into_chunk); | |||
if (block.into_chunk->info.end_time > start_time && block.into_chunk->info.start_time < end_time) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd recommend doing >= and <= to be inclusive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also think you might also want further filtering when yielding the actual messages within the chunk, and not just filtering at the chunk level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finally, this filter will remove any chunks that straddle the edge of the filter - I don't think thats the behaviour we want. We should be reading any chunks that contain any data within the start and end time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah we can filter when we yield, that's a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So save the start/end timestamps to the view, and when yielding do another bounds check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya exactly - I think that would be the right approach in this case! We definitely still want to filter out chunks for some performance gains, but then a secondary filter at message yield time will do the final checks for us.
Description of Changes
Mimics some functionality of ROS Bag views - specifically started from an offset and reading to a specific part of bag on specified topics
Test Plan
Added another test - ran succesfully