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

Allow adding time-stamp to the custom output name #1910

Closed
3 tasks
PfeifferMicha opened this issue Feb 11, 2025 · 6 comments
Closed
3 tasks

Allow adding time-stamp to the custom output name #1910

PfeifferMicha opened this issue Feb 11, 2025 · 6 comments
Labels
enhancement New feature or request wontfix This will not be worked on

Comments

@PfeifferMicha
Copy link

PfeifferMicha commented Feb 11, 2025

Description

When giving a bag name via -o or --output the time-stamp is no longer added to the output folder name. I'd like to be able to write bags that have both a custom name and a time-stamp.
I frequently record multiple bags where I want the custom name to be the same except for the added timestamp. Example:

  • calibration_data_2025_02_11-09_01_53
  • calibration_data_2025_02_11-09_10_30

Completion Criteria

  • implement --prefix for rolling
  • back-port to jazzy
  • back-port to humble

Implementation Notes / Suggestions

I see three options:

  1. Always append the time-stamp when -o is used, unless --no-time-stamp is specified
  2. Add the time-stamp when -o is given and --time-stamp is specified
  3. Add a new --prefix PREFIX (mutually exclusive with -o) option which turns the folder name into PREFIX_timestamp
@PfeifferMicha PfeifferMicha added the enhancement New feature or request label Feb 11, 2025
@fujitatomoya
Copy link
Contributor

I think this can be fairly easy done by user as shown below, and -o / --output is the destination specified by the user.
I am not sure why we need to keep this functionality for -o / --output... besides, ros2 bag record already has many options... i am not convinced to have extra --time-stamp with -o / --output just for the timestamp postfix...

root@tomoyafujita:~/ros2_ws/colcon_ws# ros2 bag record -a -o mybag_"$(date +"%Y-%m-%d_%H-%M-%S")"
[INFO] [1739303395.217173344] [rosbag2_recorder]: Press SPACE for pausing/resuming
[INFO] [1739303395.220827308] [rosbag2_recorder]: Listening for topics...
[INFO] [1739303395.220835096] [rosbag2_recorder]: Event publisher thread: Starting
[INFO] [1739303395.225336938] [rosbag2_recorder]: Subscribed to topic '/rosout'
[INFO] [1739303395.227837953] [rosbag2_recorder]: Subscribed to topic '/parameter_events'
[INFO] [1739303395.229192994] [rosbag2_recorder]: Subscribed to topic '/events/write_split'
[INFO] [1739303395.230813408] [rosbag2_recorder]: Subscribed to topic '/chatter'
[INFO] [1739303395.230864181] [rosbag2_recorder]: Recording...
[INFO] [1739303399.499334564] [rosbag2_recorder]: Pausing recording.
[INFO] [1739303399.499565413] [rosbag2_cpp]: Writing remaining messages from cache to the bag. It may take a while
[INFO] [1739303399.512315354] [rosbag2_recorder]: Event publisher thread: Exiting
[INFO] [1739303399.512499011] [rosbag2_recorder]: Recording stopped
[INFO] [1739303399.611646502] [rclcpp]: signal_handler(signum=2)

root@tomoyafujita:~/ros2_ws/colcon_ws# ls mybag_2025-02-11_11-49-54/
metadata.yaml  mybag_2025-02-11_11-49-54_0.mcap

@fujitatomoya fujitatomoya added the more-information-needed Further information is required label Feb 11, 2025
@PfeifferMicha
Copy link
Author

You're right, that's a neat solution.

