Why use the RC to control Pan/Tilt


I’m curious why you chose to control the Pan / Tilt for the camera with the RC instead of using the control built into the camera. What advantage or additional capability do you gain by doing that?


It takes longer for the CMUCam servo controller to respond (up to half a second).

This practically eliminates any kind of PI control except for the on-board one, which is also slow.

Just my $0.02 :slight_smile:

By using the RC it makes it very easy to tweak or completely change the search algorithm to find the target quickly.

The major reason I spend hundreds of hours a years writing and supporting code on my own dime is because I hope a few HS students might learn something new from reading my code. If they learn something cool, maybe they’ll take the time to really dive into the code and improve upon it (setting the hook, so to speak). If I just took the lazy route and used the camera to do the tracking, the kids wouldn’t have some code that they could use as a starting point and discussions like this one wouldn’t have taken place.

Perhaps I should ask you what disadvantage is there to providing more information & learning opportunity?


I think Joe was asking why you didn’t use the camera’s servo outputs, not why you didn’t use the camera’s automatic tracking firmware.

Your provided code has a small disadvantage: the camera cannot track while the robot is disabled. That keeps robots from finding the goal target light in advance of entering autonomous operation. Using the CMUCam “SV” command instead of the RC pwm output would let robots get a lock before they are enabled to move. We’re working on modifying the camera tracking code to do it that way, and I am grateful for the well-documented code.

If the green light is within the camera’s field of view when autonomous period starts, the software will converge on a solution in much less time than it’ll take to fire-up motors.

Because the software is modular, I suspect that it would be very easy to let the camera do the tracking and/or control the servos.


Have a bad day? Maybe a little too defensive. Not everyone has an agenda or is out to get you.

I had an honest question about the reason behind your design decision. It wasn’t laced with criticism, didn’t imply that you were wrong or foolish for doing it that way, and didn’t even suggest a preference. Given the two options, you chose one over the other.


[quote=“Kevin Watson”]
I hope a few HS students might learn something new from reading my code… * to provide more information & learning opportunity.

Another advantage is that you can control the camera a different way, say mount it on top of a rotating turret, which eliminates the need for another way to pan. :wink:

sigh I guess this is some kind of amateurish attempt to provoke a negative response from me. I haven’t a clue why you’re being so disingenuous or what your agenda is, but you should be ashamed of yourself for pulling something like this in a public forum where we’re attempting to promote engineering and the sciences as a career choice for adults.


I have a small question (which is probably answered somewhere obvious) But how do I go about setting the pwm values on the camera?
I have it hooked up properly (based on last year’s camera, which worked apparently) however I don’t know how to get the camera to output values to them.

I can verify the pwms are plugged in correctly because upon initialization and (possible) activation the camera ZIPP!s into position (and stays there no matter what i set pwm01 or pwm02, or PAN or TILT).

What do I do to set this?


I just read Rule <R28> revision #2 which stated that i could not use the 2006 camera! :ahh: Oops :D. Well, I guess i need to get longer pwm cables! :o. Oh well, just go with the flow…

It is not legal to control servos with the camera’s PWM output this year anyway:


  1. He’s an engineer, not a kid.

  2. My exchange with Joe is a year old. I’m going to have a talk with some CMU professors I know, because they clearly aren’t piling on enough work if you have this much free time on your hands :wink: .

  3. In hindsight I can certainly see why you might think I was quick to jump on Joe, but you’re not aware of the other messages that preceeded my exchange with him that convinced me he was playing the alpha-geek game. As there are few things in life I dislike more than getting pulled into an alpha-geek game, I quickly made it undesirable for Joe to continue so that I could get back to more enjoyable endeavors. One of the best methods to quickly stop such activity is to shine a light on it and call it what it is: bad behavior. Though my timing was off, this is exactly what I did, and it worked. Unfortunatly, because I was too quick to fix the problem, it made me look like I’m nuts, which may or not be true :D.

  4. I think I have a few good reasons for choosing to use the RC PWM outputs rather than the CMUcam2 outputs. I’ve noticed quite a few questions about the subject this year, so I think I’ll give the quick answer here and then follow-up with a more detailed answer in the FAQ if time allows.

Firstly, I wanted teams to have all the source code in their hands so that they could have something to improve upon should they desire, including the searching/tracking code.

Secondly, it made more sense to me to have the camera send t-packets as fast as it could (~11 Hz) by using the Track Color command. Otherwise I would need to used polled mode, which is much less efficient and possibly risky because I’d need to asynchronously cross clock domains twice, instead of once.

Third, I had a hard time getting the camera to initialize correctly. It would lock-up and stop communicating if I didn’t send it commands with perfect timing and in just the right order. The experience dealing with the fragile communication interface made me a little apprehensive about using polled mode, and made the use of the streaming Track Color command that more attractive. The last thing I wanted was to be mentioned in the same sentence as the FRC scoring software, so I took the more conservative approach.


Okay, now I look like I’m nuts… I didn’t notice that somebody else had brought this thread back from the dead. I understand the “alpha geek game” you’re talking about, and I sympathize. In any case, I take it back. And yes, I’ll be getting back to my work now (CMU gives me plenty without your help, thanks). I’m just glad to see that you haven’t completely lost it. :wink:

Also, thanks for the explanation of why you’re doing it the way you are. I’m currently trying to cobble together some CMUCam stuff with your EDU serial ports code for a different project, and now I’ve got some things to think about.

Ouch, that hits close to [strike]home[/strike]work. Some ideas that seem really cool early on should just be avoided, the problem is that the point at which you realize you should have quit sometimes comes right after you’ve finished. I sometimes wish I was one of those who doesn’t know what you’re talking about, as my ears are still ringing from it and I didn’t have a part in it! :ahh:


Whoops, no, I wasn’t referring to what you think I was referring to! I was thinking about the organization that had overall cognizance of the scoring system for the last few years.


Hahahaha. I understand now. We’ll just leave it at that, no? :rolleyes: