Posted 11/12/16

In my last post on this subject, I demonstrated a 4-detector IR-homing setup that I constructed using some nice OSRAM IR phototransistors. The next step is to mount this module on my robot to see how/if it can be used to home in on an IR source.  Rather than try to integrated it onto my already crowded 4WD WallE2 robot, I decided to see if I could resurrect my original 3-wheel WallE robot and use it as a test platform.

As I mentioned previously, I had found that the OSRAM phototransistors   (in stark contrast to the OSEPP 6-detector IR Follower module) were not at all sensitive to my overhead LED lighting, eliminating the need for a sunshade entirely.  This made the mounting chore a  lot easier, and by happy circumstance, the mounting holes in the 4-detector module matched up with the front caster wheel mounting holes on the original robot.  So, mounting turned out to be just a matter of exchanging the original 3x6mm mounting screws with 3x12s and adding 1/8″ standoffs, as shown in the following photos.

Original 3-wheel WallE, with 4-detector module mounted at the front

Closeup of the 4-detector module mount

Next, I went back through all my old Arduino code projects and found the latest version of my 3-wheel robot code (I did mention that I  never throw anything away, didn’t I?). Then I  copied the relevant motor management code from this project into the project I had already started for testing the 4-detector module, and ran a couple of benchtop field tests.  For the tests, the robot started out about 75-80cm from the IR emitter, and (after some tweaking of error feedback factors) was able to home in on the emitter, as shown in the video clip below

I ran this test several times, and the robot was able to home in on (and actually strike) the IR emitter.  A representative final position is shown in the following photo

Final position after IR homing run. Note that the IR detector module actually struck (and bent) the IR emitter diode.

All in all, I think the ‘benchtop’ field testing was a qualified  success.  I wasn’t particularly ecstatic about the back-and-forth wandering of the robot as it tracked, but it certainly got the job done (or at least I thought it did until I looked at the actual tracking data as shown below).  As the plot below shows, the left/right differential value appears to be growing larger in each cycle, until the robot ran into the IR LED at about point 82.  This may well be due to my artificially limiting the max differential motor speed value (to less than 1/2 max speed) to keep the robot on the bench top, or possibly due to the positive feedback effect of the castering nosewheel.  Remains to be seen.

left/right Differential (Diff) and Left/Right motor speed values vs time for the 12 Nov 2016 Field Test

It remains to be seen whether or not the castering front wheel contributed to the ‘hunting’ behavior, and/or whether a different selection of error feedback factors would do any better.  Suffice it to say, however, that the tests were certainly successful enough to encourage me to continue this line of development.

Next steps might be to set up a longer range field test, and maybe to set up a situation where the robot has to transition from wall following to IR homing behavior.

Stay tuned!

Posted 04 November 2016

As a result of my now extensive testing with the OSEPP IR Follwer module, I have become convinced that it’s just not going to work for my intended IR homing application.  As shown in the following plot (copied from a previous post), the six detectors each have a usable spatial detection width of about 10-15 º.  However, because they are mounted to cover  a 180 º, there is a ‘dead zone’ of about 20 º between each detector position.

Results from fourth heading tests on bench-top range. For this test, the idea was to determine the approximate beamwidth of each detector

If the IR homing beam falls into one of these dead zones, it will be very difficult to generate an appropriate steering value, so steering behavior will probably be more like a ‘bang-bang’ setup than something that can be used to home in on my planned charging station.

The good news is I learned  a lot during this exercise, and one of the things I learned is that I don’t really need most of the circuitry on  the OSEPP module.  I wound up using only the analog outputs from the OSEPP module, and according to the OSEPP schematic shown below, this is just the raw detector voltage.

OSEPP IR Follower schematic. Note the analog out is just the raw detector voltage

So, using my trusty PowerSpec 3D Pro 3D printer I should be able to fabricate my own IR detector array, with the detectors spaced closely enough so that their half-power beam edges overlap significantly. That should mean that I can determin the IR homing beam angle-of-arrival (AOA) within just a few degrees, which in turn should mean much more accurate and continuous steering information.

Stay tuned!

Frank

Posted 02 November 2016

After arriving at a ‘sunshade’ design that completely blocked overhead IR source interference, I went back to my bench-top range to re-do the directionality testing.  To do this I printed out  a scaled copy of my 4-Inch Heading Circle graphic from a previous project, and modified it to serve as a heading indicator for the IR follower tests, as shown below

