Yearly Archives: 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

 

 

 

Glass Print Bed for Printrbot Simple Metal – Part IV

Posted 11/25/2015

In my last episode of “The Perils of Pauline” (aka Printrbot Simple Metal Glass Print Bed Issues), I described a set of measurements and print tests that ultimately led exactly nowhere, except maybe to the conclusion that Printrbot’s vaunted ‘Auto-leveling’ (more accurately ‘bed tilt correction’) wasn’t all that effective, and might even be part of the problem rather than part of the solution.

So, in this episode, I decided to manually level the glass print bed with painter’s tape shims, to see if I could get better prints that way.  To do this, I used the existing Z-axis probe, the G29 ‘auto-level’ command, and the G30 ‘Z-axis probe here’ command.  The G29 command tells the Printrbot to probe the Z-axis at three pre-configured points ( (10, 150), (10,10) and (150,10) in my case), and the G30 command tells it to probe the Z-axis wherever it happens to be (I used this to probe the bed at (150,10) – the rear right corner).  Between these two commands, I could measure the print bed surface height at all 4 corners and adjust accordingly.

From previous measurements I knew that the bed tilted upwards from the rear to the front, and from left to right.  Therefore I started out by moving the single layer tape shim from the front edge, and adding a single layer shim along the left edge.  After three or four iterations, I wound up with two tape layers on the left and rear edges, and the resulting probe measurements were within 0.2mm everywhere. It’s hard to get much closer than that, due to variations in the probe results.

Initial painter's tape shim layout

Initial painter’s tape shim layout

After getting the bed as level as I could, I ran another set of test prints.  As shown in the photo below, all 5 positions printed successfully.  I also noticed that the Z-axis worm gear moved noticeably less during print operations, providing an additional indication that the print bed was in fact pretty darned level.

 

All positions printed successfully

All positions printed successfully, although the front right (Position 5) print was very lightly attached

When I removed the test prints from the bed, I noticed that the near-right (Position 5) print was less well attached than the others, and in fact the attachment quality improved as I went from Position 5 to 4 and then to 3.  Positions 3, 2, and 1 (all in the same vertical line) seemed to all be nicely attached.  So, the actual print results indicate that the extruder tip is getting farther away from the print bed as it progresses to the right, but the Z-axis probe measurements indicate the exact opposite situation – the print bed actually gets higher as it goes from left to right!  How can this be?  Well, based on everything I have learned to date, I now strongly suspect that the answer is that the tilt correction algorithm is correcting the wrong way somehow.  Maybe the fact that the Printrbot’s ‘home’ position is at (Xmin, Ymax) rather than (Xmin, Ymin) is causing a sign error somewhere, and this is causing the Printrbot to correct the Z-axis up for movements in the positive X and negative Y directions when it should be correcting it down.  This theory tracks with what I have experienced so far, as it would imply that the closer I can get the plate to absolute level, the smaller the error would be, ultimately going to zero error for a perfectly flat plate. Of course, if I’m right, I should be able to somehow track down and correct this sign issue, and therefore convert what is now a force for evil into a force for good – arggghhhh!!!!

Late addition:  After posting this to the ‘Printrbot Talk’ forum, I got a note from ‘Retiree Jay’ to the effect that I could disable the tilt correction function entirely by omitting the ‘G29’ command from the startup script, leaving only the ‘G28 X0 Y0 Z0’ command. So, I did this and ran another series of test prints as shown in the following photo.  As you can see, all prints were successful, even the added Position at the right rear of the print bed.  And even better, Retiree Jay was correct in that the Z-axis motor did not run at all (up or down) during prints of a specific layer (since I printed only one layer for each position, this means that the Z-axis motor didn’t run at all during the entire print series.  This pretty much proves that my new glass plate is flat across the entire print area; “Tilt Correction?  We don’t need no stinkin Tilt Correction!” ;-))

Print series with tilt correction disabled.  "Tilt Correction?  We don't need no stinkin Tilt Correction!"

Print series with tilt correction disabled. “Tilt Correction? We don’t need no stinkin Tilt Correction!”

Stay tuned,

Frank

 

 

Glass Print Bed for Printrbot Simple Metal – Part III

Posted 11/24/2015

A few days ago I posted a long account of my attempt to add a glass plate printing surface to my Printrbot Simple Metal, to address printing problems due to non-planar warping issues with the original print bed.  As described in the post, I was able to satisfy myself that the glass plate was much flatter than the original bed, but I still couldn’t get consistent prints except in a very small area – printing the same part at the same Z-axis offset resulted in either a print that wouldn’t adhere, or gouges in the painter’s tape.  My conclusion at the time was that maybe the vaunted ‘auto-leveling’ feature (actually just 3-point tilt correction) has been inadvertently disabled in my firmware version, or maybe it wasn’t ever functional in the first place.

So, in this post I describe my efforts to manually level the glass plate print bed.  Based on the results from the previous post, I know that the bed must slope downward from the back to the front, as the print was more or less OK at the back, but became separated from the bed as the print positions progressed toward the front.  So, I put down a layer of painter’s tape underneath the glass plate at the front edge of the original print bed, and then ran the same series of prints, starting at the rear right corner as before.

The following two photos show the painter’s tape shim installation

Painter's tape shim installation

Painter’s tape shim installation

Painter's tape shim installation

Painter’s tape shim installation

With this setup, I started by printing the 20mm cal cube at the extreme left rear corner of the print area, what I’m calling ‘Position 1’.  The first print failed partway through when the piece detached from the bed, indicating the Z-axis offset was too high, at Z = -1.1.  This was interesting all by itself, as Z = -1.1 was the offset I used for the entire first experiment a few days ago; I speculate that the addition of the painter’s tape shim may have lowered the plate very slightly at the back corner.  I changed the offset to Z = -1.2, and this gave me a good Position 1 print, as shown below.

Position 1 print with Z = -1.1. Note the detachment

Position 1 print with Z = -1.1. Note the detachment

Position 1 print with Z = -1.2

Position 1 print with Z = -1.2

Then I moved on to Position 2 (still at extreme left edge, but midway from back to front) and tried again.  As shown in the following photo, I got a good print here as well.

Position 2 print with Z = -1.2

Position 2 print with Z = -1.2

From there I moved on to Position 3 (extreme front left corner of the print area), and Position 4 (front edge, midway from left to right).  As shown in the following photo, I got a very good print at Position 3, but the Position 4 print detached immediately.

Positions 3 and 4. Position 3 printed OK, but Position 4 detached immediately

Positions 3 and 4. Position 3 printed OK, but Position 4 detached immediately

So, it appears at the moment like I have the plate leveled in the front-to-back direction, but not in the left-to-right direction.  Next I’m going to try adding a layer of tape from front to back at the extreme right edge and see what this does.  Note in all this that Printrbot’s ‘Auto-level’ feature should already be compensating, but it appears to be AWOL.

With one layer of tape added, I was still getting very poor results in the X (left to right) direction, so I added a second layer of tape.  After this, I was able to get all 5 prints to stick, although as the photo below shows,  the last two were ‘iffy’

With two layers of tape front to back at the extreme right edge

With two layers of tape front to back at the extreme right edge

So, I added a third layer of tape, and ran another print series, and got almost identical results!  How can this be?  I’ve added three layers of tape, and I’m still not able to print in the near right-hand corner – this just doesn’t make any sense.

OK, the only possible way it could make any sense at all, is if the Printrbot ’tilt-correction’ algorithm IS enabled, but not functioning correctly, either due to the algorithm itself, or due to incorrect Z-axis sensor readings from the probe.  So did another test print, but this time I concentrated solely on the Z-axis servo worm gear.  At first I simply put my fingers on the worm gear so I could feel if there was any Z-axis movement during lateral head moves, and sure-nuff, there was some!  Then I put a painter’s tape ‘flag’ on the worm gear and I can easily see Z-axis movement during even small lateral head moves.  The clear indication is that the tilt-correction algorithm is working, but for prints near the right-hand edge of the print bed, the correction is wrong.  I wonder if the errors are due to scaling based on inaccurate print bed dimensions in the printer setup dialogs; this would seem inconceivable, but what do I know?

On a recent print at the near right edge, with 3 layers of tape, the probe measurements were:

(10,143,1.46), (10,10,1.79), (143,10,2.32)

with the tape removed, the measurements are

(10,143,1.35), (10,10,1.59), (143,10,1.94).

This seems to indicate that positive Z is ‘up’ and that lower positive Z values indicate a surface that is actually closer to the bottom of the printrbot.  This, in turn, should mean that I could achieve what I want by putting tape under the left edge, not the right, even though the print performance indicated just the opposite! Oh, I have a headache!

with the right-edge 3-layer tape shim removed entirely, I re-ran the original test print series.  Instead of the mess I got the first time, printing at all 5 positions succeeded as shown in the following photo – huh?????

All three tape shim layers removed from the right edge

All three tape shim layers removed from the right edge

OK, so this just should not be happening!  When I started this post, with no shimming at all, I could print to position 1, 2 & 3 (along the left edge, from rear to front), but not positions 4 or 5 (along the front edge, from left to right).  This behavior is what led me to shim along the right edge, but although I thought I was making the situation better, increasing the shim height from 2 to 3 layers didn’t help at all, and now I find that with no shim layers I get really nice prints at all 5 positions – what gives?

Thinking back through everything I did this evening, I realized there was one thing I did that could maybe have affected the situation – I changed the printer extents via the Repetier ‘Printer Settings’ dialog.  This should not affect tilt correction calculations at all, since the Printrbot already knows the absolute coordinates for all three Z-axis probe points, so why would it care (or even know) what extents have been set in Repetier?

As a test of this wild and zany idea, I set the Y-Max value in Repetier to 350, basically twice what it should be, and set up for another print series.  When the probe results came in, they were:

(10,143,-1.06), (10,10,-0.85), (143,10,-0.5) – whoa!  How can that possibly be?  Clearly there is some coupling from the values set in Repetier’s Printer Settings dialog, but why?

For position 2, the Z-axis probe reports (10,143,1.42), (10,10,1.56), (143,10,1.90)

– Oh, now I have an even bigger headache!  How can this be?  Negative values one time, and positive values the next – with exactly the same hardware and software configuration (including the same – bogus – Y Max value)??

For position 3, I get:  (10,143,1.46), (10,10,1.72), (143,10,2.03) – print was fully successful

For position 4, I get:  (10,143,1.44), (10,10,1.70), (143,10,2.02) – print was successful, but marginal

For position 5, I get:  (10,143,1.44), (10,10,1.71), (143,10,2.02) – print fully successful

All three tape shim layers removed from the right edge

All three tape shim layers removed from the right edge

OK, I give up – I’m officially baffled.  Everything I have done has had either no effect, or an effect opposite to what I expected.  Then returning the experimental setup to its baseline condition did not restore baseline results – WTFO@!!@#$%^&*(

Frank

 

Building up the New 4WD Robot – Part 3

 

Posted 11/22/15

At the conclusion of last month’s episode of “Bringing up Baby” (AKA our new 4WD Robot), my grandson and I had gotten it to the point of doing ‘The Robot Jig’ (a test program to show that all the motors ran in the same direction and at the same speed), but without any sensors or navigation capability.  After Danny went back home I sorta let the 4WD robot out to pasture while I concentrated on reworking Wall-E to remove all the spinning LIDAR stuff and add acoustic sensors.  This effort was pretty successful, so I thought it was now time to add this same capability to the 4WD robot – now christened ‘Wall-E2’.

The plan for adding sensor capability to Wall-E2 was to move the ‘Blue Label’ LIDAR and two acoustic ‘ping’ sensors from Wall-E.  This entailed printing up a new LIDAR bracket (not really necessary, but aesthetically pleasing), and redesigned ping sensor brackets (the retainer latches on the old ones were way too fragile).  For a while I toyed with the idea of discarding the 4WD robot’s ‘upper deck’, but in the end I decided that giving up all that future expansion real estate was just too stupid for words.  However, retaining the second deck brought with it the challenge of managing the inter-deck cabling in a way that allowed the upper deck to be removed for troubleshooting without having to disconnect anything.  IOW, I wanted to be able to run everything on the second deck, while the deck was physically off the robot.  Eventually I decided on a hybrid approach to the cabling issue; I added a terminal strip to the underside of the deck, and ran +5VDC and GND wires to it from the main terminal strip, with inline disconnects.  Then I permanently connected +5 & GND wires to each acoustic sensor, but ran the ping sensor control lines back to the main deck through inline disconnects. The LIDAR cable was run all the way from the LIDAR to the main deck without disconnects, but this was OK because this cable connects to the LIDAR itself via a multipin locking connector.  All the cabling runs have enough slack so that the upper deck can be placed on the bench beside the robot without having to disconnect anything – yay!  The following photos show the disassembled and assembled states of Wall-E2.

Disassembled robot.  Note the inline disconnects on the power/gnd cable and the ping sensor and laser pointer control lines

Disassembled robot. Note the inline disconnects on the power/gnd cable and the ping sensor and laser pointer control lines

Rear view of the assembled robot

Rear view of the assembled robot

Right side view of the assembled robot

Right side view of the assembled robot

Front view of the assembled robot

Front view of the assembled robot

Left front quarter view

Left front quarter view

Left side view

Left side view

So, at the end of this episode, all the mechanical and electrical work has been accomplished, but nothing has been tested yet.  It’s late, so I think I’ll wait until I have more than two neurons to rub together to check things over and test things out.  I have found over time that late-night testing almost invariably leads to next-day wailing and gnashing of teeth 😉

Stay tuned,

Frank

 

 

3D Printed Terminal Strip Cover/LED Bracket

Posted 11/21/15

In the process of building up my 4 wheel drive replacement for Wall-E, I ran across a problem that turned out to be a perfect showcase for the power of home 3D printing.  The problem was what to do with a terminal strip mounted at the rear of the robot chassis, as shown in the photo below.  Interestingly, the terminal strip itself is sort of a story of its own; it is from the bygone era of point-to-point wired electronics, and they aren’t readily available anymore, even though they are perfect for this sort of robotics project.  I had this one left over from some 20-year old project, and when I tried to find a source for re-supply, I almost struck out entirely.  I finally found a source at Surplus Sales of Nebraska – add this one to your bookmarks!

4WD Robot with old-style terminal strip shown at the rear (right side in this photo) of the chassis

4WD Robot with old-style terminal strip shown at the rear (right side in this photo) of the chassis

OK, so the problem is – the terminal strip is great for what it is doing, but now I have Vbatt, +5V, and GND all exposed where an errant wire or screwdriver could cause real problems – what to do?  Moreover, I needed some way of labeling the strip, because I now had two sets of red wires (one from the battery pack, one from regulated +5), and without some obvious and permanent labeling scheme, I was for sure going to screw this up at some point.  Before the recent advent of 3D printing and the ‘maker’ revolution, this would have been a real show-stopper.  I could have maybe found a small plastic box that I could cut down or reform somehow, or milled something fancy from a block of Lexan, but the cut-down box wold be inelegant to say the least, and the fancy milled piece of Lexan would be exorbitantly expensive and time-consuming, even assuming that I got it right the first time (unlikely).  However, now that I have the super-power of 3D printing at my fingertips, I “don’t need no stinking Lexan!”.  All I need is my imagination, TinkerCad, and my PowerSpec 3D Pro dual-extruder printer!

So, using my imagination and TinkerCad, I rapidly sketched out a design for a U-shaped protective shroud for the terminal strip, and printed it out.  Once I had it mounted, I realized that I had only done half the job – literally!  The U-shaped shroud protected the terminal strip from the front, but not from the top – I needed a lid of some sort to finish the job.  Having a lid meant there had to be some way of keeping the lid on, while still being able to easily remove it to make changes to the strip wiring, so I needed some sort of snap-action latching mechanism.  This resulted in the design shown in the following photo.  The U-shaped shroud is shown in blue, with the lid shown in green.  the complementary groves allow the lid to snap onto the trough.

Early version of the power strip cover and lid

Early version of the power strip cover and lid

In another hour or so, I had both parts printed up and mounted on the robot – and it worked great!  However, as often happens when I design and print 3D parts, I immediately saw possibilities for improvements.  The first idea was to incorporate the labeling right into the shroud design, literally.  I have a dual-extruder printer, so that meant that I could put the ‘Vbat’, ‘GND’ and ‘+5’ labels directly into the material, in a contrasting color – cool!  In another hour or so, I had the labels incorporated into the design and another piece printed out, with the result shown below

View showing the bottom part of the two-part cover, with integrated terminal labels

View showing the bottom part of the two-part cover, with integrated terminal labels

Another view of the bottom part of the two-part cover

Another view of the bottom part of the two-part cover

After admiring my work with the integrated labeling, and the way the lid snapped on and off firmly but easily, I had another cool thought.  Wall-E has a set of 4-LED’s mounted at the rear of its chassis, and the software uses these to announce various program states, and I wanted to do the same thing for the new 4WD robot.  However, I had not yet figured out where I was going to put them, and it suddenly occurred to me that I could use my new terminal strip cover as the platform for some readout LED’s – cool!

So, in another hour or so I had yet another version designed and printed out and installed on the robot chassis, as shown in the photos below

 

Inside view of the top part of the two-part terminal strip cover, showing the LED array installation

Inside view of the top part of the two-part terminal strip cover, showing the LED array installation

LED Array/Terminal strip cover snapped onto the bottom half

LED Array/Terminal strip cover snapped onto the bottom half

4WD Robot rear view showing the completed cover/LED array bracket

4WD Robot rear view showing the completed cover/LED array bracket

