First of all I want to say
THANK YOU to everyone who replied to this thread! This information has been EXTREMELY valuable to me.
Second:
Based on what many people in this thread have said, I think Dillon and I are
going to use an optical encoder system for simplicity's sake. It sounds like many teams have had success with them, and they don't need to be replaced as often as mechanical ones do.
Quote:
|
Originally Posted by oreocookeee
3) first, using the gear teeth as a cam for the encoder would provide much more "clicks per revolution" than you would need, and the speed may surpass the ability of the encoder. convoluted teeth are also an awkward curve to follow, putting a lot of stress on the teeth and the encoder. perhaps you could cut depressions in the side of the gear to make it a little easier to follow, and allowing you to adjust the click rate.
|
Yes, you are right that in the paint sketch I made there would be way too many clicks per revolution. It was supposed to illustrate the concept more than anything...it wasn't really supposed to be a precise drawing. Same thing with the convoluted teeth...it's really hard to make a good paint sketch of a gear! But thank you for the suggestions anyways!
Third:
At our last robotics meeting,
I wired up the banner sensor to our robot, and it is working perfectly. I tested to see if it would detect the difference between black and white on the pattern that Tom posted (thanks Tom!), and it did.
We have
written a program for it to count stripes, but we haven't downloaded it yet (We ran out of time last meeting). We decided not to use interrupts, because we are still in the learning process and don't want to mess up the controller by making mistakes. Instead, we just have a counter that will increment every time it detects a change in the color. Each time the program runs through, it checks the new value that is being read against the value that it last read, so that it doesn't keep incrementing if the pattern is stationary and it is reading the same color. We also have a debug command so we can see if it is counting right and that everything is happy.
Even though this approach may not be fast enough to count ticks when the robot will be traveling very fast, this seems adequate enough for testing and learning purposes.
And speaking of learning...
Does anyone have an example of code that uses interrupts for an optical encoder like this one? I have read the quadrature encoder white paper, and I have the code examples from there, but since this is not a quadrature encoder setup I would like to see some examples that work before I start experimenting on my own.
All of your help has been greatly valuable to me and my team. This sharing of knowledge is what makes FIRST great.
Thanks,
-- Jaine