We managed to get the live feed working, the only problem being that it isn’t live. At first, with the camera set to low resolution and a moderate amount of compression, there was around 5 seconds of lag (and a similar frame rate). Then Patrick logged into the camera, did something, and the lag magically became 0.5 s with a 2Hz frame rate. The following conversation ensued:
Me: What did you do?
Patrick: I changed it to all the best settings. (640x480, 0 compression, etc)
Me: And then it worked.
Patrick: Right.
We tried everything to try and reduce the lag to something acceptable. Decreasing resolution and increasing compression both increased lag time, while changing the exposure/white balance settings did nothing. We did install the Labview update, the DS update, and all of that. We did create a FRC/FRC account. We did image the cRIO with v19.
Reducing compression reduces load on the processor.
Smaller frame size means less data to fit through that (relatively) tiny pipeline
Fewer frames per second also means less data. 2 Hz is 2 frames per second, 1/2 second lag is the best you can get at that frame rate.
I thought so too, but decreasing frame size increased lag time.
Fewer frames per second also means less data. 2 Hz is 2 frames per second, 1/2 second lag is the best you can get at that frame rate.
I know that, but I want to both reduce lag and increase frame rate, not one or the other. (I didn’t manually set the frame rate; I let the camera do that.)
The DS is the Classmate, but tomorrow we’ll try using another laptop as the DS and see how that works. As for development tools, we’re using Java with Netbeans 6.8 on a separate laptop. I just press the “Run” button to run the code; as far as I know, that builds the project, deploys the code, reboots the cRIO, and listens for output from the cRIO.
Try going to control panels, power options and set the laptop to “Always On”. This will ensure the processor is running at 1.6GHz when plugged in. The factory pre-load has it set on Max Battery which causes reduced performance even when plugged in.
Setting battery options to “Always On”.
Running the driver station software under the Developer account.
Running the software with the Dashboard selected.
Logging on to only one account at a time.
Using a laptop as the driver station.
Setting the camera’s frame rate to 5 frames/sec.
None of the above had an appreciable effect on the lag. Help!
Well, we found a problem. We had been using the driver account on the ClassMate as the driver station, silly us, of course it’s not designed for that exact purpose. When we logged off the driver account and switched to the developer account, the frame rate jumped up by a factor of ten or twenty (on 320x240 resolution), and the lag all but disappeared. What worries us now is we don’t know whether this will be allowed at the competition (looked through the competition documents). Does anyone else have this problem and/or have a solution, or know if the Developer account will be allowed for use at the competition?
The story behind this is interesting. Patrick suggested using the developer account to test the camera feed. By chance, I was busy doing something and couldn’t tell him he was being stupid because I’d already tried that (which I did). By chance, I had changed the image resolution from 640x480 to 320x240. Against all odds, these two unlikely events happened at the same time and led to our strange discovery. (I changed the resolution back to 640x480 and the lag time became the familiar 1/2 s.)
Another possibly useful piece of info is that I was using the code to test the frame rate by measuring the time it took to get 300 fresh images. We got 5 fps on 640x480, 21 fps on 320x240, and 30 fps on 160x120. However, the live feed was certainly not operating at 5 fps at a resolution of 640x480, regardless of the account used. It always operated at 2 fps.
We can confirm the behaviour that 610 is seeing. We get about 2 fps on the DS display, but there is a delay on top of that. The frames update at 2fps, but the frames we see are also more than 1s in the past. We notice this poor performance in the Driver account, even with 160x120 resolution frames.
Strangely, increasing the resolution does not seem to slow the framerates on the DS. In some cases the DS display updated faster on 640x480 than on 160x120.
However, the rate in which the cRIO processed the image was considerably faster with the small resolution.
I found the problem to be the graphs on the right side of the dashboard were causing a huge delay. I removed them and we now get near instant video (minus expected network latency). Our fixed dashboard is here http://www.chiefdelphi.com/forums/showthread.php?t=81378
/\ is our solution. The graphs on the right side of the Dashboard were lagging the image considerably so we took them out of the Dashboard and the image is very fast now (only the expected network latency). The fixed Dashboard is attached
What do you guys mean by “logging into the camera?” Is it the Axis Camera setup? Or are we talking about logging in by navigating to its IP address (and what would that be if this is the case)?