[ros-users] ROS 2.0 transports and ROS 1.x transports

[Ingo Lütkebohle]

Hi,

zmq is pretty cool, and I've been using it in other situations with great
success. In true UNIX tradition, it does one thing well, and integrates
well with other stuff. It is also a fairly minimal library. I strongly
endorse it.

cheers,



On Fri, May 24, 2013 at 11:15 AM, Jonathan Bohren <jonathan.bohren at gmail.com
> wrote:

> While this is about transports, I'm cross-posing this to ros-users since
> it's pretty high-level and contains some background that I think others may
> be interested in.
>
> So back before Fuerte, there were also a bunch of people looking at
> transport options, and there was an "IPC" SIG [1] with a mailing list that
> died pretty quickly [2] but not before they put together a bunch of
> thoughts at a meeting [3].
>
> I was curious about how the ROS transport sausage was made and it's sort
> of gross. TCP and UDP are all mangled together in roscpp and the underlying
> code isn't really modular at all. That being said, I think the ROS
> in-process communication with shared pointers is something special that we
> should keep around, even if we gut everything else. That sort of constraint
> to a finite set of shared pointer types (right now boost shared pointers
> and maybe in the future c++11 shared pointers) is more constrained than
> other middlewares are willing to go but I think we should really optimize
> the ROS transport layer for the things that we do and keep this
> functionality around.
>
> Then I was looking at some of the alternatives for the inter-process and
> inter-machine communication that exist today and provide a simple interface
> to TCP/UDP/Multicast for a variety of languages, and zeromq (zmq) comes up.
> The funny thing about zeromq is that almost a year ago, some people
> at Bonn-Rhine-Sieg University of Applied Sciences analyzed ROS TCP
> transport with zmq, and you can see their analysis here [4]. What I can't
> find, however, is if they actually modified roscpp to try this. It seems
> like we should contact someone from that group.
>
> In the spirit of the new dependency-choice philosophy of ROS 2.0 I think
> zmq is a really good choice because (a) it does what we would want ROS to
> do, and (b) it's supported by a commercial entity [5]. If someone had time
> to prototype a modification to roscpp in ros_comm as well as the master to
> allow for zmq-based TCP/UDP/PGM (multicast) without changing the current
> ROS API, that would be really cool. Fundamentally, it would work the same
> as the current ROS networking architecture, which means we'd also be able
> to compare performance to the current implementation.
>
> Most importantly, it wouldn't break any code.
>
> I know there are a lot of other far-out ideas (masterless stuff etc), but
> I think _just_ replacing the ROS transport layer with something like zmq
> would get us a LOT of capabilities and performance without having to
> completely change how ROS works. Maybe there should be separate near-term
> (1.x) and a far-term (2.0) efforts if there are enough people interested in
> this.
>
> [1] http://www.ros.org/wiki/fuerte/Planning/IPC
>  [2] https://code.ros.org/lurker/list/ros-sig-ipc.html
> [3] http://www.ros.org/wiki/fuerte/Planning/IPC/Minutes
> [4] https://sites.google.com/site/arsalanakhter1/news/zeromqwithros
> [5] http://www.zeromq.org/intro:commercial-support
>
> --
> Jonathan Bohren
> Laboratory for Computational Sensing and Robotics
> http://dscl.lcsr.jhu.edu/People/JonathanBohren
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>


-- 
Ingo Lütkebohle
Bielefeld University
http://www.techfak.uni-bielefeld.de/~iluetkeb/

PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130524/c3c1a808/attachment-0004.html>