You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Other questions :
Type of license associated to this project ?
I see you implement a other implementation (High-level implementation) in .net-core. It is a other POC or reorientation ?
I don't know if this may become the official implementation of Java for ROS2, it just happens to be the first one :-)
The goal of this project is to run ROS2 on Android, but along the way, you can also write applications that target the JVM on a PC.
I have a .NET wrapper in the works, based on .NET Core [1], mostly for UWP applications, but I haven't had time to polish it. @firesurfer is working on another implementation [2], which uses a different approach than rcljava and rclpy. Hope he can chime in and tell you more about his implementation.
@firesurfer I'm currently travelling and I left the .NET wrapper code on my Windows machine. Anyway, what I did was basically follow the same pattern as rcljava, using P/Invoke (instead of JNI) to call the unmanaged code from the managed land, and viceversa.
When I wrote the first prototype of the rclpy bindings at OSRF, I used a similar approach as yours to avoid the overhead of converting between C and Python. However, I soon found out that using ctypes and cffi to call the rcl API directly was too cumbersome and implementing nested types and arrays was difficult, so I ended up writing a glue layer in Python/C. Maybe things are different in .NET, so it might be possible to avoid that overhead, I don't know. In any case, rcljava follows the same approach as rclpy (besides the fact that Java is compiled), and rcldotnet was fairly straightforward given the similarities with Java.
I've requested a new category in the ROS discourse [1], I think it'd be a great place to have this kind of discussion.
And it'd be great to join efforts, let me know if you're interested. My usecase for rcldotnet is UWP applications, and Mono (I assume that's your usecase) would be great too.
I would really like to join efforts, I think it is more convenient for users to have one good working wrapper instead of multiple wrappers.
My rclcs and rosidl_generator_cs are following the approach to have as little as possible overhead. I'm thinking that it should be possible to reproduce the same datatypes and especially struct layouts as the rosidl_generator_c generates. The interop abilities of .Net are more advanced than the abilities of Java as far as I know.
My usecase at the moment is mono only (Mainly because I haven't done any development on Windows for a long time). I think it should be fairly easy to port my code to .net core because I'm mostly using the interop libs.
After full-install (ros2_java_desktop), my feedback : It works perfectly !! Thank.
My environment was : Debian Testing with Java 1.8 and python 3.5.2
I need to install with APT : python3-yaml python3-empy gradle
and disable 2 extra package : ament build --symlink-install --isolated --skip-packages ros1_bridge pendulum_control (fix by aptitude install python-roslz4 & ros2/demos#77)
@Theosakamg thanks for trying out the Android stuff, I just updated the command in README.md. As for the skipped packages, did you follow the general ROS2 instructions (https://github.com/ros2/ros2/wiki)? pendulum_control and ros1_bridge should not be affected by the ros2_java code.
Activity
esteve commentedon Aug 23, 2016
Thank you for your interest! I just made a first release of all code needed for writing Java and Android applications for ROS2, see https://groups.google.com/d/msg/ros-sig-ng-ros/y6m51E53Nyo/LTNUs9wADwAJ
I don't know if this may become the official implementation of Java for ROS2, it just happens to be the first one :-)
The goal of this project is to run ROS2 on Android, but along the way, you can also write applications that target the JVM on a PC.
I have a .NET wrapper in the works, based on .NET Core [1], mostly for UWP applications, but I haven't had time to polish it. @firesurfer is working on another implementation [2], which uses a different approach than
rcljavaandrclpy. Hope he can chime in and tell you more about his implementation.1 - https://dotnet.github.io/
2 - https://github.com/firesurfer/rclcs
firesurfer commentedon Aug 23, 2016
Could you show us your .NET wrapper code on github (or somewhere else). I'm interested on how you've done the wrapping.
esteve commentedon Aug 24, 2016
@firesurfer I'm currently travelling and I left the .NET wrapper code on my Windows machine. Anyway, what I did was basically follow the same pattern as
rcljava, using P/Invoke (instead of JNI) to call the unmanaged code from the managed land, and viceversa.When I wrote the first prototype of the
rclpybindings at OSRF, I used a similar approach as yours to avoid the overhead of converting between C and Python. However, I soon found out that usingctypesandcffito call therclAPI directly was too cumbersome and implementing nested types and arrays was difficult, so I ended up writing a glue layer in Python/C. Maybe things are different in .NET, so it might be possible to avoid that overhead, I don't know. In any case,rcljavafollows the same approach asrclpy(besides the fact that Java is compiled), andrcldotnetwas fairly straightforward given the similarities with Java.I've requested a new category in the ROS discourse [1], I think it'd be a great place to have this kind of discussion.
And it'd be great to join efforts, let me know if you're interested. My usecase for
rcldotnetis UWP applications, and Mono (I assume that's your usecase) would be great too.1 - http://discourse.ros.org/t/request-for-new-rosdotnet-category/448
firesurfer commentedon Aug 25, 2016
I would really like to join efforts, I think it is more convenient for users to have one good working wrapper instead of multiple wrappers.
My
rclcsandrosidl_generator_csare following the approach to have as little as possible overhead. I'm thinking that it should be possible to reproduce the same datatypes and especially struct layouts as therosidl_generator_cgenerates. The interop abilities of .Net are more advanced than the abilities of Java as far as I know.My usecase at the moment is mono only (Mainly because I haven't done any development on Windows for a long time). I think it should be fairly easy to port my code to .net core because I'm mostly using the interop libs.
esteve commentedon Aug 26, 2016
@firesurfer now we have a category in the ROS discourse for client libraries thanks to @tfoote, I think it'd best to move the discussion there:
http://discourse.ros.org/t/net-bindings-for-ros2/460
Theosakamg commentedon Aug 26, 2016
Thank @esteve .
You link https://github.com/raw/esteve/ament_java/master/ros2_java_desktop.repos in documentation return 404...
prefere https://github.com/raw/esteve/ros2_java/master/ros2_java_desktop.repos
esteve commentedon Aug 26, 2016
@Theosakamg thanks for noticing! I just fixed the URLs esteve@55710be
Theosakamg commentedon Aug 27, 2016
After full-install (ros2_java_desktop), my feedback : It works perfectly !! Thank.
My environment was : Debian Testing with Java 1.8 and python 3.5.2
I need to install with APT :
python3-yaml python3-empy gradleand disable 2 extra package :
ament build --symlink-install --isolated --skip-packages ros1_bridge pendulum_control(fix byaptitude install python-roslz4& ros2/demos#77)Theosakamg commentedon Aug 27, 2016
On ros2_java_android build command
result with
... --ament-gradle-args : command not foundadd
\on ligne 8.esteve commentedon Aug 30, 2016
@Theosakamg thanks for trying out the Android stuff, I just updated the command in
README.md. As for the skipped packages, did you follow the general ROS2 instructions (https://github.com/ros2/ros2/wiki)?pendulum_controlandros1_bridgeshould not be affected by theros2_javacode.Do you mind if we move the conversation to http://discourse.ros.org/c/rosjava and/or http://discourse.ros.org/t/announcing-java-and-android-for-ros2/445 ? Discourse is a great place to discuss this sort of development.