Tag Archives: 3D printing

LIDAR-Lite Gets its Own Motor

Posted June 16, 2015

In my last post (http://gfpbridge.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

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

Miniature DC motor with chassis mount and belt drive wheel

Miniature DC motor partially installed in chassis mount

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

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

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

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

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)

Stay tuned!

Frank

LIDAR-Lite Rotates!

1 Reply

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

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

ClearNav Joystick Part 1 – From Clay Model to TinkerCad

Leave a reply

In a previous lifetime I was a cross-country glider pilot. This means I would regularly fly an aircraft with no engine up to six or seven hours and cover hundreds of miles without landing. Expert glider pilots can do this at average speeds approaching or exceeding interstate speed limits. Since gliders must stop occasionally to regain lost altitude in rising air currents (called thermals), their inter-thermal speed has to be significantly higher than the average, meaning a glider flying along an interstate will easily outpace the cars and trucks below.

Anyway, a friend from that previous life showed me a clay model of a custom joystick handle he was working on. The model was intended to incorporate a complex instrument remote control panel in the top of the joystick, where the push-to-talk (PTT) switch would normally go. When he first showed it to me, I was just thinking about getting into 3D printing and in my ignorance I thought this would be a perfect 3D printing project (little did I know at the time!). Later on when I had just ordered (but not yet received) my PrintrBot Simple Metal Kit I asked him to send me his clay model, and promised him I would at least make the effort to turn his clay model into a finished 3D printed product. This is the story of how I went from 3D ignoramus to Joystick hero in a few short weeks.

07/28/14 Capture using Autodesk’s Catch/123d: I’ve gone through this now a couple of times with BZ’s joystick, and I am now starting to get some clues.

The first time through was with just some painter’s tape patches placed on the joystick surface to give some reference points. This worked, but not very well. The patches didn’t stick very well due to the oil in the clay, and I got a number of unstitched photos. Also, I couldn’t manually stitch photos together. just never worked
Joystick with blue painter’s tape ‘stickies’
Next time through I used narrow strips of painter’s tape, wound around the joystick in several places. This worked MUCH better, and in fact I had zero unstitched photos, and was eventually able to generate a full 3D STL file editable in 123d Design and TinkerCad (see below). However, the only fly in the ointment was that the painter’s tape wasn’t completely conformal with the joystick surface in several places, and this came through on the model as raised ridges.

Joystick wound with strips of blue painter’s tape

The third try was to replace the painter’s tape with felt-tipped marker markings. The thought was that this would be more conformal to the surface, and if done properly would also be appropriate for automatic stitching. However, what actually happened was that the model came through OK, but with many unstitched photos. Then when I laboriously manually stitched a number of photos into the model, the re-submission crashed. ouch! This problem continued even if I re-submitted after stitching only one photo. This was all done with the PC version, so I tried again with the online version.
Joystick with Sharpie pen markings for surface contrast
In the online version, I see that I have a number of projects that appear to be In processing’, even though they are older (as in days older) versions of the joystick process, and there doesn’t appear to be any way to remove them!. The Sharpie’ version is shown to be complete, and when I open it in the online version it looks great, but in the online version there is no lasso’ tool for removing all the background elements.

08/07/14: Working with a newer version of 123 Catch

A newer version of 123 Catch became available in the last few days, so I decided to try a new capture using my photos from the Sharpie’ version of BZ’s joystick. This time when I uploaded the photos, I didn’t get any unstitched images. yay!!
I discovered the mesh resolution’ setting in Catch, and was able to change the mesh resolution from Mobile’ to Maximum’. This also takes a selection area as a parameter, and re-meshes only the portion of the capture within the selection, so it takes much less time than doing the entire scene. Remeshing took only a few minutes with the selection limited to just the area around the joystick.

