0
$\begingroup$

Rosanswers logo

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.
  1. (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 !


Originally posted by malharjajoo on ROS Answers with karma: 121 on 2018-03-31

Post score: 2

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

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.


Originally posted by fergs with karma: 13902 on 2018-03-31

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by gvdhoorn on 2018-04-01:\

extra computation to serialized data back and forth between the nodes

Would be good to mention nodelets here.

Comment by malharjajoo on 2018-04-01:
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 (?)

Comment by malharjajoo on 2018-04-01:
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)

Comment by fergs on 2018-04-01:
@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.

Comment by gvdhoorn on 2018-04-02:
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.

$\endgroup$
0
$\begingroup$

Rosanswers logo

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.


Originally posted by AndyZe with karma: 2331 on 2018-03-31

This answer was NOT ACCEPTED on the original site

Post score: 3


Original comments

Comment by gvdhoorn on 2018-04-01:\

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.

Comment by gvdhoorn on 2018-04-01:\

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.

Comment by gvdhoorn on 2018-04-01:\

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

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.