Charging Station Design, Part IX

Posted 20 February 2017

As part of the project to implement autonomous charging capability for Wall-E2, I needed a way to monitor main battery voltage in normal ‘run’ mode, in order to tell when to start searching for a charging station.  The main battery is a 2-cell LiPo stack, and so has a nominal stack voltage of around 7.5-8V when fully charged.  Since this is well above the Arduino Mega’s internal +5V operating voltage, I can’t measure this directly via the analog input ports.  So, I installed a 1/3-2/3 resistive voltage divider between the main battery voltage input, analog input A0, and ground, as shown in the following schematic detail.

System schematic detail showing resistive voltage divider for battery voltage monitoring

The nominal reading at A0 is 1/3VBatt.  Using the Arduino’s internal +5V regulator as the reference, the nominal battery voltage is 5*[A0/1023]*3.

To test this arrangement, I modified the operating software to print out the raw and calculated battery voltage values, and got the following printout.

BattMonVol: Raw 568 pin 2.78V TTL Batt 8.33V
BattMonVol: Raw 569 pin 2.78V TTL Batt 8.34V
BattMonVol: Raw 539 pin 2.63V TTL Batt 7.90V
BattMonVol: Raw 559 pin 2.73V TTL Batt 8.20V
BattMonVol: Raw 567 pin 2.77V TTL Batt 8.31V
BattMonVol: Raw 570 pin 2.79V TTL Batt 8.36V
BattMonVol: Raw 568 pin 2.78V TTL Batt 8.33V
BattMonVol: Raw 554 pin 2.71V TTL Batt 8.12V
BattMonVol: Raw 553 pin 2.70V TTL Batt 8.11V
BattMonVol: Raw 566 pin 2.77V TTL Batt 8.30V

In addition, I measured the battery voltage directly using my trusty multimeter, and got 8.03V, so a pretty reasonable monitor setup.


Next up; I had previously added the 4-detector IR module to the robot, and now I needed to integrate the IR detector measurements into the telemetry stream.  The battery monitor is on A0, and the 4 detectors are on A1-A5.  After adding the telemetry code, I got the following printout.

Time Batt DET1 DET2 DET3 DET4
0.20 8.15 937 935 651 950
0.40 8.01 943 934 739 952
0.60 7.61 934 935 792 953
0.80 7.90 932 937 824 955
1.00 8.14 940 940 847 957
1.20 8.04 927 937 862 956
1.40 7.70 930 939 876 957
1.60 7.70 932 942 889 959
1.80 8.11 935 940 898 957
2.00 8.06 929 941 899 959
2.20 7.89 944 943 904 960

Now I will add back in the left/right/forward distances, the forward variance, and the left/right wheel speeds.  After adding everything back, I get the following telemetry stream:


Time	Batt	DET1	DET2	DET3	DET4	Left	Right	Front	Track	Var	LSpd	RSpd
0.20	8.12	933	944	748	956	200	200	400	IR	407	127	127
2.00	7.65	936	941	818	955	200	200	48	IR	446	127	127
3.81	8.08	924	934	821	951	200	200	64	IR	516	127	127
5.61	8.08	942	933	830	951	200	200	85	IR	641	127	127
7.42	8.15	938	943	829	956	200	200	65	IR	705	127	127
9.22	7.92	939	945	832	958	200	200	71	IR	781	127	127
11.02	8.01	944	939	827	954	200	200	73	IR	858	127	127
12.83	8.11	941	932	826	950	200	200	69	IR	921	127	127


Wall-E2 Robot Recap – Current Status and Future Work

Posted 27 January 2017

I’m writing this post from the hotel restaurant in Houston, TX, where I am attending a duplicate bridge tournament (one of my many time-wasting interests).  There have been some major changes/improvements to Wall-E2, my wall-following, cat-terrorizing robot, so I’m taking some time to regroup and think about where I am and where I want to go with Wall-E2.

Wall-E2 has a very ‘simple’ primary purpose – to follow walls and not get stuck.  It has a secondary job of amusing the humans, and terrorizing the cats – but that’s a side-benefit of it’s primary job.  Wall-E2 has been able to follow walls for some time now, and has a reasonable capacity to avoid getting stuck.  However, battery life is limited, and he has to be manually recharged.

In recent posts I describe my efforts to remove the battery life restriction by giving Wall-E2 the capability to charge itself.  This post recaps these changes, and discusses the work needed to integrate the autonomous charging capability into the rest of the system.

Autonomous Charging Subsystem

The autonomous charging system has four components; The charger module, the IR homing module, the fixed charging station with its power supply probe and lead-in rails, and the implementation software.  The on-board charging module is complete and has been tested.  The IR homing hardware/software was tested on my old three-wheel robot and provided excellent homing performance.  The fixed station power supply probe design worked well in a bench test with a lab power supply.

System Integration Tasks

Basically, all the new hardware has been designed and tested, at least on the bench with lab power supplies.  Now the challenge is to get everything integrated into the system.  I see the following tasks:

  • Complete the implementation of the fixed charging station.  The lead-in rails and the power probe have both been independently bench-tested, but the two have not been integrated into a complete fixed-point charging station.  Now that I have officially abandoned the under-belly contact array idea, the charging station design has been greatly simplified, so this process is much more straightforward than it might have been.  All I really have to do is connect a +5V power supply to the charging probe, and make sure it is properly oriented with respect to the lead-in rails.  However, as noted below, there is significant work to be done on the software side to properly manage the charging cycle.
  • Integrate the IR homing software from the 3-wheel robot into Wall-E2’s code base.  This may not be all that simple to do. The current navigation/obstacle avoidance code in Wall-E2 is quite complex, so there may well some unintended consequences and speed-bumps in the road to full integration.
  • Implement the software required to manage the the charging process.  This involves the software to initially detect and then home in on the charging station IR beam, monitor the charging process itself, and then disengage from the charging station at the end of the charging cycle.  As noted above, this may require a significant amount of work.
  • Refurbish Wall-E2 and perform system-level testing.  Currently Wall-E2 is missing its entire second-level sensor suite, so this has to be re-attached and reconnected, and the inevitable problems fixed.  The sensor suite isn’t really required for charging subsystem testing, but of course will be for full-up system testing.

