Skip to content

fix: ROSBag detects the ROS release by default (release="auto") - #164

Merged
petercorke merged 1 commit into
mainfrom
fix/rosbag-default-release-auto
Oct 22, 2026
Merged

petercorke merged 1 commit into
mainfrom
fix/rosbag-default-release-auto

Conversation

@petercorke

Copy link
Copy Markdown
Owner

Summary

ROSBag defaulted to release="ROS1_NOETIC", while bagtool --release already defaulted to "auto". The Noetic default cannot read ROS 2 (CDR) messages, so a ROS 2 bag read with the default arguments failed. "auto" tries the known releases on the first message and keeps the first that decodes it, for ROS 1 and for CDR messages.

  • The default is now release="auto". Naming a release still works and skips detection.
  • The auto-detect: ... line printed on success is now shown only with verbose=True, since a default that guesses would otherwise print it for every bag. The "FAILED ... no matching typestore found" message is still always printed.
  • The docstring now explains what release selects (the ROS distribution whose message definitions are used) and how "auto" works.

Evidence

On a real ROS 2 recording (rosbag2 directory, MCAP storage, CDR; the example attached to lucasw/ros_one2z#6), ROSBag(path):

result
main, default ROS1_NOETIC SerdeError: Invalid string length 7364973
this branch, default auto reads the images

On every other bag tested (the committed ROS 1 and ROS 2 fixtures, and 13 real bags) the default and an explicit release give identical pixels.

Tests

New tests/test_ros_release_auto.py (9 tests; 6 of the 8 portable ones fail on main): the default, the same images as the right explicit release for the ROS 1 bag and the ROS 2 bag directory, the detected release being reported, quiet unless verbose, and a real ROS 2 MCAP bag when it is available locally (skipped otherwise). pytest tests: 1048 passed, 44 skipped.

Related

This touches lines in Sources.py that #163 also edits (the auto-detect print statements), so whichever merges second needs a small rebase.

Checklist

  • PR title follows Conventional Commits
  • Tests pass locally (pytest)
  • Added tests for this change
  • Docstrings updated

🤖 Generated with Claude Code

@codacy-production

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 11 complexity · 0 duplication

Metric Results
Complexity 11
Duplication 0

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

ROSBag defaulted to release="ROS1_NOETIC", while bagtool's --release already
defaulted to "auto". The Noetic default could not read ROS 2 (CDR) messages: on
a rosbag2 directory ROSBag(path) raised a SerdeError, and a bag whose messages
the Noetic definitions do not match read nothing. "auto" tries the known
releases on the first message and keeps the first that decodes it, for ROS 1 and
for CDR messages; the choice is then available as the `release` attribute.

- The default is "auto". Naming a release still works and skips detection.
- The "auto-detect: ..." line it printed when it succeeded is now shown only
  with verbose=True, since it would otherwise be printed for every bag. The
  "FAILED ... no matching typestore found" message is still always printed.
- The docstring now explains what `release` selects and how "auto" works.

Adds tests/test_ros_release_auto.py (8 tests, 6 fail on the old default): the
default, the same images as the right explicit release for the ROS 1 bag and the
ROS 2 bag directory, the detected release being reported, and quiet unless
verbose.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
@petercorke
petercorke force-pushed the fix/rosbag-default-release-auto branch from a8bd0db to bcd5a30 Compare October 22, 2026 02:36
@petercorke
petercorke merged commit 60ef838 into main Oct 22, 2026
39 checks passed
@petercorke
petercorke deleted the fix/rosbag-default-release-auto branch October 22, 2026 05:13
@github-actions github-actions Bot mentioned this pull request Oct 22, 2026
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.

1 participant