Shop OBEX P1 Docs P2 Docs Learn Events
IR Compound Eye from RBB 4 and Let's Make Robots (Video) — Parallax Forums

IR Compound Eye from RBB 4 and Let's Make Robots (Video)

Martin_HMartin_H Posts: 4,051
edited 2012-12-01 08:01 in Robotics
RBB 4 and the Mr General Project from Let's Make Robots have information on this IR compound eye project:

http://letsmakerobots.com/node/10822

To use with a Basic Stamp 2 or Propeller you would need external A/D conversion, but that's a small thing. But two things about the schematic bug me because I don't understand them.

The 39 ohm resistors for the IR LED series/parallel array seem odd. I used this wizard http://led.linear1.org/led.wiz and it suggested two 100 ohm resistors for such an array. Using lower resistance will increase the brightness, so maybe that's desired to increase range.

The value of 820 ohms for the resistor on the transistor base also seems low. For similar circuits turning on an LED the values have been closer to 4.6 K ohm. Does the increased current draw from four IR LED's require the decreased value?
«1

Comments

  • ercoerco Posts: 20,256
    edited 2011-08-15 20:26
    Dunno about the values, but cool project! Do it!
  • Martin_HMartin_H Posts: 4,051
    edited 2011-08-16 09:48
    In intend to as I already have 20 IR LED's and 20 IR photo transistors. I also have a bunch of 4.7 K ohm resistors, while not 1% tolerance (the suggested tolerance), my DMM says they're all close in value which seems more important than being exactly 4.7 K ohm.

    But 39 ohm and 820 ohm resistors aren't available locally, so I'm thinking of substituting. I could either go with a 100 ohm which the wizard suggested or use 33 ohms which is the closest value I've seen. Both of which I also already have. I also have some 1 K ohm resistors which measure a bit above 900 ohm, so I think one of them is close enough for the bias resistor.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2011-08-16 10:23
    39 ohms is about right for two IR LEDs with approx 1.5v drop each, and a good, solid 50 mA drive. Many IR LEDs can support that current, and higher (Radio Shack's high output LEDs go up to 100 mA). You want the drive to increase the range. Be sure to use 1/4 watt resistors as 1/8 watt is a bit too close to call.

    When I tried the calculator I got 45 ohms. It all depends on the numbers you enter for drop and current.

    You can only guestimate for the phototransistor resistors , as they'll really depend on the exact phototransistors you use. Unless you're designing for specific components it's all an approximation anyway. Your aim is to increase sensitivity while providing the highest voltage swing. Adjusting the resistance affects one or the other.

    The only components you risk if you try a lower value is the IR LEDs. I wouldn't go much under 35 ohm, unless you're sure your LEDs support the current.

    -- Gordon
  • Martin_HMartin_H Posts: 4,051
    edited 2011-08-16 13:02
    Gordon, thanks for the details. I think I can find a much better substitution using that information.
  • ercoerco Posts: 20,256
    edited 2011-08-16 13:34
    I like to shield my phototransistors from ambient light with a hood. Just makes sense to ignore light coming in from the side. The degree of darkening will also affect the optimum resistor value in the ptx voltage divider arrangement. I like the LMR suggestion to parallel 2 ptx for increased sensitivity, I will have to try that too.
  • Martin_HMartin_H Posts: 4,051
    edited 2011-08-19 18:33
    After a few evenings of soldering and testing I have this:

    IMG_20110819_211010.jpg


    Looks pretty for a point to point board! Just don't look on the back!

    You'll also see the CBA with a propeller backpack and line scan camera on the Ping))) bracket. That's part of an unrelated project.
    1024 x 768 - 244K
  • Martin_HMartin_H Posts: 4,051
    edited 2011-08-21 19:11
    So here's the progress on this project:

    Picture 170.jpg


    I formed the bracket and the beginnings of a tilt pan assembly out of sheet aluminum from the hardware store. I used my typical technique of marking a line, cutting with tin snips, and smoothing the edge with a file and sandpaper. A rubber mallet and a wooden mandrel were used to make the bracket shape. This time I am using mini-servos, so the assembly is quite small.

    Between soldering the boards and making the bracket, my time investment greatly exceeded the cost of buying a kit from Robot shop. But I don't think I would have been as interested if I did that.

    However, the robot chassis is a tank bot kit I bought from Servo Magazine, so this isn't a full scratch build.
    1024 x 768 - 51K
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2011-08-21 22:29
    I'm impressed! You're a true DIYer!

    You're even using one of my Tankbot Servo bots, so I'm doubly impressed. (I no longer make it, but if you need any replacement parts let me know. I still have the pattern files on my CNC.)

    BTW, don't use the Tamiya track set with those higher power replacement FA-130 motors from Pololu. I used them on a different style of tracked robot, and they have so much torque they just strip out the plastic of the drive sprocket. I ended up having to clamp the sprocket to the hex shaft with a 1/4" collar and setscrew. Mad stuff.

    -- Gordon
  • Martin_HMartin_H Posts: 4,051
    edited 2011-08-22 08:01
    Gordon, thanks! Good to know about the spare parts option and not mixing the higher power FA-130 with the Tamiya tracks. While on vacation last month I read "Robot's Builder's Bonanza 4" cover to cover and got a number of project ideas. So my next few projects are going to be imitation as the sincerest form of flattery.

    The genesis of this project is that my CBA robot is great for odometry and line following on hard smooth surfaces, but completely hopeless on uneven surfaces of any kind. So I started getting a yen for an all terrain robot. I was thinking of scratch building a 4WD like your Rigel design, but I saw that the TankBot kit was still available from Servo magazine. So I went with that instead.

    I may still build a 4WD for outdoor use, but for the money required to build a good one a quadcopter might be the ultimate all terrain outdoor vehicle!
  • Martin_HMartin_H Posts: 4,051
    edited 2011-09-04 13:18
    I have made good progress on this project as phase one of the hardware construction is done. Here are front and side views:

    Pic 048.jpg


    Pic 049.jpg


    I am now programming and noticed that my right and top eye zones are far more sensitive than left and bottom. The DMM shows continuity for all phototransistor and equal values for all resistors. I measured voltage across the phototransistor and the values are slightly different for the more sensitive zones. So I can only assume the photo transistors are not well matched.

    Any tricks to ensure more equal response?
    1024 x 768 - 65K
    1024 x 768 - 64K
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2011-09-04 16:26
    So, if you mount the assembly "upside-down" (turn 180_deg), does the sensitivity issue follow/spin with it (left and bottom more than right and top)?
  • Martin_HMartin_H Posts: 4,051
    edited 2011-09-04 16:57
    PJ Allen, that's a good point. I took it off the tilt/pan bracket and the sensitivity issue moved with the rotation. Since the output cable is symmetric I flipped the cable 180 degrees to eliminate it as well.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2011-09-04 17:45
    The phototransistors may not be matched, the LEDs may not give off the same intensity, the LEDs may not be exactly mounted in the same plane, the phototransistors may not be all seated the same. All are not only possible, they're likely. While you could use trimmer pots to adjust for the differences, it's much easier to simply do it in code.

    Since you're dealing with proximate zones anyway, increase or decrease the returned values to equalize them. If it turns out they're not all linear (likely), and you need them to be, use a mapping function.

    -- Gordon
  • Martin_HMartin_H Posts: 4,051
    edited 2011-09-04 18:31
    Gordon, well it's good to hear that this is likely normal. I had already worked in an offset by subtracting the equivalent of a dark frame. But then I noticed the non-linearity and started to think I goofed in some way. I can definitely work out some kind of scaling function to try to normalize them.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2011-09-04 19:58
    Martin, Do remember the book makes note of this. It also suggests (see the end of the sidebar) that if the readings are within about 100 points -- given a 10 bit resolution -- you can just set threshold levels with a wider latitude.

    -- Gordon
  • Martin_HMartin_H Posts: 4,051
    edited 2011-09-05 06:21
    Ah indeed it does. I missed the last paragraph of the sidebar on my two readings of the project. I'll blame poor vision and the need for new glasses. The +1.75's aren't cutting it anymore.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2011-09-05 10:06
    I'm now up to +2.75 for soldering and close-up work. Magnifiers are now strewn all over the house. It doesn't help that boards are smaller, and so are the silkscreen legends. It's not helpful when they do 0V and 5V. I'm not fond of Vss and Vdd for the same reason. Too easy for old codgers to misread the labeling!

    -- Gordon
  • Martin_HMartin_H Posts: 4,051
    edited 2011-09-11 18:05
    Here's a video of the completed phase one:

    For phase two I plan to add edge sensors so the tankbot won't drive off edges, as well as front and rear aluminum bumpers. I may circle back and build a second IR compound eye using higher quality phototransistors. The eBay specials I purchased are really non-linear in their response, so right versus left and up versus down are not equally responsive. I added scaling functions and some code to trim the last few bits, but it is still pretty twitchy.
  • ercoerco Posts: 20,256
    edited 2011-09-11 19:55
    Looks good! And thanks for being THE builder guy in the Robot forum this weekend. Nuthin' else going on here, you're the keeper of the flame.

    Silly question: couldn't we do the same thing (with greater sensitivity & range) using four 38kHz IR detectors, looking for reflected 38kHz IR, in a multiplexed array?

    Edit: In fact, there's a Scribbler or Boe-Bot app that does an IR frequency sweep to pseudo-measure distance, based on the 38 kHz detector's off-center sensitivity. I just know something like that could be used here. Simple hardware and clever coding could make that detect direction and distance in 2 axes, as the videos in the very first post showed.
  • Martin_HMartin_H Posts: 4,051
    edited 2011-09-12 06:51
    Erco, not silly at all as the same thought occurred to me. But I had all the parts and figured building the eye per the plans would be fun. I can always build a second one from what I've learned and redesign to my liking.

    Frankly the analog eye requires a fair bit of fiddling. You need to read the un-illuminated values, the illuminated values, and subtract the two. These delta must be zero adjusted and rescaled using measured constants in an attempt to make the response as linear as possible. But lighting condition and the phase of the Moon seem to change these constant values, so the result is a fairly twitchy robot. But that isn't all bad as the eye is dirt cheap, and the twitchiness adds randomness to the motion which could be handy in getting out of corners.

    But all this means that multiple reads using a frequency sweep isn't all that much more trouble and you eliminate the need for analog to digital. Parallax designs using 38kHz IR detectors have a single center detector with an IR LED for each zone. Following that model you would have one or two IR LED's per zone and a single the 38kHz IR detector in the center.

    This might be to reduce costs as a single 38kHz IR detector cost $4.00 at Radio Shack, so one per zone would get pricey. Would using the IR detectors in parallel increase sensitivity like a phototransistor or are they essentially digital and both would fire or neither?
  • ercoerco Posts: 20,256
    edited 2011-09-12 08:40
    No need for parallel 38 kHz detectors, they are far more sensitive than bare phototransistors could ever hope to be, via onboard amplifiers & fiilters. You might get by with a single center-mount detector, and 4 IR LEDs around the outside. This is the Scribbler's configuration or obstacle avoidance. One center-mount detector and two IR LEDs, left & right. You alternate sending signals from the LEDs, so when you get a reflection, you know where the signal originated.

    I might just have to mess with this after we get back from vacation... :)
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2011-09-12 17:19
    Martin, I tend to use these kinds of sensors with one, and at most two, "proximity zones," and don't worry about linearizing them (except for gross adjustments). I really only care if something is close, and maybe very close. Anything under a certain threshold is simply ignored. That makes these analog sensors digital, but with programmable thresholds. With two thresholds you have "trigital" outputs that provide some additional proximity information, but that's not always necessary.

    The primary aim of the compound eye is to use the patterns of on/off sensors to determine direction. Most line following algorithms work this way, converting the position of the line under an array to a number from 0 to n, with n/2 meaning the line is centered. A similar technique could be used for X and Y, converting on/off values for the left/right/top/bottom zones to any of nine directions. I suppose you could try to use a sensor like this to detect distance and not just close proximity, but I'm not sure it was really intended for that (other than a happy circumstance if it works).

    The IRPD method using 38 kHz sensors can use one or two (or more) receivers; the wider the eye field, the more the separate sensors come in handy. For a sensor the size of the compound eye a single IR receiver in the center, with pulsed LEDs around it, should be sufficient. However, this still only gets you proximity. The receivers are digital on/off devices.

    (Though for experimentation, Andy Lindsey's Boe text shows how to "sweep" the carrier frequency to roughly determine distance, since the further away from center frequency you get, the less sensitive the receiver becomes. IR using the strength of the reflecting beam is never an accurate measure of distance, since lots of things can effect how much light is bounced back.)

    -- Gordon
  • Martin_HMartin_H Posts: 4,051
    edited 2011-09-13 06:19
    Thanks Gordon. Given that I can't see IR it's hard to appreciate that different surfaces vary in their reflectance of it. But the design of the Sharp IR distance sensors makes a lot of sense when you consider that.

    I got the idea of measuring distances by reading OddBot's code. But he only estimated the distance by summing the value of all four channels, not a single channel.

    Another interesting thing I've noticed is that the amount of illumination one sensor receives seems to alter the reading of the other sensors. For example if I add a light shield to one photo transistor, its reading goes down, but all the other sensors increase in value. So the channels seem some what coupled which is probably why OddBot did it that way.
  • Martin_HMartin_H Posts: 4,051
    edited 2011-10-02 11:33
    So I built a second eye using a 38 KHz IR sensor and four IR LED's. I used a digital camera and verified that all four LED's are working. I also used the TV remote trick to verify that the IR sensor is working.

    Now I'm writing the code which will sweep through a range of frequencies for each zone and read the input state from the 38 KHz sensor. Obviously I want to do this as quickly as possible, but not so quickly that the readings blur together.

    So I'm curious, how long after the trailing edge of the 38 KHz pulse will the detector stay high? I figure I need to wait that amount after the read and before the next pulse.

    Update: I tried good old trial and error and have been able to do the frequency sweep for three zones. I can definitely sense five distance zones with a bit of jitter. The fourth zone seems to not work with the same time constant. Not sure what is up with that.
  • ercoerco Posts: 20,256
    edited 2011-10-02 23:06
    XLNT work! Can you 'scope it to measure the delay? There's probably a range, as there are many different types & specs of IR modules: daylight optimized, flourescent filtered, continuous signal acceptable, etc. Video when you can, please!
  • Martin_HMartin_H Posts: 4,051
    edited 2011-10-03 13:05
    erco wrote: »
    XLNT work! Can you 'scope it to measure the delay? There's probably a range, as there are many different types & specs of IR modules: daylight optimized, flourescent filtered, continuous signal acceptable, etc. Video when you can, please!

    Thanks, that makes sense. Unfortunately I don't have a scope, and could use one for this project. Hopefully I'll have time for a video this weekend after ironing out the remaining kinks.
  • ercoerco Posts: 20,256
    edited 2011-10-03 13:57
    Martin_H wrote: »
    .

    So I'm curious, how long after the trailing edge of the 38 KHz pulse will the detector stay high? I figure I need to wait that amount after the read and before the next pulse.

    The detector goes active low, but you knew that! :)

    With some work, you could get tricky and use PULSIN to measure the active low period. You could start PULSIN with the IR output signal the IR signal seperately (no delay), then AND/OR that with the delayed IR sensor output.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2011-10-03 14:45
    Is there a reason to be concerned about the switching time of the detector? Any delay is the inherent latency in the device, and would likely vary between manufacturer and model.

    Do remember that you should provide a stream of pulses with a "quiet" time between. Most of the datasheets for these things show this. The off period aids the detector in setting a quiescent level. The AGC inside the detector may not function properly if you constantly bombard it with a signal, and range could be affected. A good rule of thumb is 600 us or longer on, then off, then on, then off, etc. If you're pulsing four LEDs, you want the quiet period between each of the four. Avoid pulsing them right after the other, as the detector could see this as a steady stream.

    -- Gordon
  • Martin_HMartin_H Posts: 4,051
    edited 2011-10-03 18:22
    Is there a reason to be concerned about the switching time of the detector? Any delay is the inherent latency in the device, and would likely vary between manufacturer and model.

    Do remember that you should provide a stream of pulses with a "quiet" time between. Most of the datasheets for these things show this. The off period aids the detector in setting a quiescent level. The AGC inside the detector may not function properly if you constantly bombard it with a signal, and range could be affected. A good rule of thumb is 600 us or longer on, then off, then on, then off, etc. If you're pulsing four LEDs, you want the quiet period between each of the four. Avoid pulsing them right after the other, as the detector could see this as a steady stream.

    -- Gordon

    Gordon, thanks this is good information.

    The detector came from Radio Shack with only the pin out diagram. The Radio Shack website has no pointers to data sheets. The part number looked like a radio Shack catalog number and not an industry one. Things are mostly working, but I definitely need to shorten my pulses and increase the quiet time between pulses.

    My concern was two fold. One was waiting two long after the pulse to read the input, but that hasn't been a problem. The second part was what you described which was not giving the detector enough down time. I think that might be the case and I need to tweak my code.

    Erco, using the microcontroller as the calibration tool is a good idea and I'll try that too.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2011-10-03 20:44
    The way most of these work is you send at least 600 us of 38 kHz pulses, and if the receiver detects the pulses its output drives low. You should look for the low signal concurrently while sending pulses, as the output will toggle with each group of pulses.

    A duration of one millisecond on, one millisecond off, is a convenient rounded-up duration most MCUs are capable of. A couple of milliseconds on and off probably won't upset its AGC. More than a half-second or a second...might be pushing it. (But I also imagine this will largely depend on the specific device.)

    Even if there is a 50% latency in the output, with respect to the input burst, you shouldn't have a problem detecting it. I don't recall what controller you're using, but a typical method is to drive the 38 kHz pulses from a timer connected to one end of the LED (or use a 555 or something), then gate the LED on and off from another pin. You can play to see if you need any slight delays after gating the LED, and before testing the output of the receiver.

    -- Gordon
Sign In or Register to comment.