Low Res Optical Encoders for Speed Control
 

This summer, Team 20 is revisiting a problem we experienced during the competition season. We had our shooter wheels powered by Banebots RS550s and on speed control with a 360 count encoder on each shaft connected to CAN jags. However, when our jaguars kept having brown-outs in CAN, we switched to PWM control, which meant we could not use the 360 count encoders for speed control at such high rpms (bye-bye shooting accuracy).

So now we are trying to resolve the CAN issues, but in the event that we cannot, we would like to have a back-up plan to get closed loop control with PWM. This would require a different sensor then we are currently using to measure rotation (we are currently using 360 count US Digital E4Ps).

Has anyone had experience with low-resolution optical encoders? And by low resolution I don't mean 64 or 100 counts per revolution, but more like single digits. I found this while searching on Digi-key:

http://www.digikey.com/product-detai...008S-ND/954400

, but I'm accustomed to using 4 pin connections with encoders (power, ground, A channel, B channel), and the ones I am finding all have 6 pins. The additional 2 pins have something to do with a switch according to the datasheets, but I have no clue how to work with that. Has anyone worked with something similar before or does anyone have other suggestions? The reason I'm interested in low-res optical encoders is because we know how to work with them, but I have seen teams with other solutions, so if there are other simple and effective ways to do the task we'd love to hear about those too.

Re: Low Res Optical Encoders for Speed Control
 

Our team used a optical sensor with a 1ms response time, and had that going through a flywheel that had 3 holes. At 5000 rpms, that required about a 2ms response time, and it always worked. I know that other teams (341 in particular) used the retroreflective sensors from last years KOP, which worked as well.

Re: Low Res Optical Encoders for Speed Control
 

Why not?

If you put the 360 count encoders on the wheel shaft, that's 24000 counts per second at 4000 wheel rpm. The FPGA can handle 40,000 counts/sec

Use only one channel of the encoder and use the Counter class to trigger on rising edge only.

Re: Low Res Optical Encoders for Speed Control
 

We have a 2 axle shooter, so if we had 2 axles reading that fast, could the FPGA handle it? I.E. would that then become 48,000 counts/sec? Also, are there other variables that could affect the FPGA and how it counts the encoders, and where can I read up to learn more about it?

Re: Low Res Optical Encoders for Speed Control
 

I believe each FPGA input channel can handle 40,000 counts/sec. Perhaps someone with intimate knowledge of the FPGA could comment.

Download a copy of the WPILib C source code and read the descriptions of the methods in the Encoder and Counter classes.

Re: Low Res Optical Encoders for Speed Control
 

I know we were having issues with the 360 count encoder on our shooter but that may have just been our setup. We end up moving to a cheap IR reflective sensor and piece of white tape and it's worked perfectly.

Re: Low Res Optical Encoders for Speed Control
 

Not that I'm an expert on the API or anything, but looking at the LV implementation, there are four 4x encoders and eight counters that can be used for 1x and 2x. As stated before, they are running on the FPGA and run in parallel along with each other, PWM generation, triggers, etc. So, the encoders will not be an issue.

Greg McKaskle

Re: Low Res Optical Encoders for Speed Control
 

I think the actual number is 39,230.

Re: Low Res Optical Encoders for Speed Control
 

Our team uses Java. I'm not much of a programmer as it relates to the robot, but I have a bit of experience.

I notice that all of the constructors for Encoder objects require both an A channel and B channel as arguments, whereas the Counter constructors allow you to specify a single channel. Is this why we would use the Counter class to only count the rising edges? The Counter class doesn't have a getRate method, but would the getPeriod method return values that are useful for what we're trying to do?

And I noticed that 1x, 2x, and 4x counting are mentioned in the descriptions of many of the methods in the Encoder class. Is this something we need to consider when using the Counter class as well?

Re: Low Res Optical Encoders for Speed Control
 

You could use the getperiod method which returns the elapsed time between the two most recent edges, or you could read raw counts and divide the change in counts by the actual elapsed time since the counts were last read.

Each method has its pros and cons, and teams have been successful with both methods.

