Skip to content
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

feat: add repeated transient local option #1051

Closed

Conversation

wep21
Copy link
Contributor

@wep21 wep21 commented Jul 28, 2022

Implement a feature equivalent to ros/ros_comm#1850

@wep21 wep21 requested a review from a team as a code owner July 28, 2022 15:30
@wep21 wep21 requested review from gbiggs and MichaelOrlov and removed request for a team July 28, 2022 15:30
@wep21 wep21 force-pushed the feature/add-repeated-transient-local-option branch from 36f08ba to 19c883a Compare July 28, 2022 15:43
Signed-off-by: Daisuke Nishimatsu <[email protected]>
@wep21 wep21 force-pushed the feature/add-repeated-transient-local-option branch from 19c883a to e4d3dec Compare July 29, 2022 01:53
Copy link
Contributor

@MichaelOrlov MichaelOrlov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wep21 I am sorry I can't approve this feature.
This feature doesn't align with rosbag2 and entire DDS communication concept by design.

First of all in rosbag2 we don't have ability to start playback from some chunk or splitted bag. Instead we can start from some timepoint and have jump/seek API. We also have ability to pause playback and burst some messages without respecting delay between them i.e. "fast forward" or play_next API.
User can start playback, wait till key frames e.g. map or tf will be published then go in pause mode and quickly playback some amount of messages with play_next API or use seek(time) API to skip some amount of messages to be able to continue playback from some timepoint. There are no way to start playback or jump in playback to the next split file.

Therefore in rosbag2 we don't have such problem with missed messages publishing only once. It's just because rosbag2 designed differently.

Another aspect is DDS communication. With transient local qos settings could be and in many cases really are topics which are publishing on regular bases. Approach when saving all messages from such topics in hash map and then writing them to each new bag doesn't look like a good idea.

One more aspect is that in rosbag2 we are trying to adhere to determinism in recording and playback. Playback should exactly repeat flow from recording as close as possible.
It means there are must not be any extra magically added messages during playback or recording which was not really published when recording was happened.

@MichaelOrlov
Copy link
Contributor

  • Closing as will not be merged due to the conflict in design and concept of Rosbag2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants