ros2/rosbag2

Rosbag service to manage rosbag complexity

bernatgaston opened this issue · 5 comments

Description

I think it is interesting to have a service using rosbag so you can basically activate or deactivate the rosbag of certain topics. Hence, if you have for example a robot doing some missions, you can activate the rosbag when you start the mission and stop it at the end. Moreover, it can also be interesting to save a rosbag knowing that the mission was not successful so you can download this rosbag for later analysis.

We have developed a node to implement such functionalities. Basically it has 3 services:

  • Start rosbag: Starts rosbag and logs all the topics indicated in the config file (params.yaml)
  • Stop rosbag: Stops the current rosbag
  • Save rosbag: Saves the given rosbag in another folder compressed using zstd.

You can find it here https://github.com/movvo/rosbag2_service
Currently it only has humble branch, but rolling one may be easy to do.

We are opening this node. We are guessing if it may be of interest for the community to add it to rosbag2 packet.

Related Issues

N/A

Completion Criteria

If interested, we can merge such code into rosbag2

Implementation Notes / Suggestions

https://github.com/movvo/rosbag2_service

Testing Notes / Suggestions

N/A

It seems like this utility node doesn't require any changes to the core - so I'm half inclined to leave it in a separate repository for now. It does look useful, but it doesn't have to live here, it can be independently released and maintained.

Great work @bernatgaston ! Can you explain why this implementation is more usefull than the snapshot mode of rosbag2? I was intending on using that to control logging of robots during missions, as the snapshot mode can be triggered once something interesting happens.

Great work @bernatgaston ! Can you explain why this implementation is more usefull than the snapshot mode of rosbag2? I was intending on using that to control logging of robots during missions, as the snapshot mode can be triggered once something interesting happens.

To be honest, I didn't know this package existed -_- , otherwise I would had probably used it. After reading its contents the only difference that I see is that in rosbag_snapshot, you always record last X seconds (or MB) and then you decide if you want to write them in memory. In our solution, you record from the trigger of the start to the trigger of the stop. My idea here was to have all the missions logged in a folder (which you can empty from time to time in a different process) and then compress to another folder just the ones that you want to last for more days.
TBH most of the use-cases I wanted to target with this solution can be also done with rosbag_snapshot. The only use case that I see when this solution may be better is when you don't know that a certain mission has failed (because you never expected such behavior and hence you don't have it as a trigger). With this solution, your still have the rosbag written in a folder.
Anyway, I am closing this proposal as rosbag_snapshot can probably do the work and it is already maintained and in the packages

I didn't know this package existed

Maybe you're talking about https://github.com/ros/rosbag_snapshot/tree/ros2

the snapshot mode of rosbag2

Is not referring to an external package though, they were talking about the builtin capabilities of the rosbag2 recorder. Unfortunately I am realizing that they are not documented in the README! However, you can see all the services that are provided by default in the source here https://github.com/ros2/rosbag2/blob/rolling/rosbag2_transport/src/rosbag2_transport/recorder.cpp#L243

$ ros2 bag record -a --snapshot-mode
$ ros2 service list -t
... builtin parameter services omitted
/rosbag2_recorder/is_paused [rosbag2_interfaces/srv/IsPaused]
/rosbag2_recorder/pause [rosbag2_interfaces/srv/Pause]
/rosbag2_recorder/resume [rosbag2_interfaces/srv/Resume]
/rosbag2_recorder/snapshot [rosbag2_interfaces/srv/Snapshot]
/rosbag2_recorder/split_bagfile [rosbag2_interfaces/srv/SplitBagfile]

Noting that this is a pretty big oversight, I've created #1411 to document these in the README, and #1412 to track work on improving the documentation in general