Software Integration

On each pass through Wall-E2’s current navigation loop, the algorithm determines what to do based on the current navigation mode, the current tracking mode, and the current forward distance.

The currently used tracking modes are

TRACKING_LEFT =  tracking wall to left
TRACKING_RIGHT = tracking wall to right
TRACKING_NEITHER = not tracking either wall

The currently available navigation modes are (Currently, only the NAV_WALLTRK and NAV_STEPTURN modes are used):

NAV_WALLTRK = normal wall-tracking mode
NAV_OBSTACLE = the system is responding to avoid a close-in obstacle
NAV_STEPTURN = the system is (probably) trying to follow an open corner
NAV_STUCK = the system has determined that the robot is stuck
NAV_OPENCNR = the open corner case has been detected

The challenge is to integrate the new ability to detect and home in on an IR beam in order to connect to a charging station to charge the batteries.  In this mode (call it TRACKING_IRBEAM/ NAV_HOMING) the idea is to home in on the IR beam, get captured by the lead-in rails, and connect to the charging probe.  Of course, this all implies that the robot needs to be charged – otherwise, the charging station should be avoided – not homed in on.  Thus, this capability also implies the need to be able to determine the current state of charge, so Wall-E2 doesn’t spend it’s entire life sucking on the charging teat.  There are only two ways that I can think of to monitor the current charge state; one is to monitor the battery stack voltage, and the other is to use run-time since the last charge as a proxy for charge state.  Either way, this capability will have to be added to the system.

The current navigation code is broken down into three tracking cases – TRACKING_RIGHT, TRACKING_LEFT, and TRACKING_NEITHER.  For each of these cases, new left/right motor motor speed selection is chosen, primarily based on the forward distance reading.   I’m thinking of adding TRACKING_IRBEAM to denote the situation where the battery is sufficiently discharged to warrant charging AND an IR homing beacon has been detected.

Side note: Just came up with a brilliant idea for the case where the robot approaches a charging station, but doesn’t need charging; put some spring-loaded ‘flapper’ doors’ at the entrance to the capture gate such that the forward LIDAR on the upper deck will ‘see’ the flappers, but the IR beam will still be visible by the IR detectors on the lower deck.  When the robot needs a charge (i.e. when the tracking mode is TRACKING_IRBEAM) it can ignore the LIDAR information in preference to IR beam homing, but in normal operation the detection of the approaching flapper gates will cause the robot to execute an avoidance turn – neat (I hope)!

The current tracking mode is determined in the subroutine GetTrackingDir(), which basically computes running averages for the left and right PING distances, and determines which is smaller (if both averaged distances are > MAX_LR_DISTANCE_CM, then the TRACKING_NEITHER case is declared).  I think I can modify this subroutine to check the battery charge level, and determine whether or not an IR beam has been detected. If both these conditions apply, then the TRACKING_IRBEAM case can be declared.  In the main loop, I’ll have to add an IF block for the TRACKING_IRBEAM case (and maybe change the code to use a switch statement vice IF blocks)

More to come – stay tuned!





Wall-E2 Charging Station Design, Part VIII

Posted 18 January 2017

In my last post on this subject, I had discovered two major problems with my current strategy to free Wall-E2 from the need for human assistance.  The first problem was how to get Wall-E2 disengaged from the charging station, and the second was how to transition from charging power to on-board battery power without going through a power-cycle reboot.  As noted there, I decided there were two things I needed to do – install a MOSFET switch in the coil circuit so I could switch the relay back from ‘charge’ mode to ‘run’ mode before the external +5V charging voltage disappeared, and to connect the external +5V charging voltage through a blocking diode to the Arduino Mega’s +5V buss so the controller could continue to operate while the batteries were charging.

So, I made the above changes to the charger module, as shown in the image below (changed areas highlighted). For reference, the ‘original’ schematic has also been included

Dual Cell Charging Module with changes highlighted

Dual cell balance charger. Note the two Axicom relays ganged to form the required 3PDT switch

As can be seen above, there are two major changes

  • Added a IR510 n-channel enhancement mode MOSFET to control relay coil current via a new ‘Coil Enable’ signal rather than directly from the external +5V line.  A 100K pullup was added so that the default configuration of the MOSFET switch was ‘ON’.  A LOW signal on the ‘Coil Enbl’ line will switch the MOSFET to ‘OFF’, thereby switching the 3.7V cells from ‘charge’ (parallel) to ‘run’ (serial) mode.
  • Removed the blocking diode from the +7.4V ‘Robot +V’ line, and added a separate ‘Chg +5’ 2-pin terminal with a blocking diode.

