Tag Archives: Charging Station

Mid-2018 Wall-E2 Project Status

Posted 26 August 2018

It’s been a year and a half since I last described the status and challenges in my ongoing campaign to create Wall-E2, an autonomous wall-following robot.  The name ‘Wall-E’ was taken from the 2006 movie of the same name.  In the movie, Wall-E was an autonomous trash-compactor robot that had all sorts of adventures, and my Wall-E2 autonomous wall-following robot certainly fills that bill!

From the previous system status report in early 2017, I described the following tasks:

Its been a year and a half since I updated the status of my ongoing campaign to create an autonomous wall-following robot.  The robot system consists of the following main subsystems:

  • Battery and charging subsystem
  • Drive subsystem (wheels, motors and motor drivers)
  • IR homing subsystem for charging station
  • LIDAR for front ranging and ultrasonic SONAR for left/right ranging
  • I2C Sensor subsystem (MPU6050 6DOF IMU, FRAM, RTC)
  • Operating system

Battery and charging subsystem:

Since the last update, the battery and charging system has been updated from dual 1-Amp single-cell Adafruit PB1000C chargers utilizing a 5V source to a TP-5100 2-amp dual-cell charger utilizing a 12V source.  This significantly simplified the entire system, as now the battery pack doesn’t have to be switched between series and parallel operation. Also, now the charging and supply leads are independent so the supply leads to the rest of the robot were upgraded to lower gauge wire to reduce the IR drops when supplying motor drive currents.  See this post for details.

Drive subsystem (wheels, motors and motor drivers):

The motors were upgraded to provide a better gear ratio, although this was done before I realized that most of the traction issues were caused by IR drops in the battery wiring.  The motor driver modules are unchanged, but I may later swap them out for more modern 3V-capable drivers so that I can swap in an Arduino Due microcontroller for the Mega (the Due has the same footprint/IO as the Mega, but has a much faster CPU and more memory)

 IR homing subsystem for charging station:

The IR homing subsystem utilizes a pulsed IR beacon on the charging station coupled with dual IR sensors in a flared sunshade housing, backed by a Teensy 3.5 CPU configured as a null pattern matched-filter.  The Teensy reports left/right homing error as a value between -1 and 1 over an I2C bus to the main microcontroller, which drives the motors to null out the signal.  As the system stands today, the operating system can successfully home in on the charging station and connect to the charger. The robot knows its current battery voltage (charge condition) and therefore can decide to connect to the charger or to avoid it.

LIDAR for front ranging and ultrasonic SONAR for left/right ranging:

The front/left/right ranging subsystem is one of the most mature subsystems on the robot.  The subsystem can successfully follow walls, and detect/recover from ‘stuck’ conditions.  The only thing this subsystem lacks is the ability to make consistent turns on different terrain, due to the lack of heading information (this will be supplied by the new tri-sensor module)

I2C Sensor subsystem (MPU6050 6DOF IMU, FRAM, RTC):

The I2C sensor subsystem is a new addition since the last update, and has yet to be fully integrated into he system.  The subsystem consists of a Inversense MPU6050 6DOF solid-state accelerometer, and Adafruit FRAM (Ferromagnetic RAM) and RTC (Real-Time Clock) modules.  The MPU6050 gives the robot the ability to sense relative heading changes, which makes it capable of executing consistent N-degree turns on both hard flooring like the kitchen and atrium areas and the carpet in the rest of the house. The FRAM and RTC units should allow the robot to remember its charge/discharge history, even through power ON/OFF cycles.

The relative heading capability has been tested off-line from the main operating system, but has not yet been integrated into the OS. Same for the FRAM/RTC modules.  Integration of this subsystem was stalled for quite a while due to problems with the Arduino I2C (Wire) library, but these problem were just recently resolved by switching to a more robust I2C library (SBWire).  See this post for details.

 

Operating system:

The operating system has evolved quite a bit over the course of this adventure, but its current state seems pretty stable.  The OS is implemented as a set of modes, as follows:

  • MODE_CHARGING: Occurs when the robot is physically connected to a charging station
  • MODE_IRHOMING: Occurs when a charging station beacon signal is detected
  • MODE_WALLFOLLOW: Occurs when the robot isn’t in any other mode.
  • MODE_DEADBATTERY: Occurs when the sensed battery voltage falls below DEAD_BATT_THRESH_VOLTS volts

 

 

Future Work Plans:

  • Complete the integration of the tri-sensor module: This entails adding the hardware and software required to sense loss of power so that the current date/time stamp can be written to the FRAM, along with the complementary ability to read out the last power cycle date/time stamp from the FRAM on power-up.  In addition, the current timed turn routines need to be replaced by the new heading-sensitive turn algorithms.
  • Investigate the idea of multiple charging stations with different IR beacon frequencies. The current matched filter algorithm forms a very narrow-band filter, to discriminate the desired IR beacon signal from unwanted ‘flooding’ from overhead lighting sources and sunlight.  The center frequency of the filter is set in software on the Teensy microcontroller, so it should be possible to have the Teensy routinely check for beacon signals at other signals, as long as the frequencies are far enough apart to prevent overlap.  The current filter center freq was more or less arbitrarily set to 520Hz – high enough to be well away from, and not a multiple of, 60Hz, but low enough for the Teensy processing rate.  Something like 435Hz (60*7.25) would probably work just as well, and is far enough away from 520Hz to be well outside the filter bandwidth (about +/- 10Hz IIRC).

Complete the implementation of the fixed charging station.

This task has been completed, and along the way the charging voltage was changed from 5V to 12V, to accommodate the new 12V on-board battery charging system.  See this post for details

Integrate the IR homing software from the 3-wheel robot into Wall-E2’s code base:

This task has also been accomplished.  See this post for details.

Charging Station Voltage Change From +5 to +12V

Posted 22 March 2018

With the replacement of my Power Boost 1000C – based charger module with the TP5100, I needed to change the charging station supply voltage from +5V to +12V.  Unfortunately, the modulated IR beam signal is generated by a Teensy 3.2 module, which requires +5V (it’s actually a 3.3V module, but can accept power of up to +5V), so now I needed both +5 and +12V on the charging station.  The answer was to add a simple 3-pin regulator, as shown in the schematic below

Updated charging station schematic showing addition of a 3-pin 12-to-5V regulator

The original Teensy 3.2 side

The original 5V charging station layout, rear view

The new +12 to +5V regulator side

Updated charging station assembly, rear view

 

The operation was a success, but …

Posted 21 February 2018

In early January of this year I posted about finishing the integration of my new-improved battery charger & battery pack into my new-improved robot chassis.  Between then and now I have been working on getting the new robot chassis mated up with the charging station (the new robot chassis is wider, and I also changed to larger diameter wheels) in preparation for renewed field testing.

Unfortunately, just as I was getting ready to move into field testing, my robot started acting funny.  About half the time, it wouldn’t disengage from the charging station and instead would reboot.  At first I thought the added weight of the new battery pack and robot chassis was causing the motors to stall, so I changed the code to have the robot disconnect at full motor speed rather than 1/2 as before.  This made the problem even worse; now not only wouldn’t Wall-E2 disengage from the charger, it wouldn’t even move forward or backward under it’s own power!  Clearly something was badly wrong, but I had no clue what it was.

Applying my time-honored troubleshooting – I simply put Wall-E2 aside for a few days and let my subconscious work backwards through all the changes since Wall-E2 had last worked properly.  After enough time had elapsed, my subconscious reported back and said:

“You are an idiot.  All of the complexity you added in your quest for an on-board charging system has placed that wonderful high-capacity battery pack at the far end of a long series of (relatively) high resistance circuitry, and the IR drop caused by full-speed motor currents is killing you!”  “Oh, and by the way, you’re ugly too!”

Well, my subconscious is almost never wrong, and it only took me a little bit of testing to confirm it’s theory.  I set the code up to go forward and backward at full speed, and monitored the CPU’s 5V regulated output line with my trusty oscilloscope.  As soon as the motor command was executed, the 5V line drooped to less than 3V, and the CPU rebooted – oops!

So now I knew what was happening, and I (or my subconscious anyway) had a good idea why.  To confirm the why, I bypassed all the charge-management circuitry and wired my 7.4V 7200mAh battery pack directly into the main robot power line, as shown in the photo below

7.4V 7200mAh battery pack wired directly into robot power

With this setup, the robot not only was able to move forward and backward at full speed, the thing damn near took my arm off when I tried to stop it – whoa!

So, the bottom line is that all the work I put in designing and implementing a really cool on-board dual-cell charge management system had the ultimate effect of making the battery unusable.  The operation was a success, but the patient died! ;-).

So, where to go from here?  It appears that I have to completely revise my thinking about battery charging and maintenance for Wall-E2.  Instead of being in series with the battery, any charging/maintenance system must operate in parallel, and be completely out of the path between the battery pack and the load when the robot is running.  Now I realize this is the reason most RC/Hobbyist multi-cell battery packs have a balance charging cable in addition to the main power cable; charging is done completely independently of the output path.

When I first started the charger project, my original goal was to avoid having to remove the battery from the robot to charge it; I wanted Wall-E2 to  connect to power and charge itself without human intervention.  At the time, I felt the only way to do this was to have the charging circuitry on board, so that only a single DC connection from the charging station was required.  I thought the only way to make this happen was to use two of the Adafruit SBC1000 charger modules to charge each of the two cells independently.  Unfortunately, the SBC1000’s grounds aren’t isolated, so this meant that I had to disconnect the two battery pack cells from each other to charge them independently and then switch them back together again to run the robot after charging.  This worked (rather elegantly if I do say so myself), but had the unintended side-effect of putting too much high-loss circuitry and wiring between the battery pack and the motors.

Now that it is clear that I can’t interfere with the current path to the motors, I know I have to abandon the current charging module design, but what are the alternatives?

  • The TP5100 is a little module that can balance charge a 2-cell LiPo stack at 2A.  It has a dual-color LED output that I might be able to use for charge termination.  Unfortunately, the specs are all in Chinese, so it may take some experimentation to figure out.
  • I can use an external balance charger like the EV Peak e4 ‘cube’ automatic balance charger, and feed the three required wires (ground, B1+, B2+) out through the front of the robot to the charging station. This solves the problem of carrying the charger around, but significantly complicates the interface to the charging station.

Stay tuned!

 

A New Chassis For Wall-E2, Part II

Posted 17 November 2017

In my ongoing quest to give Wall-E2 a bigger/roomier ride, I am continuing the process of moving all Wall-E2’s stuff to the new chassis, and modifying the charging station to work properly with the new wide-body model.

Second Deck Sensors:

Even with the wider footprint, there’s not enough real estate to easily mount the three distance sensors (LIDAR for forward distance, and acoustic for left/right distance).  I could shoe-horn it all in, but it would look messy and would leave all Wall-E2’s electronics exposed to potential damage from furniture, cats, careless humans, etc.  So I decided to transplant the second deck, complete with all the sensors, to the new chassis.  This looked to be a real PITA, until I let go of the notion that the 60mm stand-offs had to remain in the same locations. Once I did that, things got a lot easier 😉

IR Homing Module:

This was a straightforward transplant, especially since all the detection/demodulation is being

3D printed spacers for the motor controller PCBs

done by a Teensy 3.2 physically attached to the sunshade. All I had to do was drill the mounting  holes, add two more press-fit nuts, and screw on the module.

Arduino Mega Processor and Motor Controllers:

These two items came over as a group, as that way I didn’t have to disconnect anything – my kind of transplant!  However, while I was at it, I decided to neaten things up a bit by printing spacers for the motor controllers; this isolates the underside of the PCBs from the metal chassis, and provides a nice flat surface for mounting the controllers to the chassis with double-sided tape – a win-win-win (the last ‘win’ was because I got to use my 3D printer some more!)

Arduino Mega processor, motor controllers, rear taillight assembly, and IR homing module transplanted

Charging Station Modifications:

I was not looking forward to modifying the charging station to work with the new wider chassis.  The charging station electronics assembly is non-trivial, and it would be a real PITA If I had to reprint the frame and transfer all the electronics. Fortunately for me, this turned out not to be the case.   By a happy coincidence, the distance from the right-hand guide rail to the center of the power receptacle was exactly the same for the new chassis as for the old one, so all I had to do was re-position the left-hand rail to accommodate the wider tread spacing. Well, there was one minor glitch – the charging station has two physical stops, and the one that mated with the left-hand wheel guard on the old chassis now didn’t hit anything, so I had to print a small 5mm thick spacer and double-sided tape it to the front of the existing stop.

Closeup of the spacer for the right-hand charging station stop

Front view showing left and right charging station stops (with spacer added to right one)

18 November 2017 Update:

I’ve got almost everything transplanted over now, as shown in the following photos:

Side view without the sensor deck, showing that all modules are in place

Side view showing the sensor deck in place.

end-on view showing the difference between the old and new chassis dimensions

There’s still a ton of work to be done; The latest version of the charger PCB still hasn’t arrived from Bay Area Circuits, so I still need to do all that, and then wire the finished module into the battery compartment. Also, I’m having to redo the front bumper guards, as I have found they are somewhat fragile due to the way in which they were printed – bummer!  However, it shouldn’t be too long before I can take the new model out for a spin! ;-).

Stay tuned!

Frank

 

 

 

Adafruit PowerBoost 1000C Charge Termination Threshold

Posted 01 November 2017

At the conclusion of my ‘field’ testing of Wall-E2’s new-found ability to mate with the charging station using the square-wave modulated beacon signal, I noticed that Wall-E2 was always disconnecting from the charging station based on elapsed time (set for 2Hrs at the moment) rather than detection of the end-of-charge condition.  After investigating this a bit more, I found that one of the charging modules never switched from charging to ‘finished’.  This was more than a little irritating, as I was counting on that transition to make sure that Wall-E2 was fully charged before disconnecting.

During the process of creating the PCB design for my charging module, I took a dive into the datasheet for the MCP73871 charge management chip on the PB1000C in an effort to figure out if there was any way to improve the end-of-charge detection situation.  When I looked through the specs (relevant data sheet portions shown below), I found that there is a spec called ‘Charge Termination Ratio’ (oddly shown with dimensions of mA, but what do I know), and this value is controlled by the value of the resistor connected to the PROG3 pin.

On the Adafruit PowerBoost 1000C module, the resistor attached to PROG3 is 100K, the larger of the two values mentioned in the datasheet, and this value sets the charge termination threshold at approximately 12.5 mA (according to the Adafruit gurus, ‘approximately here means +/- 25% – yikes!)

So, I decided to see if decreasing the value of this resistor give me a more robust charge termination experience.  Rather than trying to replace the SMT/SMD resistor part, I decided I could just mount a regular 1/8W resistor in parallel, with the value chosen to get the right resultant value.  Since there is such a large (+/- 25%) variation, there’s no real good reason for trying to arrive at an exact value, so I just chose a convenient value (meaning the closest value I could find in a small 1/8W package) – in this case, 51K.  With a little bit of patience, and a strong magnifier, I was able to get the resistor soldered onto the SMD part without burning up the pads or anything else, as shown in the following photo

51K resistor soldered in parallel with the existing 100K resistor on the MCP73871 PROGR3 pin

This parallel combination results in an PROG3 resistor value of about 33K, which (assuming a linear progression) should result in a charge termination current of about 40mA.  When I tried this setup with a mostly charged battery and an Adafruit ‘Charger Doctor’ for monitoring charge current, the PB1000C changed to the ‘finished’ state with a measured current of about 20mA.

When I first tried this trick, I was expecting the charge to terminate when the Charge Doctor readout showed “0.04” – but it didn’t happen until more like “0.02”.  When I mentioned this on the Adafruit forum, a very knowlegeable reply was forthcoming from “Mike”

Re: Powerboost 1000C Charge termination threshold

by adafruit_support_mike on Tue Oct 31, 2017 9:54 am

“Charge termination ratio” is a general term for LiPo chargers. Most of them don’t use an external resistor to set the cutoff current, and just end the charge cycle when the current flowing into the battery reaches a given fraction of the constant-current level.. 1% is fairly common.

If you run the math out, the ratio of I.prog:I.term is R.prog1:R.prog3

We started with 100k because that’s one of the two values listed in the DC Characteristics table, and after a while you learn to take datasheets very literally. They excel at telling you the parts of the truth the vendor wants you to hear, but nothing more. It’s always best to start from the exact spec values and then vary the parameters to see what they left out.

We left it at 100k because it worked, and the datasheets for the LiPos we carry spec 1% as the termination level.

The tolerance for that value is +/-25%, so a nominal value of 33mA can be expected to fall in the range between 24.75mA and 41.25mA. The Charge Doctor has a resolution of 10mV/10mA, and I’d expect its measurement error to be about half that through rounding if nothing else. That puts the potential range of measured values for a nominal 33mA current between 19.75mA (rounded to 20mA) and 46.25mA (rounded to 40mA).

The error is almost as large as the value you want to measure, and larger than the difference you want to measure.

 So I thought about that some more, and eventually realized that the cause of my non-termination woes might well be that I’m using these chargers on much larger (capacity-wise) cell stacks than normal.  I’m using a 7400 mA stack, so a 1% threshold would be 7.4mA, which may be a little too close for comfort to the 12.5 mA termination spec for a 100K resistor on PROG3.
In any case, this exercise taught me a lot more about the PowerBoost 1000C in general, and the MCP73871 chip specifically.
Stay tuned,
Frank

 

 

IR Homing Module Integration Part X

Posted 15 October 2017

Well, we have just about reached the end of the road with respect to the ‘IR Homing Module Integration’ adventure.  As you may recall, at the very start of this trip (a couple of centuries ago back in August of this year) I showed the following block diagram of the proposed integration architecture

Teensy 3.2-based IR Demod module block diagram

The above architecture actually worked almost exactly as planned, except for using only two phototransistors vs the four in the original design, as shown below

Revised IR Demodulator block diagram. Note the removal of two phototransistors and the input combiner

After literally dozens of trials on my 1m (aka workbench) and 2m ranges (aka the floor of my lab), I believe I have arrived at a reasonably successful set of PID parameters for Wall-E2 to use when homing to a charging station.  As usual, after going all around the barn with different P, I, & D values, I wound up with the simplest possible set of parameters, namely PID = (200,0,0).  The ‘200’ value is due to the use of a  (L-R)/(L+R) computation in the IR homing module, resulting in a steering  value output that ranges from -1 to +1.

While the result at the moment is far from perfect, it is pretty good.  Wall-E2 can now successfully home to and mate with the charging station from at least 3m away, with wall offset distances from 50-91 cm as shown in the following videos (as can be seen in the last video, there is still some work to be done for wall offsets in the 25cm range)

 

So, the IR Homing Module Integration project is basically complete.  To recap, the idea for an interference-resistant IR homing scheme using a square-wave modulated IR beacon and a companion ‘degenerate N-path Band-pass Filter’ demodulator started back in May of this year during a visit from my old friend and mentor John Jenkins (see this post).  Since then, Wall-E2 and I have done the following:

  • Researched the basic theory behind the ‘N-path band-pass filter’ technology
  • Designed and implemented (with John’s help) a two-channel version of the technique using an arduino Uno.
  • When the Uno turned out to be too slow for operation at the desired 520Hz square-wave frequency, reduced the operating frequency by a factor of 10 to 52Hz to verify proper operation
  • Researched faster alternatives to the Uno, and eventually settled on the Teensy 3.x line of micro-controllers.  This hardware change allowed me to run the algorithm successfully at 520Hz, while simultaneously cutting the required real-estate by a factor of four, and the current drain by a factor of two – neat!
  • Designed and implemented the ‘crushed funnel’ two-phototransistor detector sunshade.
  • Integrated everything onto the Wall-E2 robot.
  • Demonstrated successful homing in the presence of overhead halogen lighting

