PDA

View Full Version : How does your auto-aim work?


JamesBrown
03-01-2006, 08:57 AM
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
03-01-2006, 10:27 AM
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
03-01-2006, 02:13 PM
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
03-01-2006, 02:44 PM
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
03-01-2006, 03:17 PM
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
03-01-2006, 03:28 PM
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
03-01-2006, 03:35 PM
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
03-01-2006, 04:46 PM
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
03-01-2006, 05:55 PM
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
03-01-2006, 07:23 PM
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
03-01-2006, 10:07 PM
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
03-01-2006, 10:10 PM
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
03-01-2006, 10:22 PM
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
03-01-2006, 10:29 PM
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
03-01-2006, 10:58 PM
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.

Chriszuma
03-01-2006, 11:04 PM
Obviously PID is the ideal solution.
Yeah, if you don't mind losing your mind trying to tune it.

Goldeye
03-01-2006, 11:05 PM
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.

If you graphed it ahead of time, you wouldn't need to both with the physics equations... or even with variable speed. There is a somewhat "ideal" arc that stays within the correct height for almost 25 feet

Rickertsen2
03-01-2006, 11:17 PM
Yeah, if you don't mind losing your mind trying to tune it.
true that

ICE MAN
03-02-2006, 08:07 AM
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?

first I have little experience in code but have plenty of mechanical brainpower. this year we have a code that will auto adjust for aiming. first we made a code that would read where the camera is currently pointing, which I believe is a positive or negative integer. based on this we were able to know where the target is because theoretically it is always aimed at the target. we also made a zero point on the camera that is where the camera is looking dead ahead of our robot and since or shooter doesn't tilt or turn we have to turn the robot to aim. we made so that when we think we are in a reasonable distance we flip a switch and the code basically turns the robot till the camera/code will read that the camera is at our zero/dead ahead setting which should put us aimed right at the target then we push another button and BOOM score, we hope! :D

Donut
03-02-2006, 08:24 AM
If you graphed it ahead of time, you wouldn't need to both with the physics equations... or even with variable speed. There is a somewhat "ideal" arc that stays within the correct height for almost 25 feet

This "ideal" arc varies drastically depending on the angle you shoot at and the height of your shooter though; the one on ours I think couldn't get us past 19 feet with the optimal setting.

lineskier
03-03-2006, 09:19 PM
we have our camera mounted to the top of our launcher. The launcher is located on the side of the robot, and is not a turret but it does tilt. We use the difference in the x values to determine how far away we are and we use it to determine if were centered. Right now we drive out dead reconing, and then the turn stops one the camera aligns with the target, then we open her up. Today we were scoring in between 7 and 9 of the 10 balls in autonomous.

Don Reid
03-06-2006, 04:28 PM
Our camera is bolted directly to the robot frame, no pan or tilt. It is in line with the cannon.
We mechanically align the camera to have the target at the center when the cannon shoots balls through the center of the goal from the desired position.

In use, when the driver requests it, the firmware uses a PID loop (sort of 2, for X & Y) to drive the robot until the center of the target is at the center of the camera.

We also have a custom dashboard program that shows the driver(s) where the camera sees the target. They use this to decide when to activate the auto method, or for manual aiming.

mogunus
03-07-2006, 05:22 PM
We use two cameras, each mounted on the pan/tilt servo, one on either side of the shooter, to "triangulate" the range to the target. Generally, the range estimate we get from that is accurate to within 5 inches. That gives us the x-vector that we need to plug in to the launch angle formula, given the constant Y-vector and the constant speed that we hold our shooter motors at.

This approach works well.

Greg Ross
03-07-2006, 05:48 PM
We'll find out this weekend how (or whether) our auto-aim works. :rolleyes:

We fix-mounted our camera such that at the base of the ramp, the target is at the top of the camera's field of view, and at half court, it is at the bottom. Based upon the Y position of the blob centroid, we calculate (actually lookup) the required shooter speed. We also have an auto-aim driving mode which uses the blob centroid's X position as input to a PID control loop to get and keep the robot pointed at the goal.

Ben Englert
03-24-2006, 04:13 AM
We use two cameras, each mounted on the pan/tilt servo, one on either side of the shooter, to "triangulate" the range to the target. Generally, the range estimate we get from that is accurate to within 5 inches. That gives us the x-vector that we need to plug in to the launch angle formula, given the constant Y-vector and the constant speed that we hold our shooter motors at.

This approach works well.

How do you hook up two cameras to the RC? Do you just use the program port for one, or have you put together some kind of multiplexer?

Neo3One3
03-25-2006, 11:18 PM
Well, for ours, we use two functions, one for pan and the other for tilt (obviously). For our tilt, we simply use a lookup table based on the camera's tilt servo position, and drive the motor to a certain pot reading accordingly. For our pan, we set a zero position for when the camera is centered to the turret, and the turret drives until that center is reached.

Mogunus, I was wondering what the reason was for having two cameras. Can't you simply get the distance to the goal from:
Distance to Wall = Height from Camera to Light / Tangent(Camera Angle)
and
Distance to Goal = Height from Camera to Light / Cosine(Camera Angle)
Maybe accuracy increases from two cameras, I'm not really sure.

lemoneasy
03-26-2006, 12:08 AM
accuracy could increase with two cameras if you have a problem with it tracking through a few pwm positions in the tilt of the camera. If your out by center field, that makes a big difference in calculations, so you could use the average angle from both cameras to get a better reading, but it would be more efficient to just take the numbers from two loops and average.

For our bot, we had an auto-aim that was working perfectly, but when you get to competitions and the bright lights drown out the targets, its a lot more unreliable. 220 confidence to 20 more unreliable. It also is a pretty large target, but if your shooting from further away, its nice to have auto-aim.

We had a tilt and pan motors, each powered by relays, the pan was just a number based on the servo position of our camera it drove until the pot had the same number (after conversion, the pot was 16-bit). Same with the tilt, based on the distance to the wall, we found an angle, which was converted to a postition on the pot, and driven to it, as long as it was within the limits.

Thats about it, not overly complex, and with these large nets, aiming is pretty forgiving.

iamthetallpaul
03-27-2006, 12:52 AM
I wish I had had more experience to learn about PD, PID, and PI loops, this was my first and only year as our only programmer (any my only year on the team). Th last one graduated and left me with nothing.

I used a slightly modified version of Kevin's code. Instead of driving a pan servo based on the pan_error, pan_error is just added to or subtracted from 127 to drive the turret motor towards the center of the light. Actually slightly off center since the camer is mounted off center. Tilt is exactly the same and the hood is a lookup table.

sanddrag
03-27-2006, 01:20 AM
I am not a programmer but I'll explain it to the best of my abilities. Our robot has azimuth and elevation control on the shooter. We have pots on both. The camera has it's own azimuth and elevation control (the one provided in the kit) using servos. The camera is mounted to the shooter azimuth but not the shooter elevation. When the aim button is pressed, the camera searches for the target. When the target is found, it locks on. Then, the "brains" say "okay, where are my camera's servos pointed right now?" and "where do my shooter's pots say it is pointed right now?" and "why the heck aren't they pointing the same way?" and "let's make them point the same way." This all happens in about half a second. That is a non-programmer's description of it. Anyway, because of our turret, we can be pushed around and still be locked onto the goal. At the SoCal regional, it worked so well we won the Radio Shack Innovation in Control Award for it. However, after we won that award, teams came up with autonomous modes (ramming) specifically against us. When they hit us hard, we remained dead locked on the target, but the balls in the feeder mechanism jammed, and we could not use our unjamming function until driver control mode. In one of our Saturday qualifying matches, we made some really long shots, from our low down shooter even with robots trying to block us because we could reposition and still be locked on or easily lock on again.

Also, on our feeder mechanism, we have a light sensor so when the light beam is broken, the motor stops until the "fire" button is pressed again. This allows indexed feeding and control of exactly how many balls we shoot.

Matt Krass
03-27-2006, 02:09 PM
I wish I had had more experience to learn about PD, PID, and PI loops, this was my first and only year as our only programmer (any my only year on the team). Th last one graduated and left me with nothing.

I used a slightly modified version of Kevin's code. Instead of driving a pan servo based on the pan_error, pan_error is just added to or subtracted from 127 to drive the turret motor towards the center of the light. Actually slightly off center since the camer is mounted off center. Tilt is exactly the same and the hood is a lookup table.

That's effectively P control, power output proportional to the error, with a gain of one (That is the output is the error times one, which is just the error). If you'd like a better explanation of P, I, and D contact me via PM and I'd be happy to help you out.

