How does your auto-aim work?

[JamesBrown]

How does your auto aim work? Did you have the camera drive the pan and tilt motors on your turret until it was aimed right? Did you use encoders to line up the gun with the target? Did you mount the camera with tilt and pan servos to the turret? Or did you do something different?


Our camera searches with the pan and tilt servos. It is mounted to the gun once it as been tracking for a few loops (10 I believe). It pans and tilts the gun until the camera faces the same direction as the gun. This works very well for us, it allows us to shoot while moving in our low gear or to shoot while we get pushed.

So how (if at all) did you do it?

[steven114]

The camera finds the target, then uses the pan and tilt angles to grab a pair of positioning numbers from lookup tables. Those numbers are plugged in to the PID control which aims the turret, and then we fire

[Eldarion]

The camera finds the target, calculates range and passes it to some physics equations which give speed. Speed of shooter wheels is controlled with PD loop, same with turret position.

[bear24rw]

Our camera is mounted stationary on top of the shooter... we have two pots to keep track of the pan and tilt of the turret.... we find the pot value when the turret is center and the pot when the shooter is a 45 degrees, then use that center value to line the turret up with the camera servo pan, through the ratio of servo steps to pot steps, for the tilt, we take the servo tilt convert it to a degree, take the turret tilt (from the pot) convert that to a degree and then pass those through a lookup table generated from a physics equation to acuatly position the tilt.

[phrontist]

We don't aim tilt automatically... it seems kind of pointless. You can hit the goal with the same tilt from a variety of distances, it's easier to just have the human driver do that. We have the camera mounted in the pan/tilt gimbal provided on the panning base of the shooter. The camera tries to track constantly, and when our Easy Button is depressed a PID loop tries to center the camera. It works quite well, only occassionally oscillating a bit when it's up close to the goal, but altering the PID equation to account for distance from the target could fix this.

[Stuart]

operator pulls the turret triger the camera locks on to the target and the turret then turns in an atempt(a very good attempt If I might add) to get the camera to 128. . . then if the operator hits his thumb switch the robot will look at the camera tit then looks up that value in a table and sets the cannon to that speed

[Chriszuma]

We have no turret, and thus we didn't need servos. The camera is bolted (pop-riveted, whatever) right next to the shooter. The chassis driver holds the two top buttons down and the code takes over, aiming the robot by adjusting the drive motors in a PI loop. When the robot is ligned up a LED on the OI tells driver 2 that he can fire without missing. The LED actually turns on whenever it is aimed correctly, even if it's not being centered. It provides a nice way to tell if the robot is going to score a 3-pointer or poof someone in the head.

[Rickertsen2]

The camera has a tilt axis only. The camera's pan is locked to our turret. I am using a lookup table that maps camera angle to gun angle. I wrote a nifty script to generate the lookup talbes using quadratic interpolation given a few points generated through trial and error. A PD control loop is used on both the pan and tilt axis. There is a FIR-like filter on the D term of the tilt. If the camera looses sight of the target the turret reverts to manual control mode. It is up to the turret driver to get the target back in sight.

To determine the position of the pan and tilt axis we have an encoder on each as well as a limit switch to determine "home" position. When the robot is power up, both axis automagically find their home position. At this point, the pan encoder is really only used to make sure we don't try to spin the turret around too many times and for the magic button that goes back to come posistion. The OI has "target locked" and "ready to fire" lights.

[Denz]

Camera is mounted on the robot, and is free to move with pan and tilt servos. When align trigger is pressed, the robot aligns itself with the target. When then shoot trigger is pressed, the camera takes the tilt angle, puts it into a table of values and gets the correct motor speed generated by trial and error testing. Then all we have to do it FIRE! We also have LEDs writed from the OI that turn on and off according to alignment, correct speed, camera on/off things like that.

[DonRotolo]

Camera is mounted to the pan table, a PI loop (No pun intended, but no D either) drives the pan motor until the camera says the target is straight ahead. We also use a PI loop with a potentiometer to control tilt based on camera tilt angle. We liked the idea of only one sensor, while maintaining the camera's ability to look around for the target without being hindered by being tilted too.

Don

[Rickertsen2]

Originally Posted by Don Rotolo

Camera is mounted to the pan table, a PI loop (No pun intended, but no D either)...
Don

Why PI instead of PD or PID?

[Greg Marra]

Have any of you tried aiming your shooter without auto aim? I found it easier than I thought (in practice, anyway) to line up the robot to score from the base of the ramp. I don't think we're going to be accurate enough to score on the other end of our parabola, but from the base of the ramp we didn't have too much difficulty visually gauging whether we were in place or not.

Now autonomous...

[JonBell]

Originally Posted by Greg Marra

Have any of you tried aiming your shooter without auto aim? I found it easier than I thought (in practice, anyway) to line up the robot to score from the base of the ramp. I don't think we're going to be accurate enough to score on the other end of our parabola, but from the base of the ramp we didn't have too much difficulty visually gauging whether we were in place or not.

Now autonomous...

Actually, now that you mention it...
Due to a number of technical fowl ups (including robot not being done on time, programming team degrading to just myself, and school being closed during last the last week, forcing our pickup to be the friday before), I spent a few hours playing with our robot with just the manual controls. I have had no problem adjusting the altitude (I made a knob that scales the shooter from max legal range to min to reach target), and pretty much always hit the right horizontal, but as distance increases, it's harder to line it up centered. Hopefully during the fix it window I'll be able to program the camera to stay fixed and just tell us when we're in the left-right sweet spot (it seems like this should be relatively easy).

One thing that I noticed with all of these auto-locator robots is this:
Will you have had enough practice shooting without your camera assistance? It seems like (on most robots), the camera is mounted below the shooter, making it very easy to get in between it and the vision target, a defense that may prove to be very successfull.

[Tom Bottiglieri]

Originally Posted by Rickertsen2

Why PI instead of PD or PID?

I've always thought it was a rule of thumb to use PI for position control and PD for velocity control, especially with the dead band on the victors.

In position control, you want to accurately stick to one position. (yeah, I know... duh... ) With just P control, the error can get so small that you are sending a output of 0 (-10 - 10 - victor dead band) to the motor control. You want the integral term to look at that error building up and over power it.

In velocity control, you want to change your output on the fly, and compensate for where you think you need to be. PD works fine.

[Rickertsen2]

Originally Posted by Tom Bottiglieri

I've always thought it was a rule of thumb to use PI for position control and PD for velocity control, especially with the dead band on the victors.

In position control, you want to accurately stick to one position. (yeah, I know... duh... ) With just P control, the error can get so small that you are sending a output of 0 (-10 - 10 - victor dead band) to the motor control. You want the integral term to look at that error building up and over power it.

In velocity control, you want to change your output on the fly, and compensate for where you think you need to be. PD works fine.

Maybie i am mistaken, but it thought the opposite was true and you were suppsoed to use PD for position and PI for velocity/temperature. It seems to me that when controlling velocity, I would be very important because it ends up canceling out friction and other forces that would prevent P alone from reaching the setpoint. It seems like D is very important in a position control system because it makes the system stable. If you model a perfect frictionless system with a position P controller applying a force to a mass, the system will oscillate in a sinusiodal fashion. If you add D, it becomes stable. You make a good point though about I eliminating the steady state error.
In my PD code i have a minimum output signal that the controller is allowed to output so long as the controller is outside of its allowable tolerance. This minimum is just enough to overcome friction, the victor deadband etc.

Perhaps i should code in an I to my control loop.

Obviously PID is the ideal solution.