Support DDS XTypes creation

[Splinter1984]

Description:

This changes allow us to register ros_types as DDSXtypes.
In example this allow to use cyclonedds cli tool to access to middleware of ros2.

Example (subscribe to ros2 topic):

~$ cyclonedds subscribe rt/chatter
   0:00:01 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Entities discovered: 1

 Subscribing, CTRL-C to quit
String_(data='Hello World: 1')
String_(data='Hello World: 2')
String_(data='Hello World: 3')

Example (display type information):

~$ cyclonedds typeof rt/chatter
   0:00:01 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Entities discovered: 1

As defined in participant(s) 0110283f-9e45-f5f7-b391-ffe7000001c1
module std_msgs {                                                                                                                                         
    module msg {                                                                                                                                          
        module dds_ {                                                                                                                                     
            @final                                                                                                                                        
            struct String_ {                                                                                                                              
                string data;                                                                                                                              
            };                                                                                                                                            
        };                                                                                                                                                
    };                                                                                                                                                    
};

Depends on:

• eclipse-cyclonedds/cyclonedds#1694

[eboasson]

Thank you so much for this @Splinter1984! It took forever for me to sit down and give it a proper review, but now I have. This is a lovely addition to the RMW layer and while I do have some comments, they really are about small things. I do admit that I haven't spend enough attention on all the error paths yet. Perhaps you can have a look at the comments and then we can include that aspect in a second round?

I am also quite sure that the code layout check will fail. Almost every PR seems to end up with a final round through uncrustify to meet the code formatting rules anway, so that's really not something to worry about. 🙂

@ivanpauno if you think I am wrong in assuming that doing a release for Cyclone and updating rolling to that new release would be something that the ROS 2 community would appreciate, then please do say so!

[eboasson]

I think if we do a new release of Cyclone (which is very much overdue anyway), then we could make these changes at the same time as switching ROS 2 rolling over to that new Cyclone version. That way we don't have to work on making the RMW build with 0.10.x.

Alternatively we could make sure dds/dds.h is included first, then look at whether (for example) DDS_DYNAMIC_TYPE_SPEC is defined, and if is not:

• use the old include files
• do #define ddsi_rdataa nn_rdata, &c.
• stub out all the dynamic type

That way we'll have a single RMW layer that will work with all versions. I don't think it brings much benefit beyond decoupling merging this PR and the Cyclone release + changing ROS 2 rolling over to that new release. But simplifying those processes is definitely worth considering.

[Splinter1984]

Yes, it would be great to leave compatibility with older versions.

[eboasson]

I don't quite see why this needs to be extern "C"

[Splinter1984]

I agree. extern "C" useless here.

[eboasson]

I wonder if there is no better way to do this. The C example/test code uses designated initializers to set the fields that are required (and have the rest auto-initialized to 0), if that's still not supported in C++ perhaps doing:

dds_dynamic_type_descriptor t desc{};
desc.kind = kind;
...

works out better. I'm not quite sure, but writing it out as a struct initializer like this looks fragile.

[Splinter1984]

Accepted your suggestions.

[eboasson]

I believe the actual type of array_size_ is size_t, so casting it to a pointer to uint32_t will break things quite badly on big-endian 64-bit machines.

I've checked and dds_dynamic_type_create in turn calls ddsi_dynamic_type_create_array, which copies the data. Given that it is a single-element array, changing it to:

uint32_t array_size = static_cast<uint32_t>(member->array_size_);
ddt = dds_dynamic_type_create(dds_ppant, 
        get_dynamic_type_descriptor_prim(DDS_DYNAMIC_ARRAY, member->name_, 1, &array_size_, type));

should solve that.

[Splinter1984]

Apply your suggestions.

[eboasson]

I must be overlooking something obvious, because it looks like this is so close to the function above that it might as well not exist!

(But then surely the compiler would reject it. So I must be the one who is wrong here.)

[Splinter1984]

We still need two instances of the function. one for adding primitive types, one for more complex types.

[eboasson]

It would be better to propagate the error out here, I think. I suspect continuing after an error will crash ... (This applies in a few more places.)

[Splinter1984]

I agree and change all the same moments to assert.

[eboasson]

Do we ever get here when st == nullptr? It seems to me there is not much reason to.

[Splinter1984]

Yes you are right this step is not needed here.

[eboasson]

These are allocated by ddsrt_memdup, right? Then they should be freed with ddsrt_free instead of free. (It won't matter on Linux, but on Windows it gets tricky with how they deal with DLLs.)

[Splinter1984]

My mistake. Change to ddsrt_free.

[eboasson]

Here the same thing I mentioned above about size_t vs uint32_t applies as well.

[eboasson]

I'm surprised it checks for is_array_ but apparently doesn't need to deal with is_upper_bound_ or array_size_. Is that really true?

The ROS_TYPE_STRING case is again subtly different in this regard ...

I should check the rosidl definitions, I know, but for now, perhaps you can just double-check? ☺️

[Splinter1984]

This is where I made a big mistake. I didn't check string_upper_bound.

[clalancette]

@ivanpauno if you think I am wrong in assuming that doing a release for Cyclone and updating rolling to that new release would be something that the ROS 2 community would appreciate, then please do say so!

@eboasson I think a CycloneDDS update would be great. I'd say go ahead and make the CycloneDDS releases. Once that is done, we can do a PR to https://github.com/ros2/ros2 (like we did in ros2/ros2#1402) to update ROS 2, and run CI on it.