Tag Archives: Charging Station

Wide Body Robot Charging Station Homing PID Tuning

Leave a reply

Posted 30 October 2023

Almost exactly two years ago I redid the robot form factor for better turning performance, as described in this post. Now, two years later when integrating the new ‘wide body’ robot with the charging station, I belatedly discovered that the PID values optimized for the old ‘narrow body’ robot don’t do so well anymore. Here’s a short video and telemetry showing the wide body robot homing with the old narrow body PID values.

I strongly suspect that the new form factor will require a significantly different set of PID values. Here

04 November 2023 Update:

Well, I went down a bit of a rabbit-hole on this one, but I think I have successfully found my way back to the real world. It’s been a while since I’ve had to do any PID tuning, so my skills (and code) have atrophied significantly. Fortunately, my former self left me some rudimentary clues, so I didn’t have to recreate everything from scratch.

In previous tuning sessions, I had constructed a test harness that accepted PID values on the command line of the OTA serial connection to the robot, allowing rapid parameter optimization. Unfortunately, I didn’t document this in my previous posts (what was I thinking!), so it took me a while to find some previous programs that contained the desired test harness code. After porting the test harness code to my current WallE3_Quicksort_V4 program and modifying it a bit for more testing convenience, I am documenting it here so a future me will have a better chance of avoiding unnecessary work.

PID Tuning Test Harness:

The idea behind the PID tuning test harness is to allow the user to input PID (and other) parameters on the command line and have the robot execute the desired action – in this case homing to the charging station – without having to go through the entire program structure. The test harness code is placed at the end of the setup() routine and doesn’t exit but returns to the point where a new set of parameters can be provided. This allows for rapid iteration over the PID parameter space. Here is the code as it appears in WallE3_Quicksort_V4.ino

Note that the ‘CheckForUserInput()’ function calls in the above assume a boolean return value; this change was necessary to allow the test harness to be run multiple times without having to reboot the robot code. This also required adding a new function key (*) to the list of keys handled by CheckForUserInput(). Here are the new versions of the two flavors of CheckForUserInput():

Now that I’ve gotten the test harness set up, I can actually start re-tuning the charge station homing PID values for the new wide-body robot – yay! Here’s a short video and telemetry from the first run with PID(50,0,0).

Here’s another run, this time with PID = (100,0,0)

Here’s the PID = (100,0,0) run again, but starting with an initial orientation offset:

And here is an Excel plot showing the steering value vs time:

This is a pretty nice result, and I’m tempted to leave it just like this.

Wall-E3 Charging Station Integration

Leave a reply

Posted 14 April 2022

Wall-E3 has a significantly different form-factor than Wall-E2, requiring modification of the lead-in rails on the charging station, as shown below.

Once the required mods were made, I uncommented ‘#define IR_HOMING_ONLY in my code to have Wall-E3 concentrate solely on homing to the charging station, and then worked my way into a set of PID values (100,0,30) that gave reasonable homing performance, as shown in the following short video:

And here’s an Excel plot showing typical homing performance.

24 April 2022 Update:

The above data and video was collected using the ‘NoPing’ version of the IR Homing algorithm, so I went back and did this again using the version that monitors the front distance, both for detecting a ‘stuck’ condition and for the ability to navigate around the charging station if a charge isn’t needed. Of course, this didn’t work right away for various reasons, but eventually I got it working and made another test run. Here’s a short slo-mo video, and the accompanying Excel chart showing homing performance.

IR Homing run in slo-mo with tracking status shown on rear panel LEDs
Steering value and front distance vs time

01 May 2022 Update:

Wall-E3 has made some significant progress in the last week, and is now capable of switching from right-wall tracking to IR Homing to the charging station, as shown in the following short video and telemetry output:

automatic switching from right-wall tracking to charging station homing

Stay tuned,

Frank

Another Try at Charging Station Homing PID Tuning

Leave a reply

Posted 04 April 2021

Lately I have been working on improving the performance of Wall-E2, my autonomous wall-following robot, when homing in and connecting to it’s charging station. The robot uses the PID (Proportional-Integral-Derivative) library to drive the motors to home in on an IR beacon, and this ‘mostly’ works, but still occasionally hangs up on the lead-in rails. I have made several attempts to get this right (see this post and earlier work), but have never really gotten it zeroed in. After yet another web search for tuning help, I ran across this post dealing with the Ziegler-Nichols method for PID tuning. Basically the method starts by setting the proportional (Kp), integral (Ki) and derivative (Kd) terms to zero, and then slowly increasing the proportional (Kp) term until a ‘stable oscillation condition’ is achieved (Kp = Kc). Then the Ki & Kd terms can be calculated using the following relationships:

Getting to the ‘Kc’ (Kp-critical) value for my setup is a bit more difficult than normal, as the PID engine only operates for a few seconds, from the time the IR homing beacon is detected, to the time the robot actually connects (or doesn’t) to the charging probe. Here’s a short video showing a typical run (Kd = 150 in this case), and an Excel plot of the steering value from the same run.

As can be seen from the above, there really isn’t much of an ‘oscillation’ to go on – there is basically only one full cycle from about 10.5 sec to around 12.0 sec.

Here’s another run, this time with Kd set to 200. As can be seen, this is much more like what I was expecting to see, with several full cycles of oscillation. The amplitude trails off a bit toward the end, but this may have been due to a low battery level – I’ll have to repeat this experiment after getting a full charge into the robot.

Kp = 200, Kd = Ki = 0. Period is approximately 1.3 sec

However, using the above data with Kc = 200, we get

I revised my program to incorporate the Z-N numbers from the above calculations, and this resulted in the homing runs shown below; in the first one, Wall-E2 was oriented directly at the charging station beacon, and the robot’s track was pretty much direct, with no side-side oscillation at all. In the second one I oriented the robot a bit off-axis to excite a more active homing response. In both runs, the LEDs on the rear of the robot show the current relative wheel speed commands – LED’s to the left of center indicate higher wheel speed on the left, and vice versa. In the first run, the LEDs show that there is some oscillation of wheel speed commands, but it is relatively small, leading to an almost serene homing performance. In the second run the initial orientation offset forces the robot to more actively manage the wheel speeds to stay ‘on the beam’.

Stay tuned,

Frank

Charging Station Initial Approach Algorithm Improvement

Leave a reply

Posted 20 March, 2021

In order to realize my long-term goal of a fully autonomous wall-following robot, Wall-E2 has to be able to reliably mate to its charging station when it gets low on go-juice. Unfortunately, Wall-E2 occasionally fails to mate properly, usually due to an initial misalignment with the center of the IR homing beam. I haven’t worried too much about this, as there have been more pressing problems, but as these have been solved, the mating problem has risen to the top of the to-do list.

The basic geometry for the charging station is shown below:

Tilted gate option. The tilt decreases the minimum required IR beam capture distance from about 1.7m to about 1.0m

As long as the robot starts its approach on or near the boresight of the IR beam, all goes swimmingly. However, if Wall-E2 detects the IR beam while tracking the wall at right angles to the one depicted above, it can easily start its approach before getting to the center of the beam, resulting in it getting stuck on the outside guide-in rail (upper rail in the above diagram). In addition, if Wall-E2 is tracking too close to the wall above, it can actually get stuck on the inside guide-in rail (lower rail in the above diagram).

So, what is needed here is a way to force the robot to line up on the IR beam centerline before committing to the mating approach. To investigate this, I created a part-task version of Wall-E2’s operating system that does just one thing; it detects the IR homing signal, and then takes action to position itself in the center of the IR homing beam, aligned with the beam’s boresight. In the aviation instrument (blind) flying world, this is known as the ‘IAP’ (Initial Approach Point), so I needed to create an algorithm so Wall-E2 could navigate to the Charging Station IAP, and start it’s final approach from the same place every time.

In previous work I have gotten Wall-E2 smart enough to track walls at a constant offset. so this is where I started with the current effort. When Wall-E2 starts to track a wall, the first thing it does is use the near-side array of VL53L0X IR laser TOF sensors to orient parallel to the wall, without regard to the absolute offset. It then angles toward or away from the wall to achieve tracking at the desired offset.

The starting position for the current effort is with the robot placed close to the wall leading to the charging station, pointed generally toward the charging station. When the robot wakes up, it sees that there is an active IR homing beacon, and takes action to navigate to the IAP.

  • First it uses the parallel orientation algorithm to align itself parallel to the near wall so it can measure it’s offset from the wall, and also to ensure that the front distance measurement accurately reflects the distance from the robot to the charging station.
  • Next, it compares the wall offset and front distance measurements to the known values for the IAP, i.e. a 50 cm offset at a distance of 180 cm. It then calculates how much additional offset it needs to place itself in the center of the beam.
  • If necessary, the robot turns 90º away from the wall and moves away to achieve the desired offset. If the robot is already far enough away from the wall, it skips this step
  • After getting far enough away, the robot turns in place (a ‘Spin Turn’) until the signal strength of the received IR homing beacon rises above a set threshold. This gets the robot oriented generally in the direction of the charging station
  • The last step is to fine-tune the robot’s orientation so that it is centered in the beam and also well aligned with the beam boresight.

The following photograph shows the robot at the IAP, ready to start the final approach to the charging station.

Wall-E2 at the Initial Approach Point, ready to start the final approach to the charging station.

And the following video shows the entire process, up to the point where the robot would actually start the final approach.

15 April 2021 Update:

One of the issues with the current initial approach algorithm is the lack of accuracy in achieving the desired wall offset, due to Wall-E2’s tendency to ‘coast’ past the desired distance. I could just lower the offset target by a fixed amount to account for the ‘coast’ effect, but since that changes significantly depending on whether Wall-E2 is on carpet or hard flooring, that doesn’t sound like a good ide.

Instead, I decided to use yet another PID object to manage offset distance acquisition, using the following algorithm:

Using this code, I got the following output:

And a short video showing the offset acquisition process:

Here’s the same process, but starting from farther away than desired

21 April 21 Update:

After some additional work on the initial approach algorithm, I arrived at a pretty nice spot; Wall-E2 will reliably detect the IR homing beacon, offset the proper amount from the wall using a 90º turn and a PID engine-driven rear-distance controlled movement, and then rotate to orient to the IR beam boresight. The ‘rotate-to-boresight’ operation takes place in two stages. In the first stage, the robot turns toward the beacon in 10deg steps until the beacon is re-acquired (this is necessary because the robot loses the beam signal when it turns 90º to the wall) and then uses another PID-driven algorithm to center up on the beam boresight. Here’s a short video showing the process.

IR Homing with Initial Approach Phase added. 2-sec pauses are inserted to delineate sub-phases

As can be seen from the above video, the robot successfully navigates to the initial approach point (IAP), rotates to orient with the homing beacon boresight, and then homes to the charging station. This all works, but it is pretty clunky and inelegant. The initial 90º turn away from the wall is in itself a bit problematic, as it can easily overshoot, and then the robot loses the beacon signal, which means that after the appropriate wall offset has been reached, the robot has to turn back toward the charging station to re-acquire the signal, and it has to do so ‘gently’ so as not to overshoot.

I think it would be much better if the initial turn away from the wall was just 45º so the robot won’t lose the beacon signal while navigating to the IAP, and potentially eliminating the first part of the ‘rotate to boresight’ phase. Here is the relevant geometry:

Charging station initial approach and homing geometry

In the above figure, the robot currently makes a 90º utilizes the line labelled ‘Offset =…’ to offset out to the IR beam boresight. I’m thinking that the line labelled ‘x = …’ would work better, as the robot only has to make a 45º turn initially, and then the robot might not lose the beam signal as it offsets out to the IR boresight line. Here’s the supporting math.

Initial Approach Point math

In the above figure, an example is worked out for d = 120cm, where the perpendicular offset is found to be 34.4cm and the 45º turn distance is found to be 1.09*Offset = 37.8cm.

23 April 2021 Update:

The change from 90º to 45º IAP approach angle turned out to be pretty easy to do – really just a matter of changing ‘SpinTurn(90)’ ‘SpinTurn(45)’ and the offset value to 1.09 x offset. Here’s a short video showing the result.

After a few more runs (with some failures due to the robot hanging up on the outside rail), I realized my basic beam geometry estimate was significantly off. Instead of a beam angle of about 16deg, it was more like 11, yielding a distance::offset ratio of about 0.18 instead of 0.27. Revising the program to use the more accurate ratio resulted in the following much nicer homing run.

Homing run using a distance::offset ratio of 0.18 vs 0.27

And here is the telemetry from the run:

Much nicer!

Stay tuned!

Frank