After making these changes,  I set up an experiment where I could simulate the process of connecting the robot to the charger (thereby switching the batteries from the ‘run’ (serial) to ‘charge’ (parallel) configuration, with Arduino power being supplied by the external +5V line, and then disconnecting it using the new MOSFET circuit to switch the batteries back to ‘run’ (series) configuration before mechanically disengaging the external +5V plug.

Before conducting the experiment, I wanted to confirm that the reboot problem still existed.  I set the robot up a small block so the wheels were off the ground, turned on the main power switch, waited while the robot booted up and the wheels began to turn (the program was configured for continuous half-speed motion), and then engaged/disengaged the external +5V charging plug.  As expected, when the plug was engaged the wheels stopped turning but the Arduino continued to operate (confirmed by noting that telemetry readouts continued uninterrupted).  However, when I disengaged the plug, the wheels started turning again immediately, and the telemetry readouts continued unabated, indicating that no power-cycle reboot had occurred!  I ran this experiment several more times with the same result – after making the above changes, I could not get the robot to reboot in either direction – from ‘run’ to ‘charge’ mode or from ‘charge’ to ‘run’ mode. Amazing!

OK, so what caused the different behavior?  When I ran this same experiment before the changes, I saw an approximately 50msec gap between the time the external +5V line went away, to the time when the Arduino +5V line was again stable due to the +7.4V power via the regulator block. AFAIK, there were only three significant changes made to the charging module:

  • The IR510 MOSFET was added to enable/disable the coils under computer control, with a 100K pullup to keep it in the ‘ON’ (low resistance) mode by default.
  • The external +5V line and its associated blocking diode was removed from the ‘Robot +V’ terminal to a new ‘Chg +5’ terminal
  • The blocking diode between the battery stack and the ‘Robot +V’ terminal was removed

So, what’s the deal here?  AFAICT there are only two possibilities:

  1. I didn’t/don’t fully understand the mechanism producing the 50msec power gap in the previous configuration
  2. I don’t fully understand why the current configuration doesn’t have a 50msec power gap

Previous Configuration:

I am 100% certain that I observed a consistent, repeatable power-cycle reboot when switching from external +5V to internal battery operation, and I got the 50msec number from scope measurements .  To make the scope measurements, I triggered the scope trace on the falling edge of the external +5V line, and measured the time lag from that trigger to the time that internal battery voltage was available to the Arduino.  The reboot phenomenon was verified by noting the long (5-10 sec) delay between the time the external power was removed to the time when the motors started running again, and by watching the interruption on the Arduino serial port.  The 50msec or so gap is consistent with the idea that it takes some time for the relay coil field to collapse after external power removal, plus the time required for the relay contacts to physically move from the ‘engaged’ to the ‘disengaged’ contacts.  During this interval, the only thing powering the Arduino is the charge left in the 680 uF power supply filter cap.  Assuming a current drain of around 100mA, it would take only about 5-10msec to cause a 1-2V drop on the +5V buss.  With the measured current drain of about 68mA, I measured about 30msec for a 2V drop using my trusty O’scope, so this all tracks.

Current Configuration:

In the current configuration,  after the 2V drop, the voltage drops only very slowly, so the current drain must also drop significantly – could that be the answer?  Maybe most, if not almost all of the measured current drain is the coils themselves – so that after the blocking diode gets reversed, the drain out of the filter cap goes down by an order of magnitude or so, thereby letting the Arduino live on until the internal battery takes over?  Lets see – the specs for the Axicom V23105A5476A201 relay show 30mA for the coil current, times two relays gives about 60mA total.  The measured current with the relays engaged was about 68mA, meaning that when the diode blocks, the drain from the cap goes from 68 to 8mA, meaning an additional delta of 1V (from about 4.5 to about 3.5) should take 680X10-6/8X10-3 = 85msec, which is reasonably close to what I’m seeing on my O’scope.

That’s my story and I’m stick’n to it!

OK, so now my story is this:  In the previous configuration, the Arduino 6800uF filter cap supplied relay current all the way down to zero volts, which meant that the voltage across the cap (and consequently, the Arduino working voltage) dropped to below 3V in less than 20msec, well less than the time required for the internal battery source to take over operation.  In the new configuration, the blocking diode between the external +5V supply line and the Arduino isolates the Arduino from the charging circuit after a drop of about 2V.  After this, the Arduino is powered solely by the 6800uF cap, but because the Arduino’s current drain is much smaller than the 60-70mA required by the charging circuit, the cap can power the Arduino for another 100msec or so, which is plenty of time for the internal power source to come on line.

One implication from this story is that the MOSFET circuit may not have been required at all.  As evidence, the gate of the MOSFET is tied to external +5 through a 100K resistor, so by default it is ON (low drain-source resistance) all the time, unless deliberately switched from the Arduino.  During all this testing, that control line  has been left open, meaning the MOSFET is just sitting there, doing its best to emulate a short length of wire. However, I’m reluctant to take it out or deliberately short around it for three very good reasons (actually only one good reason, and two not-so-good ones); first, it is just barely possible that the MOSFET actually turns OFF at some point in the process, maybe hastening the relay change from energized to de-energized (that’s a not-so-good reason).  Second, it is a major PITA to disassemble the robot down to the point where I can access the MOSFET and install the short (another not-so-good reason). Finally, even if I do properly understand what is going on now, it is still possible that increased Arduino loads in the future will cause the reboot problem to re-appear; in this case, being able to de-energize the relays before disengaging from the charger will be a life-saver (that’s the good reason).  In addition, I’m unwilling to screw around with something that appears to be working just like I want it to (in other words – “if it’s working, don’t screw with it!!”)

Where to from here?

As it stands, I have a robot that can be charged through its front-mounted external power jack, and should be able to (assuming appropriate information availability) switch to internal battery power and disengage itself from the charging station.  Now I need to actually implement the entire solution, generally as follows:

  • Confirm that the proposed engagement/disengagement strategy will actually work.  To do this, I’ll need to modify the operating software to
    • recognize when the external power plug has engaged and is supplying power
    • switch back from external to internal power
    • disengage from the external power plug.
  • Build up the fixed portion of the charging station, including mounting the IR LED and supplying 5V power
  • Simulate the entire IR track/side-rail capture/engagement/disengagement cycle on the bench
  • Modify the operating system to implement the required additional tracking/movement modes

Independently of the above, I need to revisit the issue of how the charging station connects to the robot.  Originally, the idea was to connect via an array of contacts on the underside of the robot.  These contacts would mate with spring contact fingers on the top surface of a raised section of the fixed charging station, which would also contain status LEDs for the two embedded Li-Po chargers.  Unfortunately, I have been unable to come up with contact fingers appropriate for the application, despite trying three different contact finger ideas (EMI shielding finger stock, TE connectivity spring contact fingers, and Mill-Max spring-loaded contacts).  Fortunately, in the meantime I was able to successfully demonstrate automatic external charging power connection using a guide funnel for the front-mounted external power jack and a semi-flexible probe tube with the mating external power plug mounted at its end.

The advantage of using the front-mounted jack for automatic power connection is that all I have to do is to get that one jack/plug pair engaged/disengaged, as opposed to the nine underside contacts.  This is a huge simplification of the problem, and one that I have already demonstrated to be feasible.  The major disadvantage of this option is that all the charge-related decision making will have to be done by the robot, as the fixed part of the charging setup won’t know what is going on at all.  If I want to monitor charging status, I’ll have to do that via the onboard Arduino.  In the previous configuration (pre-MOSFET) this disadvantage was compounded by the fact that charging power could only be removed by physically disengaging the external power plug, which could only be done by some external physical mechanism since (by definition) the onboard wheel motors weren’t available during the charging process.  Since I now have a way around that dilemma (i.e. the robot can now unilaterally switch from external to internal power by means of the MOSFET switch and then use the onboard motors to effect physical disengagement), this huge problem goes away entirely.  I still have the problem of how (or if) to display charging status, but this is trivial compared to the problem of physically disengaging the charging plug.

If I decide to abandon the underbelly contact array idea, then I can re-purpose the 8-pin header on the charging module to route charging status information to the Arduino instead of to the underbelly contact array. This header is shown in the image below:

Charger module 8-pin male status/control header

As shown, there are 3 status pins for each cell charger, a ground line, and the new ‘Coil Enable’ line.  The status pins show whether or not the charger is receiving power (PWR), and whether the cell is still charging (CHG) or has finished (FIN).  In the original charging station design, the six status lines were brought out to individual LEDs via the contact array. If the underbelly array strategy is abandoned in favor of the single front-mounted connector, then these LEDs will have to be mounted somwhere/somehow on the robot itself.  Originally I was thinking that each status line would consume an Arduino Digital I/O pin, but now I’m not so sure.  All of these lines are actually already ‘powered’ from the charger modules themselves – all that is required to illuminate the CHG and FIN LEDs is +5V – the status line is tied to an open-collector output through a limiting resistor.  The PWR status line is simply the +5V power to each cell charger, so a limiting resistor is required.  All the required signals and connections are available, so all that is needed is some sort of mounting arrangement on the robot – perhaps it could be integrated into the mounting for the front-mounted IR phototransistors in a manner similar to the ‘backup light’ mount at the rear?

‘Backup Lights’ mounted to rear of the robot

IR phototransistor mounting at the front of the robot

there would be more LEDs (7 vs 4) but each LED would be much smaller (3mm vs 5mm).  On the same 56mm panel, 7 LEDs could be spaced 6mm apart, with 6mm spacing on the ends, something like the following

Prototype for a charging status LED panel

And, with my trusty PowerSpec PRO 3D printer I printed out a full-scale feasibility assessment panel in just a few minutes, as shown below. Of course much more work would be required to make this into a fully functional panel, but just this piece shows that all 7 LEDs can be accommodated in a panel that is generally the same dimensions as the IR sensor module.

Charge status LED panel full-scale feasibility model

Charge Status Display Panel Update

After the normal number of trials, I came up with a charge status display panel that could be co-mounted with the current IR detector assembly, as shown in the following images:

Stay tuned!




Wall-E2 Charging Station Design, Part VII

Posted 15 January 2017

I received my sample spring finger contacts from TE Connectivity, but they are clearly not going to do the job as the fixed end of Wall-E2’s under-belly contact system – bummer. Even the 4mm high one is just too small – bummer :-(.

As usual, when faced with a setback, I go away and sulk for a while, and then come back with some more ideas.  I may not be all that smart, but I am persistent! ;-).  This time, after some more web research, I found a family of spring-loaded plunger contacts made by Mill-Max Inc, one of which is shown in the image below

Spring-loaded contact. Initial height is 7.67mm, compresses down to about 6mm

As an interesting aside, the Mill-Max components are (AFAICT) dimensioned entirely in English units (inches), which is of course what I grew up on here in the U.S.  However, after the last few years of immersion in the 3D printing and robotics world, I have gotten to the point where I had to convert the above ‘0.302″‘ dimension into metric units (around 7.6mm) before I could visualize how (or even whether) it was going to fit into the current design.  Even more interesting, I was an electronics design engineer in a DoD outfit during the Carter administration’s failed attempt in the 1970’s to convert the entire U.S. to metric.  There was an enormous amount of work put into relabeling everything with both English and metric notation, to absolutely no effect.  The reason it failed then, and is working now (at least for me) is the widespread use of metric notation now for 3D printing and DIY robotics.  Way to go, Carter – you had the right idea, just 50 years too soon! ;-).

