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)

 

 

 

Under-Counter Heat Gun Holster

Posted 08/18/2015

I have an old Black & Decker paint stripping gun that I have found to be perfect for shrinking heat-shrink tubing on my electronics projects. It’s old and beat up, but it is does that one thing very well.  However, it is big, bulky and its metal tip stays HOT for a long time after use (note the burned rubber/plastic on the tip), so finding a place to put the bloody thing after use has always been a bit of a PITA.

Oldie-but-goody - my trusty B & D paint stripper works perfectly for heat-shrink tubing

Oldie-but-goody – my trusty B & D paint stripper works perfectly for heat-shrink tubing

I was recently re-arranging my office/lab work areas for better efficiency, and I once again ran into the problem of “where do I put this bloody heat gun!”, when I had an epiphany; I have not only one, but TWO 3D printers, and so I should be able to design and print some sort of under counter holster for this thing!

When our Hobbit-house (earth sheltered house) was built way back when, I had my office/lab outfitted with a built-in wrap-around work surface with NO LEGS!  The work surface is supported with 5/16″ steel L-brackets built into the wall structure, so I can roll my work chair from one end to the other with nary a chance of banging my knees – yay!

Anyway, that meant that I had these steel beams in several places along the span of my work surface, and it turned out that one of them was in just the right place to be a convenient under-counter mounting location for my new holster brainstorm.  And as an added bonus, when the heat gun is in the holster, the HOT metal tip would rest against the steel support, not against anything remotely flammable – double yay!

So, now all I had to do was design and print something that would capture the forward body of the gun but still allow for easy insertion & removal.  After a few minutes with my trusty digital calipers and another few minutes on TinkerCad, I had a preliminary design that I thought might work.  I decided to not add a mounting structure in the initial design, as I just wanted to see if I had the dimensions right, and then adjust from there.  With TinkerCad and a 3D printer, you don’t have to be right the first time; if it doesn’t work or isn’t complete – it’s just a few minutes work to adjust the design, and another few minutes (or in the case of the holster – another few hours) to print another iteration; the modern version of ‘cut and try’ is ‘print and try’ ;-).

Version 1 of the heat gun under-counter holster.  I didn't include any mounting provisions on this first version - and it turned out I didn't need any

Version 1 of the heat gun under-counter holster. I didn’t include any mounting provisions on this first version – and it turned out I didn’t need any

The holster was printed in white ABS on my MicroCenter PowerSpec Pro 3D printer.  I used white ABS because that was what was on the printer at the moment  (and I didn’t want to use the brilliant neon magenta ABS stuff I had on the other extruder head).  I assumed I was going to go through several versions (and I still may) so I didn’t really care what I used for the first version.  In any case, the print took about 3 hours (most of which was spent while I was away playing bridge – hee hee).  When I tried the result on my heat gun, it actually fit pretty well.  The holster was just a teeny bit undersized, but the walls were thin enough (and ABS is flexible enough) so that the gun fit easily but tightly; I hadn’t really planned it this way, but I’d rather be lucky than good!

The whole thing worked so well in the initial tests that I decided to try and mount it under the counter on the steel L-bracket as planned.  Instead of my non-existent mounting surface, I drilled some 6-32 holes in the front and rear upper inside corners. The rounded corners of the gun leave a bit of space there, enough so a protruding screw head won’t cause a problem.  The biggest problem was drilling the mounting holes in the steel bracket – a 5/16″ thick piece of steel is not a trivial job!

After getting the first hole in, I noticed that I didn’t really need the second one – the heat gun stays pretty level, and can’t go anywhere, even with just one mounting screw.  The following photos show the installation.  The holster is mounted far enough under the counter that I can roll my chair past this spot without my knees hitting the gun, but still close enough so I can easily remove/insert the gun in the holster.

HeatGunHolster1 HeatGunHolster2 HeatGunHolster3

 

LIDAR-Lite Visible Laser Testing

Posted 6/20/15

