Monthly Archives: November 2016

Wall-E2 Charging Station Design, Part II

Posted 21 November 2016

Currently Wall-E2 is powered by a 2-cell LIPO 2000maH, 20C RC battery as shown below.

Current Wall-E2 battery pack

The charger I use is a X-Charger C6 model, which works great, except it has to be manually connected to the main T-connector, and manually started using front-panel pushbuttons.

LIPO Battery Charger

For my planned charging station, I need a charger that can be automatically activated, either by simply driving Wall-E2 up onto the charging platform, or by computer control (Arduino or some such controller). After Googling around for a while, I thought I was pretty much going to be forced to roll my own high-rate 2-cell charger, as I couldn’t find anything like the XCharger above but with a computer control option. Then, in an uncommon burst of inspiration, I realized I could use the balance connectors associated with all these high-rate packs to charge both cells in parallel, using any one of the many popular computer-controllable single-cell LiOn/LiPO chargers, like this one from Adafruit, shown below:

Adafruit PowerBoost 1000 LiOn/LiPo charger

And some LiPo batteries to go along with it, like these

Adafruit 3.7V 2500mAh LiPo battery

After thinking about this for a while, it now occurs to me that I might wind up with something very close to the setup I had in my original Wall-E wall following robot, with two 3.7V single-cell batteries and two charging modules on the robot, with a DPDT relay to switch the cells from series connection (to run the robot) and independent (for charging).

The issue is how to charge the battery pack; I can charge a 2-cell pack with my XCharger, but that requires manual interaction each time, and the XCharger is physically large. Physical size isn’t a huge problem for the fixed-position charging station, but the manual interaction issue is a deal-breaker. There are some designs for DIY multiple-cell LiPo chargers out there, but I don’t want my wall-following robot project to metastasize into a LiPo charger design project (I already have enough alligators in this swamp – no need to add more!). So, since really nice single-cell charging modules are already available, why not use them? As a bonus, the chargers can be mounted on the robot within easy reach of the standard 2-pin JST-PH connectors, so all I need on the charging station side is +5V DC power, which I can apply through the planned spring-loaded connectors on the bottom of the robot. As an added bonus, I might be able to fit the entire assembly into the bottom cavity along with the motors – this would free up lots of space and dramatically simplify the currently somewhat messy wiring layout

The following images shows the Wall-E wiring diagram from about 18 months ago

Wall-E charging setup from early 2015

Original Wall-E battery charger and relay installation. Relay is at bottom right corner of the photo

The only difference between the above setup and my planned one for Wall-E2 is the batteries themselves are 2500mAh instead of 2000, and the charging modules are a heavier-duty type.

Stay tuned!

Frank

Wall-E2 Charging Station Design, Part I

Leave a reply

Posted 20 Nov 2016

As the reader might recall, my grand plan for forcing the entire universe to kneel to my all-powerful Wall-E2 robot (OK, so that is a slight exaggeration – my real plan is to subject our two cats to the depredations of an always-charged wall-following robot). Wall-E2 has been wall-following for a while now, but I hadn’t been able to come up with a good idea for how to get it to locate and connect to a charging station. This all changed when I happened upon the OSEPP IR-follower module at MicroCenter, which resulted (eventually) in my 4-detector adaption of that concept. After some additional work, I arrived at a reasonably effective PID-based IR-homing algorithm for Wall-E2. So, now it is time to start working on the design and fabrication of a charging station.

Charging Station Concept:

The concept for Wall-E2’s charging station is that an IR emitter will be mounted in such a way as to lure Wall-E2 into a ‘capture basket’ formed by a set of slanted guide rails. Once in the basket, Wall-E2 will be forced up a ramp to a pedestal that will further guide the robot to a point where contacts on Wall-E2’s underside mate with contacts on the pedestal. Once the contacts mate, the motors will shut down and charging will commence. When charging is complete, Wall-E2 will back down off the pedestal and out of the capture basket, and continue its normal wall-following/cat terrorizing operations.

Using TinkerCad, which just has to be the greatest, most user-friendly 3D design platform known man, I whipped up a half-scale model of the charging station, and of the Wall-E2 robot chassis, as shown in the following screenshots.

1/2-scale concept model for the Wall-E2 charging station

1/2-scale model of the Wall-E2 4WD robot chassis

1/2-scale robot chassis on the 1/2-scale charging station model