So, in the space of a day or day-and-a-half, I went through a half-dozen or so design iterations, all the way from initial (incomplete) concept and (wrong) implementation, through several completely unforeseeable concept/idea mutations to a ‘final’ (to the extent that anything is final on one of my projects!) implementation that not only solved the original problem (covering the exposed wiring on the terminal strip, but also implemented integrated labeling AND added a completely new and desirable feature – the LED array bracket.

Although this little project is no great shakes in the grand scheme of things, it does serve to illustrate how the combination of essentially infinite computing power, easy-to-use design tools like TinkerCad, and cheap, capable 3D printing tool availability is revolutionizing the hardware/software development world.  40  years ago when I was a young electronics design engineer, there was a huge gap, in money and time, between a working prototype and a finished production design.  And, once the production process started, changes rapidly became impossible due to the cost and time penalties. So, everybody tried to ‘get it right’ the first time, and many really cool ideas didn’t get incorporated because they occurred too late in the design-production cycle.  Now, many of these constraints no longer apply, at least not for small production volumes; we now able to operate more like the ‘cut-and-try’ generation of the early 20th century.  No need to worry too much about which design alternative(s) is/are better when material costs are negligible and design-fabricate-test cycles are shorter than the time required to do a detailed analysis – just build them all and compare them ‘in the flesh’.

Many years ago when I was an active soaring (full-size glider) pilot, I wrote a book (“Cross Country Soaring With Condor”) about the use of a popular soaring simulator as a competition trainer.  When it came time to get the book published, I did a lot of research and eventually settled on an outfit called ‘DiggyPOD’, where the ‘POD’ stands for ‘Printing On Demand’. These folks had figured out how to eliminate most of the up-front publishing costs that made traditional book publishing inaccessible to all but established authors and professors with guaranteed markets. Consequently, I was able to get my book published in quantities and at prices that allowed me to make a profit selling into a very restrictive niche market.  I think the same sort of thing is now happening in the realm of small volume consumer products.  Not only is it now possible to conceive, design, and implement new products at very low cost and without any costly infrastructure, it is also possible to customize existing products in ways that would have been unimaginable 10 years ago.  For instance, I recently repaired a friend’s bicycle accessory.  This is something that would have been impossible before.  I think this ‘maker’ revolution is going to change our world in ways we can’t even begin to imagine!

Stay tuned,

Frank

 

 

Glass Print Bed for Printrbot Simple Metal – Part II

Posted 11/19/2015

A week or so ago I posted an account of my attempt to add a glass plate to my Printrbot Simple Metal print bed.  I thought I had a great idea – place patches of copper foil tape on top of the glass plate at the three points where the Z-axis probe sensor checks for print bed tilt (it’s called auto-leveling, but it is actually more like auto-tilt correction), and everything should be groovy.  Unfortunately, what I thought would happen and what actually happened were two different things.  It appeared that either tilt correction wasn’t being applied at all, or it was being applied, but in the wrong direction (which doesn’t make any sense either, because I didn’t change anything except adding the glass plate).

So, I decided to make another run at the problem.  My new approach was three-fold; first, I took some time to thoroughly investigate the flatness of the original Printrbot print bed, and the flatness of the glass plate.  Second, I decided to cover the entire glass plate with copper foil, not just the small areas used by the Z-axis sensor.  Third, I figured out a way (the ‘G30’ command) to take Z-axis sensor reading at multiple spots on the print plate, rather than just the 3 points used in normal printing, so I could really determine how well the Z-axis sensor itself behaved.

Printrbot print bed and glass plate flatness investigation:

I used two different techniques to evaluate the flatness of both the original Printerbot print bed and the glass plate addition.  The first technique was to place a light source so that it illuminated the bed from the side, and look for light leakage under a straight-edge placed on the bed.  The second technique was to use a piece of printer paper (approx 0.09 mm thickness) to see if there were any areas where the paper would slide freely under the straight edge.  The photos below show the result for both the original print bed and the glass plate.  The first image shows the setup, with an LED flashlight placed so it shines light parallel to the surface, with a steel straight-edge blocking the beam except where the bed is warped.  Subsequent photos show warped areas.

151119 PrintrbotBed1

Flashlight shining along surface of print bed, with steel straight-edge blocking light except where the bed is warped.

151119 PrintrbotBed8 151119 PrintrbotBed7 151119 PrintrbotBed6 151119 PrintrbotBed5 151119 PrintrbotBed4 151119 PrintrbotBed3 151119 PrintrbotBed2

 

Next I did the same thing with the glass plate, as shown in the following images.

151119 GlassPlate8 151119 GlassPlate5 151119 GlassPlate6 151119 GlassPlate7

The glass plate is clearly much flatter than the original print bed.  I verified this using the paper technique – I was able to easily slide a piece of 0.09 mm paper under the straight-edge on the original print bed, but not on the glass plate.  So, as far as flatness is concerned, the glass plate is a clear winner.

Z-Axis Probe Measurements

Since I was now convinced that the glass plate was much flatter than the original print bed, this issue could not be the reason I was having so much trouble trying to get reliable prints at different points on the print bed.  So, I turned my attention to the only other possible factor, the Z-axis probe itself.  If it was somehow producing aberrant readings, maybe that would explain why the Z-axis offset required for printing at the near right corner was wildly inappropriate for the same print in the back left corner.  To acquire the data I made use of the G-code ‘G30’ command, which causes a Z-axis probe operation at the current X/Y location.  I recorded Z-axis probe readings at 12 locations on the glass plate, and plotted the results using Excel’s ‘Surface’ plot feature

Z-axis probe sensor readings for glass plate

Z-axis probe sensor readings for glass plate

11/20/15 Glass Plate Z-axis probe sensor results

11/20/15 Glass Plate Z-axis probe sensor results

As can be seen in both the data and the surface plot, the glass plate is pretty flat – with only a 0.42 mm deviation from one extreme from the other.

 

The same set of measurements were performed on the original Printrbot metal print bed, with the following results:

11/20/15 Original print bed Z-axis probe results

11/20/15 Original print bed Z-axis probe results

11/20/15 Original print bed Z-axis probe results

11/20/15 Original print bed Z-axis probe results

The data shows that the original print bed is pretty flat too, even though the illumination experiment showed that it exhibits significant warping.  I suspect that the probe measurement locations were too widely spaced to capture the low spots.  In any case, all that can be said for sure at this point is that both surfaces (original print bed and glass plate) are pretty flat, and both exhibit some tilt, with Z-axis probe measurements consistently rising from the left rear corner (0,153) to the front right corner (130,3).

 

Print Trials:

After convincing myself that the glass plate was indeed flat, and that any residual tilt should be well within the Printrbot’s correction range, I decided to do a series of test prints – starting at the rear left corner and moving toward the near right corner.  For the first print, I adjusted the Z-offset for optimum printing – not too close, not too far away.  Then I kept this same Z-offset for all the other prints.  The following photos tell the story.

20mm cal cube printed at the rear left corner (0,153)

20mm cal cube printed at the rear left corner (0,153)

20mm cal cube printed at (0,103)

20mm cal cube printed at (0,103)

First try at printing 20mm cal cube at the third position (0,53). Note the blob attached to the extruder!

First try at printing 20mm cal cube at the third position (0,53). Note the blob attached to the extruder!

2nd try at printing 20mm cal cube at the third position (0,53). Note the raised corner

2nd try at printing 20mm cal cube at the third position (0,53). Note the raised corner

20mm cal cube printed attempt at the near right corner

20mm cal cube printed attempt at the near right corner.  Part is separated from the bed and ‘blobbed’ to extruder and

20mm cal cube printed at the rear edge, midway toward the right

20mm cal cube printed at the rear edge, midway toward the right

20mm cal cube print attempt at the rear right corner

20mm cal cube print attempt at the rear right corner.  Part has separated from bed and is ‘blobbed’ to extruder.

So, at this point I’m pretty sure of three things:

  1. The glass plate print bed is pretty darned flat
  2. The Z-axis probe seems to be working correctly
  3. The Printrbot tilt correction feature does not appear to be working properly.

Stay tuned,

Frank

 

 

Wall-E goes back to basics; Ping sensors and fixed forward-facing LIDAR

Posted November 14, 2015

Back in the spring of this year I ran a series of experiments that convinced me that acoustic multipath problems made it impossible to reliably navigate and recover from ‘stuck’ conditions using only acoustic ‘ping’ sensors (see “Adventures with Wall-E’s EEPROM, Part VI“).  At the end of this post I described some alternative sensors, including the LIDAR-lite unit from Pulsed Light.

In this same article, I also hypothesized that I might be able to replace all the acoustic sensors with a single spinning-LIDAR system using another motor and a cool slip-ring part from AdaFruit.  In the intervening months between April and now, I have been working on implementing and testing this spinning LIDAR idea, but just recently arrived at the conclusion that this idea too is a dead end (to paraphrase Thomas Edison – “I have not failed. I’ve just found 2 ways that won’t work.”).  I simply couldn’t make the system work.  In order to acquire ranging data fast enough to keep Wall-E from crashing into things, I had to get the rotation rate up to around 300 rpm (i.e. 5 rev/sec).  However, when I did that, I couldn’t process the data fast enough with my Arduino Uno processor and the data itself became suspect because the LIDAR was moving while the measurement was being taken, and the higher the rpm got, the faster the battery ran down.  In the end, I realized I was throwing most of the LIDAR data away anyway, and was paying too high of a price in terms of battery drain and processing for the data I did keep.

So, in my last post on the spinning-LIDAR configuration I summarized my findings to date, and described my plan to ‘go back to basics’; return to acoustic ‘ping’ sensors for left/right wall ranging, and replace the spinning-LIDAR system with a fixed forward-facing LIDAR.  Having just two ‘ping’ sensors pointed in opposite directions should suppress or eliminate inter-sensor interference problems, and the fixed forward-facing LIDAR system should be much more effective than an acoustic sensor for obstacle and ‘stuck’ detection situations.

Over the last few weeks I have been reworking Wall-E into the new configuration.  First I had to disassemble the spinning LIDAR system and all its support elements (Adafruit slip-ring, motors and pulleys, speed control tachometer, etc).  Then I re-mounted left and right ‘ping’ sensors (fortunately I had kept the appropriate 3D-printed mounting brackets), and then designed and 3D-printed a front-facing bracket for the LIDAR unit.  While I was at it, I 3D-printed a new left-side bumper to match the right-side one, and I also decided to retain the laser pointer from the previous version.  The result is shown in the pictures below.

Wall-E after being stripped down for remodeling.

Wall-E after being stripped down for remodeling.

Oblique view showing the new fixed front-facing LIDAR installation

Oblique view showing the new fixed front-facing LIDAR installation, complete with laser pointer.

 

Side view showing both 'ping' sensors. Note the new left-side bumper

Side view showing both ‘ping’ sensors. Note the new left-side bumper

After getting all the physical and software rework done, I ran a series of bench tests to test the feasibility of using the LIDAR for ‘stuck’ detection.  I was able to determine that by continuously calculating the mathematical variance of the last 50 LIDAR distance, I could reliably detect the ‘stuck’ condition; while Wall-E was actually moving, this variance remained quite large, but rapidly decreased to near zero when Wall-E stopped making progress.  In addition, the instantaneous LIDAR measurements were found to be fast enough and accurate enough for obstacle detection (note here that I am currently using the much faster ‘Blue Label’ version of the LIDAR-Lite unit).

Finally, I set Wall-E loose on the world (well, on the cats anyway) with some ‘field’ testing, with very encouraging results.  The ‘stuck’ detection algorithm seems to work very well, with very few ‘false positives’, and the real-time obstacle detection scheme also seems to be very effective.  Shown below is a video clip of one of the ‘field test’ runs.  The significant events in the video are:

  • 14 sec – 30 sec:  Wall-E gets stuck on the coat rack, but gets away again.  I *think* the reason it took so long (16 seconds) to figure out it was stuck was because the 50-element diagnostic array wasn’t fully populated with valid distance data in the 14 seconds from the start of the run to the point were it hit the coat rack.
  • 1:14:  Wall-E approaches the dreaded ‘stealth slippers’ and laughs them off.  Apparently the ‘stealth slippers’ aren’t so stealthy to LIDAR ;-).
  • 1:32:  Wall-E backs up and turns around for no apparent reason.  This may be an instance of a ‘false positive’ ‘stuck’ declaration, but I don’t really know one way or the other.
  • 2:57: Wall-E gets stuck on a cat tree, but gets away again no problem.  This time the ‘stuck’ declaration only took 5-6 seconds – a much more reasonable number.
  • 3:29:  Wall-E gets stuck on a pair of shoes.  This one is significant because the LIDAR unit is shooting over the toe of the shoe, and Wall-E is wriggling around a bit.  But, while it took a little longer (approx 20 sec), Wall-E did manage to get away successfully!

 