Remaining Work:

There are still some things that need to be cleaned up to complete the integration, but it is mostly minor stuff:

  • I’m still not entirely happy with the inability to successfully home & mate with the charger for wall-following offsets below about 25cm, but I don’t think there is anything I can do realistically to solve that problem; what I can do, however, is to make sure Wall-E2 starts homing far enough away from the nearest wall to avoid that problem. This will probably mean something like a pre-homing maneuver if the nearest wall distance is too small (or maybe even changing the basic wall-following algorithm to maintain a minimum distance of > 25cm)
  • Along the lines of belt-and-suspender designs, I probably also need to implement some sort of fallback algorithm if, despite all my best efforts, Wall-E2 still manages to impale itself on one of the lead-in rails.  When Wall-E2 is in normal wall-following mode and gets stuck, it has a way of detecting that condition and recovering, but that scheme isn’t currently active during homing operations.  I just need to copy that capability into the homing mode, and hopefully Wall-E2 will cooperate.
  • There’s a whole bunch of commented-out stuff and debugging printout code scattered through the program right now, and that stuff needs to be cleaned out before I forget (if I haven’t already) what it was originally intended to do.

In any case, it is time to declare victory move on to the next challenge, as soon as I figure out what that might be.

Stay tuned!

Frank

 

 

IR Homing Module Integration Part IX

Posted 09 October 2017

In my last post on this subject, I showed that the azimuth response from the V9 ‘crushed funnel’ sunshade design was almost ideal for the intended homing operation, and it was time to start seriously integrating it onto Wall-E2.  As the following photos show, this worked out fairly well.

As shown in the above photos, the Teensy 3.2 IR Homing Module is mounted on the sunshade, with connections to the sunshade IR phototransister outputs on one end, and connections via I2C to the Mega on the other.

After making the necessary modifications to Wall-E2’s operating system to incorporate the steering value input from the homing module, I ran a short azimuth scan at 1m range using the completed IR Flashlight-based transmit module, as shown in the following short video.

During the azimuth scan, steering values were acquired by the IR Homing module and transferred via I2C to the Mega on an as-requested basis.  These values were then printed out to a PC using a Wixel wireless serial link.  The result, as shown below, looks pretty good. It was pretty clear that the azimuth response was excellent over almost the entire azimuth range from -90º to +90º

 

The next step is to modify the PID parameters to translate the -1 to +1 range of steering values to appropriate wheel motor speed variations.

So, the error term varies from -1 to +1, and the motor wheel speed range is from 0-255, or MOTOR_SPEED_HALF +/- 127.  So, I would expect to have to have a Kp value on the order of 100 or so to achieve the full range of motor speeds.  I ran some manual scans for different Kp values to see what would happen with motor speeds, and got the following plots:

As expected, a Kp value of 20 appears to be a bit weak; it would do the job eventually, but probably not fast enough to get captured by the lead-in rails.

A Kp value of 100 looks better – motor speeds vary over almost the full range, so a full off-axis detection should cause Wall-E2 to almost spin in place to turn toward the beacon.

 

As shown above, using just Kp with Kd = Ki = 0 results in a constant offset with a constant error term.  However, for this application a constant output will still result in the robot turning toward the beacon, so a constant offset shouldn’t be a problem.

