Plastic Bottle Upcycling with TrussFab

csm_chair_FEA-nolable-02_ea4ad9b60f
Image from TrussFab.

A perpetual limitation of 3D printing is the print volume of the 3D printer. Any creations larger than that volume must necessarily consist of multiple pieces joined together in some way. My Luggable PC project is built from 3D printed pieces (each piece limited in size by the print volume) mounted on a skeleton of aluminum extrusions.

Aluminum extrusions are quite economical for the precision and flexibility they offer, but such capabilities aren’t always necessary for a project. Less expensive construction materials are available offering varying levels of construction flexibility, strength, and precision depending on the specific requirements of the project.

For the researchers behind TrussFab, they chose to utilize the ubiquitous plastic beverage bottle as structural component. Mass produced to exact specifications, the overall size is predictable and topped by a bottle cap mechanism necessarily precise to seal the contents of the bottle. And best of all, empty bottles that have successfully served their primary mission of beverage delivery are easily available at quantity.

These bottles are very strong in specific ways but quite weak in others. TrussFab leverages their strength and avoids their weakness by building them into truss structures. The software calculates the geometry required at the joints of the trusses and generates STL files for them to be 3D printed. The results are human-scale structures with the arbitrary shape flexibility of 3D printing made possible within the (relatively) tiny volume of a 3D printer.

Presented recently at ACM CHI’17 (Association for Computing Machinery, conference for Computer-Human Interaction 2017) the biggest frustration with TrussFab is that the software is not yet generally available for hobbyists to play with. In the meantime, their project page has links to a few generated structures on Thingiverse and a YouTube video.

 

3D Printed Acrylic Fixture

3D Printed Acrylic Fixture CADSince my last fixture project was foiled by laser cutter kerf, I thought I’d try 3D printing the next fixture to avoid laser cutter kerf spoiling my fixture accuracy.

I started with the same idea as the previous project – just put two pieces together in a right angle joint. This time I put a hinge in the fixture. The idea is that the work pieces can be put in place separately (with acrylic cement already applied to joint surfaces) and then I rotate about the hinge to bring the pieces together.

I could have stopped there, but a single joint doesn’t do anything. If I’m using up acrylic, I prefer building something that can be nominally useful. So the ambition grew to building a little box: 5 pieces (four identical for sides and one for bottom) joined together by simple right angle joints. This is only a small box, just big enough to be useful for things like holding little screws, nuts, and washers. It seemed a suitable baby step since most of the projects I have in mind for acrylic (starting with the FreeNAS enclosure) basically boil down to acrylic boxes as well. So the fixture was designed in CAD, then multiplied to create three additional copies at right angles to each other, to create my box building fixture.

3D Printed Acrylic FixtureThe end result demonstrated that, even though a 3D printer does not have cutter kerf to compensate for, it introduces other errors in the system. Maybe expensive industrial 3D printers would have enough accuracy to make this fixture work, but my little hobbyist level printer definitely did not. The corners of the box did not mate together as precisely as it did in my mind. The gaps are too wide and uneven for acrylic cement to bridge.

After this experiment, I decided I should go back to laser cutting and learn how to compensate for kerf and/or design around it.

 

Fusion 360 Foundational Concepts Tutorial

foundational-concepts-iconI went back into Autodesk’s Fusion 360 learning resources for a refresher and to set myself up to learn the Fusion 360 CAM modules. The last time I went through the tutorials, I had skipped the CAM functionality because I had no machine tools and were not likely to get time on anybody else’s machinery. Now that I might be able to access Tux-Lab fabrication machinery, I wanted to make sure I won’t break the machine from doing anything stupid in Fusion 360.

Before I got to CAM, though, the “Foundational Concepts” section caught my attention. I either didn’t see it the last time or it made no impression on me at the time. I went through the set of short videos and they were surprisingly informative. Most tutorials for Fusion 360 (and most other software packages in general) are happy to tell users how to accomplish their tasks. This is a slightly different twist – the foundation concepts talk about why Fusion 360 is the way it is. About how they tried to restructure a CAD package for the cloud-based future, about how they restructured the workflow to take advantage of today’s level of computation power at our fingertips, so on and so forth.

I come from a software engineering background and I’m all too aware of the fact that the end user typically has no idea what the software developer had intended as they built the piece of software. It can be argued that the end user doesn’t need to know anything about the intent if the software is sufficiently well-designed. But for something complex like a CAD package, I believe there is value in learning the motivation behind the design.