Having the ability to put a 1/2 scale 3D model of the robot chassis on my newly-designed 1/2 scale model of the charging station is that I can immediately check for dimensional goofs (not that I ever make that sort of mistake!). Even more cool, I can easily examine internal structural issues by temporarily converting the entire robot chassis into a ‘hole’, making it transparent. This capability immediately paid off, as I was able to identify an interference condition between the station pedestal and the robot’s wheels. As shown in the following screenshot, the inside of the wheels have an interference fit with the sides of the pedestal (the dark areas indicated by the arrows on the bottom inside portion of the robot’s front/rear wheels).

Closeup of Wall-E2 on the charging station, with the chassis model made temporarily transparent. Note the interference fit between the robot’s wheels and the pedestal (arrows)

This sort of problem is trivial to fix at this stage, since nothing has been fabricated. Gotta love that 3D modeling stuff! ;-).

When I created the charging station conceptual design in TinkerCad, I sort of eyeballed the angle of the ‘capture basket’ sides with respect to the station centerline at 20 º. As a sanity-check, I measured (in TinkerCad, it is usually convenient to simply construct a measuring stick from a box object) the opening in the ‘capture basket’ at about 158mm, or about 1.8 robot-widths. Then, going back to the videos I made during the PID tuning effort, I was able to superimpose the capture basket rails onto the last few frames of the video to see how well the capture basket dimensions fit with the observed homing behavior.

First, I captured a representative frame from my last/best ‘straight-in’ approach, and used Paint to add some lines to represent the capture basket lead-in rails. For this purpose, I measured the width of the robot in pixels (about 250 px), and used 1.5x instead of the measured 1.8x to compensate for the wheel guards on the actual robot. I called this measurement ‘Rwp’. Then I drew a 40deg capture basket with two lines starting about 0.5Rwp above and below the IR emitter location. As can be seen in the following image, the robot will indeed be captured within this capture window, at least for the ‘straight-in’ homing case.

Frame from straight-in homing video, with simulated capture basket lines

Then I did the same thing for a frame from my ‘Side Capture’ video, as shown below. For this frame, Rwp is about 200, so the capture basket lines were adjusted accordingly.

Frame from side capture homing video, with simulated capture basket lines

As can be seen in the image, the robot would have hit the right side capture basket rail. So, something will have to be done to limit the emitter beam width so that the robot can’t detect the beam unless it is more aligned with the charging station centerline.

Stay tuned!

Frank

IR Light Follower for Wall-E2, Part X. More PID Tuning

3 Replies

Posted 19 November 2016

Well, as usual, things aren’t quite as simple as they seem, and the ’10 minutes, tops’ rule still applies (whenever someone says ’10 minutes, tops’, they are lying by at least one order of magnitude!). But, on the bright side, I really do understand PID control systems a lot better now (a low bar, as just the other day couldn’t remember what the ‘P’ in ‘PID’ stood for!), and I now think that WallE (and/or WallE2) has a pretty reasonable chance of homing in on an IR beacon with sufficient accuracy to be captured by a charging station setup.

In my last post on PID tuning, I had assumed that the PID compute engine normalized the tuning constants before doing the computation, and I decided I needed to check that assumption before continuing. When I looked into the actual code in the Arduino PID library, I found that this was not true – the PID compute engine does not normalize. It simply computes the PID expression:

output = kp * error + ITerm- kd * dInput;

where ITerm is ITerm+= (ki * error)

However, what this means is that my previous attempts to simplify the tuning problem by eliminating the I and D terms and just tuning the P term was doomed to failure – there was no way ‘do just P’ because the physical dynamics are too complex. The response curves of the IR detectors (shown below),

4-detector heading test results

combined with the physical dynamics of the robot itself, require more than just a proportional response to the error (the difference between the sums of the two left and two right detector readings) term. Ken suggested I could do this by using a pulse train (similar to PWM) for the motor drive signal, but I think that is equivalent to adding some ‘D’ to the PID tuning parameters.

In addition to the physical dynamics issues, there is also the problem of the detector response versus distance. At maximum detection range, all detector readings are near 1000, so the error term is very small, on the order of 10-50. However, as the robot gets closer to the emitter, that error term rapidly gets much larger, on the order of 500-900. This means that the PID tuning parameters appropriate for the ‘far’ case will be wildly inappropriate for the near case (another consequence of not normalizing the PID values internally).

In any case, after a loonnnggggg series of floor field tests, I think I have arrived at a reasonably effective homing algorithm. Instead of trying to modify the PID tuning parameters as the robot approaches the emitter, I found it more effective to keep the PID tuning parameters constant, and instead scale the PID input (error) signal in three steps; 1 (no scaling) for error term values below 200, 0.2 (divide by 5) for values between 200 & 500, and 0.1 (divide by 10) for values above 500. A representative set of data and some videos are shown below. The last video shows a ‘side capture’ scenario, where the robot approaches at right angles to the IR beam and successfully captures the beam and homes in on the emitter.

