We got the camera to track the green, but now we’ve got another problem.
We’ve hooked up the servos on the camera directly to two motors so the camera tells the motors what to do. However, when the camera sees it, it sets the motor running in one direction and doesn’t stop it. How are some of the other teams doing this? Are you guys modifying the code sent to the motors or will this setup work?
We haven’t gotten our encoders to work well yet. What do you mean by “pot and a feedback loop?”
What is the encoder supposed to do? Our electrician says it is an “acceloromiter” but our head-programmer sayed that it detects whether a robot has been knocked off course (which would benifit autonomous.)
An encoder is a digital sensor that detects regular “ticks” on a wheel. The purpose of it is to detect either velocity or position. You count ticks and compare them to the time. In this case, an encoder can either be a tooth counter, the banner sensors, or the grayhill encoders.
For some reason I am thinking I heard that 150 was the center value for the servos. Correct me if I’m wrong.
I am by no means a programmer, but with no encoders/gyros/etc. whatsoever (method A you are referring to) is it not possible to write some code kinda like this:
if(pwm01 > 155) //giving kind of an error range of 5
pwmX = 157; //or some value that isn't terribly fast
if(pwm01 < 145)
pwmX = 97;
if(pwm02 > 155)
pwmY = 157;
if(pwm02 < 145)
pwmY = 97;
Assuming pwmX is your pan and pwmY is tilt for your “aiming” motors, 150 is the actual center value for they servos, and I don’t know if there are some default variables for the pan and tilt servo values (I just thought they were pwm 1 and 2). Probably pretty inefficient code, but that basic idea?
There are 2 solutions available using proportional control if you are either
steering a gun turret using the pan and tilt output from the camera data packet; or
slaving the turret in the x-plane by fixing the camera to it
First, if you are using an optical encoder to measure the rotation of the turret and Tmid is the midpoint measurement of the turret and Cmid is the midpoint servo output for panning, then once the camera finds the target,
the desired turret position, or turret_dx, is given by Tmid*(1+((pan/Cmid)-1)). If we set error_x = turret_dx-OE, then the pwm output to the motor powering the turret is 127-Kp*error_x, where Kp is a proportionality constant.
Second, if the camera is afixed to the turret in the x-plane, then the error is simply Cmid-pan. The pwm output is then 127+Kp*error_x.
You can refine these equations to make a PID controller if needed. The math should be optimized for integer math by multiplying and dividing by 100 to avoid truncation error.
Kevin: Would you recomend fixing the camera to the turret and slaving the pan (and a factoring in the tilt assuming the turret can tilt)? I am not an exrteemly versed programmer but i know i could pull it off. As is i figured that i would just keep them independant.
Also: is the confidance rating of the camera a good relfection of magnitude in the vector to the light (after all, vectors have direction & magnitude!). I could perhaps use this to throttle the shooter’s wheels.
Acutally, I was thinking of mounting the camera on top of the turret, and setting up the motors so that it would automatically swing the turret until the camera reads 0 pan and 0 tilt without any code modification. Would that work?
It should, but you need to recognize something that might make it work less well than you expect. The camera code doesn’t move the tilt or pan servos until the vision target gets “far enough” from the center of the view.
Look at tracking.c in the camera code provided by Kevin Watson. In the servo_track() function, it checks to see how many pixels off-center the target is. Only if it’s more than Pan_Allowable_Error left or right, or Tilt_Allowable_Error up or down, does it actually move the servo to recenter the target in the camera’s field of view.
So if you want to be as accurate as possible, you need to move the turret to zero the pan/tilt servo values and also cause the mx/my values returned from the camera to match the target pixel values.