-
Notifications
You must be signed in to change notification settings - Fork 63
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
Error generating ROS2 idl messages [10690] #52
Comments
Greetings, For that particular error: Those IDL files have no include guards. If you've got those files from installed ROS2 packages (i.e. from '/opt/ros/foxy/share/...'), next to those IDLs should be a directory 'dds_connext'. When you compare for instance the IDL files for turtlesim's rotate absolute action, you'll see that only the DDS-specific variant actually defines the topic types you see on the wire - the other one does not. The latter fact caused me to notice the error in my initial interpretation of what's what. Regards |
Hello everybody,
The strange thing is, after changing the variable name from polygon to polygon_ in the IDL file, fast-dds-gen generates the code without any problems. So it looks like the variable name is colliding with type name but the same does not happen to header. Maybe because header type belongs to another namespace. |
What I said before, i.e. use the file ".../geometry_msgs/msg/dds_connext/PolygonStamped_.idl" instead to generate code from. The contents of those idl-files match the fully qualified type names ROS2 announces on the dds layer. The struct in the file you're using as input does not. I don't recall everything, but there are also technical problems with the ROS2-provided non-"dds_connext" idl-files. At least that there are no header guards, though that problem kicks in only with a subset of topic types. |
Standard idl files in ROS2 are perfectly valid. Include guards are not needed (at least it is the case with the fast-dds-gen version I'm using). Besides, PointCloud2.idl (not from dds_connext subfolder) generated by fast-dds-gen (with -typeros2 flag) generates fine and is fully compatible with ROS2. Anyway, out of curiosity I've tried to generate with the idl files from the dds_connext subfolder. Still having the same error.
|
I looked at my modifications of Fast-DDS-Gen, but don't see anything that might relate here. But I noticed, in a script I call fastddsgen with flag -cs. IIRC, it's case insensitive by default. Maybe that's causing your troubles. Though you said, it wouldn't complain in case of "header". |
Interesting, I would have expected it to do case sensitive by default. Thanks for pointing out. I've found an additional yet similar issue while generating Odometry.idl. It occurs regardless of the -cs flag.
in this case, renaming the typename from double__36 to doubl__36 was necessary to make code generation continue. It seems string comparison was done regardless of the string length. |
I know it's getting old, but that message type doesn't employ typedefs in its dds_connext variant. |
As much as I'd love to, I won't be able to find the time to debug the tool itself. By mentioning strange behaviour I've encountered, I'm simply hoping to help the person who can fix the bug as well as others who are encountering similar issues while generating code from ROS2 idls. |
It's odd, MicroXRCEDDSGen does not have this issue in the generation I wrote for Ardupilot: However, I am facing it with |
Here is a minimum reproducible example using the vulcanexus humble image. docker run -it eprosima/vulcanexus:humble-tools bash
apt update && apt -y install ros-humble-vision-msgs
mkdir -p vision_msgs/msg
# Generate all
fastddsgen -cs -replace -typeros2 -d vision_msgs/msg -I /opt/ros/humble/share /opt/ros/humble/share/vision_msgs/msg/*.idl You can even just try generating one message that fails
Output:
Theory: The failing message has two header fields:
|
Hi @JLBuenoLopez-eProsima , I tried installing the FastDDSGen release 3 candidate, but couldn't compile it. Would you be able to test the steps above against the new version to see if this is present? |
Hi @Ryanf55 I am afraid that Fast DDS-Gen and Micro XRCE DDS-Gen are two different and independent products. I understand your frustration when something works in one but not in the other. Currently, Fast DDS-Gen requires that each IDL file (and its dependencies) define the types once and only once. For example, having two IDL files, one including the other and calling Fast DDS-Gen for both of them, it is fine, as each IDL file its passed to Fast DDS-Gen independently. The code will be regenerated the second time depending on the What it is not allowed is if you have three IDL files, the first one including the other two, and the second one including the third one. In that case, the third IDL file is included twice in the same generation unit and the redefined variable error is going to be thrown. Regrettably this issue is not fixed in Fast DDS-Gen nor it is going to be fixed in the next release (Fast DDS-Gen v3.0.0). The release candidate you mention it is not yet ready and as it is a mayor version, it would require to upgrade other dependencies in order to work properly (surely the cause of your issues installing the release candidate). |
Many thanks for the response! Are there any known workarounds other than changing our message definitions when using FastDDS to not use any messages that use the same type twice through includes? According to the RTI forums for a user facing the same problem in their software, you can modify the IDL's to add a Changing the message definitions and code implementation to not have these kinds of includes would be significant work. Any alternatives are much appreciated! |
I added |
I have issued a PR to Fast DDS documentation concerning this issue: As a C/C++ preprocessor is run by default, any preprocessor directive is applied. For instance, using compilation guards or the |
Hello everybody,
I am trying to generate structures to communicate using ros2 idl messages.
I'm able to run fastddgen for all packages except for ros2 navigation ones
The error that appears for the nav_msgs / msg / OccupancyGrid.idl message is
I enclose the structure here
You can also tell me why, for some messages are only generated the structure
Generating Type definition files ...
Generating TypeObject files ...
And not even pubsub files?
Thanks in advance
The text was updated successfully, but these errors were encountered: