2010 FRC camera vision tracking delay, image processing lag

[Zme]

i have done it, it worked out ok only problem is the other code ran a little to fast for it too keep up(was using the syncronized object and it took over the var's and never released them), you also have to be careful about data access still have a couple of the really ugly "Fatal Task Level Exceptions" i have yet to track down and kill with fire. i will see if i can get code up later on. please note that the documentation isn't exactly clear on this, the function that you want to make into a task must NOT be part of a class, or atleast in my experience it has gotten rather mad if it is. and also when you give it the function it is withOUT ()'s
here is code for spawning a new task: Task <name>("taskname",(FUNCPTR)(functionname));

don't do this:
Task <name>("taskname",(FUNCPTR)(functionname()));

[Zme]

as for semaphore etc use a synchronized object, it makes thing rather easy to protect critical areas.
you do still have to declare a semaphore object though

Synchronized sync(<semaphore name>);

[Greg McKaskle]

I wasn't sure about C/C++ image processing. The LV code runs in an independent loop, its version of the task, and that seems to be the better way to go. No matter what you do, you will not get the image processing to run at 50Hz.

As for the performance in general, a white paper was posted on ni.com that discusses some tuning and performance issues. By the way, I suspect the arcs are drawn around the targets on the dashboard, not on the cRIO. At least that is the way it is done for LV.

If you have questions the white paper doesn't answer, fire away.

Greg McKaskle

[Zme]

that is a correct assumption, the dashboard draws the arcs.
I have a random question, is there a maximum number of tasks I can start on the cRIO before it freaks out?

[pspeer]

I've read that the maximum number of tasks is limited only by the amount of memory installed on the cRio. Since the cRio is running an embedded operating system, my guess is that very bad things happen once the memory is full.

[Greg McKaskle]

That would depend on the task being created. Each task allocates a stack and some other memory. My guess is that a hundred is fine and should be enough.
I'm pretty sure that LV allocates dozens.

If you have other needs, please post.
Greg McKaskle

[slavik262]

On the topic of multithreading, I've done lots of work with multiple threaded programs (both on Windows and VxWorks. Our robot last year ran on 5 different threads). It's not that hard once you get a good grip on how to use semaphores. Send me a PM and I'd be more than happy to help you.

On another note,

Originally Posted by Greg McKaskle

By the way, I suspect the arcs are drawn around the targets on the dashboard, not on the cRIO. At least that is the way it is done for LV.

So the dashboard automatically draws arcs on the targets? Do you need to provide additional information to the dashboard for this to happen?

[Dave Scheck]

Originally Posted by slavik262

So the dashboard automatically draws arcs on the targets? Do you need to provide additional information to the dashboard for this to happen?

If you look at the default dashboard program, there is a block at the top that uses the high priority packet to process vision information. It is responsible for displaying the current image and any overlays based on the target information in the packet.

[slavik262]

Originally Posted by Dave Scheck

If you look at the default dashboard program...

The robot code or the LabVIEW files for the dashboard itself?

[Dave Scheck]

I was referring to the labview dashboard. The robot code needs to populate the packets to match what the dashboard side is expecting, otherwise you get the dreaded data type mismatch error when running the dashboard.

If you open up the default robot-side dashboard demo, you'll see where the vision data gets packed up (we use C++, but the Labview side does the same thing). If you compare that to the high priority packet format on the dashboard side, you'll see how it matches. You can then trace the wires up and to the right to get to the vision block to see how the overlay is done.

[Greg McKaskle]

You may already have what you need, but I was pretty sure the sample code for C++ and Java sent the data to the dashboard.

Greg McKaskle

[pspeer]

Our team is working with C++ using the WindRiver workbench (not labview) and data is already correctly sent back to the driverstation (data packing is not an issue).

Specifically our issue is the amout of time the tracking function takes to execute, we want it placed in it's own thread.


We need C++ help with:

(1) Creating a new VxWorks task
(to separate vision processing into its own task)

(2) Creating a shared global variable using semaphores
(to pass "target array" information back to the main OperatorControl loop)


Sorry for the confusion, I will post sample code later tonight to illustrate this concept.

[slavik262]

Since my explanation is pretty thorough and has little to do specifically with camera code, I've posted it here:

http://www.chiefdelphi.com/forums/sh...ad.php?t=82398

Share and enjoy.

[charrisTTI]

We are using latest udpates and programming in java. When testing tracking yesterday, we observed that the response time of the robot to the movement of the target got worse, the longer the program ran. After bootup, tracking response and image update were excellent. The more tracking cycles that were initiated, the worse the performance got; to the point where the robot would no longer track. On the drivers station we could see that the target was being tracked but with a significant delay as indicated by when the "locked on" circles were drawns around the target.

[gvarndell]

Originally Posted by charrisTTI

We are using latest udpates and programming in java.

Piggy-backing on an existing C++ thread, when you're using Java, even though the problem you're asking about is similar, is not likely to get you the help you need.
Consider posting to the Java sub-forum instead?