roscpp #59
Comments
|
Cxx.jl previously required specific features from LLVM, but I believe these have now be included in the standard Julia 1.0. Either way, using I can't commit too much time just yet, but want to start planning an interface for Caesar.jl with ROS/ROS2. |
|
I saw your other post on RobotOS.jl as well. I have some experience with ccall/Cxx.jl. I'm in the same boat as you on time (not a whole lot available, but would like to start using this in my research). I have a few questions/concerns:
It would be great if @jdlangs could chime in as well. As an aside @dehann, I enjoyed reading through some of your recent work and am looking to leverage it for an application here in the Personal Robotics Lab at UW. I'd love to chat sometime. |
|
If any progress is done on this issue I would be happy to help. |
Go Cxx.jl?Looks like Cxx.jl on Julia 1.1 is much better/easier than than it was back in Julia 0.6 when I last checked on this. I'm a little short on time, but that is the way I'd go. Build a new ROSCxx.jl (or similar) package/module and depend on Cxx.jl rather than PyCall.jl. CppWrap.jl not as easyThis would require special C++ code to wrap and probably not what we'd want with ROS continuously changing. Crazier Idea:Maybe all submodules here in RobotOS.jl, using optional Requires.jl for which interface to use: using Cxx
using RobotOS
# vs
using PyCall
using RobotOSIf someone is already using PyCall it might be worth it to then just allow the Python interface too -- just thinking out load. Not sure what to do about function name collisions in this case though. Don't think we want to call this or that function specifically. Perhaps either submodules or order of precedence can be used to resolve name conflicts. |
|
I actually played around with Cxx.jl + ROS (not ROS2) the other day and it was pretty straight forward. I was able to get a subscriber/publisher working with primitive types. I think Cxx.jl is the way to go (over CxxWrap) for the reason you stated (esp. w/ the benefit of meta-programming away all the repetitive stuff). I didn't experiment with passing structs/msgs so there's a bit of a question mark there (Cxx.jl docs are sparse on this). The only downside is compile time (you have to compile all the ROS code ahead of time). We can possibly deal with this down the road with PackageCompiler.jl. On the upside, your function calls can be inlined. As for the crazier idea, I think with ROS1 development killed and Python2 reaching EOL in January that jumping ship to ROS2 makes the most sense. People could always use the ROS bridge to integrate with ROS1 (albeit with a bit over overhead). |
|
We can have a package that has both. We can just add a suffix I agree with doing this for ROS2. If any development is going to be done it should be done using the latest available OS. |
|
I think that gets confusing. The functions/types should have the exact
names as their C++ counterparts wherever possible.
What's the benefit of putting them in the same package? No one is going to
be using both at the same time and their dependencies are different (PyCall
vs Cxx).
Colin X Summers
University of Washington
Personal Robotics Lab
www.colinxsummers.com
…On Tue., 13 Aug. 2019, 16:33 Amin Yahyaabadi, ***@***.***> wrote:
We can have a package that has both. We can just add a suffix C to the
end of the functions and types to get them separated from Python ones. As a
result, someone can even use both (I assume).
I agree with doing this for ROS2. If any development is going to be done
it should be using the latest available OS.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#59?email_source=notifications&email_token=AELLS2DZ5M7MWIE3UONPPF3QENACZA5CNFSM4FZXH7T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4HI2JA#issuecomment-521047332>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AELLS2A27ZBCR3DBWDBYTDDQENACZANCNFSM4FZXH7TQ>
.
|
|
Hi all, glad to see there's a lot of interest here. I'm all for getting the backend of this package running through roscpp, just have super limited time to work on it, especially since it's not something holding my own work back. Since Cxx.jl seems to be working well nowadays, I'd envision just doing a direct swap of the PyCall usage to Cxx usage, ideally without changing the API at all, since the library used should be an implementation detail. @colinxs do you have some initial work along those lines that could begin to get integrated into the repository? Even just being able to support pub/sub of primitive types would be a nice start. |
|
It does look like sooner than later there should be built-in support for ROS2, most probably via rclc. @dehann I'd be interested in talking further about how JuliaRobotics plans to integrate with ROS and if maybe we could have overlapping efforts to adopt ROS2. Long-term, I'm hoping to drive some interest in adopting Julia at my current company. If that happens, then this package will probably become an important dependency and all sorts of developer time will become available to maintain and improve it. |
|
Hi @jdlangs , sorry for the slow reply -- and now its a long reply too. TLDR; lets make a priority list for functionality that will help get more people involved, and between us knock out two or three of the most important ones. @colinxs, would you mind sharing / pointing to where your previous ROS / Cxx.jl proof or concept code is please (don't mind if its still messy and early stages)? ROS is pretty critical for robotics in general and there should be a clear interaction between JuliaRobotics and RobotOS.jl for sure. Thanks for getting this started! The origins of JuliaRobotics was to build on a middleware layer (logging/playback/spy) called LCM and therefore ROS.jl was not immediately built there. Some JuliaRobotics guys did a lot of work to convert PyLCM to LCMCore.jl (direct C, but was a similar discussion). On Caesar.jl side of things, we are working to get sufficient features + performance that should be attractive to the community. We don't want to roll out ROS integration and then disappoint, however, ROS will become more and more critical in the next year or so. As our resources increase and baseline performance settles, we would like to better support development on RobotOS.jl (and a C/C++ based interface would be best). The best way to do these things is definitely have more people involved, so maybe what we should do convert a wishlist into a priority list and try knock two or three of those items out as soon as possible. Is there a running todo roadmap somewhere, perhaps a wiki or even "expand community kanban" project? Focus on functionality now that will more people involved and help out first. JuliaRobotics as a home for the repo may help a little, however, functionality and stability are probably more important. Can always move around later if it makes sense to do so. Maybe I should just ask it this way, is My guestimate is that support for both ROS and ROS2 will be important, since many industrial users are sticking with ROS until they are convinced ROS2 is adopted and stable. Sort of a Python 2.7 / 3 transition issue. I checked and ROS1 does not seem to do a good job with C, but ROS2 has the rclc library that Colin found. My own preference is Julia<-->C, but Cxx is still much better than a PyCall dependency (in fairness, PyCall.jl works well and is amazing regardless). PyCall actually uses the Python C interface directly. |
|
Hey @dehann, sorry I missed this!! Your recent activity over at JuliaRobotics/Caesar.jl#227 prompted me to come check this issue, and I'm glad I did!
I switched machines and apparently didn't push this :(. It wasn't much though.
I actually asked the ROS2 devs about this awhile ago over at ros2/rclc#11 and tl;dr it's not something we can use. So, C++ it is!
Agreed. My lab will be on ROS for at least the next year. On Cxx.jl vs CxxWrap.jl, Cxx.jl is likely easier to write (and faster in some cases because of the ability to inline), but I'm curious about the robustness/usability. With CxxWrap.jl you'd build your wrapper once and compile it, whereas with Cxx.jl you JIT compile each run (and that's just one more avenue for something to fail). I suppose with PackageCompiler.jl we could compile a shared library? I'd rather have an easy-to-use/robust wrapper than one that saves me a few function calls. Given how often ROS runs on resource-contrained, embedded systems, I think compile time is a huge factor. Only the core library needs to be wrapped, while ROS msg types can just be generated dynamically as you're doing now, so maybe it's not all that much code to write? Either way, we should probably get some input from the folks at Cxx.jl and CxxWrap.jl (and maybe others who have wrapped C++ libraries) to see what the best option is. |
my personal preference is to only rely in Julia to do the compiling, else its bits and pieces of install ROS / get and compile the wrapper / get and run the Julia code. Therefore my opinion is for Cxx.jl, but also worth just getting stuff to work first to increase the uptake.
Even though PackageCompiler.jl might be bit more of a pain in the beginning, its also a once off. FYI, Gadfly.jl is doing some work on using PackageCompiler to reduce the 'time-to-plot' (analogous situation): We've (cc @pvazteixeira) started work using RobotOS.jl and tracking the highlights in a wiki here, in case anyone is interested: But, as per this thread, skipping Python requirement entirely is the main goal.
Fair, maybe 6 of one and half dozen other -- either one, since in time there will likely be both anyway. Not uncommon in the Package ecosystem. Will post here when we have made some progress on this issue. Aside: a little while back we had a situation where LCMCore.jl was installing python on Linux as a package dependency, but was not used in the source anywhere. This was only caught because someone was trying to build minimum size docker containers, but the python dependency introduced quite a large overhead. Was easily removed, discussion here if interested: |
(...)
The JIT compilation is definitely a concern, as it can/will introduce latency even in reseource-rich systems. |
|
Is there an update on RobotOS with roscpp? I'm runnning into some performace issues with RobotOS |
|
I have a very very very early/rough draft of a roscpp wrapper for Julia which is not working but has some functionality implemented to it. It is in a private repository, but I am willing to make it public if enough people are interested in helping out! |
|
I'm very interested in that! If possible I will help, but I'm no expert in julia Did you compile ROS into a shared library and use Cxxwrap.jl, or how did you do it? |
|
I am using Cxx and trying to wrap C++ generic functions around all the core ROS functionality. I just made the two SUPER ROUGH repos public: https://github.com/gstavrinos/ROS.jl You'll need some persistence because the code and the repos were only intended to be used internally. Good luck! |
|
Hi @gstavrinos , wonderful -- thanks for putting up a starting point! We are also working with RobotOS.jl via Python at the moment and want to replace that with Cxx.jl. I'll try help out as we integrate with ROS more. FYI (minimal proof or concept we started on and actively using at the moment): |
|
Hey @dehann , thanks for reaching out. I will definitely take a look! |
|
Any update on this? |
|
Hi, Is there an update on RobotOS without python? |
@jdlangs and anyone else who had a significant contribution to this project:
Is there any reason why rospy/PyCall.jl was chosen over using roscpp and Julia's native ability to call into C/C++? It seems like that latter would be easier, less error prone, and more performant.
Are there any plans to swap to the roscpp backend in the future? I would be interesting in contributing if there is similar interest among the developers.
Thanks!
Colin
The text was updated successfully, but these errors were encountered: