We’re looking for sensors to try out in these last few weeks before Kick-off.
Does anyone have any from last year that they didn’t use? We particularly would like to try out a gear tooth sensor.
Or does anyone know a supplier from whom we could purchase on?
thanks,
elaine
Team 2523
St. Johnsbury Academy
Personally I don’t like Gear Tooth Sensors but if you decide to use them keep in mind that mounting is very important, you do not want them being able to get loose and go INTO the gears.
Here is a link to the actual sensor from the KoP sensor from 2008 http://www.allegromicro.com/en/Products/Part_Numbers/0642/
Hope that helps.
why don’t you like them?
I should have been more clear, I dont like them for sensing position of a system that has slip. My issue with them was that our drive system had this knack for accelerating quickly and the wheels slipped occasionally. This meant that our robot thought it was further than it was.That being said, I would use these if I needed to know how fast a gear was spinning due to them being a no contact sensor. Mounting an encoder would mean that the encoder shaft would be spinning at High RPM which causes wear and the potential to have them wear out. In short, it depends on your use.
Great List. These websites are the most helpful for understanding what sensors are out there.
If you are willing to dig deeper and know exactly what type of sensor you want you can look at the big electronics distributors.
http://mouser.com
http://digikey.com
A website that I have found really useful is octopart
http://octopart.com/
You can usually find the best price and most information between many different sources.
That isn’t a problem with the sensor more than it is bad engineering to try and use the gear tooth sensor in that manner. If you want to reliably measure the distance between a goal and the robot you have to use a sensor like ultrasonic.
Also, you typically mount an encoder in a way to reduce the number of RPMs it rotates.
Yes it was bad engineering. The goal was to tell us position on the field not distances. To give us range I would have used ultrasonic sensors.
Yes, mounting an encoder so that it gets the least RPMs is a good idea but sometimes even that is a high number. Say, for shooter wheels in 2006. Yes an encoder could tell you the speed but running constantly at high RPMs just doesn’t seem like a good idea to me.
I vote for sticky in the electrical forums. This thread is similar to the mechanical forums thread for suppliers, and its posts have already produced great links.
1501 uses gyros from sparkfun.com…so far they have seemed to have held up/performed pretty well. (Hint: mount them in silly putty:D …it is a shock absorber, and is not a conductor)
I know this is a little off topic, but I still believe it is useful information.
We experienced the exact same issue last season. Our solution was to add a very simple function that would limit the acceleration/deceleration. It was tunable for each to allow for better response. This allowed for maximum acceleration without slippage. With a little tuning, it performed quite well. We were able position the robot during autonomous mode quite accurately.
The slipping issue would have been there as well if we used encoders instead of GTS’s. The same solution will work for either sensor. The biggest issue with GTS’s vs. encoders is that GTS’s, in general, really do not give you direction. You need to derive that from some other source, like the drive signal (PWM) for instance.
The slipping problem could potentially have been minimized by using non powered wheels as well. This is the approach we may be using next year if we decide we need positioning.
Thank you for the idea of limiting acceleration. I dont know why that didnt come to mind.
We considered this as well. It makes good sense that it would work, but not for the drive train we had last year. We had a dropped center wheel design. The acceleration would cause the system to rock and the front and rear wheel would not ALWAYS have contact with the carpet. So, consistent results would not have been attainable. The other reason we chose the approach we did was purely based on time. The code took 10 minutes to write and download. The change to move the sensors to the outer wheels could potentially have taken days.:o