Teams: How did you use your potentiometers this year?

Hi,
I was curious as to how teams that used potentiometers integrated them into their designs. Team 987 mounted our potentiometer on top of a pulley that controlled our shooter’s turret. Using the values between 0 and 1024, we determined the position of our turret. Also, were there any teams that actually converted a potentiometer’s value into a measure of degrees?

Last year our programers were able to use the pots to program movements into the robot by recording how much they moved and we could track our arm and had preset positions to load tetas and such

HOT used pots this year to control the turret’s spinning motion.

We tried using a potentiometer to measure the angle at which our shooter was shooting at. We are still working on the code…

We used a potentiometer to measure the angle of our shooter.

We used THREE pots to tune our PID loops.

run each one into an analog.

P = analog
I = analog
D= analog

Inside the software, they had to be mutliplied by 0.0001 I think…then the value of the pot was the P,I,D values. Made for a very fast tunable system. Used that in conjuntion with LABVIEW to graph the output…it worked out great.

I wish I could find a picture of the pots, but I can’t. I do know our software is posted at frcsoft.com if you want to check out the software side of it. Once the tune was found, we hard coded the value into the software I think…I can’t remember it’s been too long…lol…

We used one (actually two, but the second was a backup) to measure the rotation of our shooter. :slight_smile:

Last year we used pots to read position on all three arm movements (height, left-right, angle) with corresponding pots on the OI for direct position control. Yes, we converted the values into degrees for the arm angle.

This year we used one pot in conjunction with two selector switches on the OI to adjust many values. I had hoped to implement storing these values in EEPROM, but never got that far. Still, setting the shooter speed and turret position PID loop values was easy. Once we found the values we wanted, we just hard coded those as defaults.

Ours, like always, is on our motor that turns the independantly steered front wheel. We’ve dont that for the past 3 years. Infinitely better than tank steer. lol

I’m very curious as to what your PID loops controlled. Do I presume correctly turret position, launch angle, and …

Our programming team decided to use a PID control method to keep the lookup table values we had calculated offline in check with our robot system.

In order to use a PID implementation, we needed some sort of feedback device. The gear tooth sensor provided in the 2006 kit of parts was our feedback sensor of choice to measure the velocity of the wheel. The velocity set point we determined would have to come from the camera by mounting the camera on a tilt servo. While the camera was instructed to seek out the green color of the illuminated light, software controls kept the camera tilt servo field of view (FOV) in the center. Once we acquired a center of target, we then knew the servo tilt pulse-width-modulation (PWM) value to make a reference of our tilt angle.

In order to prove our theories, a prototype team went to work right away building a wooden velocity wheel “rig”. A motor was mounted in a wooden chassis along with the gear tooth sensor. Because of our inexperience with PID control in the Innovation First controller, we had to understand the capabilities of the PIC microcontroller processing power and speed at which it could evaluate the gear tooth sensor to make a good closed-loop system. The first concern was that the gear tooth sensor would be wired and configured into the controller as a hardware interrupt. This sensor would interrupt the normal control loop of the controller thousands of times per second. Our first test comprised of a large tooth gear that would only induce about 200-300 interrupts per second. We found that this affected the resolution of the feedback system and made it very difficult to tune the PID. Low resolution meant our PID system responded “sluggish” no mater how hard we tried to perfect the tuning parameters. Tuning a system means adjusting the PID multipliers commonly known as Kp, Ki and Kd by adding in various amounts of these functions to get the system to behave the way you want. Our tuning method comprised of using National Instruments LabView Dashboard for a real time feedback process to see the response of the output based on our tuning parameters. In order to make quick on-the-fly adjustments, we built a PID tuning board out of three simple potentiometers. Each pot represented each value, Kp, Ki and Kd. The pots were wired to three of the analog ports on the Innovation First controller and software scaling replaced the tuning variables inside the code that was written.

Our final proto-type consisted of a very large gear with fine pitched teeth that induced about 1200-1400 interrupts per second and gave us the best tunablity of our PID system. Once we set a velocity in the software, the gear tooth sensor measured a scaled velocity value as feedback and the PID control kept the ball shooter wheel spinning at the desired velocity. Because our shooter mechanism would shoot 10 balls one right behind the other, this created a drag or velocity recovery on the ball shooter wheel. After each shot the velocity of the wheel would decrease. With the PID control system in place continuously in a closed-loop fashion, after each shot the gear tooth sensor would measure the velocity of the shooting wheel, if the velocity was below the desired set point, the controller would increase the speed of the shooting wheel to keep the ball shooting wheel at the desired speed to make the correct trajectory launch. Of course if the wheel was measured too fast, the controller slowed down the ball shooter wheel to keep the velocity at a maintained velocity.

Now that we had a workable PID system in place, we still need to input our PID system with the “set point” value. The set point was derived using basic trigonometry. The goal light was at a fixed height of approximately 10.5 feet. Because our camera was mounted at a known height, we calculated a distance using trigonometry by knowing the angle the camera is tilted to solve the distance from the light we are located.

The required ball velocity was solved offline using an Excel spreadsheet at certain angles. We called these angles our calibration angles. At each calibration angle we created a lookup table reference that we could code in the Innovation First controller. We then linearly interpolated points between our calibration angles to make up a 75 point or 75 angle lookup table. Each angle was assigned a velocity value depending on the angle of the camera, that velocity pointer was feed into the PID control loop to control the speed of the shooting wheel. This simplified the math the controller was required to execute and streamlined coding efficiency.

Basically the greater the camera tilt angle, the slower the velocity command was, the smaller the tilt angle, the faster the velocity command was, meaning the robot was deeper in the field.

Hope that helps.







We toyed with that, but decided not to waste the CPU time, instead using the A/D values directly. They came out to something like 1/23 of a degree for each count…

Don