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

Plan to port bag migration from ROS 1 #561

Closed
weihunko opened this issue Nov 13, 2020 · 9 comments
Closed

Plan to port bag migration from ROS 1 #561

weihunko opened this issue Nov 13, 2020 · 9 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@weihunko
Copy link

weihunko commented Nov 13, 2020

Description

In rosbag, there is a functionality called rosbag/migration, which helps reusing the old bag files when the message definitions have changed.

Related Issues

Completion Criteria

  • Port rosbag/migration or have a similar functionality in ROS 2

Implementation Notes / Suggestions

Testing Notes / Suggestions

  • None
@weihunko weihunko added the enhancement New feature or request label Nov 13, 2020
@emersonknapp emersonknapp added the help wanted Extra attention is needed label Nov 20, 2020
@emersonknapp
Copy link
Collaborator

Is the desired feature to migrate a ROS 1 bag to ROS 2, or to migrate a bag from an older ROS 2 distribution to newer message definitions?

@Carlos-Loera
Copy link

@emersonknapp I can weigh in here. The latter; the ability to migrate and use an older bagfile's data from ROS 2 distribution to a new message definition.

@emersonknapp
Copy link
Collaborator

Thanks for clarifying. Yes, I can see that this is a valuable use case to use your old data on a new release.

I don't have a great sense now for what it would take to implement this, but I assume it requires having both distros installed and available. Given how different typesupport is in ros2 vs ros1, a direct port probably is not possible, it may require a lot of new code.

@Carlos-Loera
Copy link

Carlos-Loera commented Jan 20, 2021

Thanks for clarifying. Yes, I can see that this is a valuable use case to use your old data on a new release.

I don't have a great sense now for what it would take to implement this, but I assume it requires having both distros installed and available. Given how different typesupport is in ros2 vs ros1, a direct port probably is not possible, it may require a lot of new code.

Are you able to provide me with your general sense on the expected timeline for such a tool to be implemented in ROS 2?

@emersonknapp
Copy link
Collaborator

Are you able to provide me with your general scene on the expected timeline for such a tool to be implemented in ROS 2?

There aren't any resources allocated for this currently. If you have an interest in working on it, I would be happy to help evaluate designs and code!

@mschuckmann
Copy link

So if there is no ROS2 bag migration support does that mean that there is no way to use old bag files after a .msg file has been changed (e.g. it's package name changed or fields added or removed)?

@emersonknapp
Copy link
Collaborator

It seems to be that is what it means, yes. There are probably some edge cases depending how CDR parsing is done by the DDS implementation, it might be able to parse messages even if there are new fields, but not entirely sure how this plays out in practice.

@ozzdemir
Copy link

It seems to be that is what it means, yes. There are probably some edge cases depending how CDR parsing is done by the DDS implementation, it might be able to parse messages even if there are new fields, but not entirely sure how this plays out in practice.

I've tried this case recently, when I try to echo, no message is received (With no warning etc, which surprised me); but when --raw flag is given to echo, I could observe the incoming bytes.

 ros2 topic echo /topic_msg_updated # Nothing is received, and no warning message is printed both in the bag play terminal and topic echo terminal
 ros2 topic echo /topic_msg_updated --raw # Could observe the incoming bytes.

@MichaelOrlov
Copy link
Contributor

  • Closing this task since requested functionality will be implemented as part of the bigger feature implementation in core of the ROS 2 described in the REP-2011 and REP-2016 implementation.

BTW. We already have functionality for storing message definitions inside recorded bag files, however, don't have the ability yet to dynamically reconstruct type support and publisher from those stored message definitions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

6 participants