Our auto aim works similar to 696s but the camera is directly mounted to the shooter, our brain just goes "Where are we?" followed by" Where does the camera say we want to be?" and then using the error computed from that, runs through a P, I, and D formula with their own specific gains (some of them very low) set, then we run sanity checks on all the values to make sure they're sensible, add them up, check that (We're so paranoid :) ) before returning it from our aiming function, then, depending on mode it's either use to drive the Heads-Up display, the pan motor, or both.

Firing consists of three modes:

Manual - Camera feedback drives LED HUD on operators safety glasses, operator can start firing checklist at will, pan control is handled by a dial on controls representing absolute position, no auto-targeting.

Semi-Auto - Camera feedback drives pan motors to maintain targeting on goal, drives LED HUD on glasses, operator can start checklist at will, auto-targeting, no search. This mode is currently not implemented due to a few reliability issues.

Auto - Camera feedback drives pan motors to seek and maintain targeting with search algorithm, drives LED HUD on glasses, checklist constantly cycling and firing when completed, auto targeting and search within current field of view.

The checklist runs through a series of sensor checks to make sure the system is ready to take a shot:

1. Is there a ball in the firing mechanism? (Optical beam sensors)
2. Is the piston in ready position? (Reed switch)
3. Are the impeller wheels up to speed? (Tachometer/DC Motor from kit)
4. Do we have permission to fire? (Firing button still pressed/Auto fire mode)
5. Are we on target? (Camera/Overridden in manual mode)

We use manual mostly while in driver mode because our operator responds to changes faster than our conservative PID control (we slowed it down for system stability, working on improving that as well) whereas our autonomous mode, at least a few of them ;-) uses the camera based Automatic Mode to acquire a lock and score during autonomous. It worked pretty well, in the semifinals and quarterfinals of SBPLI we were rammed several times in autonomous, the turret corrected and continued scoring.

The heads-up display are two bright LEDs mounted so they're on the edge of our operators peripheral vision, they indicate to which side of the turret the target is on, in other words, which way to turn, both light when on target, neither light when the target is not visible to camera and they blink back and forth rapidly if communications with the camera fail.

Rickertsen2
03-28-2006, 04:59 PM
Anybody else normally auto-aim during the entire match, or are yall just using it in autonomous?

InfernoX14
03-28-2006, 05:13 PM
When we had a camera and shooter it was mounted stationary directly on the shooter. We brought up a dashboard that had a graphic crosshair that displayed where the target was.

So it wasn't really auto-aim, but still our idea on how to aim our shooter.

steven114
03-28-2006, 07:28 PM
Ours works during the entire match.

Chriszuma
03-28-2006, 08:18 PM
I'm really excited about our new system. The other day I finally got a PID loop coded up that uses the gyroscope to essentially lock us into our heading. It's really beautiful: it ramps up as you try to push it, so nobody will be able to push us off course while we're shooting. (This was one of the major factors in our non-victoriousness) The driver will simply push one of the joystick buttons to activate the self-centering. My next project is to integrate the camera into it, but we've been doing fine without it, since our driver has really good aim (unless being pushed, thus the new system).

DaveA412
03-28-2006, 09:11 PM
I have no clue how our auto aim works im sure James Brown does o wait he posted this enjoy James

Jeff K.
03-28-2006, 11:19 PM
At the SoCal regional, it worked so well we won the Radio Shack Innovation in Control Award for it. However, after we won that award, teams came up with autonomous modes (ramming) specifically against us. When they hit us hard, we remained dead locked on the target, but the balls in the feeder mechanism jammed, and we could not use our unjamming function until driver control mode.

Actually, I don't remember many teams aiming at you in autonomous after you guys won the award. And if anything, they had the "ramming" mode already on their bot from Thursday like we did.

Just my 2 cents..


Congrats on the award though. It definitely was a pretty neat design and looked nice too. David(Sanddrag), is your team going to the San Diego Lock In?

sanddrag
03-28-2006, 11:25 PM
David, is your team going to the San Diego Lock In?I would most certainly hope so. And hopefully with not only "Robot Man Jan" but also "Robot Man Jan B" Yes folks, two robots. If I have any say it in, it will happen. Will they be twins? Will they be different? Who knows. Find out May 20th.

I'm hoping for 5 balls in the center goal in autonomous. We'll see what happens.