Monthly Archives: January 2017

Wall-E2 Robot Recap – Current Status and Future Work

1 Reply

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!

Frank

 

 

 

Wall-E2 Charging Station Design, Part VIII

1 Reply

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!

Frank

 

 

Wall-E2 Charging Station Design, Part VII

Leave a reply

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

 

3D Printer Filament De-Humidifier Bin

Leave a reply

Posted 11 January 2017

I’ve had at least one 3D printer in my home laboratory for well over 2 years now, and having the ability to print up arbitrary 3D shapes has been a complete  creative game-changer for me.  Now when I have an idea about something I want to build or try, I don’t have to spend days in my shop trying to fabricate something out of wood or sheet metal – I can design it in TinkerCad and print it on my 3D printer.  Moreover (and this is where it gets  really  cool!), I don’t have to get it right the first time – I can make an unlimited number of versions of the idea, improving and/or changing it as I go.  Each iteration takes a few hours at most, and costs just a few pennies in terms of power and filament usage – what a deal!

Anyway, I have accumulated a number of rolls  of different filaments, all of which degrade  in greater or lesser degree over time due to moisture absorption (hygroscopic tendency).  I

haven’t worried too much about this up to now, mostly because my lab is in an air-conditioned house in the midwest, where humidity levels are low to begin with.  However, I recently started seeing some printing problems that led me to believe that I may need to address this issue.  In my typically over-the-top fashion, I decided that if I was going to work this problem, I needed a way to monitor the actual temperature & humidity in whatever arrangement I tried.

First, as usual, I did some web research, and found a solution implemented by the folks at the  Taulman  specialty 3D filament fabrication house.  Their solution was a 5-gallon plastic bucket with some air-holes, a 40-60 Watt lightbulb, and a wooden dowel.  This allowed them to combine a dehumidifier with a filament delivery system.  I fabricated one of these myself, but wasn’t particularly happy with the results.  While it worked fine, there was only room for two rolls of filament at a time, while I have literally dozens of rolls of different filaments.  In addition, I had no way of knowing what the actual temperature and relative humidity were inside the bucket – for all I knew, it could be doing nothing but wasting 40 watts of electricity!

So, I decided to combine my pile of 3D filaments, my 3D printing super-powers, and my Electrical Engineering Mad Scientist background to come up with a better solution to the filament drying problem.

Temperature/Humidity Sensors

The DIY/Robotics/Hobbyist market has spawned all sorts of new capabilities, so I was not at all surprised to find that temperature/humidity sensors were cheap and readily available.  I started with the cheaper  DHT11  (I figured I would kill at least one sensor before getting it right), but later moved on to the  DH22.  The DH11 humidity measurement range stops at 20% on the low end, and since I am trying to obtain humidities at or below that value, I decided to blow out my sensor budget from around $5/unit to around $10 – a real budget-breaker (not)!

DHT11 Temp/Humidity sensor, shown here from Adafruit.  20-80% RH range with +/- 5% accuracy

DHT22 Temp/Humidity sensor, shown here from Adafruit.  O-100% RH range with +/- 2.5% accuracy

Arduino Uno Controller

In order to effectively use the RH sensors, I needed a controller of some sort.  Happily for me, there was already a DHT11/22 library available for the wonderful Arduino  line of controllers, and I happened to have several Arduino Uno’s lying around waiting for something to do.  Connecting up the sensor, and getting a program working was a matter of just a few lines, most of which had already been written in the form of an example program

8-Character LCD Display

When I first started this project, I thought it would be adequate to simply connect the arduino to my PC to readout the data.  This worked, but turned out to be cumbersome;  I had to have a physical connection to the controller, which was located inside the dehumidifier bin.  Later I tried a Wixel connection, which also worked, but still meant that I had to bring up a serial port app on my PC to find out what my dehumidifier bin was doing.  What I really wanted was a completely self-contained system, so I could simply look at some sort of display on or in the bin and tell whether or not things were working.  After doing a bit more web research, I found the Sparkfun ‘Basic 8-character LCD display’  for all of $4.95 (plus shipping).  In addition, this display (plus a number of others with different character arrangements) were easily integrated into an Arduino program by means of the built-in ‘LiquidCrystal’ Library – nice!!

So now I had all the pieces – a sensor (DHT22), a controller (Arduino Uno), and a display for readout (Sparkfun 8×2 LCD).  Now what I needed was a nice, custom-made box to house them, and just coincidentally I had 3D printer and LOTS of filament hanging around just waiting for a project! ;-).  As usual, I went through several iterations (you would think that it would be pretty hard to screw up a simple box design, but I’m highly creative when it comes to finding new ways!).  When I was finished, I had a nice little box with enough room for everything, a recessed lid, and appropriately placed holes for the power connector, the USB connector, and the sensor cable, as shown below

To complete the project, all I had to do was drill some holes in a handy transparent storage bin, load it up with filament rolls and a 40-watt trouble light, and set the sensor box inside where the readout would be visible from the outside.  The whole thing was installed on a shelf over my workbench, so I can simply walk up to the bin and see the readout from eye level – neat!

Now all I have to do is wait a day or so to see where the system stabilizes, and make whatever airflow adjustments are necessary.  For anyone who cares, I have included below the Arduino sketch for the project.

15 January 2017 Update:  After 24 hours, the system stabilized to around 85 º F (29.4C) and about 26%, which I thought wasn’t enough better than room environment to make a difference, so I closed off about half of the air-holes.  After another 24 hours or so, the system re-stabilized at about 90 º F (32.2C) and 21% humidity – much nicer!

17 February 2017 Cleanup:  Here is the code to  display temperature & humidity on the LCD display, and  also make  the data available at the serial port.

Frank

 

Wall-E2 Charging Station Design, Part VI

1 Reply

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!

Frank