Camera lag solution

[ringo115]

So our camera has about a 5 second lag in its response to something going in front of it. Is there any way of reducing the lag, The increasing resolution and lowering compression didnt work, is there any other way of fixing it?

[reversed_rocker]

i had the exact same problem, try logging into the developer mode on the drive statino netbook and open up the driver station program (there are icons for it on the desktop) as soon as i did that, the camera ran much much much much much faster. we're talking from a 2 second lag time to close to real time, probly doubled the frame rate as well. as to why this is, i have no idea. i hope its not like this during the competition.

[reversed_rocker]

ok, slight modification. You know how if you have multiple tabs open in windows xp you click on the taskbar on the one you want to be on top? well open up both the FRC Driver Station and the FRC Dashboard, then select the FRC Driver Station tab on the task bar. dont know why, but this magically makes the camera faster. as soon as you click on the dashboard tab on the task bar, the camera lags up again

[Greg McKaskle]

After a bit of testing, here is my observation.

The big lag is not caused by any specific window ordering, but occurs when the dashboard computer cannot keep up with the cRIO. If you time the rate at which the cRIO sends the images and modify things like which windows are open and which windows are updating, you can sometimes cause the PC to process the images more slowly than they are being sent.

When more images are coming in than are being processed, the excess quickly creates a delay between real world and what you see on the screen. When the buffer is full, the images are dropped, and you will also see some jumpiness as some images are missing.

At this point, I'm still diagnosing the sorts of things that can contribute to this to see what we should change, but in general, if you have your dev environment, dashboard, and driver station all on a single computer, say a small laptop, this may happen sometimes. From what I've seen, minimizing the dev windows is often enough to correct it, and when you aren't running the dev tools at all, it will be even less of an issue.

Greg McKaksle

[Ryan Gordon]

Im just fishing here, but would that lag not happen if you open up Task Manager, nagivate to the Processes tab, and set the dashboard process priority to High / Above Normal / Realtime?

[bobwrit]

Originally Posted by Ryan Gordon

Im just fishing here, but would that lag not happen if you open up Task Manager, nagivate to the Processes tab, and set the dashboard process priority to High / Above Normal / Realtime?

We tried this today and it definitely helped a lot. We brought our lag down from ~1 second to like... ~.2 seconds.

[Greg McKaskle]

If the CPU has too many things to do, a line forms and the CPU deals with things one, or depending on architecture, a few things at a time. Priorities are where you give one task cuts in line. Some tasks are left at the back of the line watching other tasks cut over and over again.

If not used carefully, priorities will mean that some tasks will get starved out and will never get any time on the CPU. In particular, I don't think the dashboard should be higher priority than the development tools or the driver station. There is nothing stopping you from setting your own priorities, and I don't think the system will be dangerous if you play with priorities, but if it acts oddly and won't do what you want, put them back to defaults before deciding things are broken.

In most cases, the best way to deal with an overloaded CPU is to figure out how to do less work or do the work more efficiently. Again, this is very different from setting priorities.

Greg McKaskle

[Mike Mahar]

OK, our video lag is about 5 seconds and the frame rate is about 0.5 seconds. We are running the dashboard on the classmate while logged in under the Driver account. The developer account is not logged in. Our picture size is 160x120. I set the classmate power features to "always on". We are usgin C++

One thing that might be different from other code is that we are running with the Default code instead of the simpleRobot code or VisionDemo.

I tried running everything under the developer account but saw no difference either. The connection to the robot is hard wired 100baseT.

Fortunately, our application this year does not require streaming video and I haven't measured the frame rate internally to the robot for the ellipse matching routines yet.

[Radical Pi]

Our delay was fixed by removing the graphs on the right side of the dashboard. Our fixed dashboard is uploaded in http://www.chiefdelphi.com/forums/sh...ad.php?t=81378

[ideasrule]

Originally Posted by Mike Mahar

OK, our video lag is about 5 seconds and the frame rate is about 0.5 seconds. We are running the dashboard on the classmate while logged in under the Driver account. The developer account is not logged in. Our picture size is 160x120. I set the classmate power features to "always on".

Try logging in to the camera and setting it to the best possible settings (640x480 resolution, 0 compression, automatic exposure and white balance, etc). For us, this reduced the lag time from 5 seconds to half a second.

Now for the half-second delay...I created another thread just before I saw this one, so I'll be following the suggestions in this thread.

[Greg McKaskle]

I've seen very bad performance when setting compression to 0. Are you sure that is what it is set to?

Greg McKaskle

[ideasrule]

Originally Posted by Greg McKaskle

I've seen very bad performance when setting compression to 0. Are you sure that is what it is set to?

Greg McKaskle

Yes, 0% compression was sufficient to guarantee a delay no longer than half a second on 640x480. During that one day when we got a reasonably high frame rate, we had the resolution set as 320x240 and the compression set as 0%. I tried increasing the compression to 30%, but that made no appreciable difference.