[ros-users] Nodelets

[Josh Faust]

On Sun, Dec 5, 2010 at 8:09 PM, Alex Bravo <robotnv at gmail.com> wrote:

> >Game consoles are not complex robotic systems, and we wouldn't want to
> have the entire ROS PR2 tree
> >start up as a single process, and then when something crashes the whole
> robot crashes. If my game crashes, I >can live with that.
>

I know it was Radu that wrote this, but I forgot to respond before.  In many
cases games are far more complex than any robotic task a PR2 has done so
far, and they have the same kinds of soft-realtime performance requirements
(30 or 60hz).  The last game I worked on was ~1.5 million lines of code,
which did not include the tools (which were almost 1 million lines as well
if I remember correctly).


> In the system I work with we have > 100 processes running simultaneously.
> One of those processes has 20 to 100 shared objects (like nodelets) loaded
> into it. It was done to improve OpenGL performance.
> Well, guess which of our 100+ processes has 80%+ of problems/crashes? :)
> So now we are looking for the ways of separating that process into several
> processes.
> One difference is our OS (QNX) switches faster between threads than other
> OSs switch between threads (at least that's what QNX claims, but it sounds
> right.)
>

Again, nodelets do not preclude you from doing this.  They simply allow you
to combine processes as it becomes necessary/possible.


>
> I saw some discussions here a while ago about shared memory as an
> alternative to nodelets. Was there not enough benefits for it?
>

A shared memory transport that still required a serialize/deserialize isn't
going to be much faster than loopback.  One that allocates messages inside
shared memory and allows zero-copy is possible, but comes with its own
limitations and drawbacks and hasn't been proven to be worth it.  We're
happy to accept patches that implement such a thing, but we haven't found a
need that would justify the considerable time it would take to implement it.
 Any shared memory implementation that is not fully robust to other nodes
crashing while, for example, they hold a shared lock, can take down your
node as well.

Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101205/7f9b9722/attachment-0003.html>