![]() |
Why use the RC to control Pan/Tilt
Kevin,
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? Thanks, -Joe |
Re: Why use the RC to control Pan/Tilt
Quote:
This practically eliminates any kind of PI control except for the on-board one, which is also slow. Just my $0.02 :) |
Re: Why use the RC to control Pan/Tilt
By using the RC it makes it very easy to tweak or completely change the search algorithm to find the target quickly.
|
Re: Why use the RC to control Pan/Tilt
Quote:
Perhaps I should ask you what disadvantage is there to providing more information & learning opportunity? -Kevin |
Re: Why use the RC to control Pan/Tilt
Quote:
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. |
Re: Why use the RC to control Pan/Tilt
Quote:
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. -Kevin |
Re: Why use the RC to control Pan/Tilt
Quote:
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. so.... Quote:
-Joe |
Re: Why use the RC to control Pan/Tilt
Quote:
|
Re: Why use the RC to control Pan/Tilt
Quote:
-Kevin |
Re: Why use the RC to control Pan/Tilt
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? Edit: 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... |
Re: Why use the RC to control Pan/Tilt
It is not legal to control servos with the camera's PWM output this year anyway:
http://forums.usfirst.org/showthread.php?t=1747 |
Re: Why use the RC to control Pan/Tilt
Quote:
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 ;) . 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. -Kevin |
Re: Why use the RC to control Pan/Tilt
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. ;)
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. |
Re: Why use the RC to control Pan/Tilt
Quote:
-Danny |
Re: Why use the RC to control Pan/Tilt
Quote:
-Kevin |
| All times are GMT -5. The time now is 16:03. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi