>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.