Use .idl files with rosidl_gen

[carlossvg]

Hi all, I would like to formulate a request required by Apex.AI regarding rosidl_gen.

At Apex.ai we work directly using .idl files instead of ROS IDL (.msg, .srv, .action). As far as I know, this is not currently supported in rclnodejs. We would like to request to extend or refactor rosidl_gen to support .idl files.

Also, I would be interested to know how difficult is to implement such a feature and if there is any know workaround we can use in the meanwhile.

For completeness, we had a similar issue with ros1_bridge and this was resolved with the following MR https://github.com/ros2/ros1_bridge/pull/296/files.

[minggangw]

Hi @carlossvg thanks for submitting this issue.

Because rclnodejs uses dot, which is Node.js template tool, to generate the JavaScript message files instead of empy, we have to leverage JSON string to pass the spec objects of message/service/action across the boundary of Python to JavaScript and parser in rclnodejs is such a thin wrapper to do that.

The output of rosidl_adapter tends to be easy to achieve the target above. By looking throught the rosidl_parser, I think if we want to switch to rosidl_parser, the easiest way is get the JSON string from the output of the functions, e.g. parse_idl_file and we have to ensure that the JSON has the same format with what we get from the current implementation, thus, we are not necessary to refactor the rosidl_gen. (because we have isolated the changes by the JSON strings).

Now: rosidl_adapter.parse_message_string() ---> JSON object ---> rosidl_gen (rclnodjs)  
                                                      |
                                Python                |        JavaScript
                                                      |
After: rosidl_parser.parse_idl_file() ---> JSON object  (same format with above)---> rosidl_gen (rclnodjs)

This solution need kind of adaptor to get the key-value and convert to the right format.

The bigger picture I could think is that we could use empy directly to drop the usage of JSON string, which means we have to re-write a template file for it.

In conclusion, I think the first method seems more feasible to achieve in a short term. Because our resource is limited, your PR is welcome :)

[minggangw]

The JSON string of the spec is written to each of the generated JavaScript messages at the end of the file under generated/

[carlossvg]

Thanks, @minggangw for your detailed reply.

I agree with your comments, your first proposal shouldn't take too much time to implement. The second proposal would be ideal but using empy is kind of painful sometimes so it would take more time than the first option.

Since we are time-constrained we are going to use another approach to work around this issue. This will be required in the mid/long term so we will come back to this feature request in the future.

Thank you again for your support.

[minggangw]

Good to know 😄