In my last post (Lidar-Lite Gets it’s Own Motor), I discussed how I might test the new LIDAR installation, and one of the options was to mount a visible laser diode on the LIDAR, to act as a pointing reference.  This post shows some results from that effort.

First, I used TinkerCad and my trusty 3D printer to design and fabricate a mount for the laser diode.  The collar rings are spring-loaded onto the LIDAR optical tubes, with the laser diode mounted on the LIDAR’s central axis, as shown below:

Laser diode mounted along LIDAR central axis

Laser diode mounted along LIDAR central axis

Next, as an initial feasibility test, I connect the laser diode power line to a digital output that toggled on/off at each successive interrupt signal from the LIDAR tach wheel.  These interrupts occur at approximately 25-35 msec intervals, so I was curious to see whether or not such a short laser pulse would be visible.  To answer this question, I mounted a piece of paper in an arc around the LIDAR/laser diode unit, and watched – sure enough, the laser pulses were visible!

The following shots show a) the LIDAR pointing toward the camera with the laser ON; b) the LIDAR pointing toward the paper with the laser ON; c) a movie of the operation.

LIDAR facing the camera, with the laser diode ON

LIDAR facing the camera, with the laser diode ON

LIDAR pointed toward the paper screen with the laser diode ON.

LIDAR pointed toward the paper screen with the laser diode ON.

 

As a further test, I modified the test program to only enable the laser diode for the 10 msec period immediately after index plug detection, and then manually rotated the LIDAR mount relative to the tach wheel so the LIDAR unit was pointing (more or less) straight ahead when the interrupt at the end of the index plug occurred.  If everything was working properly, I should see a single 10msec laser pulse at the same spot on the paper every revolution.  The following short movie shows the result

From the testing so far, two things have become clear:

  • The visible laser diode is an effective tool for visually refrerencing the LIDAR’s look direction under rotation
  • Laser pulses as short as 10msec can be easily detected by eye on a suitable target in typical office lighting, at least for relatively short ranges.  Longer ranges can be achieved by simply turning off the lights in the room.

The Duplicate Bridge ‘Blame’ Chip

Posted 6/17/2015.

A favorite topic among duplicate bridge players is just who’s to blame for a particular screw-up.  Bridge is a somewhate unique sport in that it requires two players per side, and both players in a partnership contribute to success or failure.  A really good player can make up for many (but not all) mistakes by a weaker player, but winning partnerships require that both players minimize their mistakes. Most established (and all successful) partnerships have developed a way of handling the blame issue in a way that doesn’t degrade or destroy the partnership.  One pair that I know describes this process as ‘blame management’.  The idea, so they say (somewhat tongue-in-cheek) is to bid in a way that ensures that any blame for mistakes will fall on one’s partner rather than oneself.  This incentivizes each partner to bid as correctly as possible given the partnership agreement (their convention card) and the particular circumstances at the time.  Having ‘a bright idea’ and ‘going off piste’ might work, but if it doesn’t the blame will fall squarely on the errant partner (and even if it does work, it might incur significant blame for not adhering strictly to the partnership agreement).

I liked this idea of ‘blame management’ so much that I have tried to incorporate it into my own partnerships; I try to get the idea of blame management out in the open early on, so my partner is (hopefully) comfortable with the idea of assigning blame in an open and humorous way, rather than letting issues fester.  Lately I have started describing this as ‘moving the blame chip from one side of the table to the other’, and that got me thinking that maybe I could use my engineering and 3D printing capabilities to fabricate an actual, physical ‘Blame Chip’.

I started this project as I do almost all my new projects – researching on the internet with Google.  I found card and pip images, and then I found a set of zip files with 3D models of all the various card elements.  From this I extracted the 4 pips I needed (clubs, hearts, spades, diamonds), and arranged them circularly around the word ‘BLAME’, as shown in the following screenshot.

TinkerCad design for the Duplicate Bridge Blame Chip

TinkerCad design for the Duplicate Bridge Blame Chip

Then I printed it on my MicroCenter 3D Pro 3D printer, using blue and white (the two colors I had on the machine at the time).  Here are some photos of the result.