Anyway, back to the movie; while waiting for the above parts to arrive, I have been doing some additional work on the alternative plug-capture strategy, and came up with three additional design issues that must be resolved for either the bottom contact array or the front plug-capture methods.

  • In order for either method to work, the robot has to know when the contacts have engaged, so it can change from a wall-following to a charge-monitoring strategy.
  • The robot’s controller has to continue operating through the change from battery power to off-board charging power. The transition from battery power to off-board charging power is inherently seamless, as charging power to the Mega’s +5V (beyond the voltage regulator stage) pin appears before the batteries are switched from series to parallel for charging.
  • When charging is complete, the robot has to somehow disengage from the charging system.  This turns out to be somewhat of a trapeze act, as motor power to do the disengaging isn’t available until after disengaging – oops!
  •  Although the transition from battery to charging power is inherently seamless, the opposite transition isn’t.  5V power from the charger goes away before battery power becomes available, causing the Mega to reboot – double oops!

Knowing when contacts have engaged

For the robot to know when the contacts have engaged, there has to be some electrical signal that changes state when this happens.  For the case where the forward 5V plug is engaged, this was accomplished by connecting the normally-closed contact of the power jack to a digital input, with the pullup resistor activated; This causes a low-to-high transition when the contact is broken, which occurs when the power plug fully engages in the jack.   However, this signal isn’t available when the under-belly contact array is  utilized.  For this case, the plan is to tap off the ‘Pwr1’ and ‘Pwr2’ signals and run them to digital inputs; these lines are normally LOW, and transition to HIGH when charging power is available.