So, it appears that at least some of my original goals for a wall-following robot have been met.  In my first post on the idea of a wall-following robot back in January of this year, I laid out the following ‘system requirements’:

  • Follow walls and not get stuck
  • Find and utilize a recharging station
  • Act like a cat prey animal (i.e. a mouse or similar creature)
  • Generate lots of fun and waste lots of time for the humans (me and my grandson) involved

So now Wall-E does seem to follow walls and not get stuck – check.  It still cannot find/utilized a charging station, so that one has definitely not been met.  With the laser pointer left over from the spinning-LIDAR version, it is definitely interesting to the cats, and one of them has had a grand time chasing the laser dot – check.  Lastly, the Wall-E project has been hugely successful in generating lots of fun and wasting lots of time, so that’s a definite CHECK!! ;-).

Next Steps:

While I’d love to make some progress on the idea of getting Wall-E to find and utilize a charging station, I’m not sure that’s within my reach.  However, I do plan to see if I can get my new(er) 4WD chassis up and running with the same sort of ping/LIDAR sensor setup, to see if it does a better job of navigating on carpet.  Stay tuned!

Frank

 

 

 

Glass Print Bed for Printrbot Simple Metal

Posted 11/08/2015

I’ve been having some problems lately getting good prints on my Printrbot Simple Metal 3D printer, and after a lot of inet research I concluded the problem was a warped print bed.  The bed that comes with the Simple is pretty nice, but just not thick enough IMHO to avoid some warping. And once the bed becomes even a little bit non-planar, then the very nice ‘auto-leveling’ (more accurately ‘bed tilt compensation’) ceases to be very useful.

