Threading on the CRIO

[dpeterson3]

Is it possible to do threading on the CRIO. It is a powerPC processor, so I know the processor can handle it. I want to be able to run a targeting system along side the drive system so the bot can be ligning up shots while we are driving around. If there is no way to tell the camera to pan in a seperate thread, is there a way to simulate this behavior?

[Kevin Sevcik]

Labview by design will thread programs. Loops/code that are programmatically separate will automatically be launched in separate threads. That is, if there's no data flow restrictions forcing one loop or bit of code to operate after another, they'll be in separate threads.

The Windriver environment also supports threading via the Task class released in the latest update from WPI.

[nathanww]

Are you using labview or C++? As I understand, the "dataflow execution" model in labview means that to do multithreading you just make two dataflow things and don't connect them. In c++, it's a bit more complicated, but I think the "programming user's guide" has some stuff on how to do it.


For what you're talking about, however, you don't even really need to use all the fancy multithreading features. Instead, you can just set up a loop in your program like:


1.Get data from DS
2.Make whatever calculations you need for traction control, etc
3.Set your speed controllers
4.Get and analyze data from the camera
5.Set your panning servos
6.Repeat

[dpeterson3]

Cool. I know we couldn't do this in years past. I just want to be sure we don't drag down the processor with image processing while trying to drive. I want responsive driver controls while the bot helps us get lined up for shots. I think it could really improve accuracy.

[wireties]

The operating system running on the cRIO (Wind Rivers VxWorks) is multi-threaded and does pre-emptive priority-based scheduling. You can do exactly what you want. You can start as many threads as you want (till you run out of memory).

VxWorks supports something like processes in Linux (called RTPs in VxWorks) and something like threads in Linux (called tasks in VxWorks). There is a kernel context and any number of RTPs running at one time. Each RTP or the kernel can have any number of tasks running. The operation system schedules tasks, not RTPs (also like Linux).

But looking at the default code I see no evidence that RTPs are being used. It looks like everything is being run in multiple tasks in the kernel context. It is possible the kernels that WPI and NI have built for us do not have support for RTPs included (but they could have been).


HTH