Heading circle image, modified for heading tests. Penciled numbers are detector designators

Heading test setup. IR emitter LED is clamped to the bench vise in the background.

To perform the tests, I created a small Arduino program to read and print out the analog readings from   all six IR photodetectors, and recorded the results in a Excel spreadsheet.  Then, using Excel’s superb graphing tools, I plotted the outputs, as shown below.

Results from first heading tests on bench-top range. Minimum values for each photodetector are highlighted

As can be seen in the above results, the photodetectors read around 700-900 when no IR is present, and 50-60 when the detector aligned with the IR beam.  As can be seen, the heading response for each individual detector was rather narrow, with the minimum occurring at only one heading, with essentially zero detection on either side of the minimum value.   These results are a bit problematic, as the wide ‘dead zones’ between detection angles  may make it difficult to derive good motor steering commands for IR homing.

To determine if the above ‘dead zone’ issue is due to the inherent directivity of the detectors or to the optical isolation provided by the sunshade vanes, I decided to manually pare back the isolation vanes in small steps to determine their influence on the dead zones, and to determine if I could do so without adversely impacting overhead IR source suppression.  As a control, I took A/D readings with the LED emitter disabled, but with one overhead LED bench light turned on (this is known to be a strong IR emitter), as shown below:

A/D reading test with LED emitter OFF and one LED bench light ON. Note black foam piece blocking reflection from power strip in background

With this setup, I got the following readings with the IR LED disabled and the bench light ON:

LED1 LED2 LED3 LED4 LED5 LED6
712   796     847    864    731   818

Next, I removed 8mm from the central sunshade vane, as shown in the following photo, and repeated the heading test.  The results don’t vary significantly from the first one, and lead me to wonder if the vanes are actually doing anything, or it just seemed that way because they were combined with a larger overhang going from sunshade V4 to V6.

Central vane length reduced by 8mm

Results from second heading tests on bench-top range, with central vane length reduced by 8mm. Minimum values for each photodetector are highlighted

Since the results from the test with 8mm removed from the central vane didn’t seem to be much different from the original, I removed another 4-5 mm so the front edge of the central vane matched the outer edge of the IR follower PCB, and repeated the test, as shown below

Central vane length reduced by 12mm

Results from third heading tests on bench-top range (12mm removed from central vane). Minimum values for each photodetector are highlighted

So, it is clear from the above that at least the central vane does not significantly alter detector behavior.  After this, I decided to try and determine the approximate beamwidth of each detector.  For the beam-edge point, I used an arbitrary reading of 200, as shown in the following Excel table and plot.

Results from fourth heading tests on bench-top range. For this test, the idea was to determine the approximate beamwidth of each detector

From the above, the approximate beamwidth for these detectors is about 10-15 deg.  Since the vanes are set 36 degrees apart, they are well outside the photodiode detection angle, so that explains why removing the central vane had no significant effect.  However, it does point up a potentially serious problem when attempting to use this arrangement for IR following; the photodiodes are set 36 degrees apart, with 15 degree beamwidths, so there will be a dead zone of approximately 20 degrees between each ‘live’ sector.  This has two negative implications:

• My idea of mathematically blending detector readings to produce a continuous steering error term for motor drive probably won’t work, or won’t work very well
• The narrow detector beamwidth may be susceptible to multipath effects, where a narrow detector beam intersects a spurious reflection term from the IR emitter.

The next step is to produce another version of the sunshade with all 5  vanes cut back to the edge of the PCB, to verify that detector behavior doesn’t depend on the vanes, and to try some  different IR emitters.  The IR LEDs I have on hand at the moment are also narrow (i.e. 10-15 deg) beamwidths, but  I have some 30 deg ones on order.  Also, the current full saturation detection range is only about 20 cm, so I want to try some higher power emitters to see if I can get the range up to something practical – like 1.5-2 m.

Stay tuned!

Frank

03 November 2016 Note:

After installing the new sunshade with all vanes cut back to the outer edge of the PCB as shown below, the bench-top detector response vs angle test was performed again, with basically identical results to the previous one. This shows that the vanes aren’t needed at all, at least not the portion that extends past the edge of the PCB.

Sunshade with all vanes pared back to outer edge of PCB

