If the CMUCam documentation is correct, it'll go about 3 FPS faster than the CBC webcam even including our exposure adjustment (17 fps vs 13 fps or so), but frame rate increase is mostly irrelevant when compared to the return of near real-time imaging. We spent hours trying to fight the latency of the CBCCam, and our only solution was tracking very very slowly. Maybe we just missed a simpler/better solution, but from what I can tell many just took still frames after sleeping to let the latency catch up, and not tracking while in motion like we attempted (and mostly failed).
Now I will admit to not having used the CMUCam, but what did you hate about it Jeremy? It looks to me to have more features than even the XBCCam, albeit at a lower frame rate and less resolution (you can query subsections of the image, for instance, which could be very useful in some circumstances) I guess calibration is potentially difficult since you need to hook it up to a PC, but because the CMUCam lets you adjust tracking colors in software unlike the CBCCam, it seems like an auto-calibration program wouldn't be terribly hard to implement, which would ultimately be a better solution than just tweaking the color models at the start of the match by hand. Is the image quality poor?
--
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction.
I actually tried a script that catted /dev/video0 to /tmp, to see what would happen. I found that I got garbage, which Jorge tells me may be due to the USB drivers not liking the high resolution (I was using 640*480). I believe that the latency is inherent to the Linux camera driver, because the PC Linux driver has the same behavior. Rumor has it that Jorge may be working on improving that driver.
One of these days, I'll try disabling color tracking in the firmware, and just make it output an image into /tmp, and see whether the performance increases. I suspect that the latency won't be much better, although I expect the frame rate to increase a bit (not that a higher framerate is particularly useful; 12fps using the existing hacks is already perfectly usable).
-Jeremy Rand
Senior Programmer, Team SNARC (2012-2013), Norman Advanced (2010-2011), Norman HS (2008-2009), Norman North (2005-2007), Whittier MS (2003-2004)
2012-2013 VP of Tech, 2011 President, Botball YAC (2009-2013)
Mentor, Alcott and Whittier MS
If the CMUCam documentation is correct, it'll go about 3 FPS faster than the CBC webcam even including our exposure adjustment (17 fps vs 13 fps or so), but frame rate increase is mostly irrelevant when compared to the return of near real-time imaging. We spent hours trying to fight the latency of the CBCCam, and our only solution was tracking very very slowly. Maybe we just missed a simpler/better solution, but from what I can tell many just took still frames after sleeping to let the latency catch up, and not tracking while in motion like we attempted (and mostly failed).
Now I will admit to not having used the CMUCam, but what did you hate about it Jeremy? It looks to me to have more features than even the XBCCam, albeit at a lower frame rate and less resolution (you can query subsections of the image, for instance, which could be very useful in some circumstances) I guess calibration is potentially difficult since you need to hook it up to a PC, but because the CMUCam lets you adjust tracking colors in software unlike the CBCCam, it seems like an auto-calibration program wouldn't be terribly hard to implement, which would ultimately be a better solution than just tweaking the color models at the start of the match by hand. Is the image quality poor?
--
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction.
Albert Einstein
Project Quadcopter: http://quadcopter.wordpress.com/
Does anyone know the angle of the viewing lens?
Just throwing an idea out there for a workaround, but perhaps a script to snapshot the camera to the linux /tmp dir, and then do what it needs to?
Hi Jonathan,
I actually tried a script that catted /dev/video0 to /tmp, to see what would happen. I found that I got garbage, which Jorge tells me may be due to the USB drivers not liking the high resolution (I was using 640*480). I believe that the latency is inherent to the Linux camera driver, because the PC Linux driver has the same behavior. Rumor has it that Jorge may be working on improving that driver.
One of these days, I'll try disabling color tracking in the firmware, and just make it output an image into /tmp, and see whether the performance increases. I suspect that the latency won't be much better, although I expect the frame rate to increase a bit (not that a higher framerate is particularly useful; 12fps using the existing hacks is already perfectly usable).
-Jeremy Rand
Senior Programmer, Team SNARC (2012-2013), Norman Advanced (2010-2011), Norman HS (2008-2009), Norman North (2005-2007), Whittier MS (2003-2004)
2012-2013 VP of Tech, 2011 President, Botball YAC (2009-2013)
Mentor, Alcott and Whittier MS