How does your auto-aim work?

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

[Chriszuma]

Obviously PID is the ideal solution.

Yeah, if you don't mind losing your mind trying to tune it.

[Rickertsen2]

Originally Posted by Chriszuma

Yeah, if you don't mind losing your mind trying to tune it.

true that

[Don Reid]

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]

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]

We'll find out this weekend how (or whether) our auto-aim works.

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]

Originally Posted by mogunus

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]

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]

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]

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]

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.