There was some discussion about putting a glass plate down over the original bed, which takes care of the non-planar issue, but then the Hall-effect metal bed sensor can’t ‘see’ the metal print bed through the glass plate, unless the glass plate is too thin to do any good.  What to do?

I’m a long-time Electrical Engineer and antenna researcher, and so it occurred to me that I might be able to fake out the bed sensor by applying some adhesive-backed metal tape to the top of a glass plate, thereby establishing a new ‘zero’ reference at the top surface of the glass plate.  I ran some simple experiments, and found that the bed sensor worked fine with even very thin strips of just about any metal, including copper.  Since I knew I could get copper tape in various thicknesses and widths, I thought this idea might be worth a try.

The glass plate:

I remembered seeing a post somewhere that someone had found that a popular picture frame size worked just great for the Printrbot Simple Metal print bed, so I headed over to my local JoAnne’s fabric to see what was available.  I found lots of cheap picture frames in various sizes, but nothing that even remotely approached a good size for my print bed – bummer.  So, I decided to go the custom route, and, after carefully measuring my bed, got a piece of 3/32″ (~2.3mm) glass cut to 9.5 x 6.5″.  I brought the piece home and carefully smoothed the edges with my belt sander (a sander drum attachment for a drill would work also).  Unfortunately, when I laid the piece on my print bed, I discovered I had screwed up – the 9.5″ dimension was slightly too large, and the pieced didn’t quite fit between the two sets of mounting screws.  I was really bummed out, until I realized I might be able to recover from this disaster by simply grinding cutouts for the screwheads, thereby converting a ‘bug’ into a feature! ;-).  Indeed I was able to do this with a Dremel tool and a small grinding bit, and when I was finished I had a nice, self-registering glass plate for my Printrbot!

