Today’s topic:
Using the Camera to provide a remote set of eyes…
Using the camera to auto aim is just not in the cards for Schodinger’s Cat this year (read **"][DFTF] The Classic Blunder…](http://www.chiefdelphi.com/forums/showthread.php?t=103085&highlight=[DFTF) [/b]to learn that our robot, The Rook, is lucky to have a ball handler at all).
BUT… …we may be able to manage mounting the kit camera on The Rook’s beefy arm to
help us see if we are lined up with the basket or
see if a ball is lurking twixted The Rook and the dark side of a bridge or
get a close up view of the sweat beading up on the foreheads of our opponents
…
Frankly, I am scared to death to do it. Not that it wouldn’t be helpful but that it will screw something else up in the process (Why won’t our robot respond Scottie? It’s that video feed, Capt., it’s eating our bandwidth like I eat haggis on Burns Night …
So… …tell me all. Can we safely use the Kit Camera as a remote set of eyes for our drivers?
Yes. Just configure the camera for your team’s address, mount it (keep it electrically isolated from the robot frame) give it 5V power, and plug its network connection in to the DAP. It’s that easy.
We started the season working on auto aiming for the camera and got it to work well but in the two weeks of practice we have found that our driver can aim using the camera much faster and just as accurately as the auto function.
We commented out all of the auto aiming code.
I have spoken with another team with much more programming resources than ours and they have discovered the same thing.
Hit the nail on the head. We are using 2 camera’s, one for alignment for our shooter and another for our ball intake/bridge pusher. We power both off the 5V Wago supply using a terminal strip.
We have had no problems with lag/dropped packets or any other communication issues, I believe our video resolution on each camera is set to 640x480 in the camera f/w. The default dashboard works fine for 1 camera. Since we use 2 camera’s we modified our dashboard (along with some other info). Here is a linkto our Google Code repository, which includes the Dashboard project
>2012 Game Robot>Program>Dashboard
Last year, our classmate couldn’t display images at 320x240 30fps without pegging the classmate processor and causing occasional control lag. We changed it to 10fps and it worked well. I saw several people saying they did the same thing this year.
If you are using another driver station computer, that shouldn’t be an issue.
Right, same here, forgot to mention it. We are using a newer laptop with 4 GB RAM, 17"? screen and running Windows 7. We needed the screen size for both cameras, plus the Kinect software was super slow running on our original Classmate.
If your concerned about bandwidth, you can fairly easily reduce the framerate and resolution of the camera.
We’re using a netbook about the equivalent to the classmate and it works fine at 320x240 10fps (IIRC).
Regarding the auto aim, I was amazed to see how well our drivers were able to line up manually (we had some issues with our wifi bridge yesterday, so thats all we had). For our autoaim, I included a safeguard that prevented the operator from firing until we had a lock OR until he pressed a second button (as an override). We still have all our camera code in, but it’s barely been used.
15 FPS is good @ 320*240 on the wee DS, really no lag whatsoever. Kinect is a diff story/problem/solution that doesn’t belong here.
Just verify which camera you are using, the old 206 needs some monkeying w/ Dashboard AND Robot code that is automatically configured for the newer 1011.
As for mounting, make sure it is on something that is strong but gives just a little. IE 2405 (that’s us!) good piece of thick plexi (not thin lexan) running across front of our boxy frame, with a tapped hole in the middle for the screw on the back of the camera. Screw it on, connect wires, check lens focus on it. If neccessary, tape down the spinny thing if the vibrations from the shoooter are so violent that the drivers are “flying blind” after Auto.
