The *BIG* CMU Howto

Because many people come here before reading the manual and the manual can be cryptic at some times I’ve decided to write this howto.

The Case/Assembly

The case is made out of a Radio Shack 4x2x1 Enclosure (#270-1802) in which the control board fits nicely into. The assembly suggested in the manual uses Robovation (aka EDUBot) parts to create a static tilt(w/o a servo) system. The exploded assembly drawing in the manual is either in correct or we missed something but we added a part to make it easier (See the picture below).

http://jakesnake.no-ip.org/robotics/MODASSY.JPG

To create a dynamic tilt, the design can be modified slightly to accommodate a servo on the side.

It is also a BIG help to not mount any of the camera parts inside the case until you’ve finished everything else. It ends up getting in the way and you have to take it out.

Connectors

Most of the pin headers are marked with a capital letter ‘B’. This marks where the black wire should go. On the DB9 serial port, only pins 1, 3, and 4 are used.

Power

The camera requires 7.2v of power. This is supplied by a PWM port, by the “backup battery”. It works on both the EDUBot and the Full-size FRC.

Image

The image can be grabbed with either the GUI included with the camera docs, or by using the SF command* in a terminal window.

The image can be modified/fine tuned in a number of ways. First is the focus. To focus it there are two good ways. The first and harder way is to turn the lens a half turn and grab the image. If it gets better keep turning in that direction and grabbing the frame until its the best quality. If it doesn’t get better turn it the other way until it gets good. Don’t take the lens completely off. There is a sensitive CCD that I wouldn’t want to get dust on or anything else…

The better and faster way is through NTSC output. Follow the directions below to get the NTSC working, hook it up to your television and easily focus it.

*The SF command will return an unrecognizable string of characters that is in a format that should easily be able to be translated into an image.

NTSC

The CMU CAM comes with the ability to output a black and white NTSC signal to your television. It requires hooking up the header on the board to an RCA jack. In order for it to start outputting, the camera must be set into YCrCb.

The first method is to set it through the GUI. Simply move over to the config tab and set the color space to YCrCb.

To set it manually in a terminal window you must set register 18 to a value below with the following syntax:

cr 18 <val>

Values:
RGB w/o White Balance - 40
RGB w/ White Balance - 44
YCrCb w/o White Balance - 32
YCrCb w/ White Balance - 36

If you don’t have a TV near by. unplug it from the serial port and without unpowering it plug it into a TV. (Supposedly the registers are supposed to save, even when unpowered, but it hasn’t worked for me.)

Note: To those not in the US, your TV might not support NTSC. If it has a “Multi-System” feature on the box or in the manual you should be fine.

Serial

The camera must be connected to a serial port to be commanded (but no necessarily functional, see Demo Mode Below). Either the DB9 port or the 3-pin header will work. To use the DB9, you can connect it to either your computer through a COM port:

Default settings (to change see below):
115200
8 Data bits
No parity
1 Stop bit
No flow control

or, you can connect it to the program port on the RC.

If your computer cannot support 115200 (for any reason) or you’re connecting it to the RC (I think this does require a lower bitrate…?) you can try a lower bit rate by setting the jumpers on the board:

Pin
0 1 2 (These are the 3 right most jumper pins on the mode settings, refer to the manual for specific location)
_ _ _ 115,200 Baud
_ _ X 57,600 Baud
_ X _ 38,400 Baud
_ X X 19,200 Baud
X _ _ 9,600 Baud
X _ X 4,800 Baud
X X _ 2,400 Baud
X X X 1,200 Baud

X = Jumped

Demo Mode

The CMU CAM comes with a demo mode to autonomously track a given color. Hold down the user button while powering the cam and holding a colored piece of paper in front of the lens (8~12in) (very trick to do by yourself, get someone to help) you should now be able to move the paper and have the cam track it. If it doesn’t work try the following:

-Make sure you’re in a well lit room.
-If the servos spaz or go in the wrong direction, they may need to be reversed. This can be done by jumping the pins on the mode headers. Try alternating between the pan and tilt reverse and see which one needs to be reversed.

Links

Very good CMUCAMresources:
http://www-2.cs.cmu.edu/~cmucam/cmucam2/
Official IFI CMU docs and code:


And of course:
http://kevin.org/frc/

Hopefully this will help a lot of people, but it might take a few edits to get it perfect. PLEASE post comments on anything that needs clarification or correcting.

Also don’t feel afraid of asking how to do various GUI commands in the terminal window, (esp. those who have slow machines w/o Java) I know a lot of them ;p

Edit tracker:
-Forgot to add the links to everywhere important
-Added some assembly notes and fixed the image

Nice Tutorial, that will be really usefull for our Team since we didn’t had any time yet to mess around with that Camera, Thank you! :slight_smile:

Wow Jake. I know you had been doing some research on the CMU cam but you sure have out done yourself this time. I think you need to include some more information as to the problems that you encountered while assembling the unit and edubot parts. Also a little biit more of explination on the programming aspect of this would help. Other than that great post and I’m glad your on our team!

I am hoping someone will put up some kind of "programming with the CMU cam tutorial. I am going to try to figure it out myself, but I wish the default code was better set up for use in autonomous, rather than just the joystick button stuff.

This tutorial is excellent.
You should put it in as a whitepaper.

Thanks!

My team has got a little technical problem: we know the measre unit of the x,y coordinates of the center of the mass of pixels on the “virtual picture” it sees, but we have no idea which measure unit is used by the servos- the “pan”, “tilt” values.
could you please add these to the manual?

Allright, our team has two rather big questions. Are there any specific rules regarding the case, and what is the correct way to mount the servos? I’ve been through USFirst and Innovation First, and I can’t find anything regarding actual rules. So, are we allowed to make our own custom cases? And, how exactly do we mount the servos? We’re frankly stumped. Everything we’ve tried is wrong. :ahh:

Any way works… you really only need a tilt servo, as you can just pan with the entire robot… but its probably better to have a pan servo too.

One problem I’ve run into a lot is the camera tracking very slowly, or not at all, which is always caused by a low backup battery.

I found this in another thread (CMU easter eggs). it is a little movie demonstrating what looks like the “Demo mode” described above. It is mounted with Pan and tilt servos. I’m planning on watching this little movie a dozen more times myself:

CMU cam demo mode movie

Is there a way to have the camera stream video onto a computer or a tv screen? By steam I mean live-feed, not clicking Grab Frame… Also is there a way to hook up a screen on the OI that can see the cam?

Both of my cameras out of the blue started showing very “odd” frames when I used the GUI interface to grab a frame. Has any one else seen this?





That happens to us too, clicking reset on the GUI fixes it

Yeah, we get weird frames all the time. Sometimes they have a purplish tint, some are like that one, and others are just other weird random nonsense. We press reset on the RC to “fix” it.

Having fun with the CMU cam yet?

Having lighting issues you need to resolve?

This may help:

http://www-2.cs.cmu.edu/~cmucam/Publications/lighting.pdf

On the screwy image…
I have never tried resetting the GUI, that’s not a bad idea though…
We always assumed that when that started happening, the backup battery was running low (IC’s do wierd things when voltage is out of spec, you know) and replacing the backup battery or putting it on a permanent supply got rid of it. Whether or not that came from restarting the camera or not, I have no idea, but it was our solution.
We actually had one heck of a time getting it to interface with the TTL port. For some reason, it wouldn’t complete the handshake properly, and we’d have to plug and unplug the thing to get it to work properly. There was probably just a coding glitch (blame the programmers!) but I wonder: did anyone else have that problem?

Sparks

One of the kids on our team became soo fed up with the sub-par CMU utility that he rewrote part of it. If you like, i can post it. It grabs frames from the camera and emulates it allowing you to see the effect of color windows immediately without actually changing them in the camera.

**I was just wondering if anyone has tried to use the camera with the VEX robot?

If you have and it didn’t work, save me the trouble and let me know. It would be appreciated!

:slight_smile: **

– Team 900

The CMU cam does work with Vex Use the RX and TX TTL ports for input, output and power.