One or the other might be more appropriate depending on your encoder speed and the control algorithm you plan to use.

Re: Low Res Optical Encoders for Speed Control
 

We also had trouble with the 360 res quad. US Digital trying to control up to 1500 rpm with pwm. We switched to 100 res single channel, at it worked great.

Re: Low Res Optical Encoders for Speed Control
 

I'm not the one to go to for technical answers, but this year, we actually put our encoder on a gear reduction from the shooter so it wasn't running as fast as the shooter, and then compensated accordingly in the calculations.

My 2 hillbilly pennies.

Re: Low Res Optical Encoders for Speed Control
 

We are using a 360 count s4 encoder from US Digital, we basically use the same PID loop with feed forward that 341 does.

We were getting our shooter +- 25 rpms pretty easily.

-RC

Re: Low Res Optical Encoders for Speed Control
 

While helping team 842 this year, we found that there are issues with using the 360 counts/rev encoders at the speeds we needed. never got around to actually debug what the issue was. They were using about 6/7 feet of wire routed next to motor wires and that may have been an issue. the reading were erratic changing by a a magnitude of 2 when they were graphed.

To resolve this, we removed the plastic disc from the encoder wheel and replaced it with piece of electrical tape on the disk so we had 1 rising and 1 falling edge. We were able to run the control system to achieve the desired RPM using the modified encoders.

Re: Low Res Optical Encoders for Speed Control
 

This is the sort of workaround I'm interested in if we can't do it with a 360 count disc. The only thing that would usually concern me about this approach is a layer of tape (which if I remember correctly is thicker than the plastic disc) could change the tolerance on the encoder for the distance from the sensor to the disc. Was this even an issue, or could it be easily resolved if it does present a problem?

Re: Low Res Optical Encoders for Speed Control
 

The point is, you can do it with a 360 CPR encoder.

As with any sensor, make sure you're getting a proper signal before trying to tune the control algorithm.

Re: Low Res Optical Encoders for Speed Control
 

Ether,

we had 2 wheels and hence 2 encoders. Would that cause any problems?

also, I am not sure how much to be worried about the singal integrity over the 7 feet of wire that the students had wired next to all other wires. including the 20kHz jaguar output wires going to the motors.

Re: Low Res Optical Encoders for Speed Control
 

Since you only have 2 transitions, it would be better to space the disc off the actual distance so the image is not focused. When the encoder dist was spaced correctly, it was picking up an extra tick from a scratch on the aluminum. We put the disc closer to the sensor to make it blurry so it does not pick up small scratches.

Re: Low Res Optical Encoders for Speed Control
 

I'm not doubting that its possible, just doubting our ability to realize that possibility based on our past results. I've also seen so many successful teams with single digit CPR sensors that it got me thinking that if we weren't having success with the 360 count, we could try something else.

We will try it though, and thanks for the help!

Re: Low Res Optical Encoders for Speed Control
 

Be very careful when you look at encoders. the operating RPM for that is 120 which is far below the needed rotation rate.

Re: Low Res Optical Encoders for Speed Control
 

No. (But see the following note about wiring).

You should be worried enough to test the sensor signals thoroughly before trying to tune the control algorithm. But then again, it's proper practice to do that anyway.

For the record, Jag PWM frequency is 15KHz.

Re: Low Res Optical Encoders for Speed Control
 

I know we found a way to insolate the wire from interference and we were +/- close to 100 rpm before. After, we got it to +/- 1 rpm. I'll talk to the guys who did that and see what they actually did; I think it had some metal foil involved, so perhaps there was a faraday cage effect?

Re: Low Res Optical Encoders for Speed Control
 

I'll bet you can do it :)

You said in your original post that you had the 360CPR encoders working with the Jag. So that indicates that you have the encoders properly mounted and aligned, which is half the battle.

Something to consider: the fewer the counts per revolution, the "staler" your sensor signal will be (more phase lag). If your wheel has enough inertia that probably won't matter. Just something to keep in mind from a control theory point-of-view.

Re: Low Res Optical Encoders for Speed Control
 

Please do. I think this would be of substantial interest.

