Revision history [back]

I tend to like the multithreading approach better. I rewrote a ROS package that consisted of ~6 nodes, and it was confusing to find which node was publishing a given TF frame in particular. Synchronizing the timing between the various nodes and publishing a "state" of the system also got confusing. RViz graphics could have some timing-based glitches based on how fast a computer would process incoming messages.

When it was rewritten as a large C++ executable, I could mouse over (for example) a variable name and the Sublime development environment would tell me exactly where that variable was defined. I also only needed one global "state" variable, rather than subscribing to a state message from several different nodes.

I think modularity is easy with multiple ROS nodes but you can do the same thing with classes. I have heard it said that a good ROS design philosophy is to communicate with ROS in just one section of your executable.

Anyway, that's a mechanical-engineer-turned-programmer's take.

I tend to like the multithreading approach better. I rewrote a ROS package that consisted of ~6 nodes, and it was confusing to find which node was publishing a given TF frame in particular. Synchronizing the timing between the various nodes and publishing a "state" of the system also got confusing. RViz graphics could have some timing-based glitches based on how fast a computer would process incoming messages.

It was funny that one of the nodes was doing nothing, but the program was so complex, nobody had noticed for months. :/

When it was rewritten as a large C++ executable, I could mouse over (for example) a variable name and the Sublime development environment would tell me exactly where that variable was defined. I also only needed one global "state" variable, rather than subscribing to a state message from several different nodes.

I think modularity is easy with multiple ROS nodes but you can do the same thing with classes. I have heard it said that a good ROS design philosophy is to communicate with ROS in just one section of your executable.

Anyway, that's a mechanical-engineer-turned-programmer's take.

I tend to like the multithreading approach better. I rewrote a ROS package that consisted of ~6 nodes, and it was confusing to find which node was publishing a given TF frame in particular. Synchronizing the timing between the various nodes and publishing a "state" of the system also got confusing. RViz graphics could have some timing-based glitches based on how fast a computer would process incoming messages.

It was funny that one of the nodes was doing nothing, but the program was so complex, nobody had noticed for months. :/

When it was rewritten as a large C++ executable, I could mouse over (for example) a variable name and the Sublime development environment IDE would tell me exactly where that variable was defined. I also only needed one global "state" variable, rather than subscribing to a state message from several different nodes.nodes. Of course, there are the performance benefits fergs already mentioned.

I think modularity is easy with multiple ROS nodes but you can do the same thing with classes. I have heard it said that a good ROS design philosophy is to communicate with ROS in just one section of your executable.

A good reason to use multiple nodes would be if you're mixing Python/C++.

Anyway, that's a mechanical-engineer-turned-programmer's take.