Screw head cutouts ground with Dremel tool and small grinding bit

Screw head cutouts ground with Dremel tool and small grinding bit

The Sensor Tape:

I didn’t have any adhesive backed copper tape handy (I used this stuff by the roll in my prior life as a research scientist, but didn’t think to take any with me into retirement), so I tolled the net for a while for sources.  I finally wound up ordering a 10′ roll of 1/4″ adhesive-backed copper tape from eBay

CopperTape

Assembling the new Print Bed:

I used heavy-duty document clips to hold the glass plate down on the original print bed, and then placed copper tape patches at the X/Y home location and the two ‘slope compensation’ sensing points, and then covered the entire thing with blue painter’s tape to provide the same first-layer adhesion as before.

151108_PrintBed2 151108_PrintBed4 151108_PrintBed5

151108_PrintBed1

Testing:

I used a 20mm hollow cal cube as my test object, starting at a point near the X/Y home position.  As expected, I had to adjust the Z offset some, and wound up with a Z offset of about -0.8 to get a decent print.

151108_20mmCube1 151108_20mmCube2

Then I tried moving the cube around on the print bed, and found that I had to keep moving the Z offset further negative as I moved the print position away from the X/Y home position.  To get the cube to print properly, I would up with a Z offset of -2.0mm, way more than I had expected, and then when I tried to move the print back to near the X/Y origin with the same Z offset, I got the extrusion drag marking shown – bummer!

151108_PrintBedSlopeProb1

After seeing the above problem occur, I tried to figure out what was going wrong, and having a heck of a time with it.  Here’s what I know:

  • The Z offset required to get decent first-layer adhesion gets markedly more negative the further away the print position is from the X/Y home position
  • Trying to print near the X/Y home position with the Z offset required for a position far away from X/Y home causes extrusion head dragging.
  • However, in a somewhat contradictory finding, if I manually move the extrusion head position arm (the Y axis, I think) toward the outer edge of the print bed, it starts to drag about halfway across for X values near home, and this condition becomes more marked when the bed is manually moved in the positive X direction (to the left looking at the front of the printer).  In other words, when moving the extrusion head in manual mode, it appears the print bed has a marked upward slope as X & Y increase, causing significant head drag.  However, when printing, the opposite effect seems to occur, where the print bed appears to have a  marked downward slope as X/Y increase.  This makes no sense at all!

So, at the moment I’m officially baffled. In manual mode, the printrbot behaves as if the bed is sloped upward as X & Y increase, but in printing mode (where I assume the ’tilt compensation’ is in effect), the printrbot behaves as if the bed is sloped in the opposite direction.  What gives!?

More to come (I hope)