Hi,
I’ve been experimenting with limitless potentiometers…and have found them to be a little unreliable. Has anyone else used infinite rotation potentiometers?? If so, what kind and were they reliable? We are just trying to find another sensor other than a 10 rotation potentiometer for rotation measurement. This is because we had something like 8 potentiometers break on us last year, mainly because they get locked inside due to load on the shaft . We were also thinking of encoders but are afraid of using too many interrupts and messing with the interrupts already used by sensors like the camera and gyros. Any advise?
Thanks
maybe try finding one of those 20 circular switches and then use some converters to so it doesnt take 20 I/O pins
There are magnetic field sensors that can replace pots and encoders. Check out this device.
http://www.gmw.com/magnetic_sensors/ametes/360ASMC.html
With a simple A to D you can Know the exact position of a shaft. There is no dead band as with some continous rotation pots.
Breaking Pots? A few years back we came up with a solution in 2005, we engineered a POT Holder and custom spring idea. Basically what happens is if you over turn the pot instead of the pot breaking if it is directly connected to the shaft and special spring will slip instead to protect the pot(the spring is connected to the pot shaft and the other end to the actual shaft). The spring is wound on a wooden cork and allows no slippage during regular use, so you don’t lose any precision in your pot readings, it only activated AKA slips when the pot reaches its limit. I have posted a link below to a picture of what it looks like. In the picture look for the white color HDPE holder with a pot at the bottom of it. You can kind of see the wooden piece to the spring, but if you want more details just ask and i will try to get more pictures for you.
http://http://aceshigh176.org/drupal/index.php/v/2007/Scrimmage/100_0143_001.JPG.html?q=gallery
Just this past year team 1024 used a pair of MA2 Absolute Rotary Encoders from US Digital on our drivetrain.
Seriously, I know everyone hears analog and thinks totally noise immune. Really, with a tiny bit of smart EMF design it wasnt a problem. However, I know personally I’d rather use a digital optical shaft encoder, but unfortunately our robot this past year was really fast and to get any kind of resolution out of the encoders the frequencies got rediculous at the top end, so much so it was impossible to track without losing counts.
So, hence the move the the MA2. The driver took just one evening to write, and works like a charm. Instead of having an interrupt in the multiples of KHz, we only had to sample the encoder at 100Hz. Best of all, you get the ability to handle a high top-end RPM without sacrificing low-end RPM positioning accuracy (our robot last year could position +/-0.05 inches at the frame).
Again, as long as you can do a decent EMF design to keep the analog signals from the encoders safe, they work like a charm. Definitely worth your time to at least research.
Questions? Post.
-q
Have you considered how you mount your pots? It seems that if you are having mechanical problems with the pot due to load on the shaft, you need to think about how to mount it to have less load. For example, if you are using it to calibrate an arm, it is tempting to tie it directly to the axis of rotation. However, you could put a gear on the pot arm and a gear on the arm axis and use a chain (belt?) to turn the pot.
It is a bit more complex mechanically, but you decouple the sensor from the load bearing mechanicals, and you can adjust the amount of play you need from your pot by adjusting the gearing between the pot and the motion you want to measure.
I think we did that last year with our robot. We had a multi-turn pot to measure the movement of the tube lifting rack. It was mounted parallel to the top of the rack with a gear that transferred the motion of the rack to the pot. I think we lost a pot due to a collision, but never due to rack loading.
A few years back I experimented with continuous turn (No Mechanical Stop) Potentiometers. For my application however, the rollover from 0-1023 was too fast for the code to work with to recognize and adjust accurately for the rollover.
These are the ones I used. I found them to be reliable, and consistent.
At that I time I had obtained them from Newark-In-One.
I can’t say if they still stock them or not.
Here’s a link to the data sheet.
We have been using rubber tubing to connect the shaft of a potentiometer to a shaft that we are trying to measure the angle of rotation. If you pick the right rubber tubing, the shaft will slip if you try to rotate past the stop. We also incorporate limit switches into any arm design to insure that we don’t break anything mechanical, including the potentiometer.
We have been playing with a Vishay/Spectrol position sensor P/N 601-1045-000 (Part No 594-601-1045 from Mouser). It outputs a smooth 0 to 5 volts in 360 degrees and is very sturdy mechanically. Only downsides are the abrupt jump from 5 volts to 0 volts at the 360/0 degree position, and the cost (about $60).
Don
Sorry to hijack the thread, but I’m wondering how you would tell what direction you moved. I don’t doubt this can work very well for something that only goes under a revolution. However, let’s say you moved from 100 degrees to 200. How do you know if you moved 100 forwards or 260 back?
Thanks.
1 Like
I found the best method is simply to use a POT that has more turns than is required. For both joints of our arm this year, the arm would hit the frame or the ground before the shaft would break. Now, we obviously has limits so this wouldn’t happen, but we never had to worry about a POT breaking.
Encoders don’t need to be hooked directly to the RC. A little custom circuit using a PIC microcontroller (or other device… consider a VEX RC) can decode several encoder signals.
This means that while you might still use interrupts on the RC to count the rotations, they need not be as frequent as with a direct connection, nor do you need to worry about tracking the timing to determine direction using the RC. Heck, you could even have the custom circuit send a serial data pack of shaft position and velocity to the RC upon request if you really wanted to get creative.
We had a circuit set up like this for the gear tooth encoders a couple years back in the event we needed to use it, and used a similar… although simpler board from banebots with the encoders for the 56mm gearboxes this past year.
Using the banebots boards we had no… well… almost no… problems reading inputs from four encoders. For joints with less than about 270 or 300 degrees rotation, pots work great. (And sliding pots work great, too for linear applications of a few inches or so… although now that I think of it… why couldn’t a long length of nichrome serve as a very long linear pot…?) But in any case for continuous rotation, making an encoder work will be more than worth your time.
Jason
Sorry for the hijack, but…
Have you ever looked into using WPILib?
I know you said you wanted to stay away from encoders, but WPILib makes all the interrupts you mentioned painfully easy and very hard to screw up. Our team has been using pots for the last few years, but after beginning to use WPILib, we switched to encoders with relatively few problems.
You choose a sampling rate such that you can never move more then 180 degrees per sample. If you see a change less then 180, you’re moving forward, if you see a change greater then 180, you’re moving back.
We used continuous turn pots for our drive last year very successfully. We followed the directions in this white paper: http://www.chiefdelphi.com/media/papers/1743
There are a couple of different ways to approach rotation sensing, and one you might not have thought about is a light sensor combined with a state machine. A couple of pictures of this are in the 2006 FIRST design book.
Take a light sensor that’s not mounted on the rotation and have it reflect off a plate that is mounted on the rotation (or vice versa). Where you want the rotation to stop, mark it with a black sharpie. It’s literally that simple, but at the same time it’s not as robust as other sensing methods.
Another way to do this, if you’re trying to measure drive train ticks, is to put a mark parallel to the axle shaft on a shiny part of one of your rotational pieces. This will give you only one interrupt per rotation. If you want it to be more accurate, put 2 marks to give you 2 interrupts per rotation.
The other thing you could do is ask for pictures of how others mounted their potentiometers. We only had 1 pot on our bot in 2007, but it never broke. It was mounted to the inside of 1/4 the length of a hinge, so the hinge bolt itself took most of the load.
We used encoders on are drive train for the wheel rotation. It worked fine and never broke. It was also very reliable. However we had a pot on the arm and that broke a lot we went through quite a few of those. Mainly because it was not protected very well though. When it was working it did not give very consistent readings though
Here are my tips regarding potentiometers:
- Use the best quality pots you can get - 0.25$ pots wont perform as well as the 3-4$ pots… it’s a small amount that’s worth it.
- mount the pots securely making sure they cannot move.
- pots should not be load bearing parts. use them in a place where they will not be damaged by the load applied to your robot.
- remeber that if you need accuracy it is best to use a small gearing system that should make the pot turn more, that way you are minimizing the effect of the looseness in the pot itself.
that’s about it I guess… good luck!
-Leav
We use Digi-Key part 6639S-1-103-ND for our arms and linkages. It is a Bourns Series 6639 potentiometer. It provides electrical output over 340 degrees of rotation but there are no mechanical stops in it. That means it is easy to install and calibrate since you do not need to worry about breaking the stops due to over travel. It is somewhat expensive at $11.
Hi
Team1629 uses this pot from Mouser.com (My favorite parts vendor)
http://www.mouser.com/search/refine.aspx?Ntt=594-357-00-502
Datasheet here:
At $15 it’s not cheap, but it gave us position feedback on our 2007 arm position all season and several off-season competions with no problems.
Phil.
Before I even start, here’s the, well, you might call it the Nyquist rate for sampling these rotary analog encoders (aka Limitless Pots). Unless you use adaptive sampling rates (DO NOT if you are using a PID and don’t want to have dynamic constants on the terms) you have to sample the voltage about four times per revolution, or else you won’t know which way you went (there may be a more efficient way but this is what I used last season). Therefore, I suggest you figure how many RPM the shaft you are coupled to could do in the worst possible situation, then add some to that (use your engineering sense). Obviously if you miss a revolution you’ll be in trouble and have problems like you mentioned above.
I drew a diagram (using my graphic tablet I got on Black Friday… :] ) that explains how this system works. Essentialy you break the waveform that the analog encoder outputs into sections, and do a state-based decode. Since you’re sampling at a rate four+ times that of the rate of revolution, you will be able to detect a high-contrast change in the values comming back from the analog encoder and be able to figure that you went from a high-to-low or low-to-high transition, thus indicating the direction in which you moved.
Aside from that, the rest of the system functions on deltas: you add or subtract how much the values have changed depending on which direction the analog encoder is moving.
Here’s the code snippet that handles one of the analog encoders (there were two) on our robot. This function was called at a rate of 100Hz using a CCP module for timing (it also was running a high-performance pwm signal for the pid’ed traction motors on the robot):
void encoder_left_handler(void)
{
if(ServoOn) //if servos running, sample encoder
{
leftencoderpos = Get_Analog_Value(LEFTENCODER); //get value from other encoder
if (leftencoderpos <= 253)
{
leftencoderstate = 0; //state a
}
else if (leftencoderpos <= 505)
{
leftencoderstate = 1; //state b
}
else if (leftencoderpos <= 757)
{
leftencoderstate = 2; //state c
}
else
{
leftencoderstate = 3; //state d
}
if (leftencoderstate == 0 && oldleftencoderstate == 3) //from top to bottom, rev
{
//going backwards
leftencoder -= (int)((1009 - oldleftencoderpos) + (leftencoderpos-2));
}
else if (leftencoderstate == 3 && oldleftencoderstate == 0) //from bottom to top, fwd
{
//going forward
leftencoder += (int)((1009 - leftencoderpos) + (oldleftencoderpos-2));
}
else //intra-state position calculation
{
if (leftencoderpos < oldleftencoderpos)
{
//goingfwd, intra state
leftencoder += (int)(oldleftencoderpos - leftencoderpos);
}
else
{
//goingbkwd, intra state
leftencoder -= (int)(leftencoderpos - oldleftencoderpos);
}
}
oldleftencoderstate = leftencoderstate; //save encoder state
oldleftencoderpos = leftencoderpos; //save old encoderposition
} //end if servo on
//...
This system works very very well, we used it to run a 100Hz update rate PID (as I stated before, we were feeding the Victors a 16-bit PWM signal at 100Hz as well as opposed to the standard 8-bit 39.37Hz) which performed with silky-smooth motion control during our post-season autonomous work. I definitely reccomment analog encoders. As long as you show 'em a little love with shielded cables, smart wiring (keep the wires short!), and a little software know how, you get fantastic positional accuracy without the need to handle extreme high frequency (in the KHz) interrupts at high speed.
Questions? Post! 
-q
