We have managed to get the camera feed on to the netbook, and we have noticed that its framerate is VERY low. We know its not the camera because when we view it using its IP adress, it displays at a regular frame rate. Is there anything we can do to speed it up?
This is a bit of a silly solution, but our Team, team 3006 logged into the developer account on the Classmate, and loaded the Dashboard. When you open up the Dashboard in the Developer state, it opens it as two windows, as long as you keep the lower window, the one with diagnostics, setup, etc., selected, then the frame rate is great.
If someone has a smart solution to this, please respond
This is something I picked up on last year…
Lower the resolution for the camera. It’s able to have a better throughput through all the stuff it has to go through before showing up on the screen.
Quality won’t be as great, but it did work last year.
If you are using C++, there is an AxisCamera class member function called writeCompression that should allow you to set the level of compression. I’m not sure what value it takes though…it could either be 0 to 100 or 0 to 1 (or something else). The function takes an integer. Does anyone know what values are legal?
- Bryce
why would a value NOT be leagal? the best compression range is 20-80
Legal as in game legal? I haven’t seen any rules prohibiting compression of the data from the source (Camera) and then uncompressing it at the target (classmate).
Legal as in compression legal? 0 to 100 (It’s a percentage). With black and white images you should be able to compress upwards of 90 and still have a definable edge to track on.
Remember that MJPEG is a lossy and any compression loses some of the crispness of the picture. You should test your compression to ensure that it does not affect your tracking (in different lighting as well).
I think he means legal software-wise, not Game-Manual-wise
:yikes: Yes, legal software-wise. For instance, if the camera is looking to receive a value between 1 and 100 then 200 would not be a legal value. If the code was not written with the proper error checking who knows what would happen.::ouch:: Apparently legal was not the best term to use when dealing with a game with so many rules.
I would assume that because the GUI interface for the camera allows a setting between 1 and 100 that the writeCompression function would also use these values.
- Bryce
our resolution is at the lowest we can get it. I will try Delians idea.
I think that Delian’s idea might be a quick solution, but it’s probably not legal during competition.
- Bryce
From posts on other threads, it seem that some teams are using Fast User Switch to run both the developer and driver accounts. Running the tools and the DS in the different accounts seems to have slow screen updates.
A better approach seems to be to run all of the programs under the developer account. Run the dev tool and then run the driver station from the Start menu.
Greg McKaskle