Wall-E2 Charging Station Update

Leave a reply

Posted 17 January 2021,

While doing some ‘local sandbox’ testing with Wall-E2, I noticed that the charging station transmitter was occasionally going offline, even though I hadn’t done anything. After a while I was able to confirm that it simply shut down at some point, for some unknown reason.

After troubleshooting the problem for a bit, I came to realize that the shutdowns were being caused by the NTE960 5V LDO regulator going into over-temp shutdown. Here’s the circuit diagram for the charging station, with the NTE960 highlighted:

After puzzling over this for a bit, I realized why the regulator was going into thermal shutdown. I had stupidly routed the IR LED current through the regulator, so the regulator instead of supplying just the current to the Teensy processor, also had to handle the approximately 1A pulsed IR LED current — oops!

In my defense, this wasn’t actually as stupid as it looks now; the original system design used a 5V power supply to both charge the robot’s battery pack and run the Teensy, so there was no need for a regulator in the system. Later on, the system design changed to use the TP5100 charger, so now the charging station had to supply 12V to the TP5100 and 5V to the Teensy. Adding the 12V supply and the regulator was a non-trivial change to the existing charging station layout, and it just turned out to be MUCH easier to simply place the regulator in-line with the existing +5V power connection, which incidentally also powered the IR LED stack. This worked fine, until I started doing longer runs in my sandbox, giving the regulator more time to heat up and go into thermal overload – oops again.

So, what to do? Well, the obvious answer was to power the IR LED stack directly from 12V. This wouldn’t change the power budget for the 12V supply at all, but would dramatically reduce the power handling requirement for the regulator. However, the current 5Ω 5W current limiting resistor would have to be changed to a 10Ω 10W resistor as it would now be dropping 10V instead of 5V, at the same current. In addition, the current setup had the voltage regulator on a separate terminal strip on one side of the charging station and the IR LED modulation circuit on the other, as shown below.

Teensy 3.2 and IR LED modulation circuitry on left, 12-to-5V regulator on the right

Rather than split the two again, I decided to see if I could put all the circuitry on the left side, next to the Teensy. To do this, I started with two Bakelite terminal strips. In case you aren’t more than about 50 years old, you probably have never seen real Bakelite terminal strips, but they are perfect for this sort of thing. I got mine from a company that specializes in antique electronic items. Here’s a photo of the two-strip layout I devised to accommodate both the regulator and the IR LED modulation circuitry.

Two terminal strips ganged together to accommodate the regulator and the modulation circuitry