Continue operation through transition from battery power to charging power

As noted above, this is inherently seamless, as charging power is available before battery power goes away.  All that is required is to wire +5V charging power to the Mega’s +5V output line (i.e. after the regulator stage).

Disengage from the charging station after charging is complete.

As noted above, this is a problem, because the motors require 7.4VDC battery power, which isn’t available until about 50msec after the charger is disengaged.  So, either some way will have to be found to run the motors from the +5V charger power, or some way will have to be found to physically disengage the robot from the charging station without using the motors.

One way to skin this cat is to implement some sort of pusher mechanism on the charging station side, like a linear actuator or a solenoid or a stepper motor.  The idea would be that the charging station pushes the robot off the charging plug and/or underbelly contacts.  The problem with this scenario is that the charging station doesn’t necessarily know when charging is complete, especially if the front plug/jack option is being used.  If the underbelly contact arrangement proves viable, then the ‘FIN1’ and ‘FIN2’ LED enable lines are available for this function.

Another idea is to use the same sort of pusher mechanism, but put it on the robot side.  The advantage of this arrangement is that the robot can easily tell when charging is complete (the above ‘FIN1’ and ‘FIN2’ signals).  However, there are two significant disadvantages; first, there is the issue of how to mount a pusher mechanism – there isn’t a whole lot of idle real estate on the robot – especially on the front surface.  Secondly, as soon as the pusher mechanism successfully disengages the robot from the charger station, the power to run the pusher will go away for at least 50msec – which could lead to a mechanical oscillation condition.  Some mechanical hysteresis will have to be engineered in to make sure that once the pusher starts the disengagement process, it will complete it with plenty of margin (maybe a mechanism that winds up a spring using charger power, and then the spring actually does the pushing, or a solenoid that once triggered, completes the stroke regardless of power availability?)

Computer reboots when charging power is removed

