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 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 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/sh...ht=photoswitch

[Ether]

Originally Posted by ZehP

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]

Originally Posted by Ether

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]

Originally Posted by Ether

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!

[Ether]

Originally Posted by propionate

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.

[propionate]

Originally Posted by Ether

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]

Originally Posted by propionate

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]

Originally Posted by Ether

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]

Originally Posted by propionate

...

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]

Originally Posted by Ether

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]

Originally Posted by propionate

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?

[asteb27]

Originally Posted by ZehP

Our speed control has had quick responses and accuracy.

How did you measure how accurate you were?

Originally Posted by Tom Line

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/sh...ht=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-searc...256&vendor=136

http://www.usdigital.com/products/en...otary/shaft/S1