Update, James has the CMUCam connected to the PC and has tested the focus and connectivity. Heβs absorbing the manual. The process has started. 
Awesome!!! I canβt wait to see how you guys do with it! Feel free to shoot me any questions you have if you get stuck.
One thing I forgot to mention in the first draft of the tutorial is that the reset button appears to βtoggleβ the camera working or not working. If you seem to get stuck when trying to communicate between the atom and the cam you need to hit resetβ¦it is a strange behavior but totally consistent. I actually see it as a feature most of the time since I can power up the robot and have him NOT track if I donβt want him to track and drive away.
With the new separate 6V supply we discussed I now have 2 power switches so I can also test tracking of the head without powering the wheels.
I will add the reset part in the next rev of the tutorial draftβ¦let me know how your project goes!
I have several other ideas for extentions to the X-Rover platform such as adding a front gripper and having Rover pick up the ball and return it to you as well as other nifty dog like tricksβ¦
Mark
Alan- I plan to get a CMUcam3 which also does face recognition that would open up for more interaction with X-Rover. Maybe Iβll add a SpeakJet when Jim gets them back in stock.
The CMUcam3 ships with CMUcam2 compatability mode standard so you can get one of those if you can afford it.
Mark
Thanks, thatβs just what Iβm finding out. May order one before the yearβs end (taxes).
Alan KM6VV
Can this be implemented on a tritrack also ? Iβm building a tritrack and it would be great if I could use this code for tracking.
I would think so, most if not all of the software for the tritrack is rover code. If I can find my old CMUCAm and it works I may try it out on my new tri-track
Kurt
Sure it could be used on a tri-trackβ¦should not be a problem at all.
One thing I should mention is that you will likely need to change a few of the tuning parameters in the code but Iβm hoping I made this an easy task by making all of the tuning paramters constants. I would be glad to help direct you to which paramaters to tweak once you have it built and describe the behavior.
The code itself would not need to be modified in structure in any way for use on a tri-track. The tutorial should also still apply for everything exept assembly.
I would sayβ¦go for it!
Iβm planning on a tri-track as well but need to make more progress on X-BRAT before I start another bot 
Mark
I figured since there are several people anxious to get going with either building an X-Rover or other CMUcam2 projects I figured I would embarass myself by posting a very rough unproofread draft of the tutorial I am writing for X-Rover. There should be plenty of good info here to help get people understanding how to use the CMUcam2 with the Atom Pro. Let me know what you think so farβ¦
Mark
Welcome to the X-Rover Autonomous Color Tracking Robot Tutorial
This tutorial will help you build your own X-Rover. In order to make your X-Rover perform as in the videos all you will need is to build the robot following the instructions in this tutorial and run the supplied code. Feel free to play with the numerous parameters in the code to affect his behavior. The default Robot code tracks RED objects under a wide range of lighting conditions however you can program him to track any color you want.
X-Rover uses a CMUcam2 which can be purchased here: add link
The CMUcam2 is used in conjunction with the BASIC Atom Pro for the vision system. The CMUcam2 has farm more capabilities then are being used in this tutorial so we encourage experimentation!
The basic principal of operation for X-Rover is a double nested mixer function. The CMUcam2 is mounted on a pan/tilt head. The camera is programmed to do color blob tracking and outputs the x and y coordinates of the centroid of whatever color it is tracking. You should print and read the CMUcam2 users manual here to become familiar with the basic camera operation. (link to CMUcam PDF here). This has proved to be the most stable way to track colored objects. Once the center of mass (centroid) of the tracked object is calculated the CMUcam2 outputs the data over a serial port which can be easily read by the Basic Atom Pro. The Basic Atom Pro then uses this information to move the pan/tilt head to keep the object you are tracking centered. This is done in both x and y. Once the object is centered, the robot then uses the position of the head to determine which way it should rotate and which way it needs to drive (forward or backward) to keep the object a fixed distance from the camera.
Since the robot does not have a distance sensor (you may add this yourself later) it uses the vertical tilt of the camera to infer the distance of the object. The current code keeps a 4 in tall whiffle ball about 6 inches in front of it. The one drawback to this scheme is that if you are trying to track a larger object the robot will Γ’β¬ΕthinkΓ’β¬Β it is farther away and then ram into it before backing up (See video here). Depending on what you are trying to do, this is either a bug or a feature. It makes playing ball with X-Rover quite fun though!
If you would like to track any sized object you will need to use either a sharp GPD-xxx or an ultrasonic ranger to get the true distance to the object. Then you can modify the code for the behavior you want in object tracking.
The CMUcam2 does all of the complex vision processing for you and you can read this over simple serial protocol. Luckily the CMUcam2 is easy to configure to easily process only the data you need. The current code uses output packet masking (the OM camera command) to greatly reduce the amount of data that needs to be transferred between the CMUcam2 and the Atom Pro. Only 2 bytes of data are needed for the tracking loop. There is one byte each for the x and y coordinates of the centroid. Thatβs it!
The maximum BAUD rate over the Atom Pro software serial port is 38,400bps and I was able to communicate at that speed however the output data was not very stable as it pushed the limits of the Atom Pro. The current code runs at 9600bps and through a lot of experimentation seems to be the ideal baud rate in conjunction with packet masking.
If you plan to use a more advanced processor then the Atom Pro, or a hardware serial port, the CMUcam2 has no trouble sending frame by frame data at 115Kbps. While this may smooth out the pan/tilt servoβs while tracking it does not add much if any actual advantage to the robot as we are limited by both the servo speed (how fast the head can track the object) as well as the rover speed (how fast the rover body can react to what the head is doing).
In its current configuration, X-Rover can track a 4Γ’β¬Β colored ball up to approximately 6 feet away. If X-Rover looses track of the object he is programmed to spin continuously while scanning his head looking for the object. Once the object is found again he will immediately begin tracking the object again.
With this simple elegant design X-Rover seems to attract a lot of attention and is just plain fun to play with.
USING THE CMUcam2 with the Atom Pro
In this next section of the tutorial we are going to cover the things you will need to become familiar with the CMUcam2.
First off, it is not necessary for you to program or interface the CMUcam2 to your computer, however it is highly encouraged if you are going to be modifying the code. There are 2 ways to have your PC talk to the CMUcam2. The first way is to just use the CMUcam2 GUI that can be found here: cs.cmu.edu/~cmucam2/downloads.html
This link also contains the user manual and a demo movie of color tracking.
You will first want to first download and install the GUI and then test some of the functions of the CMUcam2. One note: The GUI only runs at 115Kbaud so you will need to ensure that none of the baud jumpers are installed. This will ensure that the PC can communicate with the CMUcam2 at the proper baud rate. If the GUI tells you that it has found the camera everything should be set up properly.
If you are using the CMUcam2+ version only available at www.acroname.com then you will also need to purchase a TTL-RS232 level shifter in order to interface to the PC. Iβm using the one from Acroname which plugs perfectly into the CMUcam2+ board and has a DB9 serial connector to interface with the computer. You can use the same serial cable use to program the Atom Pro for this.
Once you have the GUI running the first thing you are going to want to do is to focus your camera. Follow instructions in the CMUcam2 manual to do this. All you need to do is keep grabbing frames and turning the lens focus adjustment until the frame you grabbed is fairly sharp. You do NOT Need to get focus exact. I have an untested theory that slight defocus may actually be helpful for color tracking. You may want to test this yourself later.
After the camera is focused you will want to experiment by grabbing a frame and then using the mouse pointer over the objects in the frame you want the camera to track. By mousing over the objects you will see an RGB display at the bottom of the GUI that tells you the current RGB values. This is EXTREMELY useful for generating your own minimum and maximum RGB values for custom tracking colors. Remember that pure R, G, or B colors are the easiest to track under a wide range of lighting conditions. Remember to do this using similar lighting that the robot will operate in.
Another thing to note is that it is also easiest to track objects that have highly saturated colors. When you look at the frame you grabbed the more the object stands out in the frame the easier it will be for the CMUcam2 to track.
If you do not plan to right custom code to control the camera and only want to use the GUI for RGB min and max values you do not need to do the next step. If you want to try editing or writing your own code for interfacing the CMUcam2 to the Atom Pro then you will need to do the next step where you will type in manual commands to control the camera. Note: this step will be required for fine focusing the camera.
After you have confirmed that the camera is working properly now would be a good idea to power down and install the correct baud jumpers. If you are running the code I have provided then you will want to install jumpers to run at 9600 baud. Once this is done we are going to use the Basic Micro IDE terminal window so you can get familiar with the camera commands and communication protocol.
Power up the camera with the serial cable attached (still using the DB9 adapter) and open up the IDE and navigate to a terminal window. Set the IDE to communicate at 9600 baud, put your cursor in the terminal window and hit return. If you now see the current camera version on your screen everything is working properly. If you do not get a response check all your connections, power and wiring until you are able to communicate with the camera. If things are working type Γ’β¬ΕGVΓ’β¬Β and then hit return. The camera will give you an ACK to let you know it acknowledged the command and then display the camera version again. If you can do this you can now give the camera whatever commands you want.
In order to edit or write your own code you will need to become familiar with all of the CMUcam2 commands you want to use. The CMUcam2 and the CMUcam2+ have the exact same command set and only differ in board design and layout.
One thing you should note is that the TW (Track Window) command is not terribly useful unless you have very uniform lighting in the environment that the robot will operate in. The reason for this is that the TW command expects the object to be tracked to nearly fill the frame of the camera as it is grabbing the colors. This almost always ensures that the tracking colors are pinned to a very small range. This is why you really need to either use my values for tracking RED, or experiment yourself the procedure above to develop your own values.
Some notes on the DM (Delay Mode) command. If you look at the first section of code before MAIN you will see some camera commands. The first camera command sent sets the delay mode. I have a value of 4 for delay mode. For some reason when trying to get the CMUcam2 talking with the Atom Pro it turns out that we need to use the delay mode command to ensure reliable serial communication. Iβm not sure why it is needed with the Atom Pro but it is. By trial and error I have determined that you should use a delay mode of 4 for 9600 baud. Other values work but higher values slow down serial communication further. I have found a good rule of thumb to ensure reliable communications is 4 for 9600 baud, 8 for 19200baud and 16 for 38400 baud. Or doubling the delay each time you double the baud rate. I have achieved Γ’β¬Λreliableβ communication at 38400 baud which is the max the software serial port of the Atom Pro will operate, however, it appears that data becomes corrupted at this speed and tracking performance degrades.
9600 baud seems to be working fine at the current speed the code runs but feel free to experiment with other baud modes. There is a constant in the code where you only need to change the baud rate in one location for ease of experimentation.
Hi Mark,
Your document looks quite useful! To βflush outβ your tutorial, you might add pix of the camera, connections, wiring diagrams and test code. All useful to the first-time user!
Iβd even create it as a DOC or PDF file, and make it available for download. Talk to Jim/Beth about making it a proper project, which would contain files.
Again, thanks for your efforts!
Alan KM6VV
This is all in progress nowβ¦I will be working with Beth next week on turning this into a tutorial and all will be posted on the Lynx website as soon as it is finished.
I just wanted to get the info out their so people can get a feel for the scope of the project.
There will of course be pinouts and diagrams in the final tutorial/assembly guides.
If anyone already has the CMUcam2 then they should be able to follow the pin assignments in my code quite easily just using the CMUcam2 board documentation of pinouts.
Also if there is enough demand Jim will likely make custom lexan brackets to hold the CMUcam2 and/or CMUcam2+. Each board has a slightly different form factor unfortunatly.
Right now I just have the cam sticky taped to a general purpose sensor mount.
Mark
All-
Here is the latest version of the X-Rover code that I was running when I made the last video and would be a good starting point as I donβt expect any changes in the tutorial version except possible pin assignments to better match other tutorials.
Mark
[code]β
β X-Rover Autonomous Color Tracking Robot
β Mark Fedasiuk 10/25/09
β Code is nearly complete!
β I have re-coded X-Rover to make it more generalized
β All offsets and tuning paremters now have constants
β
enablehservo
pinp con p0
pint con p1
speaker con p9
leftd con p12
rightd con p13
atx con p11
arx con p10
baudpc con i9600
baudatom con i9600
bauddisp con i9600
tiltc con -3000 'Tilt Servo Offset (was -3500)
tiltd con 0 β Tilt Servo Dead Zone (dangerous to increase)
tiltr con 4000 β Tilt Range
panc con 0 β Pan Servo Offset
pand con 100 β Pan Servo Deadzone
panr con 10000 β Pan Range
height con 72 β Height Adjustment (72 centers object vertically, higher numbers lower the object in the frame) (100-120 nominal)
trackcon con 3 β Number of misses allowed while tracking (range 1-3)
β Define Variables
x var byte(3) β X Centroid Value from CMUcam2
y var byte(3) β Y Centroid Value from CMUcam2
packet var byte β Grab a single packet of data from camera
pan var sword β Pan Camera
tilt var sword β Tilt Camera
stepp var word β Pan Servo Step Size
stept var word β Tilt Servo Step Size
stepsp var word β Pan Servo Step Speed
stepst var word β Tilt Servo Step Speed
posp var word β Pan Position
post var word β Tilt Position
rtpwr var word β Right Drive Motor Power
lfpwr var word β Left DRive Motor Power
dirp var sword β Pan Dirction
dirt var sword β Tilt Direction
val var byte β Variable for sound routines
tracking var byte β Number of times to allow non tracked object (filter)
'===================================
β MAIN
'===================================
main
β Initialize Variables
x = 0
y = 0
packet = 0
pan = panc
tilt = tiltc
stepp = 0
stept = 0
dirp = 1
dirt = 1
tracking = trackcon
hservo [pinp\pan]
hservo [pint\tilt]
hservo [leftd\0,rightd\0]
'Play Boot sound
for val = 2 to 5
sound speaker, [val30\val1000]
next
pause 1000 'wait for camera to boot
βββββββββββββββββββ
βCamera Commands
βββββββββββββββββββ
β set delay mode to get comms working
serout atx,baudatom,βDM 4β,13] β delay mode serial commsβ¦DM value is about baud/2500 4,8,16 for 9600,19200, and 38400 baud
gosub ackno
serout atx,baudatom,βOM 0 3β,13] β output masinking for better tracking speed
gosub ackno
serout atx,baudatom,βNF 2β,13] β noise filtering default 2, 2-4 good range
gosub ackno
'serout atx,baudatom,βCR 19 32β,13] β used to turn off auto gain on cam
'gosub ackno
β Play Sounds to let you know that the atom pro is properly talking to the CMUcam2
for val = 5 to 18 β 18 was 28
sound speaker, [val5\val(random tca)]
next
βββββββββββββββββββ
β Color Tracking
βββββββββββββββββββ
'track the color red with track color command note not using command subroutine
serout atx,baudatom,"tc β,dec 120,β β,dec 240,β β,dec 0,β β,dec 40,β β,dec 0,β ",dec 40,13]
gosub ackno
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Scanning MODE NOT TRACKING
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
loop
gosub Tpacket
if pan > (panc + panr) OR pan < (panc - panr) then
dirp = dirp * -1
endif
if tilt > (tiltc + tiltr) OR tilt < (tiltc - tiltr) then
dirt = dirt * -1
endif
if x(tracking) = 0 AND y(tracking) = 0 AND tracking > 0 then
tracking = tracking -1
goto loop
elseif x(tracking) = 0 AND y(tracking) = 0
'tracking = 0
if tilt > (tiltc + tiltr) then
tilt = (tiltc + tiltr)
elseif tilt < (tiltc -tiltr)
tilt = (tiltc -tiltr)
endif
pan = pan + dirp * 400
tilt = tilt + dirt * 150
hservo [pinp\pan,pint\tilt,leftd\3000,rightd-3000] β scan head and body and wag tail when lost track
goto loop
endif
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β AUTONOMOUS MODE TRACKING
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
tracking = trackcon β Reset Tracking Filter
stepp = abs(x(tracking)-45)*30 β was 25 Pan Speed
stept = abs(y(tracking)-height)*10 β was 10 Tilt Speed
'get hservo pan position
if x(tracking) < 44 then
pan = (pan - stepp) min -panr
elseif x(tracking) > 46
pan = (pan + stepp) max panr
else
stepp = 0
endif
posp = abs(pan - panc)*1 max 8000 β turn acceleration multiplier
'serout s_out,baudpc,[sdec pan," ",sdec posp,13]
if pan > (panc + pand) then
rtpwr = -posp
lfpwr = posp
elseif pan < (panc - pand)
rtpwr = posp
lfpwr = -posp
else
rtpwr = 0
lfpwr = 0
endif
if y(tracking) < (height - 1) then
tilt = (tilt + stept) max (tiltc + tiltr)
elseif y(tracking) > (height + 1)
tilt = (tilt - stept) min (tiltc - tiltr)
else
stept = 0
endif
post = abs(tilt - tiltc)*3.5 max 8000 β drive acceleration multiplier
'serout s_out,baudpc,[sdec tilt," ",sdec post,13]
if tilt > (tiltc + tiltd) then
rtpwr = (rtpwr + post)
lfpwr = (lfpwr + post)
elseif tilt < (tiltc - tiltd)
rtpwr = (rtpwr - post)
lfpwr = (lfpwr - post)
else
rtpwr = 0
lfpwr = 0
endif
'serout s_out,baudpc,[dec posp," ",dec post,13]
hservo [pinp\pan,pint\tilt,rightd\rtpwr,leftd\lfpwr] β Drive the Servos while tracking object
goto loop
end
βββββββββββββ=================================
βββββββββββββ====== SUBROUTINES ==========
βββββββββββββ=================================
β wait for ACK back
ackno
serin arx, baudatom, [wait(βACKβ)]
serin arx, baudatom, [packet] 'grabs the return after the ACK that confused me! this was the big fix
return
'retrieves a T type packet
Tpacket
serin arx, baudatom, [packet,dec x(tracking),dec y(tracking)]
'serout s_out,baudpc,[13,"T β,dec3 x(tracking)\3,β ",dec3 y(tracking)\3,13]
return
[/code]
BTWβ¦I will post this as itβs own thread since it is missplaced here but this part of the code:
speaker con p9
val var byte
for val = 5 to 28
sound speaker, [val*5\val*(random tca)]
next
Is my custom R2D2 type sound effects generatorβ¦you can experiment with the 5 and 28 values to make it sound different. If you make the 28 number larger it will play for longer and create a psudo random stream of R2D2 type soundsβ¦give it a try!
Mark
Oopsβ¦that wasnβt the exact one I was thinking ofβ¦try these:
[code]speaker con p9
val var word
tim var byte
pause 10
main
for val = 5 to 28
sound speaker, [val5\val(random tca)]
next
goto main[/code]
[code]
β Atom Pro Robot Computing Sounds
β Mark Fedasiuk
β 10/13/09
speaker con p9
dir var byte
val var word
val = 1
dir = 1
main
if val > 10 OR val < 1 then
dir = dir * -1
endif
val = val + dir
sound speaker, [100\val*1000]
goto main[/code]
I will repost these snippets in an R2D2 type sound effects thread.
Iβm curious to see if people like this sort of thingβ¦I wanted to give X-Rover a bit more personality so I sat down one day and just played with the sound command a bitβ¦there is a huge variation of the type of sounds you can makeβ¦still looking for my favorite one.
Mark
Any ETA as to when the complete tutorial will be available ?
Iβll have to let the people at lynxmotion answer that one since they have the materials and are working on it now.
Mark
Weβre hoping to have the tutorial up by tonight or tomorrow. Iβll post a link when itβs up!
GREAT News!
The first draft of the X-Rover tutorial is online! At least, it is for you forum people. 
Remember that this is a first draft β Iβve been staring at this thing all day, but I easily could have missed something. Let me know if you see any errors or have any comments!
Nice tutorial!
Is the CMU2 cam carrier an LM part? Would it fit the CMU3?
Alan KM6VV