Limitless Potentiometers

[=Martin=Taylor=]

Originally Posted by 987HighRoller

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

Our team has used magnet-sensors many times in the past. These sensors work two ways. Either you can glue magnets on a rotating surface and read them as they go by (like a big LP record).

Or you can actually sense the teeth of a sprocket - without any sort of preparation - provided of course that the sprocket is made of steel.

These sensors are a lot more durable than potentiometers since they have no physical coupling with the robot's moving parts.

We have used them in 2005 and 2007. However I think we had to make custom circuit boards for them.

[ericand]

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.

[Phalanx]

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.

http://www.vishay.com/product?docid=...odel%20357

[gburlison]

Originally Posted by 987HighRoller

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

[DonRotolo]

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

[basicxman]

maybe try finding one of those 20 circular switches and then use some converters to so it doesnt take 20 I/O pins

[Gdeaver]

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.

[desi_technology]

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

[Qbranch]

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

[Guy Davidson]

Originally Posted by Qbranch

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

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.

[AdamHeard]

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.

[dtengineering]

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

[slavik262]

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.

[Joe Ross]

Originally Posted by sumadin

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.

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

[Qbranch]

Originally Posted by sumadin

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.

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