Camera to motor setup

[Windward]

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?

[devicenull]

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

[Jared Russell]

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.

[Tom Bottiglieri]

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.

[Mike Betts]

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?

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

[Windward]

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.


We haven't gotten our encoders to work well yet. What do you mean by "pot and a feedback loop?"

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.


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.)

[Astronouth7303]

We haven't gotten our encoders to work well yet. What do you mean by "pot and a feedback loop?"

Closed loop (http://www.firstwiki.org/Closed_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.

[SteveO]

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.

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?

[iBheat]

The true center value for a servo is 127 but in Kevin's code he defines them in tracking.h!

[Jon236]

There are 2 solutions available using proportional control if you are either

1) steering a gun turret using the pan and tilt output from the camera data packet; or
2) 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.

Post your own solutions!

Jon Mittelman
Team236 Programming Mentor

[Kevin Watson]

The true center value for a servo is 127 but in Kevin's code he defines them in tracking.h!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

[Jon236]

so

pan ceter is 124
tilt center is 144

right, Kevin?

Jon

[Windward]

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 Tilt

if 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?

[iBheat]

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

Yeah that is what I meant.

[Validius]

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.

[Windward]

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?

[Alan Anderson]

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.

[Windward]

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?

[Alan Anderson]

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.

[Windward]

Closed loop (http://www.firstwiki.org/Closed_loop)



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.

sorry. I meant gyro.

[devicenull]

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?

If you mean 127 pan and 127 tilt, then yes, it works very, very nicely ;)

[Bharat Nain]

Did you or anyone ever get the Camera to Motor setup working?

[Salik Syed]

Our team used a heavily modified version of Kevin's PID code,
basically all you have to do is add another motor to the motor_info data struct, and change the get_encoder_value function so that it returns PAN_SERVO when the argument is 2
now simply call set_pos(2,127)
and set your left and right drive motors to =motor_info[2].pwm+127; and 127-motor_info[3].pwm; (this may need to be change depending on your wiring and robot setup)

you may have to tweak the P, I, D constants

We had it working beautifully until we did some other stuff and screwed it up... :(
(we used our own custom PID software... but i think i'm gonna switch back to kevins because i can't figure out whats wrong with ours... and I didn't write it so I don't understand it 100%)

[Windward]

Our team used a heavily modified version of Kevin's PID code,
basically all you have to do is add another motor to the motor_info data struct, and change the get_encoder_value function so that it returns PAN_SERVO when the argument is 2
now simply call set_pos(2,127)
and set your left and right drive motors to =motor_info[2].pwm+127; and 127-motor_info[3].pwm; (this may need to be change depending on your wiring and robot setup)

you may have to tweak the P, I, D constants

We had it working beautifully until we did some other stuff and screwed it up... :(
(we used our own custom PID software... but i think i'm gonna switch back to kevins because i can't figure out whats wrong with ours... and I didn't write it so I don't understand it 100%)


We don't have encoders working and it is far too late to implement them into our bot.


On a side note, we did the zero point method making the servo's and motor values equal to the search value, it works beautifully when we implemented. Basically the human player controls the turret until the "find target" button is pressed. Then the camera re-aligns the turret to aim for the green.

[Salik Syed]

We don't have encoders working and it is far too late to implement them into our bot.


On a side note, we did the zero point method making the servo's and motor values equal to the search value, it works beautifully when we implemented. Basically the human player controls the turret until the "find target" button is pressed. Then the camera re-aligns the turret to aim for the green.


you don't need encoders, you can fake the system.... just put the camera pan servo value in place of the encoder count, the PID math is the same