Multi-Threading the TROM

[Alex]

Please review this thread (http://forums.trossenrobotics.com/showthread.php?t=1686&page=3) for a short background on this topic.

Back when I developed the TROM I always wanted to add multi-threading capabilities into it, but threading was a bit over my head at the time and we ran out of development time before I could really research how it would fit in. Now that the TRS development is back up and running and we have a ton of incredibly intelligent people working on it, I would like to bring up this topic up for discusion.

Please bear with my use of words here if I'm incorrect with the way that I worded something because I'm a little out of my league here.

I think concurrency could be very useful when building robotic systems with the TRS. In order for us to run multiple processes at the same time and take advantage of new multi-core processors coming out we need to add multi-threading capabilities to the TROM.

Agree? Disagree? Does it need to be added sooner rather than later? I want to hear everyone's thoughts on this topic:)

[Adrenalynn]

From the simple perspective - it's already parallelized - or would be if the build environment were configured in the way I envision.

TROM = process/thread
SCL (for example) = process/thread
Message passer = process/thread
Renderer = already multi-threaded
XML generator/parsers = process/thread
[...]

How many processors ya got? ;)

If one takes into account the way a modern OS plays, one can let the OS do the lion's share of the work.

[Sienna]

I agree, get the protocol right and multithreading will be as simple as running all the different processes on the same box.

Now, there is a different issue if you want to talk about putting threads inside any individual part (which is smart if you have things that get I/O bound or whatnot)

[metaform3d]

I think threading is essential. My first robotics program, which was to control animatronics for Halloween, I wrote as a single thread with multiple behaviors mutiplexing themselves over time in the same main loop. The very second thing I wrote I took the effort to create thread-safe message passing and it was *so* much easier to get the logic right.

Imagine, for example, that you are creating a two-wheeled balancing bot. What you need is tight closed-loop control over the motors to cancel out tipping detected by the accelerometer. You also want to be able to give it commands to tip it more forward or backward for movement, or to drive the wheels at different speeds. The traditional way would be to program a microcontroller to handle the closed-loop feedback and use a serial connection to send it commands.

With the power of a Pentium behind your robot, however, you can imagine spinning off the balancing task as a separate thread. It becomes essentially a "software coprocessor." You can still send it commands and receive data back at a relatively low rate, but the tight control loop can be written and debugged independently. It's closer in software to how you would factor the problem in hardware.

[Alex]

Now, there is a different issue if you want to talk about putting threads inside any individual part (which is smart if you have things that get I/O bound or whatnot)Yes, that's exactly what I meant. Sorry, sometimes my brain gets a little full and I can't get my words out correctly sometimes;)

Matt always says to people you just have to learn [the language of] "Alex" .