Encoders (What's up with those?)

[matthewdenny]

So our official season is done, but we are looking forward to some off-season events. In our attempt to remedy some weaknesses from the season we are looking to add an encoder to our shooting system. It is a miniCIM connected by ~.9 Gear ratio to a pneumatic wheel.

We have no idea what kind of sensors to look into, where to purchase them, or how to install them. Any help would be great. Thanks!

[Ernst]

We have never had much luck mounting US Digital (http://www.andymark.com/product-p/am-0174.htm) encoders to flywheels. We also haven't had luck with using another motor as a tachometer. This year and last year for flywheels we used photoelectric sensors (http://ab.rockwellautomation.com/Sensors-Switches/General-Purpose-Photoelectric-Sensors/RightSight-Sensors) pointed at retro-reflective tape strips stuck to the wheels. We have 6 strips of the tape stuck evenly around the wheel this year. 6 ticks = 1 revolution. Our speed control has had quick responses and accuracy.

[Tom Line]

Photoswitches are definitely the way to go. At the wheel speeds teams are using, finding encoders with shafts is difficult. Shaftless encoders like the US digital are a little touchy, and require decent tolerances too.

Optical sensors, on the other hand, will give you excellent speed control while allowing just about any alignment you feel like. There are a number of threads on this, however, so I suggest you search some of them out.

http://www.chiefdelphi.com/forums/showthread.php?t=111502&highlight=photoswitch

[Ether]

We have 6 strips of the tape stuck evenly around the wheel this year. 6 ticks = 1 revolution.

How are you decoding the signal from the photosensor? i.e. Are you reading the number of counts, and dividing by elapsed time, or are you using getPeriod() to read the elapsed time between pulses?


Our speed control has had quick responses and accuracy.

What speed control algorithm are you using? PID, TBH, bang-bang, something else?

[Ernst]

How are you decoding the signal from the photosensor? i.e. Are you reading the number of counts, and dividing by elapsed time, or are you using getPeriod() to read the elapsed time between pulses?

What speed control algorithm are you using? PID, TBH, bang-bang, something else?




I wasn't involved with the programming. Sorry. I'll try to direct my team's main programmer to this thread.

[propionate]

How are you decoding the signal from the photosensor? i.e. Are you reading the number of counts, and dividing by elapsed time, or are you using getPeriod() to read the elapsed time between pulses?

What speed control algorithm are you using? PID, TBH, bang-bang, something else?





Fortunately, I just made a video this weekend explaining how it all works. (It was for the SpaceX FIRST application, hence the title).

http://www.youtube.com/watch?v=zzNLlAUbbcU

Edit: Might only leave this up for a little while. Watch it quick!

[asteb27]

Our speed control has had quick responses and accuracy.

How did you measure how accurate you were?

Photoswitches are definitely the way to go. At the wheel speeds teams are using, finding encoders with shafts is difficult. http://www.chiefdelphi.com/forums/showthread.php?t=111502&highlight=photoswitch

We have encoders in the 10,000 rpm range. I know some teams are running faster than 10k rmp, but plenty (like us) are running much slower than that.

I've used both of the following with no problem

http://www.digikey.com/product-search/en?mpart=63R256&vendor=136

http://www.usdigital.com/products/encoders/incremental/rotary/shaft/S1

[propionate]

How did you measure how accurate you were?



No in-depth analysis. 0 to shooting speed is about one second. Recovery time between shots is about 300ms, accurate to within .2% speed (plenty close for what it's being used for). Barring human error, we can hit around 95% accuracy just from tests in the shop. On the field we're closer to 80 or 85% because of human error/flywheel wear and tear.

[asteb27]

No in-depth analysis. 0 to shooting speed is about one second. Recovery time between shots is about 300ms, accurate to within .2% speed (plenty close for what it's being used for). Barring human error, we can hit around 95% accuracy just from tests in the shop. On the field we're closer to 80 or 85% because of human error/flywheel wear and tear.

I couldn't tell from the code (we use java), but do you actually measure rpm with this system? if you do, I'd be interested to see how it compares to a tachometer reading.

Any reason you use retroreflective tape? From what I could tell, you weren't shining a light at it.

[Ether]

Fortunately, I just made a video this weekend explaining how it all works. (It was for the SpaceX FIRST application, hence the title).

http://www.youtube.com/watch?v=zzNLlAUbbcU

Edit: Might only leave this up for a little while. Watch it quick!

Would you be interested in discussing this? If so, I have a few observations to make, and a few questions.

[T^2]

We've used both this (http://usdigital.com/products/encoders/incremental/rotary/kit/E5) shaftless encoder and this (http://usdigital.com/products/encoders/incremental/rotary/shaft/S4) shafted encoder from USDigital on our shooter this year, with a fair amount of success with each. The female encoders are definitely a bit more finicky. If you need help with mounting any kind of encoder, ask.

[propionate]

I couldn't tell from the code (we use java), but do you actually measure rpm with this system? if you do, I'd be interested to see how it compares to a tachometer reading.

Any reason you use retroreflective tape? From what I could tell, you weren't shining a light at it.

The photoelectric sensors are pulled into LabVIEW as encoders. The encoder VI then takes the counts/second and calculates the rate. So it isn't precisely RPM - would have to be scaled to account for the fact that there are six pieces of tape.

And we just found retroreflective to give the best response (in terms of distance the sensor could be from the wheel). Gave us more wiggle room, so to speak.

[propionate]

Would you be interested in discussing this? If so, I have a few observations to make, and a few questions.




Sure, go ahead. The video length had to be 2 minutes or less so I had to skip a lot of details unfortunately.

[Ether]

Sure, go ahead. The video length had to be 2 minutes or less so I had to skip a lot of details unfortunately.

OK here goes :-)

Is there a reason why you used the encoder VI, instead of the counter VI, for this non-quadrature sensor?

Why did you use 6 pieces of tape, instead of just one?

In an earlier post you said that your speed control is accurate to within 0.2% of point. What test equipment did you use to independently measure the wheel speed to make this determination?

Are your motors directly connected to the wheel, or are there gears or belts or chains between them?

What motor controllers are you using for the shooter motors?

What is the range of wheel speeds you are controlling?

Why did you need a custom PID? Did you try other methods (LabVIEW PID, TBH, bang-bang) and they didn't work?

[Ernst]

OK here goes :-)



I can answer some of these. We have CTRE Talons controlling BaneBots 550s which drive 4:1 gearboxes.

[propionate]

Is there a reason why you used the encoder VI, instead of the counter VI, for this non-quadrature sensor?

This is actually just a habit now. When I made my first feedback control loop for a flywheel last year, I had some trouble getting it to work using the counter. On a whim, I tried inputting them as encoders and it worked great. I've since figured out how to do it with the counter VI (some simple problem with the math I had), but never switched back.

Why did you use 6 pieces of tape, instead of just one?

This was the recommendation of a mentor. His explanation was that it allowed for a 'finer' count. I have tried it with just one piece of tape and didn't notice any significant different (just different scaling).

In an earlier post you said that your speed control is accurate to within 0.2% of point. What test equipment did you use to independently measure the wheel speed to make this determination?

I should have said, the PID controller keeps the flywheel within a .2% error based on the readings from the photoelectric sensors. If those readings themselves are incorrect, then I'd have to rescind that statement.

Are your motors directly connected to the wheel, or are there gears or belts or chains between them?

See post by team member above. Directly connect w/ 4:1 gearboxes.

What motor controllers are you using for the shooter motors?

See above - talons.

What is the range of wheel speeds you are controlling?

Do you mean in RPM? I'd have to check my documentation at the shop, I can't remember off the top of my memory.

Why did you need a custom PID? Did you try other methods (LabVIEW PID, TBH, bang-bang) and they didn't work?

The LabVIEW PID has worked fine for us in the past, but it's always more fun to write the code yourself, to a reasonable extent. Better learning opportunity for rookie programmers. I don't have much experience with the half-back or bang-bang controllers, so I can't comment on those. Would be interesting to try them though and see how they compare. Sorry I don't have a good response for this one!

[Ether]

...

Thanks for the detailed answers.

I don't have access to the LabVIEW help files here, so one more question:

Can you tell me what the "12" input is for in the "Configure Timer" vi, and why did you chose that particular number.

[propionate]

Can you tell me what the "12" input is for in the "Configure Timer" vi, and why did you chose that particular number.





Number of samples to average. I think it was a bit of trial and error until we got a smooth reading from the photoelectrics.

[Ether]

Number of samples to average. I think it was a bit of trial and error until we got a smooth reading from the photoelectrics.

Can you tell me, the way you have the encoder configured, is it sampling both rising and falling edges?

[propionate]

Can you tell me, the way you have the encoder configured, is it sampling both rising and falling edges?




I believe it's configured to only count on the rising edge. I can check this tomorrow if you'd like.

[Ether]

I believe it's configured to only count on the rising edge. I can check this tomorrow if you'd like.

Yes, please do. I'm going somewhere with this...

[propionate]

Yes, please do. I'm going somewhere with this...




Now that you're making me rethink this, it may not make a lot of sense to be averaging every 12 samples. It looks like the default is actually 1. I'm not sure if this is an error or not... I will definitely investigate this tomorrow.

It works wonderfully right now, but this could be the path to making it better.

[Ether]

Now that you're making me rethink this, it may not make a lot of sense to be averaging every 12 samples. It looks like the default is actually 1. I'm not sure if this is an error or not... I will definitely investigate this tomorrow.

It works wonderfully right now, but this could be the path to making it better.

You probably don't want the default of 1 with six pieces of tape, especially if it's sampling both rising and falling edges.

Try this: one piece of tape with the default sample size of 1 and setup to sample rising edges only. That way, it's always sampling the same edge of the same piece of tape, so the spacing is perfect... and with your 20ms update rate, you'll be getting a fresh reading every execution or your controller loop at wheel speeds of 3000 RPM or higher.

[propionate]

You probably don't want the default of 1 with six pieces of tape, especially if it's sampling both rising and falling edges.

Try this: one piece of tape with the default sample size of 1 and setup to sample rising edges only. That way, it's always sampling the same edge of the same piece of tape, so the spacing is perfect... and with your 20ms update rate, you'll be getting a fresh reading every execution or your controller loop at wheel speeds of 3000 RPM or higher.




I will give this a go tonight and let you know the results. Thanks for the recommendations.

[propionate]

Sorry, didn't have any opportunity to do the tests this evening. I will send you a private message with the results when I do have a moment with the robot so as to not clutter up this thread any more.

[Doc Wu]

Any reason you use retroreflective tape? From what I could tell, you weren't shining a light at it.

The Banner photoeyes they used are retroreflective units - they have an emitter and detector in the same housing.