I wasn’t involved with the programming. Sorry. I’ll try to direct my team’s main programmer to this thread.
Fortunately, I just made a video this weekend explaining how it all works. (It was for the SpaceX FIRST application, hence the title).
Edit: Might only leave this up for a little while. Watch it quick!
How did you measure how accurate you were?
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
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.
Would you be interested in discussing this? If so, I have a few observations to make, and a few questions.
We’ve used both this shaftless encoder and this 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.
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.
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?
I can answer some of these. We have CTRE Talons controlling BaneBots 550s which drive 4:1 gearboxes.
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!
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.
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?
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…
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.
I will give this a go tonight and let you know the results. Thanks for the recommendations.