Encoder Sensor Analysis
The goal of this analysis is to make a decision on buying the Lynxmotion SingleLine Detector (SLD) or the Hamamatsu Photoreflector (HAMP) to use in detecting the encoder pattern. Even from a qualitative point a view the decision is still not easy. The SLD is $14.95 and the HAMP is $2.20. If I go with the HAMP, I can purchase 2 more IR distance rangers. However, minimal external circuitry is needed to interface with the brainstem. While the SLD comes with three convenient wires that can be directly plugged into the brainstem. As far as mounting issues, the HAMP will be a little more difficult, since its pins are small and may need to be first mounted on a PCB.
The quantitative analysis will focus on the frequency response of the 2 sensors because I have mounted the encoder disk onto the high RPM shaft of the motor. I do not know the RPM of this shaft, but it is fast! First take a look at the 2 datasheets, HAMP datasheet and the SLD datasheet. Note that what I call the SLD datasheet is the datasheet for the IR sensor and not the User's Guide given here. After all the circuit will not be faster than the IR sensor.
Looking at the rise and fall times shown in the graphs of the datasheets, the worst cases are 1 milliseconds for the SLD and 4 microseconds for the HAMP. Figure 1 depicts the relationship between the pulses and the encoder.
figure 1
The quantitative analysis will focus on the frequency response of the 2 sensors because I have mounted the encoder disk onto the high RPM shaft of the motor. I do not know the RPM of this shaft, but it is fast! First take a look at the 2 datasheets, HAMP datasheet and the SLD datasheet. Note that what I call the SLD datasheet is the datasheet for the IR sensor and not the User's Guide given here. After all the circuit will not be faster than the IR sensor.
Looking at the rise and fall times shown in the graphs of the datasheets, the worst cases are 1 milliseconds for the SLD and 4 microseconds for the HAMP. Figure 1 depicts the relationship between the pulses and the encoder.
figure 1
At the 'start' where the red arrows are and going in a counter clockwise direction, the voltage will be 0 corresponding to the reflectance of the white. There are 2 quantities of interest here. One is the rise and fall time of the pulse and the other is the length of the pulse. Since the SLD could take 1 ms to 'rise' to 5 volts when it goes into the black area and then 1 ms to fall back down to 0 volts, there could clearly be issues if our pulse was 2 ms wide. This could create either a triangle with an analog input or a missed pulse for a digital input. So without caring about the pulse width, I'll call this 2 ms for the rise and fall the theoretical limit. It should not be attempted to use the SLD sensor for anything near this speed or faster. The HAMP sensor had a rise and fall time of 4 microseconds, so each pulse will have a limit of 8 microseconds.
Next, we are concerned with what this translates into the fasted RPM that the sensor can deal with no regard on how the microcontroller will sample the signal (this will come later). For my case (and this will change based on encoder disk), I have 4 pulses per revolution as you can see in figure 1. This means the limit for the SLD will be 8 ms per revolution and for the HAMP it will be 16 microseconds. There are 2 rises and 2 falls for 1 revolution so multiply the rise/fall time by 4.
Finally, to get the RPM limit we need to convert microseconds and ms to minutes. Essentially, think that there are 8 ms per revolution so how many revolution can be done in a minute. First convert to seconds so this is 8 x 10^-3 seconds. Then convert to minutes so divide by 60 to get 1.33 x 10^-4 minutes per revolution, but we want revolutions per minute so take the inverse, which yields a theoretical limit of 7500 RPM. Doing a similar calculation for the HAMP, yields a limit of 3,750,000 RPM. Clearly, we want to stay away from this limit so choosing a 50% 'safety' margin gives a max of 3750 RPM for SLD and 1,875,000 RPM for HAMP. If I choose HAMP, the limiting factor will be sampling the sensor and not the sensor itself. However, the SLD is too close to risk so I'll be ordering the HAMP. Look forward to an article on interfacing this to the brainstem in the coming weeks.
Next, we are concerned with what this translates into the fasted RPM that the sensor can deal with no regard on how the microcontroller will sample the signal (this will come later). For my case (and this will change based on encoder disk), I have 4 pulses per revolution as you can see in figure 1. This means the limit for the SLD will be 8 ms per revolution and for the HAMP it will be 16 microseconds. There are 2 rises and 2 falls for 1 revolution so multiply the rise/fall time by 4.
Finally, to get the RPM limit we need to convert microseconds and ms to minutes. Essentially, think that there are 8 ms per revolution so how many revolution can be done in a minute. First convert to seconds so this is 8 x 10^-3 seconds. Then convert to minutes so divide by 60 to get 1.33 x 10^-4 minutes per revolution, but we want revolutions per minute so take the inverse, which yields a theoretical limit of 7500 RPM. Doing a similar calculation for the HAMP, yields a limit of 3,750,000 RPM. Clearly, we want to stay away from this limit so choosing a 50% 'safety' margin gives a max of 3750 RPM for SLD and 1,875,000 RPM for HAMP. If I choose HAMP, the limiting factor will be sampling the sensor and not the sensor itself. However, the SLD is too close to risk so I'll be ordering the HAMP. Look forward to an article on interfacing this to the brainstem in the coming weeks.
5 Comments:
I'm currently an undergrad at MIT, and am working on a mobile robot project involving a Mac mini. While we're willing to tether it, we'd prefer that robot was completely mobile and untethered -- i.e. we need the Mac mini to be battery-powered. Cost doesn't matter at all, we just need a solution. Any help? Contact me cappaert at csail.mit.edu
By Tpny Cappaert, at 1:55 PM
It's always nice to hear cost doesn't matter, oh the possibilities! Will the biggest constraints be size and weight? There seems to be 2 types of solutions, the brew your own or the the shrink wrapped solution. From the sound of things the hassle of building a DC-DC converter to accommadate the mini is not at the top of your wish list and in the end you probably will not build anything better than the CNX-P1900 that only costs $100. This is mostly due to the annoying proprietary plug that goes to the back of the mini. The people at carnetix.com are trying to get a hold of the plug and until then you will need to destroy the mini's power plug as described in the directions. However, I'm sure power plugs will be common on ebay in no time. I've decided to hold off on this since my mini is under warranty and already has been in the shop (although it really does not matter since you can bring it to a shop without the power plug and they will still fix it).
The solution I've chosen for the short term is just using an inverter. The biggest drawback is that you still need to carry the mini's power 'brick'. The power loss is really not a big deal for research projects.
I WARN you though to choose wisely and cough up the dough for a high quality inverter. Unless, you do not care about the loud sound it will make. Of course one of the main reasons for choosing the mini is the ease of adding speech recognition. So choose wisely... Finally, if you go with the inverter, don't choose anything over 100 Watts unless you have to drive other devices from it.
Good luck. What's your objective or are you trying to have the mini take over the world in which case we should combine our efforts...
By Ben Loftin, at 8:07 PM
This post has been removed by a blog administrator.
By darreljones4313, at 8:39 PM
At the recent AdHoc mac programming conference, I programmed the AI for a MacMini robot built by George Storm of the Seattle XCoders. It was wireless, autonomous, and vision-enabled. Ran pretty well.
There is an article in this months MacTech magazine, and I'd be willing to share more info on our experiences.
By Andrew Turner, at 9:02 AM
Andrew,
Sounds like we should definitely share what we can. Although, my summer was completely eaten up restoring the old floor in my home, I'll soon be able to focus more on the Mini Mac. I guess I will start the sharing process and add an entry in the blog today of a general overview of systems and parts that I am using. I am most interested in your vision setup and algorithms since this is the most alien to me on the Mac platform. I come from the OpenCV world where it was rather easy to implement basic vision algorithms. Recently, I've been playing with Tina Vision. You can always email me at bloftin@phys-x.org for further discussion. Thanks for the info.
Ben
By Ben Loftin, at 11:10 AM
Post a Comment
<< Home