Friday, February 26, 2010
Linear position tracking with a quadrature encoder
I recently searched the internet for information regarding linear position tracking with quadrature encoders. Surprisingly, there wasn't much available. I didn't find any development kits, blog postings, or other all-in-one information sources. This is strange since position tracking is needed for many applications, and can be done accurately and inexpensively. All inkjet printers, old ball-type computer mice and flatbed scanners use quadrature encoders to track motion (either linear or rotary).
I eventually found this:
http://encodernet.com/products/encoders/incremental/modules/em1/
However, $30 for each encoder, and $15 for each plastic linear strip seems a little excessive. The plastic strips are printed with a series of lines that provide an optical pattern for the sensor to track. These particular strips look like an alignment nightmare since the width of the printed area is so small. They don't seem to offer any kits either.
I also found that a company called Avago manufactures encoders, but not the plastic linear strips ("codestrips") that are required to actually use the encoder. I didn't see any development kits.
Mouser sells the Avago encoders:
http://www.mouser.com/Search/ProductDetail.aspx?R=AEDS-9641-P10virtualkey63050000virtualkey630-AEDS-9641-P10
I chose the AEDS-9641. The suffix determines the coder's resolution limit. I chose AEDS-9641-P10 for 150 lines-per-inch.
After extensive internet searching, I found some 150 lines-per-inch (lpi) plastic strips here:
http://www.goldmine-elec-products.com/prodinfo.asp?number=G15602
These strips almost certainly were designed for inkjet printers. They are called linear code strips, codestrips, encoder strips, etc. They are quite wide, and have the pattern printed nearly across their whole width.
I connected the encoder's phases to my oscilloscope and pulled the plastic strip through the encoder.
OK, that looks great. Now I need to decode and count the quadrature sensor output. Fortunately, Avago also sells decoder chips that are built to work with their sensors, and Mouser carries some of them. I bought the HCTL-2022 and HCTL-2032.
Here I have the HCTL-2022 hooked up to a National Instruments USB-6501. The 6501 reads eight LSBs from the 2022 and displays the count on a graph ranging from 0 to 255.
There are some sharp transitions in this graph because the counter was wrapping around the possible data range as I moved the plastic strip through the encoder. The 2022 chip is a so-called "4x counter", so it registers a spatial resolution that is 4 times higher than the number of lines-per-inch on the encoder strip. It does this by tracking the rising and falling edges for both the "A" and "B" phases on the encoder. So, at 150lpi*4 = 600 counts/inch. The 8-bit range of 255 can cover about 255/600 = .425". For my application, this will be enough.
The system is very stable. I was able to feed the codestrip through the encoder by hand (with unavoidable wiggling and twisting), and the system maintained perfect tracking. The encoder has some plastic bumps that keep the strip in alignment, and this seems to work superbly. Avago says the encoder can count up to 60,000 lines per second, so at 150lpi, this is 400 inches/sec -- pretty fast.
I coupled the HCTL-2022 to an Analog Devices AD558 to provide a nice 0-10V analog output signal that can be sampled at high speed by a National Instruments DAQ device.
I eventually found this:
http://encodernet.com/products/encoders/incremental/modules/em1/
However, $30 for each encoder, and $15 for each plastic linear strip seems a little excessive. The plastic strips are printed with a series of lines that provide an optical pattern for the sensor to track. These particular strips look like an alignment nightmare since the width of the printed area is so small. They don't seem to offer any kits either.
I also found that a company called Avago manufactures encoders, but not the plastic linear strips ("codestrips") that are required to actually use the encoder. I didn't see any development kits.
Mouser sells the Avago encoders:
http://www.mouser.com/Search/ProductDetail.aspx?R=AEDS-9641-P10virtualkey63050000virtualkey630-AEDS-9641-P10
I chose the AEDS-9641. The suffix determines the coder's resolution limit. I chose AEDS-9641-P10 for 150 lines-per-inch.
After extensive internet searching, I found some 150 lines-per-inch (lpi) plastic strips here:
http://www.goldmine-elec-products.com/prodinfo.asp?number=G15602
These strips almost certainly were designed for inkjet printers. They are called linear code strips, codestrips, encoder strips, etc. They are quite wide, and have the pattern printed nearly across their whole width.
I connected the encoder's phases to my oscilloscope and pulled the plastic strip through the encoder.
OK, that looks great. Now I need to decode and count the quadrature sensor output. Fortunately, Avago also sells decoder chips that are built to work with their sensors, and Mouser carries some of them. I bought the HCTL-2022 and HCTL-2032.
Here I have the HCTL-2022 hooked up to a National Instruments USB-6501. The 6501 reads eight LSBs from the 2022 and displays the count on a graph ranging from 0 to 255.
There are some sharp transitions in this graph because the counter was wrapping around the possible data range as I moved the plastic strip through the encoder. The 2022 chip is a so-called "4x counter", so it registers a spatial resolution that is 4 times higher than the number of lines-per-inch on the encoder strip. It does this by tracking the rising and falling edges for both the "A" and "B" phases on the encoder. So, at 150lpi*4 = 600 counts/inch. The 8-bit range of 255 can cover about 255/600 = .425". For my application, this will be enough.
The system is very stable. I was able to feed the codestrip through the encoder by hand (with unavoidable wiggling and twisting), and the system maintained perfect tracking. The encoder has some plastic bumps that keep the strip in alignment, and this seems to work superbly. Avago says the encoder can count up to 60,000 lines per second, so at 150lpi, this is 400 inches/sec -- pretty fast.
I coupled the HCTL-2022 to an Analog Devices AD558 to provide a nice 0-10V analog output signal that can be sampled at high speed by a National Instruments DAQ device.
Thursday, February 25, 2010
National Instruments USB-6501 minimum sampling interval
I have a project where I need to collect some parallel digital data with a computer and store it in a plain text file. Ideally the file would look like this:
t (s) Value
0.000 130
0.005 127
0.010 126
0.015 127
0.020 200
Value is the decimal equivalent of 8 individual binary data lines.
This data collection could be achieved via the parallel port with custom software, however I'd rather use USB, and I'd also like to collect 2 separate 8-bit signals. I've used National Instruments products before, and figured the USB-6501 might be a good choice for this project. I called NI, and asked specifically about the sample rate. The technical salesperson did not have a clear answer. The best answer was "about 900Hz", but it was unclear whether this referred to the sample rate of a single digital line or all 24 lines that the device provides.
I bought the USB-6501 and tested it out with the included SignalExpress freeware from NI. As it turns out, the minimal sampling interval for two 8-bit signals is about 15ms (eg 67Hz) on my Core2Duo 2GHz with USB 2.0. Yeesh. I think that's pretty lousy, and it will not work for my application.
What's really annoying is that the program will not indicate what the minimal sampling interval is. You just have to take a guess and then run the data acquisition and test it. I also noticed that generating a CPU load on the machine will cause the data acquisition to halt if the minimal sampling interval cannot be reached. So, if you keep lowering the interval, keep retesting, and find that 15ms appears to work, you may find when you start another program or move a window, the CPU becomes ever-so-slightly more loaded and the acquisition will fail. Oops. Overall, the USB6501 is only good for very low-speed applications.
I will continue my project with an NI USB-6008 and use a digital-to-analog converter to convert my 8-bit signal into an analog voltage, then use the 6008 to record the voltage. It seems a little backward, but I cannot see any other low-cost high-speed digital USB devices from NI. Do you have any suggestions?
t (s) Value
0.000 130
0.005 127
0.010 126
0.015 127
0.020 200
Value is the decimal equivalent of 8 individual binary data lines.
This data collection could be achieved via the parallel port with custom software, however I'd rather use USB, and I'd also like to collect 2 separate 8-bit signals. I've used National Instruments products before, and figured the USB-6501 might be a good choice for this project. I called NI, and asked specifically about the sample rate. The technical salesperson did not have a clear answer. The best answer was "about 900Hz", but it was unclear whether this referred to the sample rate of a single digital line or all 24 lines that the device provides.
I bought the USB-6501 and tested it out with the included SignalExpress freeware from NI. As it turns out, the minimal sampling interval for two 8-bit signals is about 15ms (eg 67Hz) on my Core2Duo 2GHz with USB 2.0. Yeesh. I think that's pretty lousy, and it will not work for my application.
What's really annoying is that the program will not indicate what the minimal sampling interval is. You just have to take a guess and then run the data acquisition and test it. I also noticed that generating a CPU load on the machine will cause the data acquisition to halt if the minimal sampling interval cannot be reached. So, if you keep lowering the interval, keep retesting, and find that 15ms appears to work, you may find when you start another program or move a window, the CPU becomes ever-so-slightly more loaded and the acquisition will fail. Oops. Overall, the USB6501 is only good for very low-speed applications.
I will continue my project with an NI USB-6008 and use a digital-to-analog converter to convert my 8-bit signal into an analog voltage, then use the 6008 to record the voltage. It seems a little backward, but I cannot see any other low-cost high-speed digital USB devices from NI. Do you have any suggestions?
Labels:
Hz,
minimum interval,
national instruments,
NI,
signalexpress,
USB-6008,
USB-6501
Black levels in video playback (Premiere Pro)
Take a look at this screen capture from a video file.
The video itself is just a black (R:0, G:0, B:0) matte. Or at least, it is supposed to be. Notice that the 16:9 video portion is actually dark grey -- much lighter than the surrounding true black border. I only noticed this recently, even though it has probably always been this way on my computer. Almost all of the video watched on this computer is from youtube, which goes through a different video display route than DVD video or video played from individual files.
Initially, I thought the problem was caused by Premiere itself. I created a very simple video with just a few seconds of solid black matte. When viewing the preview window in Premiere, it looked fully black. After encoding into MPG, it looked dark gray. Clearly, it must be a problem with Premiere or its encoder. I was encouraged by this bug report:
http://forums.adobe.com/thread/387845
http://forum.videohelp.com/threads/309449-Adobe-Premiere-MainConcept-s-H-264-vs-x264-open-source-encoder/page4
After upgrading to 4.0.1 and spending many hours fighting with codecs, filters, shaders, etc, I discovered that my video card driver actually has the final decision about black levels. Even if all of the video decoding software outputs a "0", the video card driver may still adjust this to be dark gray in order to be compatible with analog television output. I had to upgrade my Nvidia driver, which now includes the option to actually use 0-255 range in the video output.
The alternative to 0-255 range is 16-235. I guess analog TVs and maybe even digital TVs are setup to display a value of 16 as complete black and 235 as complete white. Why? I have no idea. It might have made sense when dealing with an analog signal, but it makes no sense with digital signaling. The difference in tonal range is technically known as pc.709 and rec.709. If you start reading about color spaces and transfer functions, your head might explode. Just try searching for YUV rec.709 YUY2 YV12 4:2:0
This is helpful:
http://avisynth.org/mediawiki/ConvertToRGB
The video itself is just a black (R:0, G:0, B:0) matte. Or at least, it is supposed to be. Notice that the 16:9 video portion is actually dark grey -- much lighter than the surrounding true black border. I only noticed this recently, even though it has probably always been this way on my computer. Almost all of the video watched on this computer is from youtube, which goes through a different video display route than DVD video or video played from individual files.
Initially, I thought the problem was caused by Premiere itself. I created a very simple video with just a few seconds of solid black matte. When viewing the preview window in Premiere, it looked fully black. After encoding into MPG, it looked dark gray. Clearly, it must be a problem with Premiere or its encoder. I was encouraged by this bug report:
http://forums.adobe.com/thread/387845
http://forum.videohelp.com/threads/309449-Adobe-Premiere-MainConcept-s-H-264-vs-x264-open-source-encoder/page4
After upgrading to 4.0.1 and spending many hours fighting with codecs, filters, shaders, etc, I discovered that my video card driver actually has the final decision about black levels. Even if all of the video decoding software outputs a "0", the video card driver may still adjust this to be dark gray in order to be compatible with analog television output. I had to upgrade my Nvidia driver, which now includes the option to actually use 0-255 range in the video output.
The alternative to 0-255 range is 16-235. I guess analog TVs and maybe even digital TVs are setup to display a value of 16 as complete black and 235 as complete white. Why? I have no idea. It might have made sense when dealing with an analog signal, but it makes no sense with digital signaling. The difference in tonal range is technically known as pc.709 and rec.709. If you start reading about color spaces and transfer functions, your head might explode. Just try searching for YUV rec.709 YUY2 YV12 4:2:0
This is helpful:
http://avisynth.org/mediawiki/ConvertToRGB
Wednesday, February 24, 2010
Custom Topo map overlay in Google Earth
I've been trying to determine just how difficult it would be to build a house in the SF Bay Area. The first part of the process involves finding a piece of land and checking its topographical features (among myriad other things). Google Earth is great for this task, but the topographical resolution is not high enough to get a very accurate estimate of the work needed to prepare the lot for a house. I happened to have a detailed topo map that was prepared for a property in which I am interested. I editing the map in GIMP to make a transparent GIF, then imported the image into Google Earth. Unfortunately, the transparent pixels were replaced with white, but Earth still allowed me to adjust the image's overall transparency. Alignment was made easy by existing fences and lot lines.
This is really great way to visualize the land's topography.
Cool!
This is really great way to visualize the land's topography.
Cool!
Tuesday, February 16, 2010
Etching zirconium oxide with hydrofluoric acid
I am currently working on a project where I need to replace a standard mouse ball with a non-metallic equivalent. Normal mouse balls are built from a steel core that has been coated with a thick layer of rubber. I can't use any metal in my project, so I must find a replacement. The main requirements are:
Ball must be very dense
Ball must be non-magnetic and non-conductive (ie non-metallic)
Ball must be coated with rubber or naturally have a high friction coefficient
Outer diameter 7/8"
My first solution was to use 7/8" glass marbles. These are not easy to find, but they are available. The problem is that the marbles are not perfectly spherical, and they are not nearly as dense as the original mouse ball. The lower density means the ball weighs less and will not track smoothly on the mousepad surface, since it sometimes skips and hops. I was able to etch them with hydrofluoric acid, spray them with primer paint, then coat with with spray-on rubber. They worked OK, but I have a better solution now.
I found a source of 7/8" dia zirconium oxide balls (http://www.ortechceramics.com/). This stuff is a ceramic, but 2-3 times as dense as glass. It's non-metallic, and the balls have very high sphericity. The problem is that the balls come very highly polished, and the paint will not stick to them. I tried etching them with standard glass etching cream, but there was no effect.
I found that a local lab supply company (http://www.lab-proinc.com/) sells 50% hydrofluoric acid (HF). I bought some and initially made a small 10% dilution. The ZrO2 showed no etching after 1 hour of full submersion in the dilution. I upped the concentration to 20%. Still no effect after 30 minutes. Finally, I submerged the ZrO2 in straight 50% HF. After 10 minutes, I could see the shine starting to disappear from the balls' surfaces. After 20-30 minutes, the balls appeared to have enough etching so that they would hold paint well.
Hydrofluoric acid is scary stuff. There are reports of it penetrating skin painlessly then dissolving bones and causing blood toxicity. Standard nitrile or latex gloves only provide splash protection -- ie if the HF is spilled on the glove, immediately remove the glove, and get a new one. HF will penetrate the gloves if left in contact for too long.
I was surprised to see the 50% HF was actually 'fuming'. When I left it in the open container, I could clearly see vapor droplets coming off the surface. If I blew across the surface of the HF, more vapors were produced. I am not sure if it is reacting with water in the air/breath or what. I didn't expect 50% to be fuming.
Ball must be very dense
Ball must be non-magnetic and non-conductive (ie non-metallic)
Ball must be coated with rubber or naturally have a high friction coefficient
Outer diameter 7/8"
My first solution was to use 7/8" glass marbles. These are not easy to find, but they are available. The problem is that the marbles are not perfectly spherical, and they are not nearly as dense as the original mouse ball. The lower density means the ball weighs less and will not track smoothly on the mousepad surface, since it sometimes skips and hops. I was able to etch them with hydrofluoric acid, spray them with primer paint, then coat with with spray-on rubber. They worked OK, but I have a better solution now.
I found a source of 7/8" dia zirconium oxide balls (http://www.ortechceramics.com/). This stuff is a ceramic, but 2-3 times as dense as glass. It's non-metallic, and the balls have very high sphericity. The problem is that the balls come very highly polished, and the paint will not stick to them. I tried etching them with standard glass etching cream, but there was no effect.
I found that a local lab supply company (http://www.lab-proinc.com/) sells 50% hydrofluoric acid (HF). I bought some and initially made a small 10% dilution. The ZrO2 showed no etching after 1 hour of full submersion in the dilution. I upped the concentration to 20%. Still no effect after 30 minutes. Finally, I submerged the ZrO2 in straight 50% HF. After 10 minutes, I could see the shine starting to disappear from the balls' surfaces. After 20-30 minutes, the balls appeared to have enough etching so that they would hold paint well.
Hydrofluoric acid is scary stuff. There are reports of it penetrating skin painlessly then dissolving bones and causing blood toxicity. Standard nitrile or latex gloves only provide splash protection -- ie if the HF is spilled on the glove, immediately remove the glove, and get a new one. HF will penetrate the gloves if left in contact for too long.
I was surprised to see the 50% HF was actually 'fuming'. When I left it in the open container, I could clearly see vapor droplets coming off the surface. If I blew across the surface of the HF, more vapors were produced. I am not sure if it is reacting with water in the air/breath or what. I didn't expect 50% to be fuming.
Labels:
etch,
etching,
HF,
hydrofluoric acid,
zirconium oxide,
ZrO2
Friday, February 5, 2010
Adapting a Cosmicar 12.5mm f/1.4 c-mount lens to the GH1
The micro four thirds (and standard four thirds) camera format makes it possible to use old c-mount lenses with decent results. The lenses with shorter focal lengths will not cover the image sensor fully, but it seems that anything 25mm or longer will have full sensor coverage. These lenses are very cheap (eg $30), and the quality is surprisingly good.
This is the cosmicar 12.5mm f/1.4. I got it here:
http://www.surplusshed.com/pages/item/l10128.html
One problem is that the fast, short focal length lenses have a very wide barrel. In fact, it is too wide to fit into the micro four thirds -> c-mount adapter. I machined both the adapter and the lens so that they would fit together and also achieve infinity focus.
The lens has a brass mounting plate with the C-mount threads on it. It comes off very easily by removing the three screws around the periphery.
I used a lathe to cut an angle onto the edge of the brass mounting plate.
I cut the same angle onto the C-mount adapter. I bought mine from an eBay seller called rainbowimaging.
I'm pretty sure infinity focus has been achieved. If you think this image looks soft, it may just be the overall characteristic of the lens. It is $30.
The real benefit of theses lenses is that they are very fast (f/1.4) and wide, so they are ideal for indoor video. The 16:9 format works a little better with the image circle produced by the lens.
This has been very helpful in choosing lenses:
http://spreadsheets.google.com/pub?key=p9kkgjwEQQQ-HJwvNDobeEw
Also note that this is my second attempt in adapting the cosmicar to the camera. I had bought a c-mount adapter previously and machined it without machining the lens. I eventually machined away so much material (accidentally) that the adapter became too weak and broke immediately. I then realized that some material must be removed from both the lens and the adapter to make it work.
This is the cosmicar 12.5mm f/1.4. I got it here:
http://www.surplusshed.com/pages/item/l10128.html
One problem is that the fast, short focal length lenses have a very wide barrel. In fact, it is too wide to fit into the micro four thirds -> c-mount adapter. I machined both the adapter and the lens so that they would fit together and also achieve infinity focus.
The lens has a brass mounting plate with the C-mount threads on it. It comes off very easily by removing the three screws around the periphery.
I used a lathe to cut an angle onto the edge of the brass mounting plate.
I cut the same angle onto the C-mount adapter. I bought mine from an eBay seller called rainbowimaging.
I'm pretty sure infinity focus has been achieved. If you think this image looks soft, it may just be the overall characteristic of the lens. It is $30.
The real benefit of theses lenses is that they are very fast (f/1.4) and wide, so they are ideal for indoor video. The 16:9 format works a little better with the image circle produced by the lens.
This has been very helpful in choosing lenses:
http://spreadsheets.google.com/pub?key=p9kkgjwEQQQ-HJwvNDobeEw
Also note that this is my second attempt in adapting the cosmicar to the camera. I had bought a c-mount adapter previously and machined it without machining the lens. I eventually machined away so much material (accidentally) that the adapter became too weak and broke immediately. I then realized that some material must be removed from both the lens and the adapter to make it work.
Labels:
12.5mm,
adapter,
c-mount,
cosmicar,
gh1,
infinity focus,
lumix gh1,
m4/3,
mft,
micro four thirds
Subscribe to:
Posts (Atom)