On Fri, May 24, 2013 at 4:18 PM, Nico Hochgeschwender <
nico.hochgeschwender@h-brs.de> wrote:
> I am one of the authors of the paper and I can give some more details
> about ZMQ.
>
> - The objective of our paper was to look into scalability issues for
> typical publish/subscribe systems. We did not modified roscpp and we used a
> plain ZMQ stack and the roscpp stack.
>
> - IMO the major advantage of ZMQ is the ability to build highly-efficient
> systems with a combination of different ZMQ sockets such as broker, queue,
> dealer and router and a combination of thereof. However, to construct such
> highly-efficient applications demands detailed knowledge about the topology
> "and deployment setting (inproc, inter-proc, WAN, LAN,..). I am not sure
> how to generalize this in a new transport layer for ROS. But that's maybe a
> great challenge for this SIG :)
>
Well roscpp at least already determines whether a publisher is in-process
or not, and I feel like with little effort we could add a bit more info to
the master and pub/sub APIs to provide specifications for multicast. We
could even make it compatible with the TransportHints interface, but make
it m This would be especially useful for heavy systems like TF (small
packets at high rate) or camera streams (large packets at slower rates).
>
> 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.
>>
>
> I am really curious about ROS 2.0. However, I do not have any detailed
> information about it. Is there any material available?..Sigh..I missed
> ROSCON.
>
"ROS 2.0" is like the bin that all the nice-to-haves get thrown into. While
2.0 is like a revolution and potentially a complete re-thinking of how ROS
might work, what I'm talking about is just making the current paradigms we
have better and a bit more powerful.
So is anyone interested in fixing the current ROS transport by replacing
the guts with zmq instead of imagining / re-imagining / re-writing the way
we communicate in ROS entirely?
-j
--
Jonathan Bohren
Laboratory for Computational Sensing and Robotics
http://dscl.lcsr.jhu.edu/People/JonathanBohren
(text/plain)