I think rosbag in ROS 1 had the ability to have time-stamp and custom name (unless I'm misremembering), that's why I thought it was missing from the ROS 2 version.

@MichaelOrlov
Copy link
Contributor

MichaelOrlov commented Feb 19, 2025

cc @emersonknapp @Kaju-Bubanja.
From one side, I agree that we already have too many options for the Rosbag2 recorder and player and need to avoid adding more to not overcomplicate them.
However, the proposed workaround with ros2 bag record -a -o mybag_"$(date +"%Y-%m-%d_%H-%M-%S")" is not covering the most wanted use case when we would have multiple bags in the recorded folder due to the bag splits or snapshots and want to have each bag file with its own timestamp.

If considering options on how to implement it, I am more inclined to go with option 1.

  1. Always append the time-stamp when -o is used, unless --no-time-stamp is specified

This way, we can easily backport this feature to Jazzy and Humble, but without --no-time-stamp option.
Other options require adding an extra field to the RecordOptions data structure. That change will be ABI-breaking and is not backportable.

@MichaelOrlov MichaelOrlov reopened this Feb 19, 2025
@Kaju-Bubanja
Copy link
Contributor

Kaju-Bubanja commented Feb 19, 2025

Option 1 and the proposed backports sound like a nice solution

@emersonknapp
Copy link
Collaborator

emersonknapp commented Feb 21, 2025

I think two different features are being conflated in this discussion:

  1. Directory naming
  2. Bagfile naming

The way I'm reading it, it's pretty clear that the original ticket is talking exclusively about case 1.

1. Directory naming with timestamp

@PfeifferMicha wants to have timestamped directory names, while having control over replacing rosbag2_ with customvalue_ in the directory name.

The feature the are requesting looks concretely like this:

$ ros2 bag record -o calibration_data
making directory calibration_data_2025_02_11-09_01_53/
opened file calibration_data_2025_02_11-09_01_53/calibration_data_2025_02_11-09_01_53__0.mcap for writing...
opened file calibration_data_2025_02_11-09_01_53/calibration_data_2025_02_11-09_01_53__1.mcap for writing...
opened file calibration_data_2025_02_11-09_01_53/calibration_data_2025_02_11-09_01_53__2.mcap for writing...
SIGINT
recording done!

$ ros2 bag record -o calibration_data
making directory calibration_data_2025_02_11-09_10_30/
opened file calibration_data_2025_02_11-09_10_30/calibration_data_2025_02_11-09_10_30__0.mcap for writing...
opened file calibration_data_2025_02_11-09_10_30/calibration_data_2025_02_11-09_10_30__1.mcap for writing...
opened file calibration_data_2025_02_11-09_10_30/calibration_data_2025_02_11-09_10_30__2.mcap for writing...
SIGINT
recording done!

Like @fujitatomoya this can be accomplished simply enough with

ros2 bag record -a -o mybag_"$(date +"%Y-%m-%d_%H-%M-%S")"

And this gives the user complete flexibility without requiring any new features on rosbag2 whatsoever. I would consider this a feature rather than a bug and close this issue as resolved, while recommending that we add a note to a "Tips & Tricks" section of our documentation. I've added that in #1916

2. Bagfile naming with timestamp

On the other hand, there is a separate need which is to timestamp each individual file within the recording directory. I believe this is what @MichaelOrlov and @Kaju-Bubanja are discussing.

Here is what that looks like:

$ ros2 bag record -o calibration_data --max-bag-duration 40
making directory calibration_data/
opened file calibration_data/calibration_data_20250211-091010.mcap for writing...
opened file calibration_data/calibration_data_20250211-091050.mcap for writing...
opened file calibration_data/calibration_data_20250211-091130.mcap for writing...
opened file calibration_data/calibration_data_20250211-091220.mcap for writing...
SIGINT
recording done!

This feature is part of the story for #1915

Conclusion

I feel inclined to close this issue as being exclusively case 1 and wontfix because it is achievable by a simple "tip and/or trick", and to open a new issue for case 2.

@emersonknapp
Copy link
Collaborator

Okay yeah for cleanliness of history I'm going to close this in favor of #1917 because I like well-scoped atomic tickets and on-topic discussion 😄

If anybody sees a reason for this ticket to remain open that I'm missing, please feel free to reopen it.

@emersonknapp emersonknapp added wontfix This will not be worked on and removed more-information-needed Further information is required labels Feb 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

5 participants