Multithreading vs ROS nodes

asked 2018-03-31 14:22:36 -0600

malharjajoo
121 ●23 ●31 ●37

updated 2018-03-31 14:52:16 -0600

Hi,

My Background: I am currently working on a project involving (Parrot A.R.) drone navigation. I require state estimation and controller module.

Assuming the state estimator and controller are perfectly implemented, I am currently in a dilemma choosing between 2 approaches that I can think of -

1) Solution 1: This solution is known (or) has been implemented by someone

Use C++ multithreading and run 1 loop separately in each of (a total of) 2 threads**.

StateEstimator Loop: This loop provides state estimate and fills in a Thread safe queue.
Controller Loop: This loop accesses state estimates from the queue and sends navigation controls to the drone.

2) (Possible) Solution 2: Use a ROS node for each, state estimator node provides state estimate (using topics) while the other controller node uses it to send control signals to the drone.

===============

My Question/Dilemma: The second approach sounds easier to implement than the first. But I'm aware that ROS nodes run as processes while the other approach uses threads. I am not sure if the second one might work, and also how the process scheduling etc may affect my results ...

I am looking for some advice from people's personal experience with ROS and/or drone projects,

Thank you very much !

edit retag flag offensive close merge delete

add a comment

2

answered 2018-03-31 21:37:46 -0600

fergs

13902 ●59 ●157 ●196 http://www.robotandchisel.com

updated 2018-03-31 21:38:35 -0600

If the two components are tightly coupled, and need to do a lot of back and forth between them (which needs some scheduling/handshaking), then a single node is probably the way to go. If the two components really are separate, then separate nodes may be advantageous. No matter how "thread safe" something starts off, it's only a few commits away from breaking that contract.

Splitting things into multiple nodes will certainly incur an overhead - this mainly comes in the form of extra computation to serialized data back and forth between the nodes, and depends mainly on how big the data is that has to be shared. If you're dealing with high-resolution images, avoiding serialization is good. If you're dealing with a few small bytes, it may not matter.

One of the big strengths of multiple nodes is that multiple people could work on a project at once (each on separate nodes). One other strength might be if it takes a long time to setup one component (for instance, your state estimator), you can leave that portion of the system running while restarting the other component you are still developing/debugging.

edit flag offensive delete link

Comments

2

extra computation to serialized data back and forth between the nodes

Would be good to mention nodelets here.

gvdhoorn ( 2018-04-01 01:44:06 -0600 )edit

Thanks for the answer @fergs, has helped me a bit more in understanding the overhead. My use-case (as mentioned in question) involves access to state estimate by the controller ( It's a closed feedback loop ) so I assume that it's tightly coupled ... and hence multithreading is the way to go (?)

malharjajoo ( 2018-04-01 10:43:29 -0600 )edit

Hi, @gvdhoom, that is a nice suggestion ... I've seen it being used in the stereo_image_proc node .. unfortunately I'm not sure if I have the expertise for managing nodelets (I am sort of a beginner in ROS)

malharjajoo ( 2018-04-01 10:45:02 -0600 )edit

@gvdhoorn -- while nodelets can certainly help with computation, and might be a route to go after you have a fully functioning system, I personally never recommend them for upfront use due to the mess it usually creates for debugging.

fergs ( 2018-04-01 19:49:37 -0600 )edit

I know, but I do feel it would be good to mention it (that's not recommending). You used "overhead - this mainly comes in the form of extra computation to serialise data back and forth between nodes" as an argument against nodes. Nodelets would seem to address that specifically.

gvdhoorn ( 2018-04-02 01:26:10 -0600 )edit

add a comment

3

answered 2018-03-31 22:37:43 -0600

AndyZe

2331 ●38 ●106 ●70

updated 2018-03-31 22:56:25 -0600

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

edit flag offensive delete link

Comments

1

I could mouse over [..] a variable name and [..] IDE would tell me exactly where that variable was defined.

Not discounting your experience, but this would seem to be mostly an IDE/tool setup issue, not something that is inherent to multiple / single node.

gvdhoorn ( 2018-04-01 01:45:29 -0600 )edit

Synchronizing the timing between the various nodes

Similar to @fergs answer, it might be good to mention / look into nodelets here. Nodelets could be considered mutlithreaded nodes, but keep all the advantages of seperation of concerns, testability, reusability, transparency, etc.

gvdhoorn ( 2018-04-01 01:46:40 -0600 )edit

I think modularity is easy with multiple ROS nodes but you can do the same thing with classes

Components vs objects: one big advantage of components is that applications can be created via configuration alone. That is impossible with classes (compilation always involved).

gvdhoorn ( 2018-04-01 01:48:04 -0600 )edit

add a comment

Multithreading vs ROS nodes

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Multithreading vs ROS nodes edit

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Multithreading vs ROS nodes