08/09/14 – Still working on the Sharpie’ joystick: I was able to print a ½ scale model of the joystick, but I discovered it was all solid inside, notwithstanding the hollow’ attribute advertised by the Catch/3D Print operations above. Also, I wasn’t able to figure out how to undo the minimum support’ setting that left the joystick on its side. So, I’m making another try at this from scratch and will try to document the steps more rigorously.

Started a New Capture’ in 123 Catch, using the 07/28/14 Sharpie photos. This took a long time to process. Catch asked for a Capture file name, and suggested Capture_2014_08_09_06_17_31′ (date and time). When it completed, I was presented with the constructed model as shown below.
First successful capture of the ‘Sharpie’ model
I did an immediate Save As at this point, and noticed I already had a Capture_2014_08_09_06_17_31′ folder and .3dp file saved in the same folder as the original Sharpie photos (140728_Sharpie Photos). I have seen this before, but AFAICT, this folder and file aren’t usable later. can’t figure that out. I cancelled the Save As operation.
I found a 2011 tutorial at http://aucache.autodesk.com/au2011/sessions/4056/class_handouts/v1_AC4056%20-%20It%E2%80%99s%20a%20Snap!%20Take%20a%20photograph%20and%20create%20a%203D%20Model.pdf. This was apparently a presentation at an AutoDesk conference. This tutorial explained things like the photo lock’ mode (constrains the scene view to just the available discrete camera locations), but wasn’t all that helpful for my purposes.
I somehow got into Photo Lock’ (PL) mode and now I can’t get out again! If I disable PL, I get a blank screen with just the camera locations and the coordinate axes shown. Hmm, I clicked on show mesh’ and now I have the scene back. weird. Yep. confirmed that you have to have show mesh’ checked to get *anything*!
OK, selected the lasso selection tool and deleted everything around the joystick. Shit! I deleted a small section of the mesh, and *then* got a dialog warning me that I needed to make sure I was in the correct mesh quality setting, or edits might be lost. So I tried to undo the mesh edit, only to find there’s no UNDO function!
Used the rectangle selection tool to select just a small area around the joystick for re-meshing (including part of the deleted area from the previous bullet) as shown. Note that I rotated the view to a fairly high angle so that my selection was restricted to just the newspaper around the joystick. omitting any of the office background.
Remeshing a selection of the original Sharpie model
Selected the Remesh icon and selected Maximum Quality’. This produced a dialog with the original capture name (Capture_2014_08_09_06_17_31) which I assume is a reference to the previously uploaded photos. Curiously, this field is editable, giving the impression I could have used another name. maybe then it would have saved the re-mesh into a different capture structure?
OK, the remesh finished successfully, leaving me with a rectangular patch from the original scene.
Sharpie model after remeshing a selected portion of the original scene
I saved this result as 140809 Sharpie Capture After Remesh.3dp’. I don’t really know if this will actually save anything or be useful later, but I thought it couldn’t hurt. I also saved it as an .OBJ file, which might actually be more useful/permanent. By default, both these files were saved in the same folder as the original capture photos, i.e. F:\3D Projects\Joystick\140728_Joystick Sharpie Photos’. The .3dp file is only 5.3KB, indicating that (as noted in the 2011 presentation) it only contains references to the online location of the Capture files, not the files themselves). The .OBJ file is a more respectable 4 MB.
Back in Catch, I used the lasso tool to further refine the mesh to just the joystick, and saved this in both .3dp and .OBJ format. Even after being very careful with the lasso operation, I wound up with a big hole on the right side of the joystick base. I saw this before on a previous run through, but found that the 123d Print application was able to repair’ the hole. strange.
After the ‘lasso and delete’ operation, I have a big hole in the bottom of the joystick!
Saved this as 140809 Sharpie Capture After Remesh And Lasso’ .3dp and .obj.
Clicked on the 3D Print button to launch the AutoDesk MeshMixer app. By default, this opens with the joystick in the minimum support’ orientation. no idea how to change it back to the upright orientation (note – as it turns out, this isn’t the ‘minimum support’ orientation – it just looks like it).
Clicked on the Modify’ icon and got a warning message about losing unsaved changes. Clicked OK, and got the following:
After fooling around in the MeshMixer for an hour or so, I finally gave up on this model. I couldn’t figure out a way to add surface material to repair the hole. Still fooling around, I selected Edits’ and Overhangs’ and MeshMixer crashed. oops!
Back in Catch, I opened the file 140809 Sharpie Capture After Remesh.3dp’, and it indeed opened the correct project, as shown.
This time I used this model to go to 3D Print, (which launches Autodesk’s MeshMixer app) and got the following default layout.
This is actually a bit nicer to work with, as the section of newsprint gives me a decent X-Y plane to work with for transforming the joystick to the upright position. After rotating 270 deg around X axis, and then Move to Platform’ to move the base down to the Z = 0 level, I got the following.
After a 270 degree rotation around the X axis and then ‘Move to Platform’
Hmm, I tried to go back to the Modify’ mode in MM and discovered you can’t do that. Apparently there are two distinct MM modes. Modify’ and Print’ and they aren’t integrated. Transforms/Translations in Print’ mode don’t flow back into Modify’ mode. bummer! To get to Print’ mode, click on Send to Print’. To get back to Modify’ mode, click on Modify’.
OK, finally figured out Rot/Translate in Modify’ view. The center box’ is for linear scaling for all axes. The colored arcs are for rotating about the various axes, and the triangles are for translating. After figuring this out, I was able to rotate the joystick to an upright orientation, as shown. I still have no idea what the L’, S’, A’, and W’ labels are for.
Exported the model as 140809_MeshMixer_Rev3.stl’ in Ascii STL format and tried to import it into TinkerCad, but it doesn’t seem to want to import at all. Imports easily into 123D Design, however. Tried this trick again with the binary formatted STL file. The binary version does import into TinkerCad (and 123d Design) OK. yay!!
OK, figured out how to use the Select tools to delete the newsprint mesh, leaving only the joystick (hopefully), as shown.
Joystick after newsprint removal
After this I was able to use the transform tools in Modify’ mode to rotate/translate the joystick into a more understandable orientation, and saved the model as 140809_MM_Rev5_RotXlt_bin.stl’.
Next I tried using the Edit/Plane Cut tool to cut off the garbage at the bottom of the joystick, as shown below. I accepted the transform, which gave me just a disk. oops!
Tried again, with the cut plane rotated 180 degrees. This time things worked out much better. The selection and the result are shown below.
Plan cut operation with the plane rotated 180 degrees from the original
After proper plane cut selection, the joystick bottom is nice and flat