The +5V power to the battery chargers also drives the two relay coils, which among other things, switch the two 3.7V battery packs from series to parallel connection for charging.  In addition to charging the batteries, this +5V line is connected to the Mega’s +5V buss, downstream of the voltage regulator circuit. This allows the Mega to continue operations during the transition from ‘run mode’ (powered by the 7.4V battery stack via the voltage regulator) to ‘charge mode’ (directly powered by the +5V charging voltage).  However, when the +5V power is removed at the end of the charging cycle, there is an unavoidable gap of about 50msec where there is no power available for the Mega.  This means that the Mega will perform a cold-boot at the end of each charging cycle, just as if it were being turned on for the very first time.  In other words, the Mega won’t know where it is, and certainly won’t know that it was just disconnected from the charging station. Without some additional work, the robot will assume it is starting out life anew, and will immediately start trying to follow the nearest wall (and/or trying to home in on an IR signal if one is present – and one certainly would be if it had just disconnected from the charging station).  Moreover, since the robot by definition would be well inside the capture rails for the charging station, it would most likely just plug itself back into the charger – rinse, lather, repeat ;-(.

One possible solution for this dilemma would be to store a non-volatile ‘bWasJustCharged’ flag in the Mega’s EEPROM.  This flag could be checked at boot time; if the flag is set, then the robot knows it was just disconnected from the charging station and can take the appropriate action; if not, then party on as normal.  Maybe something like the number of milliseconds since the last charge operation?  The nice thing about this idea is it could also be used as a crude battery level meter, assuming battery usage was somewhat linear over time.

15 January 2017 update:  Just confirmed that I can store and retrieve information to/from the Mega’s EEPROM.  I had a small EEPROM write/read test program lying around from a couple of years ago (I did tell you that I never throw anything away, didn’t I), and used it to update an EEPROM location with the current value of millisec() every second or so.  In the setup() function of this program, I read the same location (i.e. the initial read comes before the first update in the loop() function).  I ran the test by letting the Mega run for 10-15 seconds, thereby assuring that the EEPROM value was in the 10-20,000 range, and then power cycled the Mega.  The initial readback after the power cycle was in the correct range (i.e. 10-20,000), confirming that the elapsed run time had survived the power cycle.  For my project, I think I can set a threshold like 15-60 sec for just-charged detection; if the stored value is less than the threshold, the robot decides that it has just been disconnected from the charging station, and takes the appropriate action (backs out of the side rail capture area, turns 180, and gets the heck out of Dodge.  As a secondary benefit, the robot can consult the ongoing elapsed time counter to decide how actively it should look for ‘food’ (charging station).

16 January 2017 update: I tried a couple of ideas for mechanically disengaging the robot, with absolutely no success – it turns out the robot is actually quite heavy, and in addition it has to be moved against the motor gearing on all four wheels.  Not going to happen without a serious motor!  So, back to the drawing board again.  After a while, I realized that I was thinking about the problem (actually two of the problems) the wrong way.  The two problems are the need to disengage the robot from the charging station, and the need to deal with the reboot that occurs when the robot is disengaged.  It occurred to me that if the batteries could be switched back from parallel to series operation before the robot was disengaged, two very good things would happen; first, I could then use the robot’s own motors to perform the disengagement task – rather than having to fight the motors using an external actuator. Secondly, this would eliminate the reboot problem entirely, as the 7.4V source would provide 5V through the regulator to the Mega’s 5V node, meaning no interruption when the charging +5V disappeared.

To make all this happen:

  • I need to install a blocking diode on the +5V charging line to the Mega +5V node, so that when the 7.4V source reappears and takes over the power supply function, that there won’t be any backwards current on the +5V charging line
  • I need to be able to disable the current to the two relay coils, while still maintaining +5V power to the Mega +5V node, and this needs to be controllable using a Mega digital output (i.e. max 30mA source/sink).  This can be accomplished by adding a n-channel enhancement mode MOSFET to the circuit, between the +5V charging input and the relay coils, as shown below.  The MOSFET should be ‘normally-closed’ (i.e. low D-S resistance), so this can be accomplished by connecting the gate to a digital output with the pullup resistor engaged.  Then a LOW output will turn the MOSFET OFF (high resistance) thereby de-energizing the relays, which will in turn switch the batteries from parallel to series operation.  After a suitable delay for this to happen, the robot can then use its own motors to disengage and move away from the charging station.

18 January 2017 update: So, I made the above changes to the charger module, as shown in the image below (changed areas highlighted). For reference, the ‘original’ schematic has also been included

Dual Cell Charging Module with changes highlighted

Dual cell balance charger. Note the two Axicom relays ganged to form the required 3PDT switch

As can be seen above, there are two major changes

  • Added a IR510 n-channel enhancement mode MOSFET to control relay coil current via a new ‘Coil Enable’ signal rather than directly from the external +5V line.  A 100K pullup was added so that the default configuration of the MOSFET switch was ‘ON’.  A LOW signal on the ‘Coil Enbl’ line will switch the MOSFET to ‘OFF’, thereby switching the 3.7V cells from ‘charge’ (parallel) to ‘run’ (serial) mode.
  • Removed the blocking diode from the +7.4V ‘Robot +V’ line, and added a separate ‘Chg +5’ 2-pin terminal with a blocking diode.

The idea was to set up an experiment where I could simulate the process of connecting the robot to the charger (thereby switching the


Wall-E2 Charging Station Design, Part VI

Posted 09 Jan 2017

It’s been a while since I have posted on my evil plan to set my wall-following robot free to roam the house terrorizing cats, all without the need for charging assistance from mere humans ;-).  I have made a lot of progress – but unfortunately not all of it has been positive :-(.

Charging Platform:

I was able to complete and print the final design for the fixed part of the charging platform, as shown in the following images

The idea was that the robot would be captured by the lead-in rails and roll over the charging platform to a stop – thereby connecting to the platform via the contact array.  The status LEDs would be visible to a person standing behind the robot.  Unfortunately, when I got everything all hooked up, the beryllium-copper finger-stock fingers proved too stiff to allow connection across the contact array; a couple of fingers were just a bit higher than the others, and the robot wound up suspended from these, and not making contact with the others – BUMMER!!

So, it was (literally and figuratively) back to the drawing board on the whole charging station idea – what to do?

TE Connectivity Flexible Contacts:

When I first thought of the idea of a charging station with flexible contacts and an under-robot contact array, I did a fair bit of web research on flexible contacts, and wound up with the idea of using individual fingers from a length of beryllium-copper finger stock, which is readily available on eBay.  Now that this option has been ruled out, it was back to the web again for more research.  This time I found a company called TE Connectivity, and they have a line of flexible contacts for use in connecting PCBs to cases in mobile devices, among other things, as shown in the following images.  They have a huge variety of contacts, so I was able to find four good possibilities with uncompressed heights between 3 and 4mm.  Even better, The TE connectivity folks let me order samples – yay!!


I practically wet my pants when I found these, as I think they are the answer to my prayers; otherwise I would probably have to abandon the entire charging platform/contact array idea.

Automatic 5V Charging Connector Mating Option

When I installed the new battery pack in Wall-E2, I also re-installed the 5V power jack that came with the original kit.  I figured that I could use this jack to manually charge the batteries until I got the human-free option working.  While waiting for the connector fingers from TE to arrive, I started thinking that I just might be able to work up a way to have Wall-E automatically drive itself onto the mating 5V plug to charge, then back off of it when finished.  I had not pursued this in the past, as I thought it would be too hard to get the plug and jack lined up with any consistency, but now I was reconsidering it as possibly the only remaining option.  And, since I have a 3D printer sitting on my workbench, I started experimenting with coupling ideas.  The first challenge was to design and fabricate a ‘capture basket for the 5V jack, so that the initial alignment wouldn’t have to be perfect.  After the normal half-dozen or so failed designs (have I mentioned how much I love the ability to do short turn-around design/fabrication cycles?), I had a design that I thought would work, as shown in the following photos.

The ‘capture basket’ fits very snugly over the 5V power jack, and is designed such that the slanted sidewalls mate up seamlessly with the lip of the jack – no flat spots or corners to impede the plug on its way in.  I was a little bit worried about the granularity inherent in FDM prints, but this turned out to be a non-issue, as shown below.

After getting the capture basket designed and fabricated, it was time to work on the other end – the plug probe. I already had a tentative design for a part that would serve as a stop for the robot while also providing a mount for the IR beacon LED, so I decided to add the plug/probe to this fixture, as shown below

I was able to simply add a block of plastic onto the side of the original stop/IR LED holder to accommodate the plug/probe assembly. The probe was fabricated from NinjaFlex to allow for some flexibility as the plug mates with the jack.  As the following video clip shows, this arrangement seems to work quite well!


So, now I have what appears to be a viable alternative to the contact-finger/contact array strategy.  The jack/plug alternative has a significant drawback in that I can’t bring the battery charging status signals out for off-robot display.  If necessary that can be accommodated by constructing some sort of on-robot status LED strip (not sure where I would put it, but…), but it would certainly fulfill the primary requirement of allowing the robot to feed itself, and there’s no real need to keep those puny humans informed, anyway ;-).

Stay tuned!




Wall-E2 Charging Station Design, Part V

Posted 18 Dec 2016

The new charging system for Wall-E2 consists of three major parts:

  • The two 3.7V Li-Ion battery packs and battery chargers (one charger for each battery pack)
  • The contact array that connects the charging platform to the chargers.
  • The charging platform and charging power supply

I have spent the few days or so working on the first two items above, building up the battery pack and charging circuit for Wall-E2, and working out the details of the contact array for connecting Wall-E2 to the charging platform.

Charging Module:

This is actually the third time I have attempted a charging system for a  7.4V Li-Ion battery pack consisting of two 3.7V cells.  The first one was for my original Wall-E, and it is still cooking along.  The second one was for Wall-E2, and it didn’t go as well.  After all the work of building up the module and tucking it into the robot, I discovered that the system just wasn’t robust enough for Wall-E2’s higher power requirements, so I wound up going with a high-current RC battery and an external charger.  This wasn’t really satisfactory either, as the battery pack was just too big and awkward, and having to physically disconnect the pack from the robot to charge it was a real PITA.  Plus, I still harbored the desire to make Wall-E2 more human-independent by giving it the capability of recharging itself.  So I made another run at the dual-pack charging universe, and this time I found an article by the Adafruit guys about a ‘simple balance charger’ using two of their Li-Po chargers and a manual 3PDT switch.  This article very closely matched the charger setup I had used previously, except for one extra pole on the switch.  In the Adafruit circuit, this third pole was used to switch the positive side of the upper 3.7V pack from the load to the upper charger. My previous designs didn’t have this switch, and on closer examination, I realized that without this third pole, the upper charger might see the entire 7.4V on its output port – oops!  The reason for this is that the chargers aren’t truly isolated from each other – they share a common ground, and when the circuit is in series (RUN) mode, the upper charger’s plus output is still tied to the upper battery’s positive terminal, while its negative output is still at ground.  This puts the entire  7.4V across the upper charger – a BAD thing!

So, I needed a third pole, but although small 3PDT manual switches are easy to find, small/compact 3PDT relays are not.  In my previous designs I had used the very nice Axicom V23105 2PDT telecom relay, but 3PDT relays in the same form factor were nowhere to be found – grrr!  So eventually I decided to use two of the Axicom relays and gang the coils to get a 4PDT relay, one pole of which would go unused.  Also, learning from previous mistakes, I made sure I could easily remove/replace the battery packs and the chargers if necessary.  The final charger schematic is shown below, along with some images of the finished charger module.

Dual cell balance charger. Note the two Axicom relays ganged to form the required 3PDT switch

Closeup of the completed charging module. Note the two Axicom relays used to implement a 3PDT switch

bottom wiring layer of charging module

Finished charging module connected to two 2-cell 3.7V battery packs

Bottom rear view of 4WD robot showing battery packs and charging module

Signal/Power Contact Array

The next challenge was to figure out how to connect the robot to the charging station.  In addition to supplying +5V to the two chargers, I wanted to bring out the power, charging and charge-completed status signals from both.  This requires a total of 8 contacts ( 6 status signal lines, +5V in, and GND).  I also decided to bring out the power line to the robot, for a total of 9 contacts.  The idea here is to place contact strips on the bottom of the robot, which will make contact with spring-copper sliding contacts on the charging platform.  I played with a number of contact layouts, but ultimately decided on a straight-line array of contacts due to space restrictions in the robot.  In the image below, the contact array layout is shown, with the ‘Pwr LED2’ position partially implemented.


Bottom side view of 4WD robot showing contact array layout with the ‘Pwr LED2’ position partially implemented

Some time ago I purchased a length of beryllium-copper finger stock used for fabricating EMI gaskets, with the intention of using the individual fingers as contacts for the charging station.  In order to do this, I needed a way of capturing each finger in the top surface of the charging station.  I went through several iterations as shown below

After playing around a bit with  a single contact finger and the contact arrangement shown above, I realized that a small misalignment between the robot and the charging platform could cause a finger to bridge two contacts or even connect with the adjacent circuit.  So, I went back to Visio and redesigned the contact layout, as shown below


two-row contact layout.  Contacts are 15x10mm with 16mm center-center spacing

As shown in the following photos, this is a much more robust arrangement in terms of contact mis-alignment protection, at the cost of taking up more space on the bottom of the robot

Contacts just prior to engaging

Contacts mis-aligned low

Contacts mis-aligned high

Contacts in the fully engaged position

Contacts just before engaging

Contacts well before engaging

With the above arrangement, there is basically no possibility of a contact finger bridging the gap between two contacts, and even drastic mis-registration of the robot onto the platform will result in correct contact engagement.  That’s my story, and I’m sticking to it! ;-).

Here’s a short video clip of a few simulated engagement/disengagement cycles


The next step was to fabricate the robot-bottom contacts from copper tape and wire them to the charging module. Here are some photos of the finished product.

Interface contacts fabricated and wired to charging module

When I looked at the completed module, I recognized that I still had two issues remaining.  The first and more important one is that I needed a strip of insulation to having the sliding contacts short to ground or each other as they moved across it on their way to their final destination. The second one was that it would be nice to label the contacts so that I wouldn’t have to trust my very untrustworthy memory.  As I thought about this, it occurred to me that I could kill two birds with one stone by placing a label strip on the chassis, as shown below – cool huh!

Added labelling to contact array. This was a ‘two-fer’ as it also prevents contact shorting to chassis





Wall-E2 Charging Station Design, Part IV

Posted 10 December 2016

Well, two important steps occurred today in my plan to take over the world (well, maybe just make Wall-E2 more human-independent). The first was the arrival of my Panasonic 18650 batteries, and the second was the successful trial of my first stab at a charging platform.

The ‘platform’ part of the charging system (the blue piece in the image below) is the part that captures and positions the robot accurately enough to connect to charging power, via contact strips on the bottom of the robot and spring-loaded contacts on the platform.

1/2-scale concept model for the Wall-E2 charging station.  The blue part is the ‘charging platform’

So today I printed out a full-scale platform.  This was pretty amazing by itself, as it took up nearly the entire build area, and took about 4 hours to print.  Fortunately I had recently upgraded my build platform with a PEI surface and also re-leveled it, so the printer was up to the task. It did take me a while to get the darned thing OFF the build surface, as it was very well adhered to the base 😉

Robot’s eye view of the charging platform

Overall view of the lead-in rails and the charging platform

Closeup of the charging platform piece. Note the beveled section at the entry end

To test the combination of the lead-in rails and the charging platform, I double-sided taped the platform in what I hoped was the best position/orientation, and ran some more tests with the robot, as shown in the following video clip.

This last series of tests, in conjunction with my earlier work on IR following,  was quite rewarding for me, as I now had incontrovertible proof that the lead-in rail/charging platform idea would really work.  It might not be ‘optimum’, but I was now sure I could get the robot to track an IR beam accurately enough to get captured by the lead-in rails, and the platform would position the robot accurately enough to make the charging connections – yay!!!

Now I have to start serious work on the other end – the actual charging and battery circuitry.  With the arrival of my Panasonic 18650 cells, I now have all the required parts – I just have to put them all together, make it all work, and somehow shoehorn the entire mess into the robot!

Stay tuned,



Wall-E2 Charging Station Design, Part III

Posted 12/05/16

I’ve been making some progress with the planned charging station lead-in rails.  These rails (shown in yellow in the image below) are intended to guide the robot into the charging station, lining it up properly with the charging station so the contacts on the bottom of the robot will properly mate with the corresponding contacts on the top of the charging station platform.

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

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

These rails are too big to print in one piece on my PowerSpec PRO 3D printer, so I had to devise a way to print them in sections, which could then be plugged together to form the complete rail.  To do this, I designed a coupling geometry consisting of a ‘puzzle-piece’ connector and a slide-fit arrangement, as shown below:

Lead-in rail angle coupling design

Lead-in rail angle coupling design

Lead-in rail straight coupling design

Lead-in rail straight coupling design

After going through several iterations ‘on paper’, I printed out a 1/2 scale model to verify that I could indeed connect the pieces to make a whole lead-in rail, as shown below:

Half-size capture basket rail

Half-size capture basket rail

Half- and Full-size capture basket rails

Half- and Full-size capture basket rails

Full-size capture basket rails

Full-size capture basket rails

Now that I had the capture rails fabricated, it was time to find out whether or not the capture system would actually work.  I used double-sided tape to affix the two rails to one section of the heavy plastic desk-chair runner system in my lab/office, at the proper spacing to just pass the robot, assuming it was properly aligned with the capture gap, and then ran some tests, as shown in the attached video clip.

In the video clip, the first two trials were conducted with the ‘stock’ wheel guards with right-angle corners, and the remaining ones were conducted after filing a small bevel into the front corners to (hopefully) alleviate the sticking problem


Front wheel guard with filed bevel on outboard corner

After seeing that the filed bevel seemed to improve performance, I decided I would go ahead and redo the wheel guards to provide a more pronounced bevel.  Thanks to TinkerCad and my trusty 3D printer, this was a piece of cake.

Redesigned wheelguard to incorporate bevel on outboard corner

After changing out the wheel guards, I ran some more tests with my taped-down capture basket, but soon discovered yet another ‘capture failure mode’, as shown in the following image.

Robot stuck in capture basket

As you can see in the image, the rear part of the front wheel guard and the front part of the opposite wheel guard is just the right shape and spacing to form a stable lockup configuration.  To address this little problem, I decided to remove the rear portion of the front wheel guard on each side, but left the two rear wheel guards intact.  Then I ran some more capture basket tests, with very encouraging results.


So, at this point I’m pretty happy with the capture basket lead-in rail design (3 failures in 14 tries), and with the robot wheel guards.  Next, I’ll need to fabricate a full-scale charging platform for the robot to stop on, and also work on the new charging/battery setup in the robot itself.  Stay tuned!



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

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

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

Adafruit PowerBoost 1000 LiOn/LiPo charger

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

Adafruit 3.7V 2500mAh LiPo battery

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

Wall-E charging setup from early 2015

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

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!



Wall-E2 Charging Station Design, Part I

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 concept model for the Wall-E2 charging station

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

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

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

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)

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

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

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!