Typical run with 1/5/10x scaling as emitter is approaced

Typical run with 1/5/10x scaling as emitter is approached. Scaling term is shown here at 100x for clarity

Side capture scenario. Scaling term is shown 100x for clarity

So, at this point I’m convinced that the PID/input scaling arrangement will work, and that I can get WallE2 to home in on an IR beacon. The next challenge will be to integrate the IR homing function with the normal wall-following function, and to design/fabricate the charging station itself. Stay tuned! ;-).

Frank

IR Light Follower for Wall-E2, Part IX – PID Tuning

Leave a reply

Posted 16 November 2016

In my last post on this subject, I described by attempt to add PID control functionality to WallE’s IR light-following algorithm, and this is now looking pretty promising. As an added bonus, I managed to suck my stepson Ken Frank, who graduated from Cornell with a MS in control theory, into helping me tune the PID controller. His first comment (well, the first comment after the obligatory “what have you gotten me into now, Ollie!”) was something like “you are over-controlling – you should simplify the problem and start with just ‘P’ – no ‘I’ or ‘D’. Then add P/I as necessary after getting the P value right. Wish I had thought of that! ;-).

Anyway, I revised the code to do just that – with PID tuning parameters of 4,0,0 for both the far away and near cases, and re-ran my ‘floor range’ field test, as shown in the following video clip and plots.

Left/Right Differential (input to PID engine) and Output

All data from the run

More to follow…

After taking the above video and data, it occurred to me that it was possible (although not very probable, IMHO), that the PID engine might not normalize the tuning parameters before computing the new output. So, I ran two more tests – one with a PID of 1,0,0, and another with a PID of 10,0,0. These tests, along with the ones for 4,0,0, should provide some insight into that question. As can be seen from the plots, the tracking behavior for all three PID = X,0,0 conditions are pretty similar. I also included a video clip of the PID = 1,0,0 condition.

161116_floorfieldtest15data 161116_floorfieldtest16data

More to follow

Frank

IR Light Follower for Wall-E2, Part VIII

Leave a reply

Posted 13 November 2016

After reviewing the benchtop field test results, I decided to try implementing a PID (Proportional/Integral/Derivative) controller for WallE. There is a quite nice PID library in the Arduino eco-system, thanks to Brett Beauregard (br3ttb@gmail.com), and I already had it installed on my system from a previous project. Getting it implemented for my project wasn’t too much trouble, but of course the issue with PID controllers is getting it ‘tuned’ (i.e. finding the values for P, I, & D) for the particular physical setup.

For my 4-detector system, I used the difference between the sum of the two left detector values and the sum of the two right detector values as the input to the PID controller, and chose a setpoint of zero – i.e. the idea was to drive the difference in the detector sums to zero, which should mean that the robot is pointed directly at the IR source. The output from the controller was used in a differential fashion to drive the motors; the output was fed directly to the right motor driver as a 0-255 PWM value, and the left motor drive value was 255-Output.

The first step was to set the PID values appropriately, and I had absolutely no idea how to do that – so I just started with the default values of 2, 5, and 1 for the P, I, and D values respectively, and DIRECT for the sense indicator. Then I ran some tests on my 24″ benchtop range to see what happened. Of course the first thing that happened is that WallE immediately departed from the plan and dove off the benchtop (I caught it before it hit the ground). This was fixed by changing the PID output sense from ‘DIRECT’ to ‘REVERSE’, and I started getting some successful runs.

The next step was to make some more realistic homing tests, and for this I moved the IR emitter from my benchtop down to the floor at one end of my bench, and started WallE from the other end – about 1.5 m away. I made a number of runs, changing the PID tuning parameters to try and find a reasonable arrangement. After some playing around and some more Googling, I arrived at a tentative arrangement with a dual parameter set – one for small left/right differential excursions, and another for large excursions. As the following video shows, WallE successfully homed in on the IR emitter.

I also captured telemetry from the run, and plotted the left/right differential in Excel, as shown below:

Left/Right differential from 13 November floor field test

In the above plot, a marked difference can be seen between the differential behavior up to about point 33, and the differential between 33 and the end of the run at about 55 (the data after 55 was captured after I stopped the robot and picked it up, and before I got it shut down). I believe this change is due to my use of two different values for I & D, triggered when the differential became greater than 200 (due to increased received signal strength at the detectors, and possibly due to higher angle deviation as the robot neared the emitter). More testing will be required to determine the best set of parameters for the 3-wheel WallE robot.

Once I get comfortable with IR homing using WallE, I plan to transition the capability to WallE2, the 4WD robot. This will probably require significant re-tuning, as WallE2’s steering dynamics are quite different.

