The third post in this series describes how the final design of the mouse was modelled and some of the problems encountered. Before talking about these problems however, I should state that to a considerable extent they constitute an unfair criticism. I’m well aware that the task I’ve attempted in this exercise is one that SketchUp isn’t intended, designed or advertised as being able to do. Nonetheless, I think that by describing the software’s limitations, the magnitude of the task that would face a consumer-designer, using software tools such as SketchUp, is better appreciated. It also makes clearer what the specification and design of a software tool aimed at consumers should be.
The final task in the design stage of the exercise (detailed in the previous post) was to create accurate sketches based on the minimum volume models, which were used as underlays. These drawings were then scanned and imported into SketchUp to act as templates. It was at this point, right at the beginning of the modelling phase, that SketchUp’s limitations began to show, because there is no way to choose which plane to import images into, they all come into the ground (XY) plane. That means that if you have a number of elevations, e.g. front, side, top etc, most will need to be rotated into place. But the image is treated as an object, you can only pick a corner or edge, which means aligning what you’ve actually drawn (rather than the edge of what you scanned) in each elevation has to be done by eye. It’s not a big gripe, but it kind of sets the tone for what’s to come.
The basic profile of the mouse, constructed using imported sketches as a template (click for larger image)
In a previous post I talked about how the rationale behind this exercise was that an ‘expert amateur’ could reverse engineer an existing product and make it available for anyone else to copy or modify. The modification bit is what I’m particularly interested in, and to make this easier I proposed that this expert amateur could separate out the ‘critical features’ necessary to ensure that any new design would work. In this case the critical features referred to things like screw towers and snap features (to ensure the parts align and fit together), supports for the pcb and mouse scroll wheel (to make sure the electronics fit), pushers for the switches under the left and right buttons (to make sure the electronics work), etc. These critical feature parts had been modelled in Solidworks, and needed to be imported into SketchUp, however the only non-native import option included with the software is for .3ds files, which Solidworks cannot create. This meant searching for a Rubyscript file which provided a common import option (in this case as an .stl file), which was relatively easy to find, but once again highlights the extent to which Google relies on the expertise and goodwill of the SketchUp community.
Critical features imported into SketchUp as .stl files (click for larger image)
Although the .stl importer worked well, bringing the critical feature parts into SketchUp was a frustrating experience. Within Solidworks I had created an assembly, then exported as an .stl file; this file then contained a number of discrete, solid parts. But because the critical features included cutters (to trim material away) as well as actual features, some of the parts overlapped. When imported to SketchUp, the parts were no longer seen as solid but instead as surfaces, and because of the way SketchUp works any overlapping surfaces are immediately absorbed into each other. So importing in this way was completely useless. Instead I had to create a number of different .stl files, none of which could contain overlapping parts, import each one into SketchUp, and then orient and align by hand. In all it took almost a day to figure this out and do it, a task which should have taken only a few minutes.
Having imported the critical features, I could begin with the actual modelling. The external and visible surfaces were created relatively easily, in part because of the number of test models (21) that I’d made during the previous phase. But it was when the internal features and details came to be modelled that SketchUp’s limitations became most apparent. As I’ve already said, in some ways this is an unfair criticism. However in a ‘professional’ CAD system such as Solidworks or similar, there are numerous dedicated tools to aid the task of modelling a product’s internal details. Considering the new design was relatively simple (in terms of surface complexity) and contained no draft angles (not needed for an additive manufactured part), the design would probably have presented few problems. A simple ‘Shell’ operation (to create wall thicknesses), followed by ‘Combine’ or ‘Cut’ operations to integrate the critical features, and fillets to finish the edges, would probably have achieved 90% or so of what I was trying to do. Unfortunately SketchUp doesn’t have a ‘Shell’ command, nor indeed any boolean commands (unless you pay $495 for the Pro version), nor a fillet command, and so all these operations were carried out by intersecting and trimming surfaces.
Save point after 2 days work, with most of the external surfaces completed (click for larger image)
Not only was this incredibly laborious and time-consuming, it also presented numerous opportunities to make mistakes. And of course, the more laborious and boring it felt, the more mistakes I made. These mistakes were then further compounded by SketchUp (unlike a parametric modeller) having no ‘history tree’; this meant that when a mistake was spotted there was no clue as to when it had been made. The only solution was to go back through the previously saved versions of the model until I found one which didn’t contain the error. One of the diary entries (which maybe I’ll have to censor before I submit the thesis) shows my irritation when it describes “three fucking hours wasted”?. I suppose I learnt my lesson though – at one point I was saving a new version every 15 minutes or so.
The middle part of the mouse, which contains most of the features for locating the pcb (click for larger image)
This isn’t to say everything in SketchUp is bad though. For one thing, the ‘Paste In Place’ command is fantastic – copy a surface or part from one file and paste in place in another, and the surface or part will appear in exactly the spot you expect it. I’ve worked with CAD systems costing thousands of dollars that can’t handle that as well as SketchUp. And that certainly made things easier: on numerous occasions when I needed the original of a surface which had been trimmed and absorbed into the model, all I needed to do was go back to a previously saved version, copy the surface then paste in place in the latest model. I can forgive SketchUp for many things because of the way this is implemented.
Unfortunately though, things only got worse as I got nearer the end of the modelling. Despite the previously mentioned Rubyscript plug-in which was found to help with the issue of identifying where a part was unable to ‘knit’ to become solid, it was still a time-consuming task. This wasn’t helped by some really bad graphical clipping which sometimes occurred when zoomed in close – I did find a suggestion on the SketchUp forum which was to disable hardware acceleration under the OpenGL preference tab, but on my machine this option was greyed out (i.e. couldn’t be turned off).
The finished CAD model (click for larger image)
And, just when I thought I had everything sorted, SketchUp threw up one last problem. In order to manufacture a 3D part via additive manufacturing it’s first necessary to create a file of the correct format, usually .stl or .wrl. All the parts contained within that file have to be fully enclosed volumes (or more colloquially, “watertight”), with no overlapping, redundant or unstitched surfaces. My final design contained three parts, as in the original mouse design, all of which SketchUp identified as being ‘solid’. In its vanilla version, SketchUp has a number of export options as standard, one of which (.wrl) had the potential to be used directly, and another (.obj) which I thought could be taken into an intermediary program and then re-exported. However when I started experimenting with the options a number of problems became apparent, and so for this reason I had to search for another Rubyscript plugin which would allow the export of files in .stl format. I made files in all three formats and imported them into three CAD packages (Rhino, Solidworks and ProE) in order to check their integrity (I used three programs so that, in case of problems, I could work out whether the issue lay with the SketchUp exported file or the importing CAD program). The results are shown below:
|Exported file format||Rhino||Solidworks||ProE||File is usable for AM?|
|.wrl||Can be opened but all parts centred and combined to one part||Can be opened but no parts present (i.e. file is empty)||Can be opened but all parts centred and combined to one part||No|
|.obj||Can be opened but only one of three parts is a closed volume||Cannot be opened (no .obj import option)||Can be opened but no parts present (i.e. file is empty)||No|
|.stl||Can be opened, 3 discrete parts, all closed volumes in correct positions||Can be opened, 3 discrete parts, all closed volumes in correct positions||Can be opened, 3 discrete parts, all closed volumes in correct positions||Yes|
As can be seen, only the .stl option, provided by the Rubyscript plug-in, gave an exported file which could actually be used. The plug-in gave no options for the size or quality of file (usually provided by specifying the number of triangles), but the file size was about what I would expect (about 2.5Mb for the three parts), and when opened in Solidworks it looked okay. There didn’t really seem to be much option but to go with what I had.
Keyshot renderings of the finished model (click for larger image). After importing the .stl files into Solidworks I added some fillets (which isn’t possible within SketchUp) to make the model appear more realistic, however the sharp edges and corners reinforce the impression that this is a rendering rather than a real product.
The .stl files were output to an Objet Connex500 machine, and built using the VeroWhitePlus material. The system allows the choice of a matte or gloss finish with this material and I chose gloss as it would tend to highlight mistakes rather than hide them. I received the parts about a week after they had been built, and one of the first things I noticed was that the top part had deformed, such that the two mouse buttons were not at the same height. This is apparently a well known property of the material if the part isn’t stored in the right position; I was advised to run the part under a hot tap to try to get it back into shape, but actually after leaving it on my desk in sunlight it returned to its normal shape. However, there was a more fundamental problem, which was essentially that the main body part was too small. Although the PCB fitted inside, it was very tight and took a considerable amount of time easing it into place. At one point I broke the interior feature designed to hold the mouse scroll wheel (though actually this was as much to do with clumsiness as with bad fit) and resorted to super glue to fix it. The snap features at the front of the mouse, which located the middle part (in blue in the renderings above) to the base were also over-engineered, making them too stiff and so even harder to get the parts to fit together. If this was project was simply for my own use I would probably have started sanding things down with some wet-or-dry paper and made the parts fit better that way, but as part of the PhD I need to be able to show them in their raw, unadulterated state. There was some good news though; was once assembled, the buttons worked, locating correctly on the tactile switches on the PCB, as did the scroll wheel.
Parts from the Objet Connex500 machine (click for larger image). The snap fits were so stiff that once assembled the middle and bottom parts couldn’t be taken apart again.
The assembled mouse, with pcb inside (click for larger image)
And so the final part of the exercise was to return to SketchUp and modify the model one last time. This involved widening the whole product by 1mm, though of course it wasn’t just a matter of scaling things, instead I needed to move certain features but not others. As I expected this wasn’t a simple task, and it took more than a day to achieve. I also reduced the size of the snap locators so they were more flexible. Having made the changes and created new .stl files, this time I uploaded to the Shapeways site and used that service, in order to get better quality parts. I’d hoped to get the middle part polished, but this wasn’t available in the time I needed to receive the parts back, so instead I opted for SLS ‘White, Strong & Flexible’ nylon for the base and button parts, and SLS ‘Frosted Ultra Detail’ acrylic for the middle part. After waiting for a couple of weeks to get the parts back, to my relief they fitted together fine and I was finally able to assemble a working mouse. In all it took about ten weeks from first sitting down to learn SketchUp to ‘proving’ it’s possible to use SketchUp to create a unique, complex, functioning consumer product.
Parts supplied by Shapeways (click for larger image). Even though the snaps had been made smaller, the parts still couldn’t be disassembled once put together.
Scroll wheel and pcb fitted (click for larger image)
The final assembled product (click for larger image)
Throughout this series of posts I’ve referred to a number of CAD models and files which were created. These are all available, in different locations, to download and are subject to the same Creative Commons licence as the rest of this site (ie an Attribution-Share Alike licence).
The SketchUp model is available from my page in the Google 3D Warehouse
The models I used for manufacturing the parts are available from my page at Shapeways
The .stl files, which can be used for manufacturing the parts, can be are available from the download page on this site (as are the SketchUp files).
The Critical Features file, which can be used as a start point to design a functioning mouse, is also available from the download page in both .stl and .step formats.
The Safe Model is also available from the download page. Use this to ensure any new design is big enough to accommodate the internal parts of the mouse.
The Solidworks file of the reverse engineered mouse isn’t available for download – it’s 168Mb, which is way over the limit my site allows. If anyone wants a copy send me a mail and I can give access to my ftp site.