After this last test, I noticed that an offset to the right of the beacon boresight line (as was the case for this test produced a high left wheel speed and a low right wheel speed, exactly the opposite of what would be required to reduce the error term – oops!  This means I need to change the PID direction parameter from REVERSE to DIRECT to get the correct wheel speed adjustment sense.

To produce the above plot, the robot was left in the same position as it was at the end of the last run – offset about 20-30º to the right of the beacon boresight, but with the PID sense changed from REVERSE to DIRECT. As shown above, now the right motor speed is higher than the left, which would turn the robot back toward the beacon boresight.

The data for all the above plots was collected with the wheel motors disabled.  The next step will be to enable the motors and see what happens.  I re-enabled the motors, but also implemented a wireless ‘kill switch’ so I could keep Wall-E2 from disappearing over the horizon (or more likely, over the edge of the bench!).  Here’s Wall-E2’s maiden run with PID = (100,0,0)

 

Well, Wall-E2 didn’t home properly to the beacon, but it did manage to correct at least a little bit, and managed to not leap off the edge of my test bench – yay!  The plot below shows the data from the run

From the above plot, it is clear that Wall-E2 was trying to do the right thing, but couldn’t change the wheel speeds fast enough for effective homing.  The input value started off at about -0.5, and the wheel speeds at L = 75, R = 175, which caused Wall-E2 to correct left, as it should.  This started the input trending upwards toward zero, and the wheel speeds both tending toward 127 (i.e. half-speed).  Everything arrived at the setpoint at position 5, so Wall-E2 continued straight, which took it back off the boresight and to the right side again.  The input started down again, and the motor speeds started adjusting, but they couldn’t adjust fast enough to keep Wall-E2 from blowing past the beacon – oops!

I’m not real sure what this tells me about PID tuning, but I suspect I’m going to need a non-zero differential term to deal with the close-in rapid angle changes.  It’s late, so I’m going to quit for tonight, but I hope to run some more tests tomorrow.

11 October Testing:

Here’s another run on my 1m test range (aka test bench). The only change from the previous run is that the data is being acquired at four times the rate – at 100mSec intervals vice 400mSec

The two plots shown above are almost identical, as would be expected, but the second plot has 4x the data points and is a lot smoother.  Still, it tells the same story; the PID_In line (blue, plotted on the right-hand scale) stays relatively constant at about -0.5 until about position 13.  With PID_In at -0.5, PID_Out (orange curve) is about 50, resulting in L/R speeds of about 75 & 175 (grey & yellow curves, resp).  These speeds cause a very gentle turn to the left (way too gentle, as it turns out).  After position 13, PID_In starts rising slowly (and then more rapidly) toward zero, indicating that the robot heading is nearing the beacon boresight.  At position 23  PID_In  hits -0.1 and the wheel speeds cross at a value of 125, meaning the robot is moving more or less straight ahead.  For some currently unknown reason, PID_In actually goes significantly above zero between positions 23 and 25, causing the robot to ‘twitch’ to the right, away from the beacon!  Then at position 25 PID_In reverses course, diving from +0.3 to -1 as the robot goes past the beacon.  This causes the robot to reverse course again, undoing the ‘twitch’ just before hitting the end-of-range condition (aka my tool chest).

So, why did PID_In (i.e. the steering value coming from the IR Homing Module) continue to increase even as the angle between the beacon boresight and the robot centerline continued to increase – not decrease?

More 11 October Testing:

Rather than worry about the ‘twitch’ phenomenon observed just before Wall-E2 passed the IR beacon, I decided to attack the first part of the run, where the PID input stayed relatively constant, but well offset from the setpoint. From my reading of PID tuning, this indicates a need for a non-zero I (integration) term.  To test this, I adjusted my PID value from (100,0,0) to (100, 20, 0) and ran some more testing.  The 1m range runs were encouraging, so I tried a run on my 2m range (aka my lab floor). As the following video and accompanying data plots show, this was pretty darned successful.

 

Starting at an offset angle of about 30-40º relative to beacon boresight, Wall-E2 homed in on the beacon very smoothly and accurately.  In fact, when I picked up Wall-E2, I found that it had partially mated with the charging probe, even without lead-in rails for physical registration – neat!

Here’s another run, with Wall-E2 starting from the other side, with more of an initial offset (almost 90º)

As can be seen in the above video clip and accompanying plot, Wall-E2 makes an abrupt initial turn to point (generally) toward the beacon, but then doesn’t make any additional significant corrections until it is almost past the beacon.  From the plot, it appears that the I value isn’t quite high enough.  So, I plan to make some more runs with increased I values.

 

Stay tuned!

Frank

IR Homing Module Integration, Part VIII

Posted 21 September 2017

As I mentioned at the end of the previous post on this subject, there are still some ‘issues’ with the charging station system.

Ambient light flooding, TSAL-6200 LED Power:

AFAIK, there are only two ways to beat the ambient light flooding problem; by reducing the amount of ambient light allowed to hit the phototransistors, or reducing the gain of the phototransistors, or both.   The ‘flat funnel’ sunshade design appears to be effective in reducing the incidence of ambient light from above (i.e. overhead incandescent lighting and sunlight) while preserving off-axis beacon detection ability, but it may not be enough by itself.  The problem with reducing detector gain to a level that would guarantee protection from flooding is that it might make it impossible to detect the charging station signal from far enough (i.e. around 2m away) to maneuver in time to be captured by the charging station lead-in rails.  Thus, the lower limit on the detector gain is set by the beacon field strength at approximately 2m distance.  So, if I want to reduce the detector gain, I have to increase the IR beacon field strength.

With the current setup with a single-TSAL-6200 IR LED transmitter, there’s not much more I can do to increase field strength at 2m.  The flashlight reflector idea significantly increased detection range, but even with the reflector I had to use a gain resistor of over 100K to achieve 2m detection/homing range, and that is probably 2 orders of magnitude greater than the maximum gain for flooding prevention.  The use of a square-wave modulation with it’s 50% duty factor makes this situation even worse, although I can get most of this loss back by running the LED at 200mA instead of 100.

While I was pondering my navel on this subject, someone mentioned that there are now small, cheap IR flashlights available for the tactical and hunting markets, and these flashlights use one or more Cree high-power IR LEDs.  I happened to be familiar with the Cree line of LEDs, as I have used their visual-light models to replace the el-cheapo LEDs in a couple of my bench lamps.  The visual-light models can easily handle 1Amp, and at that current are too bright to look at directly.  A little research showed that the IR models have the same high power rating, making them ideal for this purpose.  In addition to the high power, the IR flashlights typically come with adjustable optics that allow for a broad or spot beam, which would eliminate the requirement for a reflector – cool!

So, I ordered a ‘IR-940’ IR flashlight from eBay, and it looks like it might fill the bill. The flashlight as received is shown below.

IR-940 IR Flashlight

I ran a small series of tests to see if the adjustable optics really made a difference, and discovered that they did.  As shown below, the spot beam is noticeably smaller and more intense than the other settings.  Interestingly, the illumination pattern at the ‘wide’ setting is almost undetectable – it would be easy to conclude that the flashlight was actually turned OFF, when in fact it was still ON, but with a broad-beam pattern.

IR-940 flashlight at the most narrow-beam setting

IR-940 flashlight halfway between the narrowest and widest settings

IR-940 flashlight at the widest setting

After investigating the flashlight’s physical construction for a bit, I figured out that I could simply hacksaw off the battery compartment, leaving only the front optics adjustment section, and of course the 3-LED module itself.  The following photos show the result

IR flashlight LED and optics section wired into charging station transmit module. The black plastic piece is a prototype of the holder to be used in place of the current reflector

I ran some simple distance tests using my digital camera as an IR sensor.  With the room lights off, I could easily detect the flashlight output from up to 5 m (this was as far away I could get without too much trouble), as shown below

IR flashlight from across the room

Then I redesigned the charging station module to accoMmodate the IR flashlight head, as shown below.

Charging station module with IR flashlight head installed

After getting the flashlight head installed on the charging station module, I ran some azimuth tests with the V10 sunshade, as shown below

-90 to +90 degree azimuth scan at 1m: 2ea SFH-314 phototransistors with 1KΩ Rc using the V10 sunshade and the IR flashlight head

-90 to +90 degree azimuth scan at 2m: 2ea SFH-314 phototransistors with 1KΩ Rc using the V10 sunshade and the IR flashlight head

-90 to +90 degree azimuth scan at 3m: 2ea SFH-314 phototransistors with 1KΩ Rc using the V10 sunshade and the IR flashlight head

As can be seen from the above plots, the IR flashlight idea is definitely a winner.  Even with the detector Rc reduced to 1KΩ the square-wave modulated IR signal can be successfully demodulated from at least 3m away.  All three plots above are essentially identical, except for the scale.   So, if needed, the Rc value could probably be further reduced, and/or the flashlight drive current could be lowered.

 

Phototransistor azimuth pattern alignment:

In the ‘original’ (V9) ‘crushed funnel’ sunshade design, the phototransistors were aligned with about 70º offset, i.e with a 110º internal angle between the two back walls.  This resulted in the following azimuth plot

Azimuth scan using 2ea SFH-314 photo transistors

This indicated to me that I needed to bring the two phototransistor boresight angles more in parallel, thereby moving the two individual azimuth responses toward each other, filling the gap between them.  To accomplish this, I printed up another ‘crushed funnel’ sunshade (V10), with the phototransistors offset 50º instead of 70º (i.e. an internal angle of 130º).  This piece was used for the 1m, 2m, and 3m plots above (repeated below for comparison purposes)

-90 to +90 degree azimuth scan with SFH-314 phototransistors using the V10 sunshade and the IR flashlight head, 1m distance

Comparing these two plots, it looks like I overshot a bit with my adjustment, as now the two individual phototransistor responses are too close together to produce a decent slope on the ‘steering’ (L-R)/(L+R) curve shown above in gray.  Fortunately, it costs essentially zero to produce yet another ‘crushed funnel’ design, this time with an offset midway between the V9 (about 70º) and V10 (about 50º) versions, i.e. an offset of about 60º (V11).  The image below shows the result on my 1m range

-90 to +90 degree azimuth scan with SFH-314 phototransistors using the V11 sunshade and the IR flashlight head, 1m distance

The above plot definitely shows an improvement in the phototransistor azimuth response alignment, and this might well be the one that I want to go with.  However, it makes me a little suspicious of the original V9 data, as the V9 and V11 offsets are almost the same (70º for V9 vs 60º for V11).  Maybe the only real difference between V11 & V9 is the Rc value?  To test this theory, I re-ran the V9 setup with a 1K vs 10KΩ, with the following results.

-90 to +90 degree azimuth scan with SFH-314 phototransistors using the V9 sunshade and the IR flashlight head, 1m distance

As can be seen from the above, my suspicions about the original data were well-founded; the V9  scan with the 1KΩ is just about perfect; the two detector az responses cross at about 1/2 amplitude, and the steering curve is smooth and steep in the boresight region.  So it appears that something else was responsible for the anomalous V9 results – either the use of a 10K Rc or the fact that the original V9 results were acquired with the TSAL-6200/reflector setup versus the IR flashlight setup.  Just for completeness, here’s a shot of all three ‘crushed funnel’ designs.

All three ‘crushed funnel’ sunshade designs. As it turns out, V9 was the winner

At this point, I think I have just about everything I need to integrate the square-wave modulation detection/homing scheme onto the robot; I’ve got a good (V9) sunshade, an excellent IR source with the modified IR flashlight, and a well-tested Teensy 3.2-based demod/homing module.  I think the next step will be to mount the sunshade/detector unit and the demod module on the robot, modify the main robot controller software to acquire steering data via an I2C channel, and then do some homing tests.

Stay tuned,

Frank

 

 

 

 

 

 

 

 

IR Homing Module Integration, Part VII

Posted 18 September 2017

So now that I have the Teensy 3.2-based IR Homing module working on the robot end, I shifted my attention to the charging station end.  Now that I’m using a square-wave modulated IR beacon signal, I needed to separate the LED drive and charging probe circuits; the charging probe needs a constant +5VDC, but the LED circuit needs a pulsed signal.

So, I pulled an IRF-510 power MOSFET from my supplies and wired it up to switch about 200mA through the TSAL-6200 IR LED, driven from the output of my Teensy 3.2-based sweep generator.  I needed to mount the Teensy and the IRF-510 on the charger/beacon module, so I used a 1950’s era terminal strip, some hot glue, and some double-sided foam tape – see the photo below.

Teensy waveform generator and IRF-510 MOSFET mounted on charging station module

I used my CCD camera to verify that the TSAL-6200 IR LED was indeed LED-ing, as shown in the following photo

CCD camera shot of square-wave modulated IR beam from TSAL-6200 mounted in a flashlight reflector. Note the direct and reflected energy.

Then I used my Teensy-based rotary table controller and IR Beacon Homing Module to generate an azimuth scan, as shown below.

Setup for azimuth scan acquisition

Azimuth scan using 2ea SFH-314 photo transistors

And here’s a scope photo showing the square-wave modulation waveform at the Charging Station Module and the received waveform at the IR Homing Module

Square-wave transmit modulation (bottom trace) and received waveform at the IR Homing Module (upper trace)

So, at this point I have both the transmit and receive halves of the square-wave modulated beacon system working, but (as usual) there are still some significant flies in the ointment.

  • I’m still worried about the ambient light interference issue, although my initial tests with the improved sunshade have been encouraging.  With the setup as shown in the above scope photo, turning the overhead incandescent indoor spots on and off just caused a barely perceptible DC drop in the upper waveform.
  • In the same vein, I’m concerned that the TSAL-6200 LED, even pulsed at 200mA, won’t give me the detection range I need for successful homing to the charging station capture basket, especially if I further reduce the phototransistor Rc values to make the system less susceptible to IR ‘flooding’.
  • The azimuth scan data indicates that the SFH-314 phototransistors may not be optimally aligned.  It looks like they should be oriented a little more parallel to each other to close the central response gap.

Stay tuned!

Frank

 

 

IR Homing Module Integration, Part VI

Posted 13 September 2017

While I was doing the work that led to the last post, I realized that my el-cheapo stepper motor was just barely able to get out of its own way.  This worked OK for the previous setup,  but when I moved to a larger sunshade arrangement, I started having problems with the torque – or lack thereof.  As I normally do when faced with this sort of obstacle, I hopped onto the Adafruit site and ordered a couple of NEMA17 stepper motors and companion driver modules.  When these arrived a few days ago, I started playing around with them in preparation for testing the upgraded sunshade.

NEMA17 200 steps/rev stepper motor from Adafruit

This stepper model is the one used widely in 3D printers, and they have excellent speed and torque specs.  The only downside is they run very hot – hot enough to burn fingers :-(.

After receiving the units from Adafruit, I spent some quality time on the web figuring out how to drive them. I discovered that I could use the same L289 motor drivers that I am using for my robot motor driver, so that was cool.  Here’s a short video showing it running an example sketch using the L289 driver

 

Next I printed up an adapter so I could mount my new, improved sunshade (with OSRAM SFH-314 phototransistors installed), and soon had the whole thing running, as shown in the short video below

Then I ran my IRBeaconHomingModule program in conjunction with my TeensySweepGen and Teensy_NEMA17_L289_RotaryTable programs to perform an azimuth scan of the new sunshade with OSRAM SFH-314 photo transistors installed in a crossover configuration, as shown in the following short video

 

Next, I modified my little IRBeaconStepperMotorTracker sketch for compatibility with the L289 motor driver, and used it to demonstrate IR beacon tracking with the new sunshade design and the OSRAM SFH-314 phototransistors, as shown in the following short video