RosBridgeClient Refactoring

[MartinBischoff]

We are just starting a major refactoring of the RosBridgeClient library.

Here are some things that we want to achieve:

• add generic communication protocol interface This enables us to easily switch between websocket-sharp, Websocket-Sharp-UWP .NET Websocket and to add other (also non-WebSocket) communication protocols in the future. Thanks to @jaguar243 for suggesting this in issue #21 months ago!
• add NUnit tests
• improve readability, code structure and performance

You can follow the current state of development on my fork.

[MartinBischoff]

On my fork we just completed refactoring the RosBridgeClient library and realised all points mentioned above.

Based on above changes RosBridgeClient now comes with a different syntax. See RosSocketConsoleExample.cs for an example. We thus will also update the Unity3D project and some Wiki pages before pushing the changes upstream.

Here are some advantages of the new verison:

• All message types are strongly typed based on generics. No more types as arguments or Json Objects to parse.

  string publication_id = rosSocket.Advertise<std_msgs.String>("publication_test");

• The ROS message name is directly included in the message type definition. No separate message type dictionary is required. See e.g. Messages.Standard.String.

  • RosSocket is instantiated by passing a IProtocol interface implementation, i.e.

    RosSocket = new RosSocket(new RosBridgeClient.Protocols.WebSocketSharpProtocol(192.168.0.2));

• The following two IProtocolimplementations currently exist :

  • WebSocketNetProtocol: using System.Net.WebSockets and requiring .NET 4.5+ to compile and Windows 8+ to run.
  • WebSocketSharpProtocol: our good old websocket-sharp interface that runs well with everything but UWP/.NET Core.
  • We skipped the WebSocketSharp-UWP implementation metioned above, since we think it will not be needed.
  • We should be able to easily write other implementations for also non Websocket (e.g UDP) protocols in the future if necessary.

• We started setting up the first unit tests in RosSocketTests.cs.

• We restructed the VS solutions such that all ROS# .dlls will be generated from one single VS solution located in the directory ros-sharp/Libraries. Will will also migrate the UrdfImporter there.

I hope you guys like these modifications and will not have much effort adjusting your ROS# application to this update that will come in some weeks.

If you have any concerns about the changes, please inform us here in this issue.

[roalchaq]

Hi!

I am interested in using ros-sharp with the Hololens so I recently tested the code from @MartinBischoff 's fork with a very simple scene and an ImagePublisher message. I noticed some difference from siemens/ros-sharp in the way that the GameObjects and the scripts are related in the scene:

• A protocol now needs to be specified for the Ros Conncetor Script
• Image Publisher script needs to be related with a Ros Connector GameObject
• unitytimepublisher removed
• Player Settings -> Other Settings -> Configuration -> Scripting Runtime Version: .NET 4.x Equivalent

When I use the code from this branch (siemens/ros-sharp) everything works perfectly fine (Image1 displayed using rviz) but it doesn't work when I used the new version (even if I use WebSockectSharp protocol - see Image2 attached).

I have tested in Unity 2018.1.6f1 and 2018.1.4f1. Is anyone else having an issue with this or am I omitting some other important steps? Thank you in advance for your help.

[MartinBischoff]

Hi @roalchaq ! Thanks for testing the code on my fork ;-) Thank you also for indicating the functional differences to the upstream version. The code on my fork is not ready yet, otherwise we would merge it upstream (into this branch as you call it). The code here is working, but not with the Hololens as discussed here #33.

[IoannisKaragiannis]

Hi,

Yesterday I asked a question regarding the HoloLens deployment of an app that uses ROS-Sharp. For some strange reason my comment was deleted by Siemens. Did I do something wrong?

Thanks

[MartinBischoff]

Hi @IoannisKaragiannis thanks for reaching out. We had to delete your message since we considered it off-topic and not constructive. Please feel free to contact us via ros-sharp.ct@siemens.com for further clarification.

Though Hololens was not the orignial contents of this issue (@rolchaq brought it up only in his message above), I go into this topic here:

At our research group we have not developed and are currently not planning to develop ROS# applications for the Hololens. So, to be honest, I personally do not know whether ROS# or any branch works with it or not.

Of course we are very much interested in developing a perferably generic ROS-Unity communication framework. This is the reason why we are currently refactoring RosBridgeClient as discussed above. We expect that one nice side-effect of the new .NET ClientWebsocket implementation will be that it also works with the Hololens, due to the higher .NET Framework version and UWP support.

In this open source project everyone is kindly invited to contribute, find and resolve bugs, and adjust the ROS# code in his forks to his needs and liking. Thanks a lot to @tarukosu again for including a websocket-sharp version for UWP that is supposed to work with the hololens on his fork: https://github.com/tarukosu/ros-sharp/tree/support-for-uwp

[IoannisKaragiannis]

Thanks for your thorough response.

[MartinBischoff]

done (cf. https://github.com/siemens/ros-sharp/commit/34fb2a8ddd58c5f099b1e4b887a253b954808fb4)

[philipogorman]

I'd like to update the RosBridgeClient project to be .NET Standard 2.0. The only issue I see is that the WebSocketSharp nuget and WebSocketSharpProtocol.cs would have to be removed from the project. I dont think this is an issue so long as your platform was at the supported version for .NET Standard 2.0. Although I am not sure about unity. See https://docs.microsoft.com/en-us/dotnet/standard/net-standard Does anyone see an issue moving RosBridgeClient project to be .NET Standard 2.0?