04 November Note:

I acquired some Vishay TSAL6200 100mA  17 deg beamwidth IR LEDS (see spec sheet excerpt below), and ran some quick detection range tests with an LED current of about 60 mA, I was able to easily detect the IR signal at well over 1m.  This distance is probably sufficient for initial detection in time for IR homing into my planned charging station, so I am reasonably optimistic that this just might come together ;-).

Vishay high-power IR LED. Max forward current = 100mA

Posted 29 October 2016

In my last post, I described the evolution of an IR ‘sunshade’ for the OSEPP IR follower board.  The version 3 shade did indeed cut out most of the direct IR term from the overhead lighting, and most of the high-elevation multipath as well.

So, I set up some directional tests on my bench using an IR LED clamped in a small vise, with the OSEPP board sitting on a pad of post-it notes to achieve the proper elevation relative to the IR diode.  I then wrote a short Arduino program to print out the IR detector analog values, to see if the board was directive enough for use as part of a IR homing setup.

Benchtop directionality testing setup.  The transmitting IR LED is visible in the background, clamped in my bench vise

Unfortunately, the initial test results were not what I hoped for.  Directionality response was erratic, with LED 1 (3 O-clock using the connector strip as 6 O-clock) responding better  when the board was oriented directly toward the IR led than when boresighted on the IR emitter.

Board orientation for max response on LED1 (LED1 is oriented toward 3 O-Clock)

By moving an opaque 1/2″ mixing stick around, I was able to discern that the odd response angle  It appears to be caused by IR energy being reflected from other internal structures on the board, although this doesn’t explain the lack of response on-boresight.  So, I decided to add some internal isolation vanes to the sunshade in a ‘vane attempt’ (pun intended) to suppress internal reflections, as shown in the following image.

Sunshade V4, with detector isolation vanes installed

02 November 2016 Post:

As it turned out, the above sunshade wasn’t quite big enough, so I wound up going through two more versions before arriving at one that completely blocked overhead IR sources.  The final design is shown below:

‘Final’ sunshade design

‘Final’ sunshade design. Note the manually cut away portions to clear PCB components

Final (hopefully) version of the sunshade, incorporating the PCB component clearance cutouts

Posted 28 October 2016

In my last post on this subject, I described the OSEPP IR Follower circuit I found at MicroCenter a few days ago, and my thoughts about incorporating it onto Wall-E2, my wall following robot.  After a few tests, it became apparent that the OSEPP circuit is quite sensitive to IR, and in fact the LED track lighting in my lab puts out enough IR to swamp out the signal from my test IR emitter.  So, I set about developing an ‘IR Shade’  to shield the detectors from elevated IR emitters (this turns out to be harder than I thought, due to IR multipath effects, but I digress).

So, my first attempt was a 3D printed ‘sunshade’ as shown below

IR Shade V1 – Top View: 1 mm thick, with approx 5 mm overhang

IR Shade V1 – Side View: 1 mm thick, with approx 5 mm overhang

This shade was 1mm thick, with about a 5 mm overhang on the IR detectors.  The shade is supported via two posts that mate with mounting holes on the OSEPP board.  When I tested this shade with my LED bench lamp, it basically didn’t do much.  Apparently 1mm is nowhere near enough material :-(.

Next, I tried placing some black electrical tape on the shade, as shown below.

IR Shade V1 with black electrical tape – Top View

The black electrical tape helped significantly, which is how I found out about the IR multipath problem.  Not only am I having to contend with blocking the direct path, reflections from nearby objects can also cause problems.

To address the direct path problem, I modified the shade design to be 3 mm thick, with 80% fill density vs the original 40%.  Hopefully this will be enough to cancel out the direct path, leaving only the multipath issue.  I don’t think there is much I can do about the multipath, other than assume that the field (i.e. the hallways in my house) won’t have that problem, as the lighting is mostly incandescent, and the ceilings are mostly 10 ft (3.3 m) away – we’ll see.

IR Shade V2. 3mm thickness, 80% fill

Even this one didn’t work as well as I’d hoped, so on to version 3 – with a larger overhang – about 8 mm.  This one blocked all the direct path IR and most of the multipath as well.  I’ll stick with this on for now, and move on to some steering tests.

The version 3 IR ‘sunshade’ with 7-8 mm overhang