And even if the user doesn’t need to know, sometimes the user is curious and wants to know. I appreciate the Fusion 360 user education team for putting this information out there available for those who want to know.

Fusion 360 vs. Onshape: Raspberry Pi

raspberry-pi-logoAnd now for something completely silly: let’s look at how our two competing hobbyist-friendly CAD offerings fare on the hobbyist-friendly single-board computer, the Raspberry Pi.

(Spoiler: both failed.)

Raspberry Pi

I have on hand the Raspberry Pi 3 Model B. Featuring a far more powerful CPU than the original Pi which finally made the platform usable for basic computing tasks.

When the Raspberry Pi foundation updated its Raspbian operating system with PIXEL, they switched the default web browser from Epiphany to Chromium, the open-source fork of Google’s Chrome browser. Bringing in a mainstream HTML engine resulted in far superior compatibility with a wider range of web sites, supporting many of the latest web standards, including WebGL which is what we’ll be playing with today.

Autodesk Fusion 360

Fusion 360 is a native desktop application compiled for Windows and MacOS, so we obviously couldn’t run that on the Pi. However, there is a web component: Fusion 360 projects can be shared on the Autodesk 360 collaboration service. From there, the CAD model can be viewed in a web browser via WebGL on non-Windows/MacOS platforms.

While such files can be viewed on a desktop machine running Ubuntu and Chromium, a Raspberry Pi 3 running Chromium is not up to the task. Only about half of the menu bar and navigation controls are rendered correctly, and in the area of the screen where the actual model data should be, we get only a few nonsensical rectangles.

Onshape

Before this experiment I had occasionally worked on my Onshape projects on my desktop running Ubuntu and Chromium, so I had thought the web-based Onshape would have an advantage in Raspberry Pi Chromium. It did, just not usefully so.

In contrast to A360’s partial menu UI rendering, all of Onshape’s menu UI elements rendered correctly. Unfortunately, the actual CAD model is absent in the Raspberry Pi Chromium environment as well. We get the “Loading…” circle and it was never replaced by the CAD model.

Conclusion

Sorry, everyone, you can’t build a web-based CAD workstation with a $35 Raspberry Pi 3.

You can, however, use these WebGL sites as a stress test of the Raspberry Pi. I had three different ways of powering my Pi and this experiment proved enlightening.

  1. A Belkin-branded 12V to 5V USB power adapter: This one delivered good steady voltage at light load, but when the workload spiked to 100% the voltage dropped low enough for the Pi to brown out and reset.
  2. A cheap Harbor Freight 12V to 5V USB adapter: This one never delivered good voltage. Even at light load, the Pi would occasionally flash the low-voltage warning icon, but never low enough to trigger a reboot. When the workload spiked to 100%, the voltage is still poor but also never dropped enough to trigger a reset. Hurray for consistent mediocrity!
  3. An wall outlet AC to 5V DC power unit (specifically advertised to support the Raspberry Pi) worked as advertised – no low-voltage warnings and no resets.

OpenSCAD for Motion Visualization

Now that I’ve climbed the initial learning curve for OpenSCAD, it’s time to start working towards my goal for doing this: I want to visualize arbitrary motion between components as a rough draft to see how things move in virtual space.

This is not an unique capability in CAD packages. Both Fusion 360 and Onshape have ability to define object hierarchies and visualize their motion. However, they are both focused on the assemblies that have been mechanically defined in CAD. If I wanted to visualize a  hinge-like motion between two objects, I first need to build that hinge in CAD or the software would “helpfully” tell me I’m trying to perform an impossible motion in my design.

In contrast, OpenSCAD does not care. I can place a rotate() operation anywhere I want and it won’t care if there’s no hinge in the design. It is happy to let me rotate about an arbitrary point in 3D space with no hardware around it. This makes OpenSCAD ideal for trying out how wild ideas would (or would not) work in virtual space, before getting down to the nitty-gritty about how to build the mechanisms to implement those wild ideas.

This means some cool-looking ideas would turn out to be impossible to implement, but that’s OK. I wanted something with a lot more freedom than I can get in the CAD packages that limit what I can do for (in their view) my own protection.

But that’s still in the future. For now I’m still climbing the learning curve of moving objects around in OpenSCAD in a way that ties into the built-in animation capability and generating animated GIF to illustrate concepts.

As a learning exercise, I’ve re-implemented the motion of the Luggable PC hinge. Thanks to OpenSCAD flexibility, I didn’t have to spend time building the hinge before I move it!

lug3