Re: Low Res Optical Encoders for Speed Control
 

We were worried about the little shaft of a US Didital encoder spinning at such a high rate for so long as well as the high number of counts flying around. I guess many teams did this it and it worked okay so our worries were misplaced.

We used a small 14 tooth steel sprocket and a Hall effect gear tooth sensor for a no-worry solution. Our wheel speed control was rock solid but that may have also been because we had a high mass shooter wheel.

Re: Low Res Optical Encoders for Speed Control
 

reported

Re: Low Res Optical Encoders for Speed Control
 

Can you share what you found out?

Re: Low Res Optical Encoders for Speed Control
 

Yes, it could handle it. Each input is independent.

Re: Low Res Optical Encoders for Speed Control
 

Our meeting last week was cancelled, but we are meeting tonight to work on this exactly. I will post it here when I find out. Thanks for the reminder.

Re: Low Res Optical Encoders for Speed Control
 

So it turns out the wire we used is 22 AWG shielded cable which the mentor says is available from Digikey. It has five 22-gauge wires (we only used 4) and these are wrapped with aluminum foil. Around the aluminum is more insolation. The aluminum foil is twisted at one of the ends of the cable, and grounded to the source ground (the jaguar 5 pin connector's ground in this case). It is important to only ground one side of the cable and not both, otherwise you could create a closed circuit, which may cause EMI if there is current going through the foil. My sources say you could also get away with grounding to the frame, but I don't think this is legal and it is usually better practice to ground it to a source anyway.

"[R38]
All wiring and electrical devices, including all control system components, shall be electrically isolated from the Robot frame. The Robot frame must not be used to carry electrical current."

I could see how both sides could be argued. I don't quite know if the aluminum is considered part of the "wiring", or if this would be considered carrying electrical current by the frame, but this is a tangent anyway since it can be grounded to a source.

I wouldn't usually think about the EMI on our robots, but looking at the number of sensors, motors, and other electrical components on that robot in comparison with our past robots, it's not surprising that this would be the one out of all of them to benefit from shielded sensor wires. I could post pictures if anyone is interested.

Re: Low Res Optical Encoders for Speed Control
 

By the way, we were able to get the robot shooting about 50% last night without speed control. This was using the camera feed to the driver station for manual aiming and we had driver voltage control on the shooter motors. We may work toward integrating a simple non-PID speed control algorithm and vision processing from there. The vision processing part was complete during the build season, we just need speed control that works in PWM or to get our CAN working.

Re: Low Res Optical Encoders for Speed Control
 

If it's not too much trouble, please do.

Re: Low Res Optical Encoders for Speed Control
 

posted here, there are 3 pictures:
http://www.chiefdelphi.com/media/photos/38088?

Re: Low Res Optical Encoders for Speed Control
 

Were you thinking of trying a bang-bang controller, or perhaps a take-back-half?

Re: Low Res Optical Encoders for Speed Control
 

Thanks. You got a lot of hits. I guess there was some interest :-)

Re: Low Res Optical Encoders for Speed Control
 

We haven't decided exactly yet. Haven't hooked the encoder backup since we stopped using it in competition, so that's the first step along with verifying that it works.

I had thought of a bang-bang approach where we base the original voltage on motor curves, then if the speed drops X% below the target speed, raise the voltage by Y%, or if the speed exceeds the target by X%, lower the voltage by Y%. X would be the max allowable deviation from the target speed and Y would be an experimentally determined voltage correction. If its between 100-X % and 100+X %, we would apply no voltage correction.

I'd also like to see what the students come up with. After reading about take back half control here:
http://www.edn.com/design/analog/432...ence-algorithm
that seems like a good option. It looks like a good opportunity to explore different speed control options so we may try multiple approaches to see what gives us the best results (at least that's what I would like to see).

Re: Low Res Optical Encoders for Speed Control
 

There's a lengthy discussion (and paper) of bang-bang here, if you haven't seen it yet:

http://www.chiefdelphi.com/forums/sh...d.php?t=105679


Here's a thread (and paper) on take-back-half:

http://www.chiefdelphi.com/forums/sh...d.php?t=105965