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?
Servo values don’t directly translate to motor values.
A servo value of say 175 could be off to the left or right of center. In terms of a motor, it is forward.
You need some translating code in there
Servos are position-commanded. A pwm value of 127 is center, 0 is one extreme, 254 is another.
Motors are velocity-commanded. Pwm 127 is neutral, 0 is full reverse, 254 is full forward.
You have to translate between the two. Using an encoder or pot and a feedback loop is one way.
Better yet… read back the “wanted” pan servo rate from the camera, convert that into an angle relative to the bot in radians, and either
a) Turn the bot until the pan servo reads 127 (0 degrees)
b) Use a gyro (It would be a shame if a team skimped out on using one of these, seeing as we got a pretty nice one in the kit!) and turn to the calculated angle.
c) Use a combination of both: Lock onto the target… get the relative angle… turn UBER fast using the gyro to slow down… and reposition yourself by using choice A.
The servo PWM value commands position. The motor PWM value commands velocity and/or torque. These are not equivalent… You will have to do some math to make it work…
Mike
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?
The true center value for a servo is 127 but in Kevin’s code he defines them in tracking.h!
There are 2 solutions available using proportional control if you are either
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.
Post your own solutions!
Jon Mittelman
Team236 Programming Mentor
The values in tracking.h define the calibrated servo PWM values when the camera is centered (i.e., pan and tilt angles of zero degrees).
-Kevin
so
pan ceter is 124
tilt center is 144
right, Kevin?
Jon
This is the basic outline that I came up with, where the camera is mounted on the cannon.
// pwm1 = Camera Pan
// pwm2 = Camera Tilt
// pwm5 = cannon Pan
// pwm6 = cannon Tiltif CamPanLeft
turn cannon right
if CamPanRight
turn cannon left
if CamTiltUp
rotate cannon down
if CamTiltDown
rotate cannon up
Also when a pwm > 125 is the motor/servo turning to the right or the left. Once I know that I can write more specific code.
Does the pan & tilt center change when you change the degrees of panning & tilting?
Yeah that is what I meant.
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.
What do you mean by this?
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.
sorry. I meant gyro.