Add ROS2 support

[Georacer]

Hello everyone!

I might be mistaken, but ROS2 bag files have a different format than ROS1.

Does bag-database support ROS2 bag files?

Thank you!

[pjreed]

You are correct, ROS2 bag files have a different format; in fact, rosbag2 is designed to have a plugin-based storage backend, so it is not technically tied to any specific format at all, although the default implementation stores data as SQLite databases.

The Bag Database doesn't currently support ROS2 bags, although I'd like to add support for them in the future.

In order support ROS2 bags, it would need a Java library that is capable of reading them; just reading SQLite databases is easy, but things get a little bit more complicated because the default rosbag2 implementation serializes messages using the DDS cdr format, so extracting useful information from the messages would also require being able to deserialize that.

[Georacer]

I see... thank you for your answer! Cheers!

[Timple]

Not sure if it helps, but there is already some ROS2 - java combining going on: https://github.com/ros2-java/ros2_java

[danthony06]

There's been some movement on making ros2 bags fully self describing, which would help out this issue quite a bit. See the discussion on this issue: https://github.com/ros2/rosbag2/issues/782

[pjreed]

Oh that'd be nice. I was just looking into this again the other day, actually...

Basically, there are two problems right now standing in the way of this:

1. ROS2 bags don't contain their message definitions (unlike ROS1 bags). This means it's impossible to parse messages in bag files without having the messages pre-defined somewhere else, like a ROS installation, and parsing custom message types that are unknown to the bag database is impossible. Hopefully the linked issue will result in a solution for that. In the meantime, if we want to be able to ingest ROS2 bags, we may have to just accept only being able to parse a subset of known message types.
2. The message data inserted into the standard SQL format is, as mentioned previously, in DDS CDR format and needs to be deserialized in order to get anything useful out of it. I had briefly hoped that maybe this was identical to CORBA CDR format and tried using JacORB (a pure-Java CORBA implementation) to parse it, but had a bunch of problems. It's probably possible to write our own parser, but it'd be a pain.

It might be possible to incorporate ros2-java into it in order to use Fast DDS to deserialize messages... while it'd be nice to have a pure Java implementation that doesn't rely on having a whole ROS stack included in the image to function, it's probably worth investigating to get a feel for how difficult that would be to use vs. writing our own CDR deserializer.

[danthony06]

I haven't looked into the Java CDR decoding, but it would really be nice to not have a dependency on actual ROS. We could hard code a few definitions for GPS and image messages that we really care about for some of the core functionality, and then wait for the bag format to get updated, but I'm not holding my breath on that.

[danthony06]

@pjreed what if as part of the Docker image building process, we cloned the standard ROS message definitions, and optionally user defined repos, built the message definitions/CDR representations, and then found a Java library for deserializing CDR formatted messages? We could then use the message definitions we built in the first stage and for deserializing information in the database. That way, we wouldn't have a runtime dependency on ROS but could still get some level of introspection.

[pjreed]

That's a possibility, but finding a Java library that can deserialize CDR data is the hard part; I've spent a while looking around and haven't found anything. I've seen a few DDS implementations that advertise Java support, but all of them are just JNI wrappers around C/C++ libraries, and the ones that look decent are not open source. So far I haven't found any standalone CDR libaries.

[danthony06]

I assume you're talking about something like OpenDDS? https://github.com/objectcomputing/OpenDDS

[pjreed]

Yep. I have specifically had enough experiences with ACE/TAO in the past that I'm shy about touching anything that uses it. I do see that they provide a pre-built Docker image, so maybe it would be possible to do something like make our own image based on that which can take in message definitions, serialized data, and output it in some other format we can easily interpret... but that might be just as much work as making our own CDR parser.

[pjreed]

Just thought I'd point out that, while it's not useful for ingesting things on the backend, here's a Typescript-based CDR implementation and ROS2 message deserializer: https://github.com/foxglove/cdr https://github.com/foxglove/rosmsg2-serialization

Might be useful as a reference for writing our own.

[danthony06]

I'm hoping with some of the conversations that have occurred in the Tooling WG that this might be resolved in the near future. I'll push on it again in the next WG meeting, and see if we can get more traction.

On Tue, Aug 24, 2021 at 4:48 PM P. J. Reed @.***> wrote:

Just thought I'd point out that, while it's not useful for ingesting things on the backend, here's a Typescript-based CDR implementation and ROS2 message deserializer: https://github.com/foxglove/cdr https://github.com/foxglove/rosmsg2-serialization

Might be useful as a reference for writing our own.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/swri-robotics/bag-database/issues/129#issuecomment-904999289, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBZWHFRDVPD2KYT2MURLRTT6QHRZANCNFSM4TT6PE5Q .

[danthony06]

It sounds like the H-release of ROS2 will have the ability to store message definitions in the bag file, which should make it more feasible to implement ROS 2 support.

[gjaeger1]

Hi all,

I'm currently working on a project that sets out to acquire large datasets (3D LiDAR, camera data, GNSS, etc.) of outdoor environments. We would like to use bag-database for that, but are using ROS2. Are there any news on whether/when bag-database will be able to handle ROS2 bags as well?

From the looks of it, this project could be very helpful in maintaining a consistent overview on our ros bags and their data!

[danthony06]

@gjaeger1 It might be worth revisiting this. ROS2 bag support still will be tricky. Support for storing message definitions in an MCAP file, not a bag file, was recently added: https://github.com/ros2/rosbag2/issues/782. Unfortunately, embedding those message definitions in an MCAP file still requires having those message definitions available on the system doing the recording. So unlike ROS1, you can't attach a computer with a minimal ROS installation to your robot and have it read the message definitions off the wire for storage in a ROS bag.

That being said, adding support for MCAP at this point seems reasonable. There's a bunch of different languages supported for it (https://github.com/foxglove/mcap), so we may be able to just pull off of their native interface to add it to the bag database.

[smash0190]

Just wanted to see if there are any new developments with regards to mcap support?

[danthony06]

It looks like we'll have to write our own MCAP decoder or wrap one of the existing implementations. Let me look at this a little bit over the weekend, because I was thinking about it today.

On Thu, May 2, 2024, 10:03 PM Sebastian Scherer @.***> wrote:

Just wanted to see if there are any new developments with regards to mcap support?

— Reply to this email directly, view it on GitHub https://github.com/swri-robotics/bag-database/issues/129#issuecomment-2092049430, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBZWHGEAZMK6ZSNODJDDNTZAL473AVCNFSM4TT6PE52U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBZGIYDIOJUGMYA . You are receiving this because you commented.Message ID: @.***>

[smash0190]

Did you get a chance to look?

[space192]

any updates on the support of mcap ?

[shrijitsingh99]

This is something I am interested in too, an potentially can contribute some cycles to help get up and running. If you have some idea of what would be a good path forward, I can start looking into it