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://gfpbridge.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://gfpbridge.com/2015/04/robot-of-the-future-lidar-and-4wd/) shown below

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

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

DC motor speed control using optical tachometer

2 Replies

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

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. 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 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

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.

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

The Ender’s Game Flash Gun Project – Success!!

Leave a reply

03/22/2015

As I write this, my grandson Danny and his family are walking out the door to go back home to St. Louis (Danny’s sister has a soccer game late this afternoon), and Danny is taking a brand-new, finished and functional Ender’s Game Flash Gun with him (not to mention a ‘Tower of Pi’ pencil holder, one of my old-but-still-very-functional laptops, and a lot of experience (good and bad) with 3D printing.

Here is a series of photos of the build process, and a video at the end showing the end result.

Starting the build

Added the second half of the forward body section showing the arduino

Battery sled showing the Sparkfun PowerCell charger

Adding the handle with battery sled already wired up. Also note the push button ‘trigger’ has been wired in

Another view showing the trigger pushbutton

Handle completely seated, working on getting the arduino wired up properly

Handle completely seated and power applied to arduino, working on rest of arduino wiring

Left side. Note the white heatshrink tubing on Arduino I/O connections had to be cut down to half length to fit

Lower focus rail added. This part has an extension of the body cavity to give more room for the arduino board (and it is needed!)

Other side showing the lower focus rail in place

Handle button glued in place. Super-glue won’t work here as there isn’t enough intimate surface contact. Used ‘Gorilla Glue’ instead. Note also the lower grey focus rail would not stay on (just a press fit), so I used a small strip of double-sided foam tape.

If you are interested in trying this for yourself, I plan to post the above images along with more detailed build comments on Thingiverse as a ‘Make’ for the Ender’s Flash Gun

Frank

The Ender’s Game Flash Gun Project

Leave a reply

3/20/2015

Some months ago, my grandson got interested in the possibilities represented by my rudimentary 3D printing capability, and decided he would like to try and make GlitchTech’s really coo Ender’s Game Flashgun, popularized in the Ender’s Game book by Orson Scott Card and the wildly popular movie. Not knowing what a HUGE adventure this was going to be, I encouraged him. Over the winter of 2014/15 Danny and I collaborated via frequent Skype sessions about the project, culminating with Danny, his parents (Electrical Engineer and Attorney), and his sister arriving on our doorstep late last Wednesday night for a 3-4 day geek fest to assemble all the 3D-printed parts and the electronics for the Flash Gun.

The Flash Gun is quite complex. It consists of over 30 separate 3D-printed parts, and contains a Li-ion battery, a Sparkfun PowerCell battery charger, 2 Adafruit NeoPixel LED rings, an Arduino Pro Mini microprocessor to run it all, and various other small parts. As an added bonus, the Pro Mini board doesn’t have any sort of programming connector, so something like an Adafruit FTDI Friend or CKDevices FDTI Pro board to connect to the Pro Mini for programming. I happened to have a CKDevices FDTI Pro hanging around from a previous project, so I hoped this would do.

There’s a Flash Gun in there somewhere, I’m sure!

The Adafruit Neo Pixel rings, the ‘Beam LED’ and the Arduino Pro Mini

There were three main threads in the Flash Gun project. The first and most time-consuming was 3-D printing all the parts – there were a lot of them, and many had quite complex internal structures. It became apparent rather rapidly that my little old PrintrBot Simple Metal printer wasn’t up to the task, so Christmas brought me a MicroCenter PowerSpec 3D PRO dual-extruder printer. With the dual-extruder setup, I could now use HIPS dissolvable filament for the required support structures, then dissolve them away using Liminonene.

As the winter went by and I continued to push out Flash Gun parts, Danny and I also worked on other projects. We have a Wall-following robot powered by an Arduino UNO, and we also did a jointed robot (pose-able figurine) project.

The original designer of the Flash Gun provided a very complete and elegant Arduino program to run the NeoPixel rings, but it still has to be uploaded into the Arduino, and then the whole thing tested. Also, as we approached this point, it became apparent that the code documentation, while quite robust, still left a few things as ‘exercises for the student’. In particular, the Arduino Pro Mini I/O pin assignments in the code did not match the photo of the Arduino Pro Mini in the Thingiverse post (http://www.thingiverse.com/thing:417286/#files, fifth picture from the left). It was at this point that Danny’s father Ken, also an EE with a lot of hands-on experience was invaluable in acting as a second set of eyes and a second brain to keep me from doing anything too stupid. In particular it was Ken that figured out the pin assignments for the Arduino Mini – Thanks Ken!

As a pre final assembly test, I wired up the Arduino, the two NeoPixel LED rings, the front-facing ‘beam’ LED, and the 10K pull-down resistor on the pushbutton ‘trigger’ pin. After uploading what I hoped was the final Flash Gun program, and using power from the FTDI pro board, I tried my luck at ‘triggering’ the Flash Gun. To my surprise and delight – it worked the very first time – no debugging required (see the video below)

After running the test a few more times for all the assembled multitudes (well, the family anyway), we moved on to more mundane aspect of the electrical wiring. I connected the Sparkfun VCC output through the ON/OFF switch and then on to the main VCC connection point, and connected the Sparkfun GND pin to the main GND connection point. Now I was able to ‘trigger’ the LED rings using just the Flash Gun’s internal battery – cool!

So, a very good day by any measure. It’s Friday night as I write this, and we have one more full day to get everything done. All that’s left on the electrical side is to wire the ‘trigger’ pushbutton into the circuit, so that shouldn’t take long. Then comes the task of putting all the mechanical parts together, and of course shoe-horning the Arduino into the not-so-large cavity designed for it. Hopefully by the time we break to watch the Ender’s Game movie Saturday night, Danny will have a real live Ender’s Game Flash Gun to fire at appropriate places in the movie! ;-).

Frank

Flap Handle ClearNav Remote Caddy Done! (I hope)

Leave a reply

John tells me that the latest and greatest flap handle ClearNav remote caddy version is alive and doing well in his glider. The flap grip section fits over the metal flap control handle nicely, and the redesigned remote caddy section with its beefed-up quarter-turn fastener seems to be holding up OK so far. The ‘caddy garage’ piece also seems to be working to hold the remote caddy in an out of the way place when not in use, allowing John to enter/exit the glider without worrying about damaging the caddy or breaking a cable. Only time will tell, but for now it looks like I might be DONE!!!

Original flap grip replaced with ClearNav remote caddy

Remote caddy detached from flap grip and connected to ‘garage’ piece mounted to instrument panel using one of the instrument screws

I Need a Better Class of Pilot!

1 Reply

In our last episode of the Flap Handle Follies, I was sure I had all the bases covered.

Larger set-screws in grip – check!
1/4 turn locking latch connecting flap grip to remote caddy assembly – check!
Rotatable remote caddy with spring-plunger detent every 10 degrees – check!

Unfortunately, one essential item for success with this version was missing from my checklist, and its absence spelled doom:

Non-gorilla pilot – check!

A few days after sending the latest version to John, I got an email with some photos and suggestions, and a few days after that I got my folded/stapled/mutilated flap handle assembly back – boy was I embarrassed! What I had thought was a *brilliant* solution to a problem turned out to be not-so-brilliant when exposed to a pilot who expected things to go together in a particular way. I had designed the 1/4 turn locking mechanism so the locking direction was opposite the normal “righty-tighty” direction because by doing so, the pilot’s normal thumb position on the remote caddy tended to hold the caddy locked onto the flap grip, as opposed to tending to unlock it. Unfortunately, I had forgotten to mention this feat of brilliance to my friend, who expected everything to conform to normal lock/unlock conventions – oops!

Ah, well – it wasn’t a total failure, because we learned some things in the process:

The 3-piece assembly (flap grip, grip-to-caddy converter, caddy) was too long; John couldn’t reach the CN remote’s buttons with his thumb while his hand was comfortably placed on the flap grip.
The 1/4-turn locking mechanism was way too fragile (jokes about gorilla pilots notwithstanding)
The dimensions of the rectangular slot in the grip piece seemed to be just about right.

So, back to the drawing board yet again. hunting through the forest of design possibilities for just the right combination.

Minimize or eliminate the grip-to-caddy converter to reduce overall length
Enlarge/strengthen the 1/4-turn locking mechanism (but keep the opposite direction actuation)

Minimizing or eliminating the converter piece required that I drop the caddy rotation feature. This was kind of overkill anyway, as John had marked the correct (for him) rotation much earlier in the game; I was trying to generalize his preference into something other pilots could use as well. I just needed to think about the rotation feature as something ‘baked in’ to the design, rather than something pilot-adjustable.

Enlarging/Strengthening the 1/4-turn locking mechanism shouldn’t be too much trouble, as the latch parts were available in their own separate design files, so a simple scaling operation should do the trick there. The only limitation on size being that the latching mechanism has to fit into the top of the flap grip and the bottom of the converter piece.

Based on my now extensive experience with printing parts on my PrintrBot, I also added the requirement that each part be printable in a way that preserves the quality of the mating surfaces. I have come to understand that there is a right way and a wrong way to print parts; the right way result in very clean and smooth mating surfaces, while the wrong way results in ugly, bumpy surfaces that no amount of sanding can make right. Fortunately, the combination of careful design and clever positioning of the part on the print plate seems (so far) to be effective. The trick here is to make sure that parts are positioned so the mating surfaces are either perfectly parallel or perfectly perpendicular to the print plate; in either orientation the result is nice, clean surfaces. In the case of the converter part, the mating surfaces aren’t parallel to each other, so it was placed vertically on the print plate so the larger mating surface (remote caddy interface) was perpendicular to the print plate, and the smaller (flap grip) surface was tilted 20 degrees from the vertical. Near-vertical surfaces also print very well, so this resulted in both mating surfaces printing nicely, but the cost was a much longer printing time (2 -3 hours vs about 15 minutes!).

In the previous version, the thickness of the grip-to-caddy converter part was driven by the need for the caddy to rotate on the converter-to-caddy mating surface, which required that the converter have a hole deep enough to accommodate a reasonably sized axle post on the caddy part. Eliminating the rotation feature allowed me to eliminate much of this thickness. I still had the following requirements:

The caddy has to be rotated about 25 degrees CCW with respect to the fore-and-aft centerline of the flap grip, when looking at the top of the caddy. This value was measured from John’s marks on an earlier version.
The caddy has to be tilted vertically about 20 degrees with respect to the flap grip mating surface (again taken from John’s feedback).

To implement the ‘minimized’ grip-to-caddy converter piece, I went back to Autodesk 123d Design’s ‘sketch loft’ feature. This is a very cool capability, and makes it (just) worthwhile to deal with 123d Designs many other ‘non-linear frustrations’ (see 2014/10/tinkercad-vs-123d-design-vs-meshmixer-pick-poison/). I started with a 2D ellipse that matches the flap grip cross-section, and then added a 2D sketch of the caddy. Then I tilted and rotated the caddy sketch as defined above, and then ‘lofted’ the ellipse sketch into the caddy sketch – voila!

: Grip-to-Caddy bottom view showing twist

: Grip-to-Caddy wireframe view showing 25 degree CCW twist

: Ellipse-to-Caddy exploded view

: Grip-to-Caddy converter print. Note vertical placement required to achieve smooth mating surfaces.

Now that I had the grip-to-caddy converter design worked out, all I had to do was to insert the scaled up 1/4-turn latching mechanism into the top of the grip and the bottom of the converter, and print all the parts. Scaling and inserting the latch parts turned out to be pretty easy, as I already had all the latch geometry issues worked out from the time before, and all I had to do was use Tinkercad’s uniform scaling feature to ‘grow’ the latch about 150% or so. After scaling the parts, I latched and unlatched them in Tinkercad a couple of times to make sure that Part A did indeed fit into Part B, and then simply copy/pasted them into the grip and converter designs.

There was one complicating factor; due to printing concerns, I decided to print the converter and caddy parts separately, and then screw them together using 2ea 4-40 screws. I designed matching 2mm pilot holes in both the caddy and converter mating surfaces, and I added thickness to the bottom of the caddy so I could countersink sufficiently (about 3mm) to hide the screw heads below the bottom surface of the caddy. However, when I got everything done, I wound up just gluing the parts together with gap-filling superglue from my local hobby shop, and this seemed to do much better than screws.

In summary, I was able to quickly design and implement a new flap-grip version with ‘baked-in’ caddy twist and tilt, and was able to get the caddy about 12mm (about 1/2 inch) closer to the flap grip than in the old design.

: Note the built-in strain relief loop

: Side exploded view

: Side by side comparison of the old and new versions. Note the newer one (on the right) is considerably shorter

As an added amenity for the pilot, I decided to design and implement a ‘caddy garage’ so John would have a place to store the caddy when it wasn’t in use. As part of the original testing program for the 1/4-turn latch, I had built some thin test pieces with the same cross-section as the flap grip – one with a plug, and one with a socket. I did the same thing for the larger latching mechanism, so all I had to do was to put some mounting holes in the socket test piece and throw it in the box with the completed flap grip/caddy assembly. John can mount the ‘garage’ in some convenient location in his cockpit, and simply latch the caddy assembly to the ‘garage’ after unlatching it from the flap grip.

Caddy Garage. Note mounting holes for convenience

OK, off to the Post Office tomorrow to mail the new stuff to John. I hope this new version will survive the ‘Gorilla Pilot’ test in better order than the last one did! 😉

Frank

ClearNav Joystick Part 4 – Back to the Drawing Board Again

Leave a reply

Part 3 described a ‘back to the drawing board’ approach to the ClearNav remote caddy joystick grip project. That effort resulted in a cylindrical grip with the CN caddy from the clay model grafted on. This worked out OK, but it didn’t look very pretty – it was a bit asymmetric, and I never got the surface smoothness I wanted on the caddy section – it was kind of lumpy and irregular.

So, I went back into MeshMixer and spent some quality time figuring out how to use the sculpting tools more effectively. The documentation for all of the Autodesk 123 products (and TinkerCad too) is almost non-existent, so the only way I have found to learn how to use the various tools is by trolling for the few (and also now outdated) YouTube videos and by brute-force experimentation. Anyway, after many hours of playing around, I figured out how to do such things as combining MeshMixer-provided primitive shapes with my clay model derived CN caddy section, and how to use the ‘attract’ sculpting tool to regularize surfaces – very neat!! I was ultimately able to combine both a rectilinear solid and a torus into something that was a lot more regular, and may well have formed the basis for a successful CN remote caddy grip. However, as I was doing all this (and learning a LOT), it occurred to me that I was once again going about this the hard way….

It finally occurred to me that if all I wanted was a minimal CN remote caddy, I already had one! Early on in the project I constructed a blank plug using TinkerCad and working off the dimensions from an old CN remote I had laying around the house. All I had to do to create a ‘minimalist’ caddy would be to expand this plug a few mm in all directions, and then put a plug-sized hole in the middle of it.

CN Remote plug constructed early on in the project

So, I copy/pasted the above plug into a new TinkerCad design, expanded it as described above, and mated the result with the cylinder grip from Part 3, as shown below.

Minimal CN remote grip with caddy cavity and CN remote shown. Note the cable management loop about halfway down the grip cylinder

Top view showing CN remote installed on minimal grip. Note the cable management loop about halfway down the grip cylinder

Side view showing CN remote installed. Note the two cable management loops built into the design.

Side view showing CN remote cable and cable management loops

On all the previous designs, the plan was to utilize the ClearNav stick-top remote accessory rather than the fob-mounted style, as the fob style has a telephone-style connector on the front to connect the cable that goes from the remote to the ClearNav itself. On this ‘minimalist’ design it occurred to me that I could do away with that requirement by putting a slot in the front of the caddy section to accept the phone jack, and adding a couple of cable management loops to the grip body. In this way the user could simply detach the remote from the fob and press it into the caddy cavity, and presto – instant stick-top remote!

A complication with this plan is that the CN stick-top remote accessory comes equipped with an integrated PTT switch, as the stick top remote assembly typically takes over the real estate formerly used by the original PTT button. Since the ‘minimalist’ design doesn’t do that, the user can simply re-use the original PTT button. To facilitate this, I put a small pilot hole in the top center of the cylinder. I used a pilot hole here because I don’t know the diameter of the original switch.

Anyhoo, this design was shipped off to my friend yesterday, for its date with reality. I have high hopes for this one, but who knows? Stay tuned! 😉

Frank

ClearNav Joystick Part 3 – Back to the Drawing Board

Leave a reply

At the conclusion of Part 2, I had a finished design and a finished 3D part, which I sent off to my friend for evaluation in his glider. Unfortunately, the evaluation was – “It sticks up too high, and hits my stalk-mounted ClearNav unit” After going through some back-and-forth, he sent me some photos to illustrate the problem. The original rubber stick grip with top-mounted PTT switch just clears the bottom of the ClearNav (CN) unit, so anything higher than the original is going to be a problem. The finished grip I created based on the clay model was, unfortunately, about 2″ too high :-(.

So, back to the drawing board. I tried a ‘shorty’ version of the original grip, but that only got me about 1″ of the needed 2″ or so height reduction, so that was out. Then I decided to throw the entire clay model derived design out the window, except for just the CN remote caddy portion, and start over from there. The problem with the original clay model design was that it was slanted in such a way that it could not slip all the way down onto the stick, so I decided to start with a simply cylindrical grip that would slide completely down onto the stick, and then somehow tack the CN remote caddy onto the front.

Cockpit photos showed that the vertical portion of the joystick was about 4″ long, including the trim release trigger, so I started with a cylinder of a little over 100mm. This cylinder would house the hole for the stick, so it would obviously have to be bigger than the stick diameter of 25mm, plus some additional wall thickness. How much bigger? I decided make it just big enough to completely sever the CN remote caddy portion from the rest of the ‘finished’ grip derived from the clay model. I started this process in TinkerCad by placing a cylindrical ‘hole’ in the model, and increasing its diameter until it just stuck out of both sides of the model at the neck, separating the front and back halves. This required a cylinder diameter of 35mm, as shown below.

: Original aircraft stick grip. Just clears the ClearNav

: Aircraft joystick without the grip, showing clearance to ClearNav

: ‘Shorty’ grip version. Still too tall

Separating the CN remote caddy from the rest of the grip

Removing the rest of the grip from the design

After that, I added a rectangular ‘hole’ to remove the now-separated back half of the grip, leaving only the CN remote caddy portion with a 35mm-diameter arc in the back. Then I simply added a 35mm diameter solid cylinder to the design in the same place as the ‘hole’, and of course this cylinder fit perfectly into the arc made earlier by the 35mm diameter ‘hole’. The only thing left to do was to ‘drill’ a 25mm hole into this grip cylinder, leaving a 5mm wall on the sides, and a 3mm wall at the top. Assuming this grip arrangement was seated fully on the stick, then it should stick up no more than 3mm from the top of the stick itself, or less than the height of the original grip plus PTT switch.

: Top view showing CN remote caddy details

: Side View

: Side view showing trim trigger cutout and bottom of remote caddy

This design is nowhere near as elegant as the clay model derived one, but it should work as a practical starting point for a design that actually works – the elegance can come later!

As a side note on all of this, the process of going from the original design to the ‘cylindrical grip’ design was very interesting because it is completely and utterly different than normal design practices. Instead of building another design up from scratch, I was able to add just two ‘holes’ and one hollow cylinder to the original design to come up with something completely different. In TinkerCad, you can add and combine solid parts, but you can also remove material by adding ‘holes’. Every primitive in TinkerCad can be used as either a solid object that adds material to the design, or as a ‘hole’ that removes material from the design. Moreover, portions of a design removed by holes don’t get removed until grouped with that hole. Material that is removed via the addition of a hole isn’t really deleted – it is just ‘hidden’ by whatever combination of holes negates its presence (exporting the design as an STL file and then re-importing it into TinkerCad does, in fact, permanently remove all ‘holed’ portions of the design). This process leads to some bizarre and counter-intuitive results, as it the order in which holes and solids are grouped determines the final visible result. In a complex design, it is quite possible to wind up with an unexpected result, because the grouping order got changed somewhere along the way. If the grouping error occurs down inside the design, then it might not get noticed until the 3D part is printed, and a hole that was supposed to be there isn’t, or some material that wasn’t supposed to be there suddenly reappears!

OK, so this design will go off to my friend tomorrow for yet another clash with reality. Hopefully this one will be a little closer to usable, and maybe point the way toward a final product – we’ll see!

Frank

Dewalt Cordless Drill Bit Holder

Leave a reply

I have a really nice DeWalt DCD710 3/8″ cordless drill/driver, and I think it’s the greatest thing since sliced bread. It’s small, light, very powerful, and the lithium Ion batteries last forever and charge quickly. What more could a guy ask for, anyway?

Well, what I could ask for, but didn’t get, is a convenient way to carry extra (or any, for that matter) driver bits with the cordless drill. My previous drill had a nice bit caddy built onto the case, and this was a very nice feature. I tried gluing a metal clip onto the side of the DeWalt, but that lasted only a day or so before it broke off again, leaving only an ugly scar. So, now that I have my own 3D printing factory, I thought I’d give this another whirl.

The first step was to find a shape that would fit snugly over the top of the drill body, out of the way of normal use. I started with a circular ring with a rectangular cross-section, and adjusted the diameter and thickness to get what I wanted. Initially I kept the width small to cut down on printing time

First try at the body clip ring

After three more tries, I got a body clip that I liked, complete with a prototype bit clips attached. The bit clips were actually the body clip scaled down, rotated, and translated to attach the sides. Unfortunately, the details in the body clip didn’t scale well down to the bit clip size, so I basically had to start from a fresh sheet of virtual paper for the bit clip.

TinkerCad drawing for the final body clip, with prototype bit clips attached

Again it took 3/4 revs to get the bit clip geometry the way I wanted it – with a good, firm grip on the bit, but not so ‘firm’ that it would be impossible to get the bit out of the clip without a broken fingernail or two.

Final bit clip detail. Note the beveled edges (done with a wedge and a rectangle hole

Now to combine the body clip and the bit clip into a final product. Rather than attach the bit clip to the outer surface of the body clip as I did with the prototype, I had the brilliant idea that I could create an outrigger from the body clip that went forward along the drill body, and then attach the clip to the outrigger. This would get the stored bits closer to the drill body, and hopefully make them less prone to being pulled off or snagging.

Final body/bit clip fixture. The clip was copy/pasted into the overall design

ClearNav Joystick Part 2 – From TinkerCad to Finished Print

Leave a reply

At the conclusion of ‘Part 1 – From Clay Model to TinkerCad’, I had finally managed to get a decent 3D model into TinkerCad as a binary STL file. Now the challenge would be to transform that blank template into something that could actually be printed on my PrintrBot and used in a real glider aircraft. To get from where I was to where I wanted to go required the following steps:

Modify the joystick top to accept a ClearNav remote controller
Design in the the ability to install a separate switch, for use either as a ‘climb/cruise’ vario switch or as a separate ‘push-to-talk’ (PTT) switch (the ClearNav stick-top remote controller accessory has it’s own integral PTT switch, but…).
Create a 1″ diameter hole to mount the joystick onto the glider joystick handle/tube
Create a wiring passageway up to the top of the joystick
Print it out on my PrintrBot Simple Metal.

Modify the top to accept a ClearNav remote controller

This step appeared to be the hardest and most critical part of the design, so I decided to tackle it first.

Of course, a fundamental part of this step required that I have precise dimensions for the ClearNav stick-top remote controller, and this turned out to be rather more problematic than I had expected. ClearNav, Inc didn’t have any technical specifications for the part on its website, and the support crew there couldn’t provide anything either. The president of the company promised to send me a 3D design of a blank controller part as an STL file, but never delivered anything, even after multiple inquiries. Fortunately, I had a hand-held remote controller left over from my previous life as a glider pilot, and I happened to know that the outside dimensions of the stick-top and hand-held controllers were identical. The difference was that the stick-top remote has an extra button to replace the normal PTT button, and the hand-held controller does not. Another non-relevant difference is that the hand-held remote has a telephone-style RJ-45 connector, while the stick-top version uses a wire pigtail.

So, I was able to use my hand-held controller to produce a blank 3D model for sizing the stick-top cavity. I started out with a blank that was as precise as I could make it, and then oversized it by about 1mm in all dimensions to use as a ‘hole’ in the design.

Disassembled Hand-held ClearNav Remote

Slightly oversized blank for joystick ClearNav remote cavity

Then I started trying to fit the blank into the top of the joystick, with very limited success initially.

First attempt at fitting the ClearNav remote into the top of the joystick

The thickness of the 3D representation of the clay model just wasn’t sufficient to contain the volume of the ClearNav remote, no matter how I moved it around. So, back to the drawing board (literally!).

I did some more research, and taught myself how to use MeshMixer’s ‘Inflate’ sculpting brush to add some bulk to the top of the joystick, and the ‘Flatten’ brush to slim and smooth the neck area. After several back-and-forths between MeshMixer and TinkerCad, I arrived at a version that would indeed contain the remote.

Close, but no cigar!

Remote is completely contained now in the joystick, so this one is very close to final

Remote is completely contained now in the joystick. Note the neck has been slimmed down as well

Design in the the ability to install a separate switch.

The typical cross-country glider uses a boom microphone and a stick-mounted push-to-talk (PTT) switch for radio communications, and there is often at least one more switch (typically a SPDT toggle) mounted on the forward surface of the stick top. The stick-top ClearNav takes over the real estate used by the original PTT pushbutton, but cleverly replaces it with an integrated PTT switch on the remote itself (this integrated PTT button isn’t on the handheld version). However, I still needed to make room for the front-mounted SPDT switch.

The first step in this portion of the design was to create a 3D model of a ‘subminiature’ SPDT switch. Fortunately I happened to have one in my design shop, left over from an even earlier lifetime as an electrical design engineer. Now that I have my high-quality Fowler calipers from McMaster-Carr, it was a snap to measure the switch and create a fairly accurate 3D model in TinkerCad.

Subminiature SPDT switch model

Once I had the switch, I was able to figure out how to shoehorn it into the top of the joystick, in a forward-facing orientation. This took a while, and involved creating a smaller ‘sub-basement’ cavity under the one created to accommodate the ClearNav remote.

Create the 1″ diameter mounting hole and wiring passages

You’d think this would be the simple part – just a couple of cylindrical ‘holes’ added to the part and we’re done. Unfortunately, life (or joystick design) just ain’t that simple, and what I thought would be a ’10 minutes tops’ job turned into a multi-day headache, and finally into a fun piece of creative work. The initial 1″ diameter hole wasn’t too bad, but since the joystick body isn’t particularly symmetric, it wasn’t (and still isn’t really) clear where the hole should go. I finally opted for the placement that would allow the hole to penetrate the farthest up into the joystick body, as that would result in the widest range of mounting options in the actual aircraft. Then I created a smaller diameter angled cylinder to connect the vertical hole to the top cavity, to act as passage for the necessary wiring.

This seemed to be working really well, until I printed a couple of half-scale models and discovered that both the vertical and slanted cylinders poked through the side of the joystick, even thought the TinkerCad model showed some material thickness all the way around. I was trying (and failing) to figure out how this could possibly happen when my wife, who knows nothing about 3D printing, pointed out that the minimum printable wall thickness stays the same regardless of scale, so something that shows 2-3 min thickness walls at full scale might not be even one min wall thickness at half-scale – oops!

OK, back to the drawing board. I played around with this forever, but finally concluded that I was going to have to give up on the linear passageway idea, and go with something curved if I wanted to have decent wall thickness all the way around the passageway for its entire length from the top of the 1″ mounting hole to the cavity at the top of the joystick. To make this work, I used TinkerCad’s ‘Torus’ primitive, and adjusted the torus diameter and cross-section to get what I wanted. When everything looked right, I used several rectangular ‘holes’ to cut off the sections I didn’t need.

Final version, showing the 1″ vertical cylinder for joystick handle mounting, and the curved wiring passageway

Printing on my PrintrBot Simple Metal

After verifying this hole structure via a half-scale model, I was ready to step up to full scale testing. However, I really really did not want to pay the time and filament cost for multiple full scale prints, so I decided I would just print the top of the model to verify all the cavities at full scale. Since none of the hole structures poked though anymore at half scale, I was pretty confident they wouldn’t at full scale. So, I made a series of full scale prints of just the top portion, and these caused me to make some adjustments in the auxiliary SPDT switch cavity and mounting arrangements. With these partial full scale prints, I was able to use the actual full scale real-world parts (ClearNav remote and subminiature SPDT switch) to check for fit and clearances.

First full scale print of just the top cavity structure. Note the top part of the cavity is incorrect.

Second full scale print of the top cavity structure. Note the top portion of the cavity has been corrected.

Final version of the joystick top cavity structure. This just required a slight resizing of the cavity to accommodate the actual full scale ClearNav remote, and the actual full scale SPDT switch.

After the full scale partial printouts, I was ready to go for a full scale print. The overall height of the joystick (121.6 mm or 4.8″) would be close to the 6″ maximum for my PrintrBot, so I was a bit worried that bad things were going to happen. Also, since this was to be such a long duration print, I was worried about filament jams and all the other things that could go wrong on a long print. As it happened, the print went off without a hitch, and produced a near-perfect model.

: Just getting started…

: Neck and neck 😉

: Starting the ClearNav Remote cavity. Note the small bubble imperfections

: View of the support structure, and more detail on the bubble defects

: Almost finished…

: Finished!

: Interior view of remote controller cavity, with some support structure still visible

: View of the aux switch cavity, with support structure and bubble defects visible

: View of the bottom with central hole support structure and author signature

: Another view of the bottom hole

: Removing the central hole support column with a hole reamer

: Central hole support column removed

: The joystick evolution, from the clay model on the left to the finished 3D print on the right

Summary and Lessons Learned

Although I much prefer to have a ‘real’ project as a motivator when learning a new software package or skill, I probably overreached a bit with such a complex project so early in the learning curve. Learning how to capture a 3D model from photos, how to use MeshMixer’s sculpting tools, advanced TinkerCad techniques, and a challenging print size and overhang configuration all rolled into one project!
The combination of the Autodesk suite of 3D applications (123d Catch, 123d Design, MeshMixer, and TinkerCad) forms a very complete and rich design suite for capturing a 3D object in a form suitable for further development and eventual 3D printing. The fact that all of these applications are (at least for the moment) entirely free is amazing!
the 3D capture and design application world is changing and evolving at warp speed. All of the above apps have serious bugs, deficiencies, and internal inconsistencies, so staying light one’s feet is an absolute necessity. If it doesn’t work right now, check back tomorrow! In my case the 123 Catch application literally changed overnight – on day 1 I couldn’t seem to get my capture to stitch at all, and on the next it was all done automagically! The downside of all this is that skills and/or workarounds learned today may be irrelevant tomorrow, so the need for constant retraining is going to be a fact of life.
As in other endeavors, success is 1% inspiration and 99% perspiration. I just kept banging away at the problem until it gave up and rolled over. It didn’t matter to me whether my progress was due to my brilliance or just sheer doggedness – either one was fine with me ;-).