Monthly Archives: December 2015

New Battery and Wireless for Wall-E2

Posted 12/22/2015,

As I write this, I’m watching the Space-X video webcast following their historic launch and first stage recovery at Cape Canaveral.  I am absolutely ecstatic that someone (in this case Elon Musk and Space-X) finally got a clue and got past the “throw everything away” mentality of previous generations.  Also, as  a retired civil servant, I am more than a little embarrassed that our great and mighty U.S. Government, with its immense resources couldn’t get its collective head out of it’s collective ass and instead gets its ass handed to it by Elon Musk and Space-X.  I’m sure for Elon this was just another day in his special toy factory, but it was a great day for U.S. entrepreneurship and individual initiative, and just another shameful lapse for our vaunted U.S. Government space ‘program’.

OK, so much for my ranting :-).  The reason for this post is to describe two major upgrades to the Wall-E2 4WD robot; a new, more powerful battery pack, and the addition of a Pololu Wixel wireless link to the robot.

New Battery Pack:

For Wall-E1 I used a pair of 2000maH Li-Po cells from Sparkfun, coupled with their basic charger modules and a relay to form a 7.4V stack.  This worked fine for the 2-motor Wall-E1, but I started having problems when I used this same configuration for the 4-motor Wall-E2. Apparently, these Li-Po cells incorporate some current limiting technology that disconnects a cell when it senses an over-current situation.  Although I’m not sure, I suspect they are using something like a solid-state polyfuse, which transitions from a low resistance state to a high resistance state when it gets too hot. When this happens, it can take several minutes for the polyfuse to cool back down to the point where it transitions back to the low resistance state.  I discovered this when Wall-E2 started shutting down for no apparent reason, and voltage measurements showed my 2-cell stack was only producing 3.5V or so, i.e. just one cell instead of two :-(.  At first I thought this was a wiring or relay (I use a relay to switch the cells from series to parallel configuration for charging) problem, but I couldn’t find anything wrong, and by the time I had everything opened up to troubleshoot, the problem would go away!  After two or three iterations of this routine, I finally got a clue and was able to observe the battery voltage transition from 3.5V or so back to the normal 7.4V, all without any intervention from me.  Apparently the additional current required to drive all 4 motors was occasionally exceeding the internal current trip point on at least one of the cells – oops!

So, I started looking for a Li-Po battery pack without the too-low peak current limitation, and immediately ran into lots of information on battery packs for RC cars and aircraft. These jewels have abou the same AH rating as my current cells, but have peak current ratings in the 20-40C range – just what I was looking for.  Now all I had to do was to find a pack that would fit in/on my robot, without looking like a hermit crab carrying a shell around.  I eventually settled on the GForce 30C 2200mAh 2S 7.4V LiPO from Value Hobby, as shown in the following screenshot.

New battery pack for Wall-E2

New battery pack for Wall-E2

This pack is quite a bit larger (102mm X 34mm X 16mm) than the original 2000mAH cells from Sparkfun, and also requires a different (and much more expensive) charger.  At first I thought I would have to mount this monster on the top of the top deck, as shown below,

Original mounting idea for the new battery

Original mounting idea for the new battery

but then I figured out that I could actually mount it on the underside of the top deck, leaving the top deck area available for other stuff (in case one of the cats decides to take a ride), as shown in the next two photos.

under-deck mounting, looking from rear of robot

under-deck mounting, looking from rear of robot

under-deck mounting, looking from side of robot

under-deck mounting, looking from side of robot

After getting the battery pack mounted, I removed the existing battery pack and associated wiring from the motor compartment, and spliced in the new battery wiring through the existing power switch, as shown below (the power switch is shown at the extreme right side of the photo. The red wire is from the battery + terminal, and the black wire from the battery was spliced into the existing ground wire.

Empty battery compartment showing new battery wiring at front

Empty battery compartment showing new battery wiring at front

Pololu Wixel Wireless Link:

As I continued to improve Wall-E2’s wall following ability, I became more and more frustrated with my limited ability to see what Wall-E2 was ‘seeing’ as it navigated around my house.  When ‘field’ testing, I would follow it around observing it’s behavior, but then I would have to imagine how the observed behavior related to the navigation code.  Alternatively, I could bench test the robot with it tethered to my PC so I could see debugging printouts, but this wasn’t at all realistic.  What I really needed was a way for Wall-E2 to wirelessly report selected sensor and programming parameters during field testing.  A couple of years ago I had purchased a pair of Wixels from Pololu for another project, but that project died before I got around to actually deploying them.  However, I never throw anything away, so I still had them hanging around – somewhere.  A search of my various parts bins yielded not only the pair of Wixels, but also a Wixel ‘shield’ kit for Arduino microcontollers – bonus points!!

After re-educating myself on all things Wixel, and getting (with the help of the folks on the Pololu support forum) the Wixel Configuration Utility installed and running, and after assembling the Wixel shield kit, I was able to implement a wireless link from my PC to the Arduino on the robot.  Pololu has a bunch of canned Wixel apps, and one of them does everything required to simulate a hard-wired USB cable connection the robot – very nice!! And, the Wixel shield kit comes with surface-mounted resistive voltage dividers for converting the 5V Arduino Tx signals to 3.3V Wixel Rx levels, and a dual-FET non-inverting upconverter to convert 3.3V Wixel Tx signals to 5V Arduino Rx levels – double nice!  Even better, the entire thing plugs into the existing Arduino header layout, for a no-brainer (meaning even I would have trouble getting it wrong) installation, as shown in the following photo.

Wixel shield mounted on top of Arduino 'Mega' micro-controller

Wixel shield mounted on top of Arduino ‘Mega’ micro-controller

After getting everything installed and working, it was time to try it out.  I modified Wall-E2’s code to print out a timestamp along with all the other parameters, so I could match Wall-E2’s internal parameter reporting with the timeline of the video recording of Wall-E’s behavior, and this turned out to work fantastically well.  The only problem I had was the limited range provided by the Wixel pair, but I solved that by putting my laptop (with the ‘local’ Wixel attached) on my kitchen counter, approximately in the middle of my ‘field’ test range.  Then I set Wall-E2 loose and video’d its behavior, and later matched the video timeline with the parameter reports from the robot.  I found that the two timelines weren’t exactly synched up, but they were within a second or two – close enough so that I could easily match observed behavior changes with corresponding shifts in measured parameters.  Here’s a video of a recent test, followed by selected excerpts from the parameter log.

The video starts off with a straight wall-following section, and then at about 10 seconds Wall-E2 encounters the door to the pantry, which is oriented at about 45 degrees to the direction of travel.  When I looked at the telemetry from WallE2, I found the following section starting at 11.35 seconds after motor start:

Time Left Right Front Tracking Variance Left Spd RightSpd
11.46 21 200 400 Left 474 90 215
11.51 21 200 63 Left 475 90 215
11.56 21 200 400 Left 435 90 215
—- Starting Stepturn with bIsTrackingLeft = 1
11.60 21 200 56 Left 476 255 50
11.65 20 200 53 Left 525 255 50
11.71 20 200 52 Left 589 255 50
11.76 20 200 53 Left 640 255 50
11.81 20 200 52 Left 692 255 50

[deleted section]
12.31 26 200 53 Left 1107 255 50
12.35 24 200 55 Left 1136 255 50
12.40 23 200 61 Left 1155 255 50
12.46 23 200 99 Left 1151 175 130
12.51 22 200 188 Left 1320 215 90

The lines in green are ‘normal navigation lines, showing that Wall-E2 is tracking a wall to its left, about 20-21 cm away (the first value after the timestamp), and is doing a good job keeping this distance constant.  It is more than 200cm away from anything on its right, and the distance to any forward obstruction is varying between 400+ (this value is truncated to 400cm) and 63 cm (this variation is due to Wall-E2’s left/right navigation behavior).

Then between 11.56 and 11.60 sec, Wall-E2 detects the conditions for a ‘step-turn’, namely a front distance measurement less than about 60 cm (note the front distance of 56 cm – third value after the timestamp).  The ‘step-turn’ behavior is to apply full power to the motors on the same side as the wall being tracked, and slow the outside motors, until the front distance goes back above 60cm.  The telemetry and the video shows that Wall-E2 successfully executes this maneuver for about 1 second, before the front-mounted LIDAR starts ‘seeing’ beyond the pantry door into the hallway behind, as shown by the pointing laser ‘dot’.

Similarly, at about 28 seconds on the video, Wall-E2 gets stuck on the dreaded furry slippers (bane of Wall-E1’s existence), but gets away after a few seconds of spinning its wheels.  From the telemetry shown below, it is clear that Wall-E2’s new-improved ‘stuck’ detection & recovery algorithm is doing it’s job.  The ‘stuck’ detection algorithm computes a running variance of the last 50 LIDAR distance measurements.  During normal operation, this value is quite high, but when Wall-E2 gets stuck, the LIDAR measurements become static, and the computed variance rapidly decreases.  When the variance value falls below an adjustable threshold (currently set at 4), a ‘stuck condition’ is declared, and the robot backs up and turns away from the nearest wall.  As you can see from the telemetry excerpt below, this is precisely what happens when Wall-E2 gets stuck on ‘the slippers from hell’.  In the excerpt below, I have highlighted the calculated variance values.

30.96 77 26 26 Left 99 255 50
31.01 77 27 27 Left 88
31.36 77 27 26 Lef
31.51 77 28 22 Left 21 255 50
31.56 77 28 23 Left 18 255 50
31.61 77 26 25 Left 14 255 50
31.67 76 27 26
31.71 76 26 27 Left 9 255 50
31.76 76 27 25 Left 6 255 50
31.81 76 27 26 Left 5 255 50
———- Stuck Condition Detected!!———–
31.86 77 26 28 Left 4 127 127
34.13 61 200 117 Left 167 255 50
34.18 62 200 118 Left 325 215 90

This ‘field’ trial lasted less than two minutes, but the combination of the timestamped video and the timestamped telemetry log allowed me a much better understanding of how well (or poorly) Wall-E’s navigation and obstacle-avoidance algorithms were functioning.  Moreover, now that I can record and save video/telemetry pairs, I can more precisely assess the effects of future algorithm developments (like maybe the addition of PID-based wall following).

So, the combination of the new battery pack and the Wixel wireless link has given Wall-E2 some new super-powers.  It can now drive around with much greater energy, and it can now tell it’s human masters what it is thinking while it goes about its work – doesn’t get much better than that!

Stay tuned!

Frank

 

Glass Print Bed for Printrbot Simple Metal – Part V

Posted 12/17/15

In my last post on this subject I described my (ultimately successful) efforts to level my new glass print bed and disable Printrbot’s ‘auto leveling’ feature so I could get decent prints everywhere on my print bed.

During this project I had been posting results and questions on the ‘PrintrbotTalk’ forum (see this post), and one responder suggested the use of a cheap dial indicator from Harbor Freight to level the bed, independent of Printrbot’s Z-axis probe.  After some initial missteps I was able to get one (item #623 on Harbor Freight’s website) and figure out a way to mount it on the extruder carriage. The following photos show the mounting arrangement, using the handy mounting tab on the back of the dial indicator.

Dial indicator mounted to the extruder carriage. Note ground-down portion of the carriage .

Dial indicator mounted to the extruder carriage. Note ground-down portion of the carriage .

1/4" by 1/4" bushing fit nicely inside the 1/4" I.D. mounting hole.

1/4″ by 1/4″ bushing fit nicely inside the 1/4″ I.D. mounting hole.

Dial indicator mounting tab and mounting screw/bushing

Dial indicator mounting tab and mounting screw/bushing

Dial indicator mounted, with carriage height adjusted to achieve a zero reading

Dial indicator mounted, with carriage height adjusted to achieve a zero reading

With this arrangement, I was able to simply move the carriage around by hand, noting the needle excursions from zero.  Then painter’s tape was added to the low side (or removed from the high side) to minimize the differential across the printing area.  A 1mm height difference equates to about 40 small divisions on the indicator, and after shimming I was able to achieve a height differential of  +/- 5 small divisions (about 0.125mm) across the print area.

After getting the glass plate all shimmed up, I decided that because I was no longer using the ‘auto-leveling’ (actually more like ’tilt correction’) feature, I could now remove the copper foil layer from beneath the painter’s tape – BIG MISTAKE!!  On the very first test print after doing this, I realized to my horror that the Printrbot still needed to find the Z-axis ‘home’ position, and the only way to do that was with the Z-axis metal-sensing probe.  Fortunately I was able to pull the power plug before the extruder tip had a chance to shatter my nice new glass plate!

After beating myself up for a while over such a bonehead move, I realized I had just two choices; I could laboriously replace the copper foil layer (one quarter-inch strip at a time), or I would have to find some way of replacing the metal-sensing probe with something else.  I did not want to go through the agony of replacing the foil layer, so I was left (I thought) with option 2.  Someone on PrinterbotTalk had mentioned a mechanical switch replacement for the Z-axis probe, and said there was at least one Thingiverse design for a bracket that mounted to one of the vertical carriage posts.  I took a look at this and decided I could adapt it for one of the normally-open pushbutton switches I had in my electronics parts bins.  After some further Googling, I realized that the replacement project might be a bit more involved than I originally thought, as there was an issue with later rev motherboards requiring a pullup resistor and some extra wiring to make the mechanical switch idea work.

Then I had an uncharacteristically brilliant idea, if I do say so myself.  Rather than removing the Z-axis probe and replacing it with a mechanical switch mounted on the vertical slide assembly, why not combine the two ideas and simply mount the Z-axis probe itself on the vertical slide assembly?  Then I get the best of both worlds – I don’t have to screw with the wiring at all, and the metal carriage base is perfect for the Z-axis probe to sense – voila!

Looking around a bit, I found that if I mounted the probe on the rear vertical slide post bushing, it would have a clear shot at a nice, flat open spot on the carriage base.  All I needed was a right-angle bracket to attach the probe to the bushing.  A few minutes in TinkerCad produced a printable design, and after a few minutes more I had the bracket printed up (I had to fake the Z-home a bit to get the bracket printed, but who’s counting).  I super-glued the bracket to the slide bushing as shown in the following photo, and simply adjusted the height of the probe in the bracket so the extruder just ‘grabbed’ a sheet of printer paper when the Z axis was ‘homed’.

Z-axis probe relocated to the rear vertical post bushing

Z-axis probe relocated to the rear vertical post bushing

OK, so now I have a really cool glass print bed, with no ugly copper foil layer, and the Printerbot is no longer trying to murder my glass plate.   I’ve only done a couple of test prints so far, mostly to figure out what M212 offset is required now with all the changes.  However, I am looking forward to consistent prints with the new setup.

Stay tuned!

Frank

 

 

Wall Following Tests with the New 4WD Robot

Posted 12/14/15

After a bit of a hiatus, I finally got around to some basic wall-following tests with the new 4WD robot (aka ‘Wall-E2’), and they seemed to go fairly well, with of course the normal number of screw-ups and minor disasters.  As the wife and I were planning weekend with the kids & grand-kids in St. Louis, and one of the grand-kids was also my fellow robot-master, I decided to take Wall-E2 along so he could strut his stuff in a different environment.  While we were there, we got in lots of kitchen/dining room testing (turns out the breakfast room at their place has a wall layout just about perfect for the testing we were doing).  During the testing, we ran down and killed off at least one significant, but very subtle bug (guess what happens when you send -15 to the 8-bit Arduino D/A) in the motor driver routines, so that was real progress, and we also investigated a couple of advanced ‘pre-turn’ algorithms that showed promise for more natural wall-to-wall intersection navigation.  All in all we had a great time, and Danny got to see (and influence!) the current state-of-play for the 4WD robot.

After returning home, I decided to try and document Wall-E2’s behavior with and without the new pre-turn algorithm, as a prelude to investigating modifications that might retain the advantages of the pre-turn algorithm while avoiding some of the problems we discovered.  So, I made the two short videos shown below. The first video shows Wall-E2’s baseline behavior, without the pre-turn maneuver enabled, and the second one shows the same situation, but with the pre-turn maneuver enabled.

 

 

In ‘normal’ operation, as shown in the first video above, Wall-E2 has a very simple instruction set.  Follow the closest wall until it hits something.  When an obstruction is encountered, it backs up, turns away from the closest wall, and then parties on.   The idea of the ‘pre-turn’ is to give Wall-E2 more natural wall intersection behavior; instead of waiting until it hits the wall to react, the pre-turn maneuver anticipates the upcoming wall and makes the turn early.  If done correctly, Wall-E2 should be able to navigate most wall-wall intersections, as shown in the second video above.

While this works great in the above situation, we discovered some significant ‘gotchas’ with this algorithm while testing it in Danny’s breakfast nook/Wall-E2 test range.  Correct execution of the pre-turn maneuver assumes that Wall-E2 will be following the closest wall when the upcoming wall (the one on the other side of the upcoming corner) gets into the trigger window, but in several of our tests, Wall-E2 turned the wrong way, into the wall it was following instead of away from it.  Upon closer observation we discovered this was due to Wall-E2 going by a nearby table leg at just the right distance from the upcoming wall.  Just as Wall-E2 got into the trigger window, it switched control from the wall on the left to the table leg on the right, because (at that exact instance, Wall-E2 was closer to the table leg than it was to the wall. And, because in the pre-turn maneuver Wall-E2 is programmed to turn away from the followed (i.e. closest) wall, it dutifully turned away from the table leg – and smack into the wall – oops!

Another major gotcha with the current algorithm is that the pre-turn maneuver is executed in the foreground, so nothing else can happen at the same time.  In particular, no sensor measurements are taking place, so the duration and/or magnitude of the turn can’t be adjusted (extended or truncated) based on the actual corner geometry.

So, although the pre-turn maneuver works great when it works, and it works most of the time, it has real problems in even mildly cluttered environments, and creates a 1-2 second ‘blind spot’ for the sensors.  We may be able to use filtering/averaging to handle clutter, and we may be able to segment the pre-turn maneuver sufficiently so that it can be adjusted on-the-fly to accommodate different corner geometries – we’ll see.

Stay tuned!

Frank