Join or stitch together multiple rosbags

[vinnnyr]

Description

I am going to be needing to "stitch" or join together multiple rosbags that have been split at 30 second intervals. As you can imagine, this is quite cumbersome to deal with, and I would like a way to point to a directory of rosbags and have it joined together into a ~ 5min rosbag.

Something like ros2 bag reshape <my_directory>

Maybe present a warning to the user when rosbags have wildly different timestamps. (should this be controlled by a command line argument or parameter?)

Related Issues

Opposite of #599

Completion Criteria

• Successful merging of rosbags in chronological order
• new rosbag is successfully played
• Warnings when timestamps of wildly different rosbags are in the directory
• New rosbag2 verb for joining rosbags

Implementation Notes / Suggestions

Not an expert here ... just need to mainly go into a directory, walk through each bag inside, and write to a new bag.

As for the implementation, I can see it going something like: open a reader for an existing bag, open a writer for new bag with new options, read from the reader as fast as possible and give to the writer. Might not be the most efficient possible, we may want to consider if storage implementations are able to combine bagfiles whole. But this way would also allow converting from one storage format to another in a generic way too

Testing Notes / Suggestions

• test to have several small rosbags in a directory with small chatter messages make sure chronology is maintained
• test to make sure a warning is raised when attempting to merge rosbags with different timestamps.

[vinnnyr]

If there is further interest, I am wanting to work on this since I am needing this feature. Would love some guidance on direction before I get started.

[emersonknapp]

Related to #599, but the opposite feature :)

[emersonknapp]

I think that this feature should be implemented in a few phases : add the core functionality with tests, then add the frontend, e.g. The new verb.

I'm thinking that it might make sense for the frontend to be something like ros2 bag reshape so that, using mostly the same options as record , we could take input bags of any splitting-length and output them at any other. That would solve both this and #599 as a feature.

As for the implementation, I can see it going something like: open a reader for an existing bag, open a writer for new bag with new options, read from the reader as fast as possible and give to the writer. Might not be the most efficient possible, we may want to consider if storage implementations are able to combine bagfiles whole. But this way would also allow converting from one storage format to another in a generic way too

[emersonknapp]

@gbiggs is working on an implementation that will handle this use case - when you have a PR can you link it to this issue?