Hello OpenSCAD! You remind me of an old friend…

HelloOpenSCADOpenSCAD is a very popular 3D modeling tool in the 3D printing community. Many of the projects available to print on Thingiverse were generated from OpenSCAD. This is most obvious when authors uploaded their .scad files for sharing with the community, but also visible as a core pillar of the “customizable things” section. The customization capability is made possible by variables the author made adjustable in OpenSCAD.

I started designing for 3D printing with the GUI CAD tools, Onshape and Fusion360, so the text-based approach of OpenSCAD seemed strange and foreign at first glance. The official OpenSCAD web site documentation pointed to several tutorials. Not knowing the comparative advantage of one versus another, I just clicked on the first in the list How to use OpenSCAD. It linked to several other tutorials, the most notable one being Know only 10 things to be dangerous in OpenSCAD as having the most compact words-to-content ratio.

I had initially approached it as “Boy it’s going to be hard to completely change my thinking” but as I got along in the tutorial I realized things didn’t feel as foreign as I thought it might be. Digging through musty memories, I realized I had encountered this type of 3D modeling (CSG or Constructive Solid Geometry) before many years ago in the form of POV-Ray. Back in the days when a 20-megahertz 386 was a pretty speedy CPU, and the floating point processor wasn’t a standard part of every PC. I had to upgrade my computer with the purchase of a 387 math co-processor in order to render my POV-Ray projects at a reasonable speed.

Editing CSG files for rendering in POV-Ray was my first exposure to 3D computer graphics, and I chose it because it was free. I couldn’t afford GUI graphics software (the flagship at the time was Autodesk 3D Studio) so I started with the basics and I learned a lot that way. In time, I might appreciate the straightforward simplicity of OpenSCAD in the same way.

Fusion 360 vs. Onshape: Multiple Views

Advantage: Onshape.

When working on a CAD project, the majority of my time is spent focused on a single view of my subject. But when it comes to align parts into an assembly, it is very useful to have multiple views, and this is where Fusion 360 falls behind Onshape.

Fusion 360 can toggle between the standard single-view mode and a quad-view mode. In quad-view mode, the window starts with four equal-sized views and the user can adjust the relative sizes within the window.

F360MultiView

This is a bare-bones baseline level of functionality. I can work with it, but I’m not happy with it. Onshape does it better.

Onshape takes advantage of the fact it runs in a browser. You can have multiple browser windows open on the same Onshape project, and each window can be a different view. Onshape infrastructure keeps all the windows in sync – any change made in one view is immediately reflected in all the others. Want four views? Open four windows. Want 6 views? (top/bottom/left/right/front/back) Open six windows.

And since these Onshape views are all separate windows, they can be placed on different monitors to build a great multi-monitor workspace. Fusion 360 is limited to a single window. Trying to use Fusion 360 across multiple monitors means manually scaling the application window across them. Toolbars get cut in half, resolution doesn’t match, problems left and right. It is not ideal.

What about opening multiple instances of Fusion 360, one for each monitor? It turns out that doesn’t work because the instances are unaware of each other. Change made in one instance is not reflected in the others until the user hits “Save” in one instance and “Reload” in all the other open instances.

The obvious conclusion is that Fusion 360 works best on a single high-resolution display instead of multiple screens. Sadly this is also false. As mentioned in my first Fusion 360 vs. Onshape comparison, Fusion 360 does not scale to high-resolution displays (4K, Retina, etc.) whereas Onshape takes advantage of the fact browser makers have long since handled the problem of scaling for high resolution.

Since the time of my first comparison Autodesk knowledge base published a workaround for running Fusion 360 on high-resolution displays. With these workarounds, Fusion 360 now runs poorly at 4K, which I guess is an improvement over not running at all.

With more multi-view options, including multi-monitor, plus superior support for high-resolution displays, Onshape handily wins this comparison, and they know it.

Luggable PC Project Complete!

The Luggable PC project page on Hackaday.io has been fully documented for anybody to build their own home-built 3D-printed computer chassis. All the components required for assembly have been listed, and all the steps of assembly documented with pictures taken at each and every step.

I expect to continue to make small tweaks to the design, improving little things here and there, but the machine is usable enough that I should stop tinkering with it and actually start using it. This means no new versions rebuilt from scratch for the foreseeable future. But if inspiration strikes, there will be!

When I’ve taken my Luggable PC to various maker events in the local area I’ve received generally positive reception and appreciation. Now I wait to see if anybody actually takes me up on the information compiled and build their own.

