Posted 31 August 2017

The goal for this part of my evil master plan to bend my robot to my will (or at least get it to breakfast) is to demonstrate that I can utilize steering information generated by the 2-channel N-path digital band-pass filter to track the movement of a square-wave modulated IR source.

As you may recall from a post long ago in a galaxy far away, I started this particular tangential odyssey as a result of a visit from my old friend and mentor John Jenkins.  I mentioned to him that my robot was having some difficulty homing in on a charging station with an IR beacon, due to interference from sunlight and overhead incandescent lighting.  His recommendation at the time was to use a square-wave modulated IR beacon, and detect it using an ‘N-path digital band-pass filter.  Since that time, I have successfully implemented the receiver algorithm and am now working on integrating the whole thing back onto the robot.  In my last post  on this subject, I described how I created a rotary table using an Arduino Uno driving a cheap stepper motor via a ULN2003 driver module, and then used the rotary table to acquire azimuth scan data for the IR detector module that is to go on the front of the robot.

After getting all the azimuth scan stuff to work, and enjoying my new stepper motor super-powers, it occurred to me that the rotary table could also work as a way to test the homing performance of the system.  In the final configuration, the IR detector module will be mounted on the front of the robot, and the system will home in on a fixed position IR beacon by modulating the left & right wheel motor speeds.  However, I could turn that around a bit and use the current rotary table setup where the IR detector is fixed (but can rotate) and the IR beacon can be moved to simulate tracking/homing perturbations.  Then the stepper motor would be used to rotate the IR detector module right or left to follow the moving IR source.  If I can get the stepper motor/IR detector module to properly follow the moving beacon source, then I can work many of the bugs before working with the entire robot.

In a previous post, I demonstrated I2C communications between two Teensy modules, so I planned to use this method to transmit steering values from the IR homing module to the rotary stepper motor controller.  Unfortunately, I ran into a problem right away, because the Uno I was using to control the stepper motor runs on 5V logic, and the Teensy modules all run on 3.3V – oops!  I solved this problem by replacing the Uno with yet another Teensy 3.2 from my inexhaustible Teensy drawer (thank you again, Paul Stoffregen!).  This also allowed me to use the previous I2C master/slave demo code pretty much unaltered – yay!!

So, the first baby step in getting all this going was to verify that the Teensy 3.2 replacement for the Uno would indeed run the stepper motor via the ULN2003 driver, as shown below

Teensy 3.2 used as rotator controller in place of Arduino Uno

Here’s a short movie demonstrating that the stepper motor can indeed be controlled using the Teensy.

The next step is to integrate the code from my I2C Master/Slave example code that I used to produce the output described in  this post, so the rotary table movement  can be controlled by data transmitted over the I2C connection between the table controller and the IR Homing module.

01 Sept 2017 Update:

Turned out that getting the I2C master/slave code and the stepper motor code integrated wasn’t too hard.  Here’s a short video showing the sensor module tracking my square-wave modulated IR beacon transmitter

In the above video, The Teensy 3.5 SBC that I am moving around by hand is transmitting a square-wave modulated IR signal, which is being received by the detector module mounted to the rotary table.  The signal from the detector module is being fed to the Teensy 3.2 SBC in the far background, which decodes the modulated signal and generates real-time diff/sum steering values. The stepper motor controller module (the Teensy 3.2 in the near background) acquires these values about 5 times/sec via the I2C channel between the two Teensy’s, and uses this information to turn the stepper motor cw or ccw to track the moving beacon transmitter.

I’m probably not going to win any awards for smoothness and accuracy of tracking, but that’s not the point.  The point is that I now have implemented all of the components needed for a fully functional tracking system.  In the above video, the tracking system controls a cheap stepper motor to track a moving IR beacon, but in the intended application, the tracking system will control the robot’s wheel motors to home in on a stationary IR beacon.

Still lots to do, but at least I now know that I can make all the pieces work together once I get each piece optimized.

1. Still need to finalize the IR detector part.  I’m now leaning toward the OSRAM SFH-314 +/- 40 º beamwidth phototransistor.
2. Still need to finalize the collector resistor value for the detector.  Need a sufficiently low value to prevent detector saturation under worst-case (or nearly worst-case) conditions for the intended environment (not the thermonuclear warfare on Mars environment that my friend and mentor John Jenkins apparently recommends, but still stressful), but a sufficiently high value so that the IR beacon can be detected from far enough away (approx 2m) so the robot has a chance to engage the lead-in rails and mate with the charging connector.
3. Still need to finalize the sunshade configuration.  Currently it is a simple rectangular cylinder with the detectors angled away from the centerline.  There is some evidence in the azimuth scan data that the side walls are too close to each other, overly restricting the side-look angles of the detectors.  This issue may be further exacerbated when I go to the wider beamwidth SFH-314’s vs the SFH-300’s.  I may wind up with a sort of ‘squashed funnel’ shape in the end – but more testing is required to nail this down.
4. And finally, I still need to get this all back on the robot and actually get it to work!

Stay tuned,

Frank