I think ROS in general is a bit notorious for not giving any realtime guarantees, though there are groups working on it.
I'm definitely looking forward to the new garbage collector (#8699 <https://github.com/JuliaLang/julia/pull/8699>) as I'm currently seeing quite noticeable stuttering with high bandwidth data like images. On Monday, December 22, 2014 12:54:00 PM UTC-5, Spencer Russell wrote: > > Do your robotics applications have any realtime (or soft realtime) > requirements? I suppose if folks are using python then that's already out > the door, but possibly in the future wrapping the C++ interface could be a > path towards more deterministic performance, along with the GC work that's > being done on the Julia side. > > > peace, > s > > On Sun, Dec 14, 2014 at 7:07 PM, Josh Langsfeld <[email protected] > <javascript:>> wrote: > >> Yeah, the performance is still an open question I'm looking into. >> Fortunately, for a lot of use cases, you either want to publish or >> subscribe at a fixed rate and not just go as fast as the library will >> allow. For small messages, like vectors and poses, I didn't see any >> performance issues going all the way up to 500Hz. But I think passing >> around high bandwidth sensor data may clog it up, especially since it has >> to copy the entire message from the python type to the julia type or vice >> versa. >> >> Going through roscpp instead of rospy is definitely an interesting >> question that I have not investigated. Rospy is required to introspect on >> the message data for the type generation but it might work to do everything >> else through roscpp with ccall or Keno's CXX package ( >> https://github.com/Keno/Cxx.jl). If performance is lacking that should >> definitely be the first thing to start investigating. >> >> Thanks, >> Josh >> >> >> On Friday, December 12, 2014 9:17:49 PM UTC-5, Tony Kelman wrote: >>> >>> Josh, >>> >>> This is very cool, thanks for releasing this! Some of my colleagues are >>> starting to use ROS and I've been gently nudging them towards Julia rather >>> than legacy C or Matlab solutions. The timing on this package is a >>> convenient coincidence. >>> >>> How much performance do you think this might be leaving on the table by >>> having to go through PyCall and rospy? Are most of the underlying API's >>> exposed through a C interface that could be wrapped directly via ccall? >>> >>> -Tony >>> >>> >>> On Friday, December 12, 2014 11:06:37 AM UTC-8, Josh Langsfeld wrote: >>>> >>>> After about 6 weeks of initial part-time development, I'm announcing >>>> the first release of the RobotOS.jl package, which enables essentially >>>> seamless integration of Julia code with ROS <http://wiki.ros.org> (Robot >>>> Operating System). At the core, it is mostly a wrapper for the rospy >>>> python >>>> library (many thanks to Steve Johnson for PyCall), but on top of that I >>>> added an automatic Julia type generation system so the back-end python >>>> details are completely hidden from the end-user. >>>> >>>> https://github.com/phobon/RobotOS.jl >>>> >>>> I believe the robotics community is especially well suited to adopt >>>> Julia, as speed and natural mathematical expressiveness are both highly >>>> desirable features in whichever programming language is used. For about >>>> six >>>> months now, I've been doing all my research in Julia and it has been >>>> vastly >>>> more pleasurable than using either Matlab or Python. >>>> >>>> I am quite eager to continue development on the package with whatever >>>> community feedback I can get but hopefully it can already prove useful to >>>> anyone out there who has already thought of using the two systems together. >>>> >>>> Thanks, >>>> >>>> Josh Langsfeld >>>> Graduate Research Assistant >>>> Maryland Robotics Center - UMD >>>> >>> >
