Revision history [back]

1) Your first question is a general software engineering/software architecture design problem and applies to more than just ROS. There are both costs and benefits to any abstraction you choose to solve a problem. Nodes provide encapsulation, isolation, modularity, robustness, the ability to run across a network -- but they come at the cost of spawning an OS-level process plus the cost of serializing/transport/deserializing messages. In general, if an idea is "big enough" (you be the judge of that), make it into a node. If you run into a problem where the interprocess communication overhead of ROS is too much on a the same host...then you can always refactor and aggregate nodes together. If you're using C++, you also have the option of using nodelets which runs a node as a thread within a single process.

2) For your second question, option 1 makes more sense. Nodes are operating system processes...it's not "free" to create one in terms of resources. Also you have to send the image information to each node via ROS publishers/subscribers...again not free. You're serializing messages, sending them over TCP, deserializing them. This is contrast to spawning 100 threads within your process and having them share pointers. With the case of image processing, it would be a very bad idea to have 100 nodes subscribed to an image stream! Each node would have a P2P connection to the camera driver -- image streams are usually in the 10s of MB/s or higher then * 100.

I'm kind of getting the gut feeling that you're thinking of ROS nodes as primarily a means to parallelize computation. It is used for that in a sense, but high performance concurrent computing is not the point. Rather the point is to break down various aspects of a robot's software stack into modular components that can be reused, easily reasoned about, and isolated from each other. You could just write your software as one giant process with a single thread for each "node"...but if one thread segfaults, the entire thing goes down. As ROS nodes are processes, if one crashes, it won't bring down another node and can just start itself back up. Also ROS nodes allow multi-programming language development. You can write your image processor in C++ and I can then write a visualizer in Python to view your output -- I'll be able to talk to your C++ program through ROS topics.

Also, ROS services are built on top of topics/publishers/subscribers. The cost is essentially double that of publishing a message (send to service provider request, provider sends back result to client).

Hope that helps.

1) Your first question is a general software engineering/software architecture design problem and applies to more than just ROS. There are both costs and benefits to any abstraction you choose to solve a problem. Nodes provide encapsulation, isolation, modularity, robustness, the ability to run across a network -- but they come at the cost of spawning an OS-level process plus the cost of serializing/transport/deserializing messages. In general, if an idea is "big enough" (you be the judge of that), make it into a node. If you run into a problem where the interprocess communication overhead of ROS is too much on a the same host...then you can always refactor and aggregate nodes together. If you're using C++, you also have the option of using nodelets which runs a node as a thread within a single process.

2) For your second question, option 1 makes more sense. Nodes are operating system processes...it's not "free" to create one in terms of resources. Also you have to send the image information to each node via ROS publishers/subscribers...again not free. You're serializing messages, sending them over TCP, deserializing them. This is contrast to spawning 100 threads within your process and having them share pointers. With the case of image processing, it would be a very bad idea to have 100 nodes subscribed to an image stream! Each node would have a P2P connection to the camera driver -- image streams are usually in the 10s of MB/s or higher then * 100.

I'm kind of getting the gut feeling that you're thinking of ROS nodes as primarily a means to parallelize computation. It is used for that in a sense, but high performance concurrent computing is not the point. Rather the point is to break down various aspects of a robot's software stack into modular components that can be reused, easily reasoned about, and isolated from each other. You could just write your software as one giant process with a single thread for each "node"...but if one thread segfaults, the entire thing goes down. As ROS nodes are processes, if one crashes, it won't bring down another node and can just start itself back up. Also ROS nodes allow multi-programming language development. You can write your image processor in C++ and I can then write a visualizer in Python to view your output -- I'll be able to talk to your C++ program through ROS topics.

Also, ROS services are built on top of topics/publishers/subscribers. The cost is essentially double that of publishing a message (send to service provider request, provider sends back result to client).

Hope that helps.

1) Your first question is a general software engineering/software architecture design problem and applies to more than just ROS. There are both costs and benefits to any abstraction you choose to solve a problem. Nodes provide encapsulation, isolation, modularity, robustness, the ability to run across a network -- but they come at the cost of spawning an OS-level process plus the cost of serializing/transport/deserializing messages. In general, if an idea is "big enough" (you be the judge of that), make it into a node. If you run into a problem where the interprocess communication overhead of ROS is too much on the same host...then you can always refactor and aggregate nodes together. If you're using C++, you also have the option of using nodelets which runs a node as a thread within a single process.

2) For your second question, option 1 makes more sense. Nodes are operating system processes...it's not "free" to create one in terms of resources. Also you have to send the image information to each node via ROS publishers/subscribers...again not free. You're serializing messages, sending them over TCP, deserializing them. This is contrast to spawning 100 threads within your process and having them share pointers. With the case of image processing, it would be a very bad idea to have 100 nodes subscribed to an image stream! Each node would have a P2P connection to the camera driver -- image streams are usually in the 10s of MB/s or higher then * 100.

