.NET Core for ROS2 about design

[samiamlabs]

Hi,
I implemented a ROS2 dotnet wrapper for Crystal Clemmys based on a combination of the versions by @esteve and @firesurfer. My use case is mainly the Unity game engine for simulation, visualisation and VR/AR demos.
(https://github.com/DynoRobotics/unity_ros2)

Have only tested it on Linux/Mono so far. I used DllLoadUtils.cs from ros2_common for all the linking so it should be relatively easy to get it working on Windows/UWP as well.

It is pretty minimal so far, but there is some new stuff as well:

• Generation of nested types and arrays (not arrays of nested types or static arrays yet)
• Unit tests (https://github.com/DynoRobotics/rclcs/tree/master/src/dotnet/Test)
• Can be built using colcon

It would be nice if the NUnit tests could be run with the colcon test comand for CI but not sure how much work that would be to set up.

I started working on a fork of your rclcs repo @firesurfer, but I don't think there is any code left from the original repo at this point. Do you plan on updating it for crystal yourself?
(https://github.com/DynoRobotics/rclcs)

[wjwwood]

Thanks for the input, that's definitely something we'd like to see supported. I think it would be appropriate to have a first class dotnet based API that wraps our C API. One issue is that our team at OSRF, and to some extent the ROS community at large, have a lot less experience with dotnet. External contributions and efforts would certainly be welcome.

However, I don't think it replaces our need for a deterministic and embeddable version. For this we'll continue to use C/C++, as I believe that dotnet is still garbage collected and uses a JIT compiler. I know it's probably possible to accomplish some of these goals by doing things like disabling the JIT (or hotspot JIT) and the GC for real-time applications, but I think most of our community would be more comfortable with C/C++ for real-time and embedded applications. So as a replacement for what we're working on now, I don't think it's a good fit, but as I said before I think it's a really good idea to have good dotnet bindings. It does, after all, support two of the most popular programming languages in the world in C# and VB.net.

To that end, if you see us doing anything that blocks a path to dotnet bindings, or have questions about what would be required to create them, please let us know.

Thanks!

[esteve]

@jacquelinekay I don't shy away from a challenge, you've assigned this to me, so the only thing I can say is:

[esteve]

@omidkrad thanks for the suggestion! I can't seem to find what the API for extending C and C++ libraries to support C# looks like, do you have any pointers or documentation? Thanks!

We have added bindings for Python in our latest alpha: https://github.com/ros2/rclpy I have also worked on adding support for Java, and ported ROS2 to Android: https://github.com/esteve/ros2_java so hopefully adding support for the CLR would be similar.

[esteve]

I think I figured out a way to do it with:

• P/Invoke for calling the underlying rcl API (like in https://github.com/esteve/ros2_java/blob/master/rcljava/src/main/java/io/ebinoma/rcljava/Publisher.java#L19)
  https://msdn.microsoft.com/en-us/library/aa719104%28v=vs.71%29.aspx
• And how to call managed code from unmanaged libraries (like in https://github.com/esteve/ros2_java/blob/master/rosidl_generator_java/resource/msg_support.entry_point.cpp.template#L51)
  https://support.microsoft.com/en-us/kb/828736

[omidkrad]

Hi @esteve, see here: Native interoperability

[esteve]

@omidkrad thanks!

[gbiggs]

A .NET library for ROS would be great. Windows/.NET are popular in Japan, so this would capture a fairly good chunk of potential users. @omidkrad It sounds like you have much experience with .NET. Are you able to contribute to implementing bindings?

[omidkrad]

@gbiggs .NET Core is not Windows specific, but like regular .NET Framework gets good support on Visual Studio. I'll try to contribute when I'm more familiar about ROS2 and if my time allows.

[omidkrad]

I just saw this .NET bindings for ROS2 repository by @esteve. This is an excellent start!
https://github.com/esteve/ros2_dotnet

[BrannonKing]

I've written a number of C#-on-C wrappers (like this one: https://github.com/BrannonKing/NLoptNet). Feel free to ask me questions. Here are a few thoughts on this to address concerns listed above:

1. Definitely wrap C, not C++. You want to use DllImport with the attributed parameters; those attributes, especially the [out] ones are critical.
2. For messages (both their definition and serialization) you will need to generate the C# code using the IDL compiler from the various middleware providers. Don't try to use C or C++ message libraries in C#.
3. In C#, structs are stack-only (aka, not affected by the garbage collector), copy-by-value objects. As long as you are using small messages, this is a good option to avoid GC saturation.
4. The garbage collector in C# has been well-optimized over the years, especially in "server" mode. It prefers to run collections for suspended threads instead of active threads. Hence, as long as your threads all suspend themselves regularly (aka, sleep), it's highly unlikely that you will get any threads blocked for garbage collection.
5. The JIT works by compiling methods the first time they are called. After all methods are hit, JIT is out of the picture. However, it can be avoided altogether by precompilation. Just run crossgen on your application before deploying it.

[dirk-thomas]

2. For messages (both their definition and serialization) you will need to generate the C# code using the IDL compiler from the various middleware providers. Don't try to use C or C++ message libraries in C#.

This is not entirely correct. The user land code must not use the implementation specific generated code. Instead it uses the ROS specific (rmw implementation agnostic) data structures which need to be generated for C#. Every rmw implementation then converts them into their own data structures (often generated from the .idl files) or uses introspection to handle custom types at runtime.

[firesurfer]

Hi,
I found this issue by taking a look at the call for contributions for the ROS2 Core.
For people interested in contributing to a dotnet wrapper for ROS2 might take a look at my rclcs (https://github.com/firesurfer/rclcs). It is currently build against the normal .net framework (4.5). But I don't use any classes as far as I know that aren't available in the donet core framework. Building against dotnet core might be as easy as setting it as target in the msbuild files.

Unfortunatly I wasn't able to keep track with the changes of the rcl api which is the reason why the rclcs currently doesn't work. Nevertheless someone interested in contributing might find it useful as a starting point. Also feel free to ask for more information on the wrapper.

[firesurfer]

@samiamlabs Probably not going to do anything about it. Writing a wrapper takes a fair amount of time I don't have at the moment. Let me know if your code runs on windows ;)

[esteve]

@samiamlabs so good to see more people interested in .Net and ROS2. Just a few things:

• ros2-dotnet can be built with colcon, except for the Hololens. I patched ament_tools to support Win32, but I haven't ported the changes yet to colcon (should be straightfoward, but I haven't had time).
• ros2-dotnet already supports Unity, even on the Hololens.
• Linux and macOS are supported as well.
• Seeing that you've rewritten @firesurfer 's generator in Python, I can't help but wonder why. The generator in ros2-dotnet is written in Python: https://github.com/esteve/ros2_dotnet/tree/master/rosidl_generator_dotnet so you could just use it, instead of starting from scratch.
• The rcldotnet_common fork contains a couple of inherited bugs, which were fixed recently.

I'm more than happy to accept patches for ros2-dotnet, it's still in active development, is there anything in ros2-dotnet missing for your usecase? It'd unfortunate to duplicate efforts.

[esteve]

@samiamlabs I just checked again your Python-based generator seems to be somewhat based on the ros2-dotnet code generator, it'd be great to have your changes included in ros2-dotnet. Something I noticed is that there's a bunch of files with the copyright header changed and your forks are missing the NOTICE file. The Apache license states that any derivative work must redistribute upstream's NOTICE file if it has one.

[samiamlabs]

@esteve
About the NOTICE files:
I assume you are referring to:
https://github.com/DynoRobotics/rosidl_generator_cs and https://github.com/DynoRobotics/rclcs

I started out trying to update rclcs to work with crystal, but ended up rewriting everything based on the tests in rclpy/rcl and TDD. I suspect that is why the headers "changed". Did you have something specific in mind, I may very well have changed something by accident. Happy to fix if I know what sould be fixed :)

The repos i forked from don't have a NOTICE file.

rosidl_generator_cs is based on https://github.com/ros2/rosidl_python/tree/master/rosidl_generator_py/cmake
Was unsure about the changes from bouncy to crystal in terms of mainly the generator cmake code and was not able to build rosidl_generator_dotnet with colcon on crystal for some reason. I got rosidl_generator_dotnet to build with ament_tools however, so I thought colcon was the problem...
rosidl_generator_py does not have a notice either as far as I can tell.

I did, however, make heavy use of ros2-dotnet for reference, so have added the NOTICE from there to these two repositories. Is that ok? Sould I do anything else?

[samiamlabs]

In terms of what I was missing:

• Support for bulding with colcon on crystal
• Unit tests
• Nested types in messages
• Arrays in messages

There are also a couple of other things that I wanted in order to make it easier to keep it up to date with the newest release of ROS2:

• Interface tests for all the c-functions used so that it is easier to maintain when the rcl API changes.
• @firesurfer:s approach of linking directy to the rcl libraries instead of having an extra c wrapper for everything. (I do use extra c-libs for messages currently)

I'm hoping to use Unity as a replacement for Gazebo (PhysX 4.0 will probably be availabe in Unity soon). I got the ROS1 navigation stack working with Unity via ros-sharp (rosbridge) this summer:
https://www.youtube.com/watch?v=7NCSMg_bq1I
However, I ran in to bandwidth problems when trying to send scans and pointclouds from multiple robots via websockets...

I wanted to try to get navigation2 and py_trees_ros working (uses actions), among other things, which is why I needed a C# wrapper for crystal.

Obviosly it is a bad idea to duplicate efforts. Do you plan to add tests and and crystal support relativly soon @esteve?

[samiamlabs]

I would be willing to contribute my new generator and rcl-wrapper to ros-dotnet as a crystal branch if you want me to @esteve, but this would mean some rather extensive changes to ros-dotnet. It is also not tested on UWP/Windows desktop yet.

[samiamlabs]

Looked over the headers in rosidl_generator_cs again and think I understand what you meant about them changing now. I started out trying to get the cmake code from rosidl_generator_dotnet to generate message wrappers but was not able to get it to work.

I eventually gave up on that approach and started over by commenting out your code and adding cmake code from rosidl_generator_py little by little. (I used dotnet generetor as a reference for how to build and export DLLs with dotnet_cmake_module at the end of course.)

Some of the headers from the dotnet generator got left on top of the files because of this, even though they are actually mostly derived from the py generator at this point. I have not been thinking of build configurations as something covered by copyright licenses but given the complexity of the generators that seems more than reasonable in this case. I apologize for not adding the NOTICE before publishing the repo.

Besides adding the NOTICE I'm honestly not really sure how I should have dealt with the headers in this case. rosidl_generator_py and rosidl_generator_dotnet are both under Apache License, Version 2.0 and have different headers even though dotnet seems to be derived from the python generator. You appear to have written a significant part of the cmake code for the python generator so I assume you had permission to change the header and distribute. Do you have any tips on how I should deal with this type of thing in the future (combining very similar code with different headers)? Should I ask the authors before publishing?

[clalancette]

The discussion and community collaboration on a .NET wrapper for ROS 2 is valuable. That being said, this issue hasn't really seen activity in 2 years and there is no real action to be done on this repository, so I'm going to close this issue out. Please feel free to keep discussing if there is active work in this area; I'll suggest https://discourse.ros.org for continuing discussion.