Add ULog to ROS2 bag script

[ds196]

For various reasons, it has become convenient for my work to be able to convert ULog files to ROS2 bag files for post-flight analysis. Inspired by the ulog2rosbag script already in pyulog, I have created a similar script that works in ROS2, with a few additional features to make life easier:

• Support for ROS2 distros newer than Humble (still backwards-compatible)
• Warns upon encountering message types in the log file that do not agree with the sourced px4_msgs, then omits them while still successfully writing the rosbag
• No ROS2 installation required to see the help message
• Regex-based message type matching for topics that break the camel-case/snake-case convention
• Verbose flag for viewing debug output
• Default name for output file based on input ULog file name

Here is an example output:

(venv) root@d56300f5c6a7:/pyulog-release# ulog2ros2bag log_122_2026-5-20-10-52-46.ulg 
[INFO] [1780890561.835443660] [rosbag2_storage]: Opened database 'rosbag_log_122_2026-5-20-10-52-46/0_rosbag_log_122_2026-5-20-10-52-46_2026_06_08-03_49_21.db3' for READ_WRITE.
W: Message type for position_setpoint_triplet is composed, skipping.

Wrote rosbag 'rosbag_log_122_2026-5-20-10-52-46' with 90 topics and 337633 messages.
(venv) root@d56300f5c6a7:/pyulog-release# ros2 bag info rosbag_log_122_2026-5-20-10-52-46

Files:             0_rosbag_log_122_2026-5-20-10-52-46_2026_06_08-03_49_21.db3
Bag size:          27.3 MiB
Storage id:        sqlite3
ROS Distro:        lyrical
Duration:          545.688479000s
Start:             Jan  1 1970 00:08:43.593650000 (523.593650000)
End:               Jan  1 1970 00:17:49.282129000 (1069.282129000)
Messages:          337633
Topic information: Topic: /px4/action_request | Type: px4_msgs/msg/ActionRequest | Count: 4 | Serialization Format: cdr
                   ...

I still haven't added support for composed message types, but I have successfully tested the script on various ULog files recorded in-house aswell as a SITL log file from online and with ROS2 distros Humble, Jazzy, and Lyrical, and all other topics seem to work. Please let me know what changes you would like to see and if this would be a good candidate for merging.

[bkueng]

Looks good. I'm a bit surprised that this does not use mcap.
For mcap I saw there was a conversion script added here: foxglove/mcap#1531.

Can you also check the linting failures?

[bkueng]

Not mcap?

[ds196]

Thank you for the quick feedback. I almost exclusively use ROS2 Humble, but have noticed that ROS2 Jazzy changes the default for rosbag2 from sqlite3 to mcap. Would you like the script to reflect this change? As for the pylint warnings, I believe I have resolved all of them except for 'unnecessary-lambda-assignment' and 'too-many-branches'. How would you like me to go about resolving these?

[bkueng]

I almost exclusively use ROS2 Humble, but have noticed that ROS2 Jazzy changes the default for rosbag2 from sqlite3 to mcap. Would you like the script to reflect this change?

If you actually use it it's perfectly fine to keep sqlite3. Based on what I've seen ROS2 is generally moving over to mcap entirely, that's why I asked.
We could add both as options and make mcap the default, if that is easy to do?

As for the pylint warnings, I believe I have resolved all of them except for 'unnecessary-lambda-assignment' and 'too-many-branches'. How would you like me to go about resolving these?

For the lambda, you should be able to follow the hint and directly use def rosbag_write( topic, msg, timestamp): inside the condition.
For the other one it's fine if you add an ignore.

[ds196]

It looks like there is no clean way to check for the availability of a rosbag2 storage plugin from rosbag2_py in Humble, so I left sqlite3 as the default and added a parameter for mcap. If the user specifies mcap and they don't have it installed, it will error and the user can re-run the command without the parameter or install the storage plugin.

I resolved the other pylint warnings, it looks like there is one last warning from pytest in 3.14 coming from pyulog internally.

[bkueng]

Let's get this in then. I'll look into the unrelated CI failure