LuggablePCAssembly640

Luggable PC Drive Bay Revisions

Here’s the 2.5″ drive bay in the initial iteration of the threaded-box Luggable PC design. It is a simple, basic place to hold one laptop-sized drive, but not a very efficient use of space.

IMG_20170228_090310 - Copy

The most obvious thing to do is to vertically stack another drives adjacent to the existing drive. Easy to do in CAD, but has problems in the real world.

Problem 1: How do you access the fasteners? The laptop storage market have mostly settled around two basic fastener schemes: four screws on the bottom of the drive, or four screws along the sides. If we use the side fasteners, they would not be accessible for drive replacement without taking the whole case apart. The bottom fasteners would be accessible, except that bracket would be impossible to print on a FDM 3D printer.

Problem 2: How do you connect the wires? While at first glance there is enough space to physically accommodate the drive and its plugs, it fails to take into account the wires. The wires for the existing drive barely clear the edge in the picture. Stacking another drive into that space (even if moving it another cm or two to the right) would demand wires make relatively sharp right-angle turns. This would place strain on the connectors including the fragile unsupported SATA connectors on the drive itself.

After some experimentation with the available space, keeping in mind the requirements above, I decided to angle the two stacked drives:

IMG_20170228_091421 - Copy

Now the Luggable PC has two independent drives: One for Windows 10, and another for Ubuntu Linux 16.10.

This design solves the fastener issue: in this arrangement, it is possible to 3D print the drive bay so both drives are held in place by the shape without use of any screws on the sides or on the bottom. Both drives are held in place by a single 3D printed clamp that is secured with just two screws. The downside is that the design only works when both drives are present. It is unable to hold a single drive in place.

This also solves the initial wiring issue: By angling both drives, the wires do not have to make sharp turns and would not place unreasonable strain on the connectors. However, this comes at a cost of usable interior volume. By angling the connectors, and avoiding sharp turns, the cables consumed more precious interior volume than the previous design.

Going back to the idea of drives stacked in the available volume, we revisit the problem of forcing wires to make sharp turns. The turns can be relaxed if we can find more room for the wires without angling it into precious interior volume. The solution turned out to be… turning the drives instead! By rotating 90 degrees a drive can be positioned to make room for the cables’ turns. It also allows two drives to exist side-by-side, allowing the bay to work with a single drive or dual drives.

This design was incorporated into the following iteration of the chassis, built using aluminum extrusions instead of threaded rods as the metal structure.

DriveBayV3

 

Luggable PC Feet Design Considerations

After some time using the assembled Luggable PC prototype, I wanted to adjust the screen ergonomics. While the screen has been raised to a height much more comfortable compared to a laptop, after a few hours of use I wished I could tilt the screen upwards a few degrees.

At first glance this would have been impractical – the screen hinge design is already complicated and adding a tilt adjustment mechanism would only make it more so. So instead of tilting the screen, let’s achieve the goal by tilting the entire Luggable PC by adding 3D printed feet that can be bolted to the bottom of the machine.

The easiest approach would have been to print a simple solid wedge with the desired angle, but I decided to be a little more experimental. I played with Fusion 360’s spline tool to sketch out feet that are designed to move and flex a tiny bit. The flexibility adds two features:

  1. Shock absorption: We still need to be careful setting it down on a surface, but the minute bit of flexibility we gain will help cushion the harshest part of initial impact and make it feel less like we’re breaking the machine every time we set it down.
  2. Flatness compensation: With a bit of flexibility in the feet, the Luggable PC can now conform to surfaces that are not perfectly flat. Previously, the solid bottom means it will rock on 3 out of 4 feet on any surface that isn’t perfectly flat (which is most of them.)

Here is the first iteration, which accomplishes the desired goals:

IMG_20170228_173547 - Copy

Unfortunately it also has a problem: by moving the contact points inward, the front feet are now uncomfortably close to the center of gravity. A slight push from the rear will send the whole thing toppling forward. The design needs to be adjusted to have a wider stance… but we are constrained by the fact the fastening nuts still need to be accessible.

In this case, the short-term fix is to move the feet as far front as possible while still allowing wrench access to fasteners.

IMG_20170228_174620 - Copy

The real solution is to redesign the bottom of the case to accommodate the feet while maintaining a sufficiently wide stance. This idea was incorporated into the following iteration of the Luggable PC. As it used aluminum extrusions for backbone instead of threaded rods, the new wider feet were installed on the bottom extrusion.

FeetV3