Saved this as 140809_MM_Rev6_PlaneCut_bin.stl. Then I opened it in TinkerCad successfully, as shown below. Note that the joystick in TinkerCad is still laying on its side, so maybe the transformations in MM aren’t getting into the export file?

TinkerCad model after successful Plane Cut operation. Note that the model is on its side

Tried undoing the rotation transformation in MM and re-exporting. OK, this worked! Apparently, the coordinate systems in MM and the rest of the world are defined differently. so if going from Catch to MM to TinkerCad, don’t have to rotate in Meshmixer.
After undoing the rotations & translations
After this, I went back into MM and used the Flatten’ brush to smooth out some of the rough spots, saved it as Rev8Flattened, and imported that back into TC

Summarizing lessons learned so far:

MeshMixer can be used to remove the newsprint background from the Catch export
No need to rotate/translate in MM when going from Catch to MM to TinkerCad
Probably need to establish a scale in Catch, as the resulting model winds up being very small in MM and TC (3.5 x 6 mm). OTOH, I can just as easily establish the scale in TC (this is what I wound up doing).

08/09/14: Starting from 140809 Sharpie Capture After Remesh.3dp:

Click on 3DPrint to launch MeshMixer and load the file: Opens as 2014-08-09-13-06-47_8466_41.obj’ in MM, with the Print’ mode active.
Click on Modify’ to get into that mode.
In Modify’ mode:

o Analysis/Inspector/Auto Repair All

o Edit/Plane Cut & adjust as low as possible with a solid bottom. This should also remove much of the newsprint area.

o Choose Select tool with Unwrap Brush active and double-click anywhere in the remaining newsprint area to select it all. Then hit DELETE to delete it all. Save this state as a .MIX file, and export it as a binary STL. Check in TC to make sure it can be imported properly (140809_MeshMixer_Rev4_JoystickOnly_binary.stl)

o Choose Sculpt’ and the Flatten’ brush. Run the brush over the entire surface, flattening out minor bumps and wiggles. Spent some quality time on the top surface, flattening it out for future work. Went through a bunch of revisions, but saved the last one as 140809_MM_Rev9_Flattened_bin.stl.

08/09/14 – in TinkerCad:

Imported 140809_MM_Rev9_Flattened_bin.stl. This was very small, but it was properly oriented with the joystick upright. yay!
Found the all axis scale’ function. Alt-Shift-Corner resizer. This allowed me to scale all axes until the vertical dimension matched the measured 121.5mm from the original clay model. Saved this in TinkerCad to 140809 Rev 9 Scaled to Clay Model’

Next up – Modifying the basic model in TinkerCad to incorporate the mounting hole for the joystick, wiring passage to the joystick head, and mounting arrangements for an auxiliary switch and the ClearNav remote head. Stay tuned!

Clamp for Bicycle Aux Instrument Holder

1 Reply

Just as I was contemplating the dive into 3D printing, a friend came to me with an interesting problem. Ray is an avid bicycler, and he has a number of auxiliary gadgets attached to his bicycle. One of these gadgets is an auxiliary instrument holder that clamps onto the horizontal tube from the vertical fork tube to the handlebars, and provides its own small ‘handlebar’ for more instruments, as shown in the following picture

Side view showing aux instrument bar holder clamped to horizontal fork tube

Side view of aux instrument holder

Unfortunately, after a short time the strap that holds the instrument holder to the bicycle broke, rendering the whole thing useless. The first time he thought it was maybe it was just a random manufacturing defect, but after going through several that all exhibited the same failure mode, he basically gave up on that model. When I mentioned that I might be able to help out with my brand-new PrintrBot 3D printer, he brought me the parts.

When Ray brought the broken clamp in, it quickly became obvious what the problem was, and why it was breaking so quickly. the system uses a metal band that is drawn down into a cavity by an adjustment screw, and this action requires the clamp band to make a right-angle turn right at the nut on the screw. The band metal is thin steel, and quickly develops fatigue cracks right at the bend.

Mounting clamp interior view showing the capture nut

Mounting clamp and steel strap. Note the break occurs right at the right-angle bend

Capture bolt/nut. Notice the strap residue still on the nut

After some thought, I decided that the solution was not to try and reproduce the system exactly, but to redesign the clamping system to use a standard pipe clamp instead of the steel strap. The trick would be to ‘cut’ a slot through the body of the plastic clamp in such a way as to still allow the mounting bolt to attach the clamp to the rest of the system, while still leaving enough thickness to prevent the pipe clamp from breaking through the plastic part under load.

After going through a number of revisions and downright mistakes, I finally got a product that worked. One of the mistakes I made was trying to create the part without a decent set of calipers for precision measurements, resulting in a part that was about 10% undersized in one dimension, and about 10% oversized in the other. I remedied this problem by getting a very nice Fowler digital caliper from McMaster-Carr. Another minor problem was that the capture screw was too long, and interfered with the pipe clamp band. I solved this problem by simply cutting down the bolt a bit with a hacksaw, as the extra length was no longer needed. Also, as this was my first real 3D printing project, the print quality left something to be desired. Since this project, I have figured out how to get much higher quality prints.