2010 FRC camera vision tracking delay, image processing lag

[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?