-
Notifications
You must be signed in to change notification settings - Fork 240
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
Implement converter plugin for CDR format and add converter plugins package #48
Conversation
…d link against rmw_fastrtps_cpp
7d1c2b8
to
20a3a7d
Compare
@Karsten1987, we don't really understand why all the CI jobs failed. It seems that the problem is not related with our code, though. |
Based on the job parameters and error message are you maybe trying to run tests for a package which hasn't been built? |
@dirk-thomas, thank you very much. You're right, the parameters we gave are, for this branch, wrong. We didn't think about that. |
> | ||
<description>This is a converter plugin for cdr format.</description> | ||
</class> | ||
</library> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
</library> | |
</library> | |
Not sure if this helps, but github complains that there is no new line for this file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it makes sense to fix that - I expect the xml linter to find this problem later on once it'll be enabled.
#include <string> | ||
|
||
#include "rcutils/strdup.h" | ||
#include "rmw/rmw.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this including "rmw/rmw.h"? In case of a different middleware, this is there is no CDR support available?
Shouldn't this directly link against fastcdr
or similar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment below.
namespace rosbag2_converter_default_plugins | ||
{ | ||
|
||
void CdrConverter::deserialize( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer a similar argument order than in the rmw_deserialize
function:
https://github.com/ros2/rmw/blob/master/rmw/include/rmw/rmw.h#L247-L253
the ros_message
is the last argument, so being consistent with the place of the input/output arguments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes perfect sense, will do.
Just in case I missed something here. But this PR should convert ROS 2 messages to CDR and CDR messages to ROS 2 messages, right? |
My understanding is that it will work - but since there is no other rmw with a serialization format, yet, it's hard to verify (I don't like to implement a But I agree that one has to be careful. That's why we suggested using Poco to grab the real The third way would be to reimplement |
@Martin-Idel-SI That is not true. There are a couple of non-DDS RMW implementations using different serialization protocols: see https://discourse.ros.org/t/non-dds-based-rmw-implementation/5890
The problem is that you can't rely on FastRTPS even being present. It is absolutely viable to build ROS 2 without FastRTPS - either only with Connext or OpenSplice - or only with OPC UA or DPS. |
@dirk-thomas Thank you for the link to the other rmw implementation - that means we can at least to some manual testing 👍 Regarding the other point, would that mean that we'd have to reimplement our own serialization routines or is there some part that would be okay to link against (statically if we must)? |
I am not sure how you map between rmw implementations and serialization formats. My point was aiming to clarify that you can't rely on a specific rmw impl. to always be present. It is possible build ROS 2 with a single rmw impl. and it should then be possible to record and playback without requiring any extra dependencies. That is probably already the case? I was just wondering about it when you mentioned to always link against FastRTPS. |
Yes, currently With the changes introduced by PRs #56 and #57, it will be possible to specify the format to save the messages in, and to play back bags whose messages are in a different |
…t_plugins/cdr/cdr_converter.cpp Co-Authored-By: Karsten1987 <karsten@osrfoundation.org>
Load fastrtps dynamically
* Deserialize McapWriterOptions from storage_config_uri YAML file Signed-off-by: Emerson Knapp <emerson.b.knapp@gmail.com>
* Deserialize McapWriterOptions from storage_config_uri YAML file Signed-off-by: Emerson Knapp <emerson.b.knapp@gmail.com> Signed-off-by: James Smith <james@foxglove.dev>
This PR is based on #47.
This PR implements a converter plugin to convert ROS 2 messages to
CDR
format and back, usingfastrtps
asrmw
implementation.The plugin is contained in the new package
rosbag2_converter_default_plugins
.This new package also contains helper methods to extract
rmw
functions needed by the converters. It might be a good idea to expose these helpers, to benefit plugins developers. In order to do that, though, we need visibility control to be added to the package.