3D printed version of the 'Duplicate Bridge Blame Chip'.  The chip laying on the pen is actually two chips glued together to form a 2-sided chip.

3D printed version of the ‘Duplicate Bridge Blame Chip’. The chip laying on the pen is actually two chips glued together to form a 2-sided chip.

The items that come off the printer are blank on the reverse side, so to get a real 2-sided ‘poker chip’ style item, I simply printed two chips and glued them together.  In the photo above, the chip leaning on the pen is a 2-sided version, while the others are single-sided.

I’m not really sure where I’m going with this, as the sudden appearance of a real, physical ‘blame’ chip at the table may have unintended (read ‘disastrous’) consequences.  My wife has suggested these might make great bridge party favors, and I may try giving some of these away to established partnerships before I get too ambitious. Also, I will probably try printing some with white pips on a red background to see how they look.

Frank

 

LIDAR-Lite Gets its Own Motor

Posted June 16, 2015

In my last post (http://fpaynter.com/2015/05/lidar-lite-rotates/ – over a month ago – wow!) I described the successful attempt to mate the Pulsed Lite LIDAR with a 6-channel slip ring to form a spinning LIDAR system for my Wall-E wall-following robot.  As an expedient, I used one of Wall-E’s wheel motors as the drive for the spinning LIDAR system, but of course I can’t do that for the final system.  So, I dived back into Google and, after some research, came up with a really small but quite powerful geared DC motor rated for 100 RPM at 6 VDC (In the image below, keep in mind that the shaft is just 3mm in diameter!)

 

Very small 100RPM geared DC motor.  See http://www.ebay.com/itm/1Pcs-6V-100RPM-Micro-Torque-Gear-Box-Motor-New-/291368242712

Very small 100RPM geared DC motor. See http://www.ebay.com/itm/1Pcs-6V-100RPM-Micro-Torque-Gear-Box-Motor-New-/291368242712

In my previous work, I had worked out many of the conceptual challenges with the use of an offset motor, O-ring drive belt, and slip ring, so now the ‘only’ challenge was how to replace Wall-E’s temporarily-borrowed wheel motor with this little gem, and then somehow integrate the whole thing onto the robot chassis.

The first thing I did was come up with a TinkerCad design for mounting the micro-motor on the robot chassis, and the pulley assembly from the previous study onto the motor shaft.  Wall-E’s wheel motor has a 6mm shaft, but the micro-motor’s shaft is only 3mm, so that was the first challenge.  Without thinking it through, I decided to simply replace the center section of the previous pulley design with a center section sporting a 3mm ‘D’ hole.  This worked, but turned out to be inelegant and WAY too hard.  What I should have done is to print up a 3mm-to-6mm shaft adapter and then simply use all the original gear – but no, I had to do it the hard way!  Instead of just adding one new design (the 3mm-to-6mm adapter), I wound up redesigning both the pulley and the tach wheel – numerous times because of course the first attempts at the 3mm ‘D’ hole were either too large or too small – UGGGGGHHHH!!

Anyway, the motor mount and re-engineered pulley/tach wheel eventually came to pass, as shown below.  I started with a basic design with just a ‘cup’ for the motor and a simple drive belt pulley.  Then I decided to get fancy and incorporate a tach wheel and tach sensor assembly into the design.  Rather than having a separate part for the sensor assembly, I decided to integrate the tach sensor assembly right into the motor mount/cup.  This seemed terribly clever, right up until the point when I realized there was no way to get the tach wheel onto the shaft and into the tach sensor slot – simultaneously :-(.  So, I had to redesign the motor ‘cup’ into a motor ‘sleeve’ so the motor could be slid out of the way, the tach wheel inserted into the tach sensor slot, and then the motor shaft inserted into the tach wheel ‘D’ hole – OOPS! ;-).

Assembled Miniature DC Motor Mount

Assembled Miniature DC Motor Mount

Miniature DC motor with chassis mount and belt drive wheel

Miniature DC motor with chassis mount and belt drive wheel

Miniature DC motor partially installed in chassis mount

Miniature DC motor partially installed in chassis mount

MotorTachAssy1

Miniature DC motor mount, with tach sensor attachment, side/bottom view

Miniature DC motor mount, with tach sensor attachment, side view showing motor contact cover

Miniature DC motor mount, with tach sensor attachment, side view showing motor contact cover

Miniature DC motor mount, with tach sensor attachment, top view

Miniature DC motor mount, with tach sensor attachment, top view

Completed assembly, with drive belt pulley and tach wheel

Next up – the LIDAR mount.  The idea was to mount the LIDAR on the ‘big’ side of the 6-channel slip ring assembly, and do something on the ‘small’ side to allow the whole thing to slide toward/away from the motor mount to adjust the drive belt tension.  As usual, I didn’t have a clue how to accomplish this, but the combination of TinkerCad and 3D printing allowed me to evolve a workable design over a series of trials.  The photo below shows the LIDAR mounted on the ‘big’ side of the slip ring, along with several steps in the evolution of the lower slide chassis mount

Evolution of the slide mount for the LIDAR slip ring assembly

Evolution of the slide mount for the LIDAR slip ring assembly

The last two evolutionary steps in this design are interesting in that I realized I could eliminate a lot of structure, almost all the mounting hardware, and provide much easier access to the screw that secures the slide mount to the robot chassis.  This is another huge advantage to having a completely self-contained design-fabrication-test loop; a new idea can be designed, fabricated, and tested all in a matter of a half-hour or so!

Original  and 2nd versions of the LIDAR slip ring assembly mount

Original and 2nd versions of the LIDAR slip ring assembly mount

Once I was satisfied that the miniature motor, the tach wheel and tach sensor assembly, and the spinning LIDAR mount were all usable, I assembled the entire system and tested it using an Arduino test sketch.

 

After a few tests, and some adjustments to the tach sensor setup, I felt I had a workable spinning LIDAR setup, and was optimistic that I would have Wall-E ‘back on the road again’ within a few days, proudly going where no robot had gone before.  However, I soon realized that a significant fly had appeared in the ointment – I wasn’t going to be able to accurately determine where the LIDAR was pointed – yikes!  The problem was this; in order to tell Wall-E which way to move, I had to be able to map the surroundings with the LIDAR.  In order to do that, I had to be able to associate a relative angle (i.e. 30 degrees to the right of Wall-E’s nose) with a distance measurement.  Getting the distance was easy – just ask the LIDAR for a distance measurement.  However, coming up with the relative angle was a problem, because all I really know is how fast the motor shaft is turning, and how long it has been since the index plug on the tach wheel was last ‘seen’.  Ordinarily this information would be sufficient to calculate a relative angle, but in this case it was complicated by the fact that the LIDAR turntable is rotating at a different rate than the motor, due to the difference in pulley diameters – the drive ratio.  For every 24mm diameter drive pulley rotation, the 26mm diameter LIDAR pulley only rotates 24/26 times, meaning that the LIDAR ‘falls behind’ more and more each rotation.  So, in order to determine the current LIDAR pointing angle, I would have to know not only how long it has been since the last index plug sighting, but also how many times the drive pulley has rotated since the start of the run, and the exact relative positions of the drive pulley and the LIDAR at the start of the run.  Even worse, the effect of any calculation errors (inaccurate pulley ratio, roundoff errors, etc) is cumulative, to the point where after a few dozen revolutions the angle calculation could be wildly inaccurate.  And this all works only if the drive belt has never slipped at all during the entire run.  Clearly this was not going to work in my very non-ideal universe :-(.

After obsessing over this issue for several days and nights, I finally came to the realization that there was only one real solution to this problem.  The tach wheel and sensor had to be moved from the motor drive side of the drive belt to the LIDAR side.  With the tach wheel/sensor on the LIDAR side, all of the above problems immediately and completely disappear – calculation of the LIDAR pointing angle becomes a simple matter of measuring the time since the last index plug detection, and calculation errors don’t accumulate.  Each time the index plug is detected, the LIDAR’s pointing angle is known precisely; pointing angle calculation errors might accumulate during each rotation, but all errors are zeroed out at the next index plug detection.  Moreover, the pointing angle calculation can be made arbitrarily accurate (to the limit of the Arduino’s computation capability and timer resolution) by using any per-revolution error term to adjust the time-to-angle conversion factor.  As a bonus, the motor no longer has to be speed-controlled – I can run it open-loop and just measure the RPM using the tach wheel/sensor.  As long as the motor speed doesn’t change significantly over multiple-revolution time scales, everything will still work.

So, back to TinkerCad for major design change number 1,246,0025 :-).  This time I decided to flip the 6-channel slip ring so the ‘big’ half was on the chassis side, and the ‘small’ half was on the LIDAR side, thereby allowing more room for the new tach wheel on the spinning side, and allowing for a smaller pulley diameter (meaning the LIDAR will rotate faster for a given motor speed).  The result of the redesign is shown in the following photo.

Revised LIDAR and DC motor mounting scheme, with Tach wheel and sensor moved to LIDAR mount

Revised LIDAR and DC motor mounting scheme, with Tach wheel and sensor moved to LIDAR mount

In the above photo, note the tach sensor assembly is still on the motor mount (didn’t see any good reason to remove it.  The ‘big’ (non-spinning) half of the slip ring module is mounted in a ‘cup’ and secured with two 6-32 set screws, and the tach wheel and LIDAR belt pulley is similarly mounted to the ‘small’ (spinning) half.  The tach sensor assembly is a separate peice that attaches to the non-spinning ‘cup’ via a slotted bracket (not shown in the photo).  The ‘big’ slip ring half is secured in the cup in such a way that one of the holes in the mounting flange (the black disk in the photo) lines up with the IR LED channel in the tach sensor assembly.  The tach wheel spins just above the flange, making and breaking the LED/photo-diode circuit.  Note also how the slip ring ‘cup’ was mounted on the ‘back’ side of the drive belt tension slide mount, allowing much better access to the slide mount friction screw.  The right-angle LIDAR bracket was printed separately from the rest of the LIDAR assembly to get a ‘cleaner’ print, and then press-fit onto the pulley/tach wheel assembly via an appropriately sized hole in the LIDAR bracket.   The following movie shows the whole thing in action

 

In the above movie, note the quality of the tach sensor signal; it is clamped to the voltage rails on both the upper and lower excursions, and the longer ‘high’ signal of the index plug is clearly visible at the far right of the oscilloscope screen.

Details of the Tach Wheel:

Wall-E’s spinning LIDAR system features a tachometer wheel with an ‘index plug’, as shown below.  Instead of a series of regularly spaced gaps, the gap in one section is missing, forming a triple-width ‘plug’ that allows me to detect the ‘index’ location.  However, this means that instead of 20 equally spaced open-to-opaque or opaque-to-open transitions, there are only 18, as two of the transitions are missing.  In addition, the LIDAR pointing angle isn’t as straightforward to calculate.  If the trailing edge of the ‘index plug’ is taken as 0 degrees, then the next transition takes place at 18 degrees, then 36, 54, 72, 90, … to 306 degrees.  However, after 306, the next transition isn’t 324 degrees – it is 360 (or 0) as the 324 and 342 degree transitions (shown in red in the diagram below) are missing.  So, when assigning pointing angles to the interrupt number, I have to remember to multiply the interrupt index number (0 – 17) by 18 degrees (17*18 = 306).  This also means that there is no ability to ‘see’ obstacles in the 54 degree arc from 306 to 360 degrees.

 

Diagram of the tach wheel for Wall-E's spinning LIDAR system

Diagram of the tach wheel for Wall-E’s spinning LIDAR system

Next Steps: Now that I have a LIDAR rotation system that works, the next step is to design, implement and test the program to acquire LIDAR distance data and accurately associate a distance measurement with a relative angle.  With the new tach wheel/sensor arrangement, this should be relatively straightforward – but how to test?  The LIDAR will be spinning at approximately 100 RPM, so it will be basically impossible to simply look at it and know where it is/was pointing when a particular measurement was taken, so how do I determine if the relative angle calculations are correct?

  • I could put the whole think in a large cardboard box like I did with the XV-11 NEATO spinning LIDAR system (see ‘Fun with the NEATO XV-11 LIDAR module‘); If the (angle, distance) data pairs acquired accurately depict the walls of the container over multiple runs, that would go a long way toward convincing myself that the system is working correctly.  I think that if the angle calculation was off, the lines plotted in one run wouldn’t line up with the ones from subsequent runs – in other words the walls of the box would blur or ‘creep’ as more data was acquired.  I could also modify the box with a near-distance feature at a known relative angle to Wall-E’s nose, so it would be easy to tell if the LIDAR’s depiction of the feature was in the right orientation.
  • I could mount a visible laser (similar to a common AV pointer) to the LIDAR so I could see where it is pointing. This would be a bit problematic, because this would simply paint a circle on the walls of the room as the LIDAR spins.  In order to use a visible laser as a calibration device, I’d need to ‘blink’ it on and off in synchronism with the angle calculation algorithm so I could tell if the algorithm was operating correctly.  For instance, if I calculated the required time delay (from the index plug detection time) for 0 degrees relative to the nose, and blinked the laser at that time, I should see a series of on/off dots directly in front of Wall-E’s nose.  If the dots appear at a different angle but are stationary, then I have a constant error term somewhere.  It they drift left or right, then I have a multiplicative factor error somewhere.

I think I’ll try both techniques; the box idea sounds good, but it may take a pretty large box to get good results (and I might even be better off using my entire office), and it might be difficult to really assess the accuracy of the system.  I already have a visible laser diode, so implementing the second idea would only require mounting the laser diode on top of the LIDAR and using two of the 6 slip ring channels to control it.   I have plenty of digital I/O lines available on the Arduino Uno, so that wouldn’t be a problem.

RobotGeek Laser, Item# ASM-RG-LASER available from Trossen Robotics (TrossenRobotics.com)

RobotGeek Laser, Item# ASM-RG-LASER available from Trossen Robotics (TrossenRobotics.com)

Stay tuned!

 

Frank

 

 

 

 

 

 

 

LIDAR-Lite Rotates!

Posted 5/29/15

In previous posts I described a couple of LIDAR alternatives to my original ultrasonic ping sensor system for Wall-E’s navigation capabilities, and the challenges I faced in implementing them.  The LIDAR-Lite module is easily interfaced to an Arduino controller via the I2C interface and there is plenty of example code for doing this.  However, in order to use it as the primary navigation sensor, it needs to spin at a controlled 1-5 RPS (60-300 RPM) and there has to be a way to determine the rotational angle associated with each distance measurement.  In a previous post (http://fpaynter.com/2015/05/dc-motor-speed-control-using-optical-tachometer/) I described my experiments with one of Wall-E’s wheel motors to implement speed control using an IR LED/photodiode/toothed-wheel tachometer.

After successfully implementing speed control on Wall-E using the right wheel motor, I next turned my attention to implementing a drive train to connect the wheel motor to the LIDAR Lite unit.  I couldn’t just connect the LIDAR module to the motor shaft, as the LIDAR wiring would simply wrap itself to death as soon as the motor started turning.  I had previously acquired the slip ring module (described in http://fpaynter.com/2015/04/robot-of-the-future-lidar-and-4wd/) shown below

Adafruit Slip Ring with 6 contacts

Adafruit Slip Ring with 6 contacts

So I needed a way to connect the rotating part of the slip ring to the LIDAR module, and the non-rotating part to the robot chassis and (via a drive belt) to the motor shaft.

In TinkerCad, I designed a grooved pulley with a rectangular cross-section axial hole to fit over the motor shaft, an adapter from the rectangular LIDAR mounting plate to the cylindrical slip ring rotating side, and a chassis mounting bracket that would allow the non-rotating side of the slip ring to be adjusted toward and away from the motor shaft pulley to properly tension the drive belt.  The drive belt is a standard rubber O-ring from McMaster Carr.

Now that I have motor speed control working and the LIDAR spinning, I need to connect the LIDAR electrically to the Arduino Uno controller and see if I can actually collect angle-specific LIDAR distance data (distance from the LIDAR, angle from the wheel speed tachometer control software).  Stay Tuned!

Frank

 

LIDARMountChassisBracket LIDARMountChassisSlipRing LIDARMountLIDARBracket LIDARMountMotorPulley

Spinning LIDAR drive assembly and LIDAR unit.  Note O-ring drive belt.

Spinning LIDAR drive assembly and LIDAR unit. Note O-ring drive belt.

 

DC motor speed control using optical tachometer

Posted 04/13/15

In my last post I described my plans for upgrading Wall-E (my Wall-following Robot) with a LIDAR package of some type, and my thought that I might be able to use such a package to not only replace the existing front-facing ping sensors, but (with a bit of rotating magic) the side sensors as well.

In order to replace *all* the sensors, the LIDAR package would have to rotate fast enough so that it could produce front, left, and right-side distance readings in a timely enough fashion to actually implement wall-following.  I’m not sure exactly what the requirements for wall-following are, but I think it’s safe to say that at least the measurements to the followed wall must be in the several-per-second range, or Wall-E could run into the wall before it figures out it is getting too close.  The other side, and the front could be taken at a more relaxed pace if necessary, but the wall being tracked has to be done correctly.

In order to rotate a unit such as the LIDAR-Lite from PulsedLight, I would need a speed-controlled motor of some kind.  I considered both stepper motors and direct-drive DC motors.  Since I already had two DC motors (the left and right wheel motors on Wall-E) and they came with ‘tachometer sensors’ (plastic disks with slots for optical wheel motion sensing), I thought I’d give this a try.  Earlier in my robot startup phase, I had obtained some IR LED/Photodiode pairs, so I had at least the basic building blocks for a tachometer system.  I was already speed-controlling Wall-E’s wheel motors for steering using PWM from the Arduino Uno, so that part was already in place.  ‘All’ I had to do was couple the input from a tachometer into the already-existing PWM speed control facility and I would have a closed-loop speed-controlled rotating base for my LIDAR system – cool!

OK, so now I have all the parts for a speed-controlled motor system – I just have to assemble them. First up was a way of mounting the IR LED and IR detector in such a way that the slots in the tachometer wheel would alternately make and break the light path between them.  In the past when I had to do something like this, I would carve or glue something out of wood, or bend up some small pieces of aluminum.  However now I have a very nice 3D printer and the TinkerCad design package, so I could afford to do this a different way.  The confluence of hobby robotics and 3D printing allows so much more design/development freedom that it almost takes my breath away.  Instead of dicking around for a while and winding up with something half-assed that is used anyway because it is way too much trouble to make another -better – one, a 3D printer based ‘rapid iteration’ approach allows a design to be evolved very quickly, with each iteration so cheap as to be literally throw-away.   To illustrate the approach, the image below shows the evolution of my IR LED/IR detector bracket, along with the original 20-slot tachometer wheel that came with the motors and a 10-slot version I printed up as a replacement (the tach signal-to-noise ratio was too low with the 20-slot original).

Evolution of an IR tach sensor bracket, along with the original and a custom-printed tach wheel

Evolution of an IR tach sensor bracket, along with the original and a custom-printed tach wheel

The evolution proceeded from left to right in the image.  I started with just a rectangular piece with a horizontal hole to accommodate the IR LED, and a threaded hole in the bottom to affix it to the robot chassis.  Then the design evolved a ‘foot’ to take advantage of a convenient slot in the robot chassis, for physical stability/registration purposes.  Then I added a second side with a slot in it to accommodate the IR detector, with the tach wheel passing between the two sides.  This basic two-sided design persisted throughout the rest of the evolution, with additional material added on the IR LED side to accommodate the entire length of the IR LED.  Not shown in the photo are some internal evolutionary changes, most notably the width of the slot that allows IR energy from the LED to fall on the detector – it turns out that the detector opening should be about 1/2 the width of a tooth slot for best signal.  Each step in the above evolution cost me about 30 minutes of design time in TinkerCad, and a few pennies worth of filament.  Moreover, once I have the end design, printing more is essentially free.  Is that cool, or what?

Wall-E's right motor being used as my tachometer test bed

Wall-E’s right motor being used as my tachometer test bed.  Note the piece of scotch tape on the wheel, used for manually timing RPM.

Tachometer sensor bracket, showing IR LED and tach wheel

Tachometer sensor bracket, showing IR LED and tach wheel

Tachometer sensor bracket, showing slot for the IR detector

Tachometer sensor bracket, showing slot for the IR detector

Since I was already controlling the speed of Wall-E’s motors with an Arduino Uno (albeit for steering), I simply modified the wall-following program to act as a test driver for the tach feedback system.  The output of the IR detector was connected to an analog input, and the analog readings were captured and imported into an Excel spreadsheet for analysis.

The first test showed that I wasn’t getting enough signal swing between the slot and non-slot (plug) states of the tach wheel (less than 100 out of a possible 1024 levels), and this led me to start experimenting with different IR detector apertures.  As shown in the second plot below, constricting the aperture provided a marked improvement in SNR (about 3 times the peak-peak variation).

First test of the tach sensor system.  Note the not-impressive variation between wheel slot and plug readings

First test of the tach sensor system. Note the not-impressive variation between wheel slot and plug readings

Paper barrier with a small slot placed in front of detector aperture

Paper barrier with a small slot placed in front of detector aperture

The above results led directly to the final round of evolutionary changes to the tach sensor bracket, where the detector aperture was changed from a large circle (same diameter as the IR LED) to a small slit.  In addition, to further improve the SNR, the tach wheel itself was redesigned from 20 slots to 10 with the slots and plugs equal area.  In addition one slot was removed to create an absolute wheel position ‘index mark’.  After these changes, the tach sensor test was redone resulting in the following plot.

IR Detector response with a narrow slit aperture and a 10-tooth wheel.

IR Detector response with a narrow slit aperture and a 10-tooth wheel.

Now the signal varies from 0 to 800, allowing easy and reliable ‘off’ to ‘on’ state detection, and index mark detection.

After incorporating the physical changes noted above, an Arduino program was developed to test whether or not the motor could be accurately speed controlled.  Rather than trying to manually threshold-detect the above waveform, I simply used Mike Schwager’s very cool EnableInterrupt Library (see https://github.com/GreyGnome/EnableInterrupt) and set the Tach signal analog input to trigger an interrupt on each signal change.  This resulted in two interrupts per slot position, but this was easily handled in the software.

After getting the program working, I found that I could control the motor such that, when set to 60 rpm, 20 wheel revolutions (as measured by counting the scotch tape on the wheel) took exactly 20 seconds.

Well, I’m not quite sure where I’m going from here.  Now I have demonstrated that I can control a typical hobbyist/robot motor for use as a LIDAR turret.  However, I’m not entirely convinced that a spinning LIDAR can produce wall distance measurements fast enough for successful wall following, and it will be a major PITA to modify Wall-E sufficiently to find out.  For one thing, I can’t really use one of Wall-E’s drive wheels as the LIDAR turret motor without giving Wall-E an unacceptable ‘limp’ (If I did that, I guess I would have to change his name from ‘Wall-E’ to ‘Quasimodo’ ;-)).  For another, to mount the LIDAR and turret on the current Wall-E chassis would be a major project by itself, as Wall-E’s real estate is already heavily populated with ‘stuff’.

So, I think I’m going to wait until my new 4WD robot chassis arrives (it was unfortunately delayed for a week or so), and then build it up from scratch as a LIDAR-only platform. I can then use one of the motors from Wall-E as the turret motor for the PulsedLight LIDAR-Lite system.  In the meantime, I think I’ll try and mount the NEATO XV-11 spinning LIDAR on Wall-E, as it doesn’t require any additional motors (it has its own motor built in), and see if I can successfully follow a wall using only LIDAR.

Stay Tuned…

 

Frank