First I revised the circuit to bypass the 5V regulator for everything but the Teensy processor, and changed the current limiting resister from 5Ω to 10Ω. When I tested this, everything worked OK, except when I disconnected the modulation signal output from the Teensy to the modulation circuit. To my horror, the IR LED stayed ON! The input to the base of the 2N3904 was pulled low by the 10K pulldown resistor, turning it OFF, which turned the IRF520 MOSFET ON – oops! This was a problem with the original circuit – I had just never noticed it before. This is not a particularly disastrous situation, as the 12V power supply can handle the current, as can the MOSFET and the IR LED’s. However, it just isn’t very good engineering, so I decided to change the 10K resistor to be a pullup rather than a pulldown. As it turns out, this works fine, except now I couldn’t turn the IR LEDs on at all! Some more head-scratching and I figured out that in the pullup configuration, I had formed a voltage divider with the 1K current limiting resistor from the Teensy, and now the LOW signal from the Teensy was being converted to a (mostly) HIGH signal by the voltage divider. Changing the 10K to 100K solved this problem, and now the IR LEDs stay OFF when the modulation is disconnected, and operates properly when the modulation signal is present – YAY! One last ‘gotcha’; when operating from my lab power supply, the Teensy had a tendency to reset when the circuit first went to full load. I cured this with the addition of a 680 uF cap on the +5V line (actually I found that 10 uF would do, but I had more of the 680’s floating around, so…

Here are some photos showing the modified regulation/modulation control circuit

And a scope photo showing the input modulation (yellow) and the IR LED cathode voltage (green), along with the power supply voltage, current, and power values

Input modulation (yellow), IR LED cathode voltage (green), and Power supply output voltage, current and power

Hopefully this will completely solve the intermittent shutdown problem I was seeing in my sandbox trials – we’ll see!

20 January 2021 Update:

After getting everything running, I set up an experiment with a spare IR sensor mounted about 20cm away from the IR flashlight emitter. As shown below, the scope trace in the background is from the IR transistor on the left, in response to the 520Hz square wave transmitted over the IR path from the charging station. Once I got it set up, I let it run most of the afternoon and overnight. The next morning after almost 24 hours, the setup was chugging along beautifully – YAY!

Scope trace shows IR signal received by IR transistor on left. IR Flashlight and charging station electronics shown on right

28 December 2021 Update:

In the process of bringing up my new Wall-E3 robot, I was testing the IR homing module, and discovered that it wasn’t acting correctly – the values being read from the IR homing module were basically zero, even with the charging station IR transmitter less than one meter away. Troubleshooting, I found that the IR transmitter wasn’t transmitting correctly, which I finally tracked down to a (probably) misplaced connection to the Teensy 3.2 waveform generator. However, in the process of doing that, I also discovered that the driving waveform to the IR emitter had a big spike on one transition, which if not really a system problem, sure looked unprofessional.

So, I started looking at the IR transmit module schematic, and decided it could use some TLC. One problem that leapt out at me was the 01/17/21 mod to force the IR transmitter OFF if the connection to the Teensy was lost. This mod involves a 100K resistor pullup to +12V, which, if the 2N3904 transistor base failed ‘OPEN’ would mean putting +12V into the Teensy – probably not a good thing! So, I changed the circuit to route the 100K pullup to +5V instead of +12V. This still works to force the 2N3904 output LOW, which in turn would force the IRF520 OFF. Teensy digital I/O pins are all 5V tolerant, so this is a much better deal.

Chasing around a bit regarding the big spike on the leading edge of the IR transmit pulse, I found that a 0.01 uF cap on the gate lead of the IRF520 did a nice job of killing the big spike, as shown in the photos below:

  • Big spike on leading edge
  • No capacitor at IRF520 gate

  • No spike
  • 0.01uF cap at IRF gate

With these two modifications, the IR transmit block looks pretty solid. Here’s the updated schematic:

The way that I implemented the IR transmit hardware on two parallel terminal strips looks kind of ugly, so I decided to replace that with a perfboard setup and not think of barfing every time I look at it. Here’s the ‘before’

and here is the ‘after’

While I was in the neighborhood, I also decided to modify the IR Beacon transmit code to force all unused Teensy GPIO pins to a known HIGH or LOW state in setup(). This is something I learned about just recently in the Teensy forum, and it sounds like a good idea. I think I’ll write a ‘InitAllGPIOPins()’ function that sets ALL pins to a known state, and follow it with just the necessary changes for functionality. From now on, I plan to do this with all my Teensy projects.

Stay tuned,

Frank

Mid-2018 Wall-E2 Project Status

Leave a reply

Posted 26 August 2018

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

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

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

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

Battery and charging subsystem:

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

Drive subsystem (wheels, motors and motor drivers):

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

 IR homing subsystem for charging station:

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

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

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

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

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

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

 

Operating system:

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

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

 

 

Future Work Plans:

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

Complete the implementation of the fixed charging station.

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

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

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

Charging Station Voltage Change From +5 to +12V

Leave a reply

Posted 22 March 2018

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

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

The original Teensy 3.2 side

The original 5V charging station layout, rear view

The new +12 to +5V regulator side

Updated charging station assembly, rear view

 

The operation was a success, but …

1 Reply

Posted 21 February 2018

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

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

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

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

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

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

7.4V 7200mAh battery pack wired directly into robot power

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

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

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

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

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

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

Stay tuned!

 

A New Chassis For Wall-E2, Part II

Leave a reply

Posted 17 November 2017

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

Second Deck Sensors:

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

IR Homing Module:

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

3D printed spacers for the motor controller PCBs

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

Arduino Mega Processor and Motor Controllers:

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

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

Charging Station Modifications:

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

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

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

18 November 2017 Update:

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

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

Side view showing the sensor deck in place.

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

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

Stay tuned!

Frank

 

 

 

Adafruit PowerBoost 1000C Charge Termination Threshold

2 Replies

Posted 01 November 2017

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

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

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

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

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

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

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

Re: Powerboost 1000C Charge termination threshold

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

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

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

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

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

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

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

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