Phil,
I counted the belt revolutions one day and would guess 400 fpm. The Hagen "camera" is not really a camera; it is an array of 20 infrared LED’s horizontal and 20 vertical.
Brian
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Imagination is more important than knowledge..."Albert Einstein
400 fpm is really fast, but typical for potatoes, since they're tough and don't bruise easily. Anyway, that's 320 scans per second (~3 ms/scan) if you do a scan every 1/4" of conveyor travel. I'm not sure the MoBo will be able to keep up without some custom coprocessor firmware. Or is 1/4" a more refined measurement than you need? (It probably would be for russets, if you can align them lengthwise. We used 1/8" for fruit.)
Phil,
A 1/4" should work fine, I'm going to start with the washer sorter first (they are easier to clean up). I have been collecting parts to build a proof of concept test conveyor. It will be 3"X5' black conveyor (for good contrast with washers) and have 3 electromagnets to remove the washers off at there proper spot.
Anyhow that has to wait a couple of weeks untill I get some other stuff finished up.
Brian
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Imagination is more important than knowledge..."Albert Einstein
The washer project sounds like a good "entry ramp". Be sure to use very diffuse lighting for the washers. Basically what you'll be looking at is the reflection of the bright diffuser in the shiny surface of the washers. Otherwise, surprisingly enough, they will be invisible against a black background if they're very shiny and lack diffuse reflectivity.
This looks like a interesting device. I'm looking for a device (maybe 2) to help me determine the x,y location of a object hitting a flat screen, similar to that of a touch screen on a monitor. Objects hitting the screen /glass will be about a 1/4 inch in diameter and will be hitting this screen at around 200-400 fps. Do you think this device would have the potential to detect an event such as this? I've been looking at IR-based multi-touch screen devices as a input to applications running on a PC. For many of the implementations, IR-Lasers and a web cam are used for detecting the "touch" point (X,Y position) on the screen. a few things which concern me are 1) that depending on the FPS of the web cam, I figure it may miss a lot of the hits, and 2) the image processing on the PC is pretty demanding. Also these solutions tend to be pretty large in scale, where as I'm looking for something more in the 10"X10" size.
Do you think I may be able to capture these events with the TSL1401 and one of the parallax CPU's? The information on the web page also mentions that information could be captured on PIC's and AVR's as well. How would one go about interfacing this sensor to one of those processors?
Spreading 128 pixels over 10" gives about 12.8 pixels per inch. A 1/4" dia. object will subtend 3.2 pixels at the maximum diameter point of the sphere. To subtend two pixels (the minimum for reliable detection), the object would have to be caught within the central 0.19" of the sphere's travel. At the maximum 400 fps (4800 ips), you'd have to capture and interpret a snapshot every 39 microseconds to catch such an event. This, unfortunately, is not within the capabilities of the TSL1401-DB, so I cannot recommend it for this application.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 2/4/2010 5:36:22 PM GMT
Horizontal and vertical light curtains could work. Each would have 80 or so focused beams and that many opposing sensors. Each sensor would be connected to a resettable latch that latched when its beam was broken and which could be polled after the fact. (Of course, you'd have to keep the flies out! ) The biggest problem with such a densely-packed light curtain would be crosstalk. Since the response time has to be so quick, pulsing the beams serially is almost out of the question, so it would have to be done optically.
Of course, you could always set up a continuous roll of paper in the way of the pellet, analyze the hole position after the fact with a 2D camera, then crank a clean sheet into view for the next shot.
But this has now become a topic for another thread, and you should post your more general query there.
i am interested in some of this extrusion. i couldn't find it in the store. how can i get a piece of this? probably like a four inch piece, or however long you have them cut already.
Any timeframe on when the StrobeLED-DBM will be avaliable Phil? Also, i probably just missed it in the documentation, but what is the 'Code' button on the monitor program for?
Ken Gracey (Parallax) said...
A bit of a thread hijacking here.
Regarding the extrusion, we have 300 lineal feet in stock that we'd love to start cutting up with our new automatic drop saw. I've had to move it out of the way every year on June 30 for inventory count and I'm excited about the possibility of putting it in our inventory once and for all.
I'm curious about our customer's level of interest in the extrusion. I imagine it would be around $5 a section or so. We don't have endcaps, as Phil noted.
Anybody interested in the extrusion for this kind of application?
kf4ixm said...
Any timeframe on when the StrobeLED-DBM will be avaliable Phil?
No. I'm going to start over on the design. There are some really neat RGB LEDs available now in the P4 package. This would allow the TSL1401 to see close-range objects in color at not much more cost. I guess this is as good a place as any to ask: Would color be important to you? Or is price the greater consideration?
kf4ixm said...
Also, i probably just missed it in the documentation, but what is the 'Code' button on the monitor program for?
It's a placeholder right now. The plan was to set everything up the way you want it, click the Code button, and a window would pop up with the PBASIC code needed to make the indicated measurement.
Good eye, though! You're the first person to inquire about it!
That is SOOO SWEET!!! i kinda thought thats what it may be for, but wasn't sure. As far as color goes, i reall have no preferance on color, although an rbg would be great, to allow the user to select in software, like LED 255,255,255 or some such. if price is a consideration, then i would have to say white, then users could use colored film or something to change it to thier preferance. I just got mine today, (tls1401 & the stamp 2pe mobo), this is a great product and im greatly interested in the future of its uses and add ons. i love the idea about interfacing with automationdirect plc's. i've used these plc's·many times over the years, along with others (AB), and i think these would be a great addition to the industrial world, mainly because it's priced great·AND open source. (ooops, i used open source and AB in the same sentence!)
Phil Pilgrim (PhiPi) said...
kf4ixm said...
Any timeframe on when the StrobeLED-DBM will be avaliable Phil?
No. I'm going to start over on the design. There are some really neat RGB LEDs available now in the P4 package. This would allow the TSL1401 to see close-range objects in color at not much more cost. I guess this is as good a place as any to ask: Would color be important to you? Or is price the greater consideration?
kf4ixm said...
Also, i probably just missed it in the documentation, but what is the 'Code' button on the monitor program for?
It's a placeholder right now. The plan was to set everything up the way you want it, click the Code button, and a window would pop up with the PBASIC code needed to make the indicated measurement.
Good eye, though! You're the first person to inquire about it!
Greg Hayes said...
... do you think this device can be used to count or detect falling objects like seeds or pills with appropriate back light?
Short answer: yes.
Long answer: it will depend on how fast the objects are falling and how small they are. Basically, you need to take into consideration your shortest practical exposure interval and make sure it's short enough to capture the events you're looking for. If a pill completely passes the field of view between two exposrues, you'll miss it. It also matters whether the subjects you're detecting are organized into columns and singulated (spaced apart) or falling at random and possibly clumped together.
In the example of line following you used an led connected to the mezzanine connector controlled by an I/O pin. How much current can that setup source to the LEDs? I also don't know what color LEDs to use. The robot will be on a table. The table will be either dark brown or light colored. The main thing I need to detect is the edge of the table. The second thing in importance to detect would be a block (black on light table, white on dark brown table).
Driven directly from a BS2 pin, 25mA is the absolute maximum. With an open-collector NPN driver, it can be anything you want. (After reviewing the line follower post, I realize that I was driving two LEDs in series without a current-limiting resistor. This is will cause the BS2 to sink more current than it really should. A 75-ohm series resistor would be adequate protection.)
Red LEDs will provide the best reflection from a brown surface. With a light-colored surface, just about any visible color would work.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 5/28/2010 5:27:52 AM GMT
Since I using a Prop I should use the two rightmost sockets in J1, VDD and the Prop to go low to turn LED on with a current limmiting resistor. Jumper J2 open or closed? I cannot figure out what Q1 is used for.
John Abshier
Post Edited (John Abshier) : 5/28/2010 9:45:59 PM GMT
Phil, I ordered one of these camera on Sunday's free shipping day. It hasn't come yet, but I hope it arrives soon as I'm looking forward to playing around with it.
In reading the manual it looks like having a BS2pe motherboard is a win because Parallax provides image processing code which can be uploaded to the on-board AVR. Now I have a BS2e and an AVR on my robot, so I am wondering if I can do something similar. But it looks like the code is a hex file and uses a custom up loader.
I'm curious, what does the custom AVR code do? I suppose I could Google the algorithm and re-implement it in C. Also, I can run the demo code using a BS2, but the AVR has an on board ADC and more RAM. So I might be more bang for my buck interfacing it to that processor instead.
From what I've read the camera is going to return analog data at a certain baud rate so that it delivers a total of 128 bits. I would assume if I sample the analog pin during that time window I could accumulate these pixel values. But it occurs to me that I might sample during a pixel transition, so I would need to over sample in order to get accurate data.
To take advantage of the specialized AVR code, you would need both an ATTINY13 and a BS2p, -pe, or -px. The BS2e does not have the requisite OWOUT and OWIN commands needed to communicate with the AVR program. The AVR/MoBo combination provides the functionality documented in the TSL1401-DB manual. Although you can connect the '1401 board to a BASIC Stamp directly, you will lose the gray-level analog capabilities and, perhaps more importantly, the ability to take advantage of the PC-hosted monitor and setup program.
In lieu of a MoBo, you could also plug the '1401 board into a Propeller Backpack and tether the BP/DB sandwich to your BS2e via a three-conductor header cable. At least then you would be able to take advantage of the PC hosted program. The current Propeller object does not yet support all of the post-acquisition image processing functions provided by the AVR, however.
OK. I was less interested in the PC hosted program anyway and more interested in doing some of the projects (line following, flame detection) you posted in the forums. So I can probably get by without what I have for now. My ultimate goal is to try object recognition of objects with black and white bar codes on them which identify them.
I'm fairly confident I can use the thresholding technique I saw in the manual to get bit patterns. So I'll try that on the stamp and AVR and see how it works out.
The propeller backpack sounds interesting.
Update: I just read through the shiftIn and shiftOut C code for the AVR. It looks straight forward to do and sample one of the analog pins as you shift the clock pin on your own.
I've been thinking about starting my humanoidish robot (2 pan/tilt eyes, 2 arms, pan/tilt head, neck, wheels, etc). Originally, I planned for the eyes to be just for show. But I really want some kind of vision for it.
So, I'm thinking using 2 of these sensors, 1 to scan horizontally, and 1 mounted 90 degrees for vertically. And maybe checked to see if her serving tray is clear (and try to find other uses!).
Would it work in different/unknown lighting conditions? Has somebody done this already? Are there better vision systems for this bot? Or am I just lost in Disneyland? BTW, I don't have a whole lot of money for experimenting
So much depends on what you're trying to see and how much contrast it has against the background. Generally, ambient lighting cannot be relied upon for solid detection/recognition with any vision system. Controlled lighting is always better. If you're trying to detect objects whose characteristics can be discerned in a single dimension (or if you can sweep across the field of view accurately), and if those objects have good contrast against their background, the TSL1401-DB will probably work for you.
Comments
I counted the belt revolutions one day and would guess 400 fpm. The Hagen "camera" is not really a camera; it is an array of 20 infrared LED’s horizontal and 20 vertical.
Brian
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Imagination is more important than knowledge..." Albert Einstein
-Phil
A 1/4" should work fine, I'm going to start with the washer sorter first (they are easier to clean up). I have been collecting parts to build a proof of concept test conveyor. It will be 3"X5' black conveyor (for good contrast with washers) and have 3 electromagnets to remove the washers off at there proper spot.
Anyhow that has to wait a couple of weeks untill I get some other stuff finished up.
Brian
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Imagination is more important than knowledge..." Albert Einstein
The washer project sounds like a good "entry ramp". Be sure to use very diffuse lighting for the washers. Basically what you'll be looking at is the reflection of the bright diffuser in the shiny surface of the washers. Otherwise, surprisingly enough, they will be invisible against a black background if they're very shiny and lack diffuse reflectivity.
-Phil
Here is how one washer scans, notice the 4 extra holes. Sorry for the goofy colors, I wanted a small download.
Brian
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Imagination is more important than knowledge..." Albert Einstein
This looks like a interesting device. I'm looking for a device (maybe 2) to help me determine the x,y location of a object hitting a flat screen, similar to that of a touch screen on a monitor. Objects hitting the screen /glass will be about a 1/4 inch in diameter and will be hitting this screen at around 200-400 fps. Do you think this device would have the potential to detect an event such as this? I've been looking at IR-based multi-touch screen devices as a input to applications running on a PC. For many of the implementations, IR-Lasers and a web cam are used for detecting the "touch" point (X,Y position) on the screen. a few things which concern me are 1) that depending on the FPS of the web cam, I figure it may miss a lot of the hits, and 2) the image processing on the PC is pretty demanding. Also these solutions tend to be pretty large in scale, where as I'm looking for something more in the 10"X10" size.
Do you think I may be able to capture these events with the TSL1401 and one of the parallax CPU's? The information on the web page also mentions that information could be captured on PIC's and AVR's as well. How would one go about interfacing this sensor to one of those processors?
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 2/4/2010 5:36:22 PM GMT
Is there another sensor that you may be aware of that could possibly work for this application?
- Mark
Of course, you could always set up a continuous roll of paper in the way of the pellet, analyze the hole position after the fact with a 2D camera, then crank a clean sheet into view for the next shot.
But this has now become a topic for another thread, and you should post your more general query there.
-Phil
i am interested in some of this extrusion. i couldn't find it in the store. how can i get a piece of this? probably like a four inch piece, or however long you have them cut already.
Any timeframe on when the StrobeLED-DBM will be avaliable Phil? Also, i probably just missed it in the documentation, but what is the 'Code' button on the monitor program for?
It's a placeholder right now. The plan was to set everything up the way you want it, click the Code button, and a window would pop up with the PBASIC code needed to make the indicated measurement.
Good eye, though! You're the first person to inquire about it!
-Phil
Neat little device, do you think this device can be used to count or detect falling objects like seeds or pills with appropriate back light?
Thanks
Greg Hayes
Long answer: it will depend on how fast the objects are falling and how small they are. Basically, you need to take into consideration your shortest practical exposure interval and make sure it's short enough to capture the events you're looking for. If a pill completely passes the field of view between two exposrues, you'll miss it. It also matters whether the subjects you're detecting are organized into columns and singulated (spaced apart) or falling at random and possibly clumped together.
-Phil
John Abshier
-Phil
John Abshier
Red LEDs will provide the best reflection from a brown surface. With a light-colored surface, just about any visible color would work.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 5/28/2010 5:27:52 AM GMT
John Abshier
Post Edited (John Abshier) : 5/28/2010 9:45:59 PM GMT
I'm trying to attach this sensor to a line following robot, any ideas on how to detect a black line in white background??
-Phil
In reading the manual it looks like having a BS2pe motherboard is a win because Parallax provides image processing code which can be uploaded to the on-board AVR. Now I have a BS2e and an AVR on my robot, so I am wondering if I can do something similar. But it looks like the code is a hex file and uses a custom up loader.
I'm curious, what does the custom AVR code do? I suppose I could Google the algorithm and re-implement it in C. Also, I can run the demo code using a BS2, but the AVR has an on board ADC and more RAM. So I might be more bang for my buck interfacing it to that processor instead.
From what I've read the camera is going to return analog data at a certain baud rate so that it delivers a total of 128 bits. I would assume if I sample the analog pin during that time window I could accumulate these pixel values. But it occurs to me that I might sample during a pixel transition, so I would need to over sample in order to get accurate data.
Does this sound like it will work?
To take advantage of the specialized AVR code, you would need both an ATTINY13 and a BS2p, -pe, or -px. The BS2e does not have the requisite OWOUT and OWIN commands needed to communicate with the AVR program. The AVR/MoBo combination provides the functionality documented in the TSL1401-DB manual. Although you can connect the '1401 board to a BASIC Stamp directly, you will lose the gray-level analog capabilities and, perhaps more importantly, the ability to take advantage of the PC-hosted monitor and setup program.
In lieu of a MoBo, you could also plug the '1401 board into a Propeller Backpack and tether the BP/DB sandwich to your BS2e via a three-conductor header cable. At least then you would be able to take advantage of the PC hosted program. The current Propeller object does not yet support all of the post-acquisition image processing functions provided by the AVR, however.
-Phil
I'm fairly confident I can use the thresholding technique I saw in the manual to get bit patterns. So I'll try that on the stamp and AVR and see how it works out.
The propeller backpack sounds interesting.
Update: I just read through the shiftIn and shiftOut C code for the AVR. It looks straight forward to do and sample one of the analog pins as you shift the clock pin on your own.
Post Edited (Martin_H) : 7/28/2010 1:51:54 AM GMT
can any one tell me how to interface it with pic microcontroller
or with avr alone without using other microcontroller
because only available in Egypt
pic and avr
thanks for reading topic
All the information you need to interface the TSL1401-DB to a PIC or AVR can be found in the TAOS datasheet for the TSL1401R-LF sensor:
-Phil
So, I'm thinking using 2 of these sensors, 1 to scan horizontally, and 1 mounted 90 degrees for vertically. And maybe checked to see if her serving tray is clear (and try to find other uses!).
Would it work in different/unknown lighting conditions? Has somebody done this already? Are there better vision systems for this bot? Or am I just lost in Disneyland? BTW, I don't have a whole lot of money for experimenting
-Phil