Stay tuned!

Frank

IR Light Follower for Wall-E2, Part VII

1 Reply

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!

IR Light Follower for Wall-E2, Part VI

3 Replies

Posted 04 November 2016

As I described in my previous post on this subject, the OSEPP IR Follower is a nice module, but its IR detector arrangement seems to be ill-suited for my intended application, which is to implement an IR homing capability to allow my wall-following robot to autonomously home in on a charging station so it can recharge its batteries and (hopefully) wander the house indefinitely (or at least until one of the cats figures out how to kill it!).

As shown in the following detection vs angle plot for the OSEPP module, there is a dead zone of about 20 º between IR detector beam edges. This dead zone makes it very difficult to determine the proper steering value to feed to the motors for homing, as it is basically impossible to determine which dead zone the IR beacon beam is hitting.

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

It would be much nicer if the individual IR detector beams overlapped at their respective half-power points, so that dead zones would be completely eliminated. This requires that the beam centers be spaced at the same value as the half-power beamwidths, i.e. about 15 º. So, a six-detector array would span 90 º instead of 180 º

Looking over my electronics parts hoard, I see that I have some Oshram SFH309FA-4 phototransistors on hand that should do the trick, and as a bonus, these units have a 24 º half-sense beamwidth instead of 15 º, which means I can do a 72 º span with just four units – yay!!

OSRAM SFH309FA-4 phototransistor specs, page 1

OSRAM SFH309FA-4 phototransistor specs, page 2

Using the wonderful DipTrace schematic capture package, I whipped up a circuit using 4ea of the above phototransistors, 4ea 1K load resistors, and a 0.1uF noise suppression cap for good measure, as shown below

Wall-E2 IR Follower circuit diagram

My first try at a module design is shown below. Because the print time is so short (~9 min) and the cost is so trivial, it’s easier and faster to just take a stab at the design, print it, and then repeat as necessary to optimize the solution. The down side, if you can call it that, is that it is so easy to make small adjustments to the design that it is hard to stop – there’s always ‘one more small thing’ that can be done to make the product just a little bit better ;-).

First try at a 4-element IR Follower array

Posted 07 November 2016: USA Presidential Election Eve!

After a few more versions, I had one that I liked. To test the idea, I mounted the new module onto the old ‘sunshade’ just for mechanical stability, and added the 6-pin right-angle header (4 detectors plus pwr & gnd) and one photodetector, as shown here

Trial assembly of 4-detector module

This seemed to be OK, so I went ahead and built up the 4-detector module, as shown in the following photos

Bottom side of assembled 4-detector module, showing all 4 detector emitters tied to ground

Top view of completed 4-detector module. Note load resistors are now 330K for better sensitivity

Front edge view of completed 4-detector module

Edge view of completed 4-detector module

After verifying that the module was indeed operational, I ran a range test at 24″ from the IR LED. I really didn’t have a good way of attaching a heading circle printout to the new module, so I simply taped the 4-detector module to the top of the OSEPP module’s sunshade as shown. This let me use the same heading circle printout I used before – clever if I do say so myself! ;-).

Completed 4-detector module taped to original OSEPP module to utilize existing heading printout

After getting everything working, and modifying the Arduino program for 4 detectors vice 6, I ran a detector output vs angle test at a range of 24″ from the IR emitter, as shown.

24″ test range for the completed 4-detector module

4-detector heading test results

The results came out better than I could have hoped. As can be seen from the data and the plot, I’m getting close to the expected 24 º beamwidth, and it is clear that there are no dead zones between detector minimums. For every angle between 45 º and 130 º there is no ambiguity as to which detector(s) are active, and how to steer to home in on the emitter.

A couple of side notes:

My original design (see above) used 1K load resistors, but I soon found that to be way too low – the detectors could barely detect the IR emitter from less than 6″ away. After some empirical testing, I finally settled on 330K as a reasonable compromise that allows decent response from approximately 1m away.
I discovered that the OSRAM photodetectors are not at all sensitive to my LED bench lamps, or to my overhead LED track lighting, due to (I believe) the visible light rejection coating on the detector lens assembly. This means I no longer need the sunshade at all, which should make the physical mounting issue much easier to deal with.

The next step is a big one, and will require a fair amount of work. I’ll need to physically mount the new module on Wall-E2, wire it into the Mega controller, and modify the program to exploit the new capability. At the moment, Wall-E2 is a mild state of dis-repair, so this all may take some time. No worries – I’ve got plenty of that (I hope).

IR Light Follower for Wall-E2, Part V

Leave a reply

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

IR Light Follower for Wall-E2, Part IV

Leave a reply

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