Does anyone have and idea for a speed sensor for the ball shooting wheels, I don’t really want to use encoders, I had an idea of using a frequency to voltage IC and connecting it to the analog port of the R/c as I don’t need direction or exact positioning and would rather not go into interrupts. The wheel would have an optical sensor mounted with a disk on the shaft or something similar, however all the frequency to voltage chips I saw wanted about 15 volts in and like 100Hz. The frequency is doable, but theres no way I want 12v battery voltage going into the r/c if something goes wrong. So anyone have an idea?
my priorities
Very little coding
cheap
commonly available
easy to interface
Unfortunately, interrupts are probably the best way to go (cheap, commonly available, easy to interface). Kevin Watson does have some interrupt / encoder sample code at http://kevin.org/FRC
To measure wheel speed, use one of the gear tooth sensors provided in the kit of parts. It’s cheap (free), available (you already have two of them), easy to interface (one PWM cable to the RC and a pair of lines for power/ground), and I estimate the required programming is approximately a half dozen lines of code, one in the interrupt service routine, three in the Process_Data_from_Master_uP() routine, and the rest of them in User_Initialization().
Something we’re considering as an alternative… paint part of the wheel of your launcher and use an optical sensor to detect the change in color/reflection. It will not be as accurate as an encoder, but in theory it is the same thing, and requires no gear to read.
One thing to note on the gear tooth sensors, they will be generating an interrupt for every tooth, so it would not be wise to mount them on a many toothed gear on the actual shaft of the wheel. If you guess that the shooter is going ~2000 RPM, you have ~33RPS, and if you had a 49 tooth gear (like the ones that the gear tooth sensors are reading in the default transmission setup), you would be getting 1617 interrupts per second. Kevin and teams have had problems using the gear tooth sensors because of the massive amount of interrupts generated and because of the way the new processor saves data, resulting in some very weird program crashes. I don’t know the current state of how things are going or why this problem is occuring, but keep in mind large amounts of interrupts could be an issue, especially if you still have interrupts being generated by other sensors.
All,
I am currently looking at the LM2917 frequency to voltage IC as a solution, it uses an variable reluctance(hall effect?) sensor to read magnets, or ferrous materials and based on some capacitor and resistor values of your choosing outputs a voltage proportional to the frequency. If I can get the circuit working, this will be the ideal solution in my mind, all you would need to do is read the analog input that it is connected to. If someone with more electronics experience than me wants to look at the data sheets, etc. for this they can be found here http://www.national.com/ds/LM/LM2907.pdf
I also wonder if one could use optical pickups instead of the magnetic sensor as I have a few of those already, and they seem to be very reliable.
Looks like I’m off to the electrical engineering instructors office tomorrow.
Use an optical sensor, such as a banner sensor with reflective tape, that generates one interrupt per rotation of the wheel. Use this interrupt to measure the amount of time that it takes for the wheel to go around with one of the hardware timers, preferably a 16 bit one (timer 1 or timer 3). Use the interrupt from the overflow on the timer to increment a “high word” maintaining a 32 bit result for the time in clock ticks that it takes for the wheel to go around. You can get very high precision for the wheel speed this way with only one interrupt per rotation and any additional interrupts associated with overflow of the timer. The “period” of the wheel is then maintained by the interrupt setup, to be read in the user loop by the PID control for the wheel power, any time it needs to be read.
<edit>
There is a race condition in this scheme that you must be careful about.
<edit>
Other options available are DC tachometers, if you can find them cheap, or other crazy IC circuits. The frequency to voltage converters appear to be able to operate from 7.2V, I’m unsure about 5V, and I can’t tell you how well they’ll work at the moment. Any of these analog input options have certain advantages and disadvantages over digital encoders. The main advantage is that you can sample at otherwise unreasonable frequencies of 100+Hz and still get higher resolutions of more than 100 steps. Trying this with an encoder would give you 10,000 intrerrupts a second at top speed, and likely leave your processor a quivering pool of molten silicon. You can also get up to 10-bits of resolution, provided you design your circuit to provide such. The downside is you’re working in the analog world and now have to deal with temperature effects and such. Such is life, but I think the pros outweigh the cons if you can pull it off.
I have tried most F/V converters available in the market for a project a while ago. Those are pretty neat devices, but I’m afraid you will not have a very good performance.
It’s tricky to adjust the circuit for the correct voltage and real resistors and capacitors will not be as precise/stable as you’d want them to be. If you read a bit into the workings of those converters, you’ll find out most of them work with an integrating capacitor. The output voltage will have some ripple, inversely proportional to the capacitor value. This ripple will affect your readings, and filtering it out in software will result in a code that is slower and more complex than using interrupts. If you use a big capacitor, you’ll introduce a phase lag that may render your sensor impractical.
That said, I think a Banner sensor with a small piece of retro-reflective tape will be more than enough for your application (that’s what we’ll be using), and Kevin Watson has provided us code that works without even needing modifications.
If you still want to try the F/V thing, I suggest you use the Analog Devices AD650 or the Texas/Burr Brown VFC320. You can get free samples on both of those, and they’re much better than the National IC. The AD650 is a very good piece of hardware and, to get a decent result, that’s the one I’d use.
Whats wrong with encoders or hall effect sensors? Since you know what direction the thing is spinning, if you use encoders you only need to use of of the two lines. This makes life alot easier because you can use one of the PIC’s built in CCP modules to compute the speed automagically. you only need and interrupt each time a measurement is complete. These measurements will complete in a fixed time, and can be even used as the timebase for your speed control loop
Justin,
The device you have chosen is OK for what it does but any of these other options will provide a more accurate result. The LM2907 stilll needs an input device and the output will be subject to non linearities in speed and transducer and have a finite limit. Get to the maximum frequency and you will get no higher output.
There could be a problem if you are trying to use a lot of encoders. i.e. two shooter wheels running at ~2000 rpm, and 4 drivewheels and whatever else. You “could get the red light of death” as our programmer calls it when you are servicing interrupts so often…
I found this and are thinking about taking a look at it… Anybody have any experience with it?
As with the previous device, this should work. Just remember that the accuracy depends on a lot of variables, sense clicks/rotation, linearity in the ADC, power supply, etc. You could increase the number of sense points on the wheel (2 per rotation or 4/rot, etc.) but you still are subject to the accuracy of the ADC on the input of the RC and it’s conversion to bits. Will the number in this conversion give you enough accuracy?
The two shooter wheels shouldn’t be a problem programming wise. Based solely on implications, I’m assuming you dont care how slow your roller is spinning, you care how fast your roller is spinning. Therefore, unlike in a drivetrain, you can easily get away with a non directional, 1 PPR encoder type switch. (As easy as a light sensor picking up a piece of relefective tape on a shaft!)
You can use this because you are only trying to determine a relative (to the other roller, or to a standard you set) velocity for each roller. Even at 2000 RPM, a simple “1 tick” sensor would pulse ~33 times per second. This will run pretty parallel to the loop in the default program. So, yes you are using an interrupt, but no, it is not taxing the processor anymore than a few commands in the default routine would. You can even determine actual velocity by using a timer to look at the times between interrupts.
If you do decide to go with a Frequency to Voltage IC you should also remember that if you are using a source >5v you can possibly create an output voltage >5v which could damage the A/D. You may need to use a buffer/amplifier circuit to clip the output to 5v.
The other issue is that to reduce the ripple you can use higher frequency inputs and smaller capacitors (watch the max input frequency), but as you increase the frequency you also reduce your resolution (larger frequency range in the same number of A/D counts).
Note: This post really deals with measuring the ball speed, not the shooter…
Per the attached spec sheet from Rockwell Automation, the photo receiver 42SMR-7100 has the following response times:
1ms ON/1.5ms OFF
So, if you are going to measure ball speed based on the time the ball is blocking a single light beam, the sensor will indicate OFF ~1.5ms after the beam is blocked and ON ~1ms after the beam becomes unblocked. So the sensor will indicate the ball has passed through the sensor ~0.5ms faster than actual.
So, if you’re blocking the beam across the full ball diameter (approx 18 cm) and the elapsed time according to the optical sensor is 14.5ms, the actual crossing time is 15ms. That would put the ball speed at 12 m/s - just barely legal !
In terms of assessing measurement error, the actual response times for the optical sensor are needed (plus any jitter, which should be small). Error in the assumed ball diameter (i.e. is the sensor measuring the full ball diameter or is the ball off-center or out-of-round?) also needs to be taken into account (this is probably the dominant factor, 1% error would require better than 2 mm knowledge). If you use the FRC controller timer interrupts as eugenebrooks has described in:
!