Limitless Potentiometers

[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