Designing 3D Printable Mechanisms in OpenSCAD

My Trumpet-Playing Robot Needed Motor-Controlled Fingers. This Is How I Designed Them

OpenSCAD is my favorite tool for designing 3D-printed parts. It has a feature which appeals to software developers (like me): you create your 3D models by writing code. This means you can use variables, loops and functions, create re-usable components, and make parametric designs (such as the small shelf I designed for my bathroom).

I started my journey with OpenSCAD thanks to a great tutorial called Know only 10 things to be dangerous in OpenSCAD. I spent about 20 minutes following the tutorial, and by the end of the tutorial, I was able to start modeling simple shapes.

After working with OpenSCAD for several years, I developed a workflow which allows modeling complex mechanisms with multiple 3D-printed parts. In this post, I am going to share my workflow with you. I will use the finger mechanism I designed for my Trumpet Playing Robot, which will hopefully be ready for display in the Chrome Dev Summit in a few weeks.

My 3D Design Workflow Was Very Inefficient

I can sit and watch it for hours

I downloaded the rack and the pinion models from Thingiverse, and then designed the other part that would attach the rack to the motor. The first version of the design didn’t work — the rack was too tight with the gear, and it wouldn’t really moved. I had to iterate on this part twice until it worked.

Later, I wanted to create a more complex version of this mechanism and design motorized syringe pump. The final design had 11 different 3D-printed parts, 16 screws and a bearing:

What would you do with a Syringe pump?

My design process was the same — designing a single part, printing it, trying to attach it to the other parts, failing, and then iterating until it worked. I printed each part at least 3 different times until I got it right (well, only 2 times for the big ladders).

As you can imagine, designing this part took several days, as I had to wait for the parts to print before I could test them, making each iteration taking an hour or more. Overall, the process was very inefficient and also wasted a lot of plastic (but I recycle my failed prints ♻).

Integration Tests Before Going To Product

In other words, I wanted a way to do Integration Tests for my designs before I go to production. Just like I do when creating Web apps 😎

I spent a couple of days looking for information online, reading discussions in the OpenSCAD forums, and found an incomplete tutorial about using OpenSCAD for Machine Design. And this is what I came up with:

You Need To Take Vitamins 💊

You will need to model these Vitamins, despite the facts that you are not going to print them. This will allow you to use them in your design’s integration tests — it is similar to mocking a database server, if we continue with the web application analogy.

The first Vitamin I modeled for the finger mechanism project was the trumpet itself. Obviously, the mechanism would need to attach to the trumpet and press its keys. Modeling the complete trumpet would take me a long of time, so I only modeled the relevant section: the keys (and the attached values), and part of the lead pipe that goes in front of the keys, as I wanted to attach the mechanism to it:

my first Vitamin: the keys, valves, and part of the lead pipe

Modeling this took me roughly half an hour. I spent most of the time measuring different parts of the trumpet with the calipers and translating then to OpenSCAD code. I ended up with about 40 lines of code for this Vitamin.

The next Vitamin was a Micro-servo motor. I had a couple of MG90S Servos servos that I wanted to use in this design, so I needed a model for these as well. This time, I didn’t have to work hard — I simply found a ready-made model on Thingiverse and used it.

Not the prettiest servo model, but does the trick

At this point, I had the basic Vitamins I needed, so I moved on to the next step: designing the actual parts.

Designing Parts, Creating Assemblies

  • Part — whatever you 3D print (or laser-cut, mill, etc.)
  • Vitamin — whatever you don’t 3D Print (screws, motors, electronics, 🎺)
  • Assembly — Parts, Vitamins and other Assemblies put together

The directory structure that I use also follows these three concepts — each part, vitamin or assembly is defined in a single OpenSCAD source file, and there are 3 directories in my project: parts, vitamins and assemblies.

Top-Down Breakdown

This is what the completed design looks like (in OpenSCAD):

3 servos, one trumpet
And a side view

The design includes two sub-assemblies, each of them is repeated 3 times in the final design. The Servo assembly and the Finger assembly:

The Servo Assembly
The Finger Assembly

These assemblies are parametric — they have a slightly different variation that I use for the middle finger. As you can see in the assembly of the complete mechanism (the photo above), the middle finger mechanism is oriented in a different direction, so the angle of the rack has to be different:

My Design Process

During this process, I created the initial version of the Servo mount part and and fingertip part (that’s the square part on top of the key).

Then, I started creating the Servo Assembly and the Finger Assembly. Initially, these weren’t separated assemblies — I started by putting everything into the top-level assembly, but later refactored the code and split it to smaller sub-assemblies.

At this point, I started to move around the assemblies in place the parts in different ways. For instance, this is one of the initial sketches, where I tried to mount all the 3 servos in the same orientation:

As you can see, the fingers in this design are far-off the center of the keys, so I decided to ditch this approach and experiment with putting together the parts differently.

The Code Editing Workflow

I edit the files in Visual Studio Code, and see the changes whenever I save on the right

You can configure OpenSCAD to automatically reload and render the model whenever you change one of the source files. In order to do this, go to the Design menu, and enable Automatic Reload and Preview there. I also keep the small OpenSCAD output console open, so see any error messages.

I also find this similar to developing Web Applications: It is just like having a browser open with live reload and the Devtools Console for spotting any error messages and debug prints.

Even More Vitamins!

I plan to add the screws and the nuts as soon as I figure out how the lips for the robot will work. After all, the goal of my project is to get some nice sounds out of the trumpet!

Testing The Mechanism In Action

I implemented this animation by translating both the Finger Assembly (the pink part) and the Trumpet’s keys by $t * -15.45 (this is the distance that the actually keys go down when depressed, measured using the calipers).

I also rotated the servo gear by $t * 50, so it rotates 50 degrees as the rack goes down. This is not very accurate, but was good enough for me just to get a feeling how everything works together.

Printing, Assembling and Testing!

Three fingers and two finger tips in one go

After printing everything, it took me about an hour to assemble and fine-tune the mechanism. Everything fit nicely, except for the leftmost finger which did not have a tight enough grip on the lead pipe (seems like my measurements were a little bit off, after all). After fixing this issue, the printed mechanism was assembled and ready for testing!

It looks more colorful on the computer

And the final mechanism in action:

You can find the current version of the project (as well as the JavaScript code that controls the fingers, running on Espruino) in the GitHub repo. The parts are also available on Thingiverse.

Wait, There Is More!

The assembly files that I produced during the design also double as documentation. They show you exactly how many copies of each part you need, how to put everything together. You can also learn from these files about the Vitamins — for instance, how many screws and nuts are needed, their sizes, and where each one goes in the final design.

OpenSCAD is a very capable tool, but it seems to lack well-established coding conventions and best-practices. It also lacks a widely-adopted package manager (many library authors simply use Thingiverse as their distributed channel). I hope to see the ecosystem evolve and that this blog post will serve as a step forward in this direction.

Happy modeling!

This is the 21st post in my Postober Challenge — writing something new every single day throughout October.

I will tweet whenever I publish a new post, promise! ✍

Google Developer Expert for Web Technologies, Maker and Public Speaker

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store