>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.
>
>Multiple processes can actually act as "guards" too - by separating
important levels of functionality. I'm pretty >sure that an ill-malformed
nodelet can easily crash a manager. But sure, I did notice that you said
"fully-
> debugged applications" ;) Unfortunately, in my opinion we're still not
there... yet.
>My point is that different processes are still good enough for our current
robotic infrastructure and should be
>used wherever possible if your bottleneck is not the
copy/(de)serialization. But sure, ultimately, people are free
>to use whatever they want :)
Besides agreeing with Radu on all points, I would warn
against underestimating the importance of having separate memory spaces
between different processes.
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.)
I saw some discussions here a while ago about shared memory as an
alternative to nodelets. Was there not enough benefits for it?
On Sun, Dec 5, 2010 at 2:15 PM, Radu Bogdan Rusu <
rusu@willowgarage.com>wrote:
>
> On 12/05/2010 01:56 PM, Josh Faust wrote:
> >
> > In general, nodelets should not be abused. If the performance of
> nodes (copy/(de)serialization) is really what's
> > dragging your processing graph down, then sure, nodelets are offering
> a viable alternative. However, this should really
> > be profiled first for each application.
> >
> >
> > This isn't entirely true. Adding processes also means adding threads,
> which increases context switches/etc. Having
> > everything in a single process means more control over everything.
> There's a reason game consoles run a single process,
> > and that process generally has # threads == # cores. I think in the
> "ideal" world everything that can be a nodelet
> > should be, and a fully-debugged application would be a single process
> running many nodelets. In practice there are
> > likely exceptions (like, say, GUI applications), but overall I think it's
> a reasonable goal.
>
>
> Agreed, but though I'm pushing for nodelets (at least in all the perception
> infrastructure) like crazy, I think having
> multiple processes still makes a lot of sense (whether they should be nodes
> or nodelets ran in multiple managers, that's
> a different story). 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.
>
> Multiple processes can actually act as "guards" too - by separating
> important levels of functionality. I'm pretty sure
> that an ill-malformed nodelet can easily crash a manager. But sure, I did
> notice that you said "fully-debugged
> applications" ;) Unfortunately, in my opinion we're still not there... yet.
>
> My point is that different processes are still good enough for our current
> robotic infrastructure and should be used
> wherever possible if your bottleneck is not the copy/(de)serialization. But
> sure, ultimately, people are free to use
> whatever they want :)
>
> Speaking of GUIs, it would be really nice to get image_view/rviz/pcd_viewer
> to have a nodelet component for displaying
> data fast(er). Do you see any drawbacks of nodelets w. GUIs? If not, I
> might try to do the image_view/pcd_viewer part
> next week as an exercise.
>
> Cheers,
> Radu.
> --
> http://pointclouds.org
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
(text/plain)