I'm kind of getting the gut feeling that you're thinking of ROS nodes as primarily a means to parallelize computation. It is used for that in a sense, but high performance concurrent computing is not the point. Rather the point is to break down various aspects of a robot's software stack into modular components that can be reused, easily reasoned about, and isolated from each other. You could just write your software as one giant process with a single thread for each "node"...but if one thread segfaults, the entire thing goes down. As ROS nodes are processes, if one crashes, it won't bring down another node and can just start itself back up. Also ROS nodes allow multi-programming language development. You can write your image processor in C++ and I can then write a visualizer in Python to view your output -- I'll be able to talk to your C++ program through ROS topics.

To give you an understanding of how many nodes are usually running on a system...a PR2 runs in the ballpark of 150 nodes. These nodes include camera drivers, servo drivers, navigation algorithms, laser drivers. A Turtlebot2 runs around half that. Not saying there's a target number for a given robot or application, but trying to give you a feel of the granularity of nodes.

In the end, there's no wrong way as long as your computer and application can handle it. Today 100 nodes for a task like you're describing is a bad idea, but in 10 years when we have thousands of cores per processor it might be standard practice. ROS topics/publishers/subscribers are implemented very efficiently...it's just a P2P TCP connection streaming a packed binary representation of the respective ROS message (.msg) files. Unless you're dealing with large data streams (like image streams off cameras, big point clouds) or hard real time control...ROS topics are very very very fast. The Linux kernel also has optimizations when data is being sent over TCP on the same machine...though de/serialization routines will still be run.

Also, ROS services are built on top of topics/publishers/subscribers. The cost is essentially double that of publishing a message (send to service provider request, provider sends back result to client).

Hope that helps.

1) Your first question is a general software engineering/software architecture design problem and applies to more than just ROS. There are both costs and benefits to any abstraction you choose to solve a problem. Nodes provide encapsulation, isolation, modularity, robustness, the ability to run across a network -- but they come at the cost of spawning an OS-level process plus the cost of serializing/transport/deserializing messages. In general, if an idea is "big enough" (you be the judge of that), make it into a node. If you run into a problem where the interprocess communication overhead of ROS is too much on the same host...then you can always refactor and aggregate nodes together. If you're using C++, you also have the option of using nodelets which runs a node as a thread within a single process.

2) For your second question, option 1 makes more sense. Nodes are operating system processes...it's not "free" to create one in terms of resources. Also you have to send the image information to each node via ROS publishers/subscribers...again not free. You're serializing messages, sending them over TCP, deserializing them. This is contrast to spawning 100 threads within your process and having them share pointers. With the case of image processing, it would be a very bad idea to have 100 nodes subscribed to an image stream! Each node would have a P2P connection to the camera driver -- image streams are usually in the 10s of MB/s or higher then * 100.

I'm kind of getting the gut feeling that you're thinking of ROS nodes as primarily a means to parallelize computation. It is used for that in a sense, but high performance concurrent computing is not the point. Rather the point is to break down various aspects of a robot's software stack into modular components that can be reused, easily reasoned about, and isolated from each other. You could just write your software as one giant process with a single thread for each "node"...but if one thread segfaults, the entire thing goes down. As ROS nodes are processes, if one crashes, it won't bring down another node and can just start itself back up. Also ROS nodes allow multi-programming language development. You can write your image processor in C++ and I can then write a visualizer in Python to view your output -- I'll be able to talk to your C++ program through ROS topics. If you're interesting in computational node graphs, check out another cool project that came out of Willow Garage called "ecto" -- http://wiki.ros.org/ecto

To give you an understanding of how many nodes are usually running on a system...a PR2 runs in the ballpark of 150 nodes. These nodes include camera drivers, servo drivers, navigation algorithms, laser drivers. A Turtlebot2 runs around half that. Not saying there's a target number for a given robot or application, but trying to give you a feel of the granularity of nodes.

In the end, there's no wrong way as long as your computer and application can handle it. Today 100 nodes for a task like you're describing is a bad idea, but in 10 years when we have thousands of cores per processor it might be standard practice. ROS topics/publishers/subscribers are implemented very efficiently...it's just a P2P TCP connection streaming a packed binary representation of the respective ROS message (.msg) files. Unless you're dealing with large data streams (like image streams off cameras, big point clouds) or hard real time control...ROS topics are very very very fast. The Linux kernel also has optimizations when data is being sent over TCP on the same machine...though de/serialization routines will still be run.

Also, ROS services are built on top of topics/publishers/subscribers. The cost is essentially double that of publishing a message (send to service provider request, provider sends back result to client).

Hope that helps.