TL;DR: I re-learned basic electromagnetic theory and built a solenoid actuator that’s suitable for pressing a piano key. I also built a driver circuit that can scale up to all 88 keys. In the future, I will improve this system and use it to build a self-playing piano.

Background

I own an upright piano that nobody plays. It occurred to me about a year ago that it might be fun to build a machine that plays it by pressing the keys for me. This isn’t a new idea and seems to be the core of a viable business, but I’m interested in finding a way to do it myself for a reasonably low dollar cost¹. As usual, my main goal is to learn new things, and getting something to actually work is a secondary goal—although in practice it usually works out better to focus on the second goal and let the first one take care of itself.

In mechanical terms, playing a piano is the process of pushing any of 88 keys in a sequence that produces music. Keys are levers that connect to an internal mechanism that strikes one or more strings to produce a tone. Non-trivial compositions require more than one key to be pressed simultaneously and held down for up to several seconds. Pressing keys with more or less speed produces louder or quieter sound. This soulless description reveals that any piano playing system ultimately takes some kind of musical representation as input and produces corresponding motion at the keyboard as output.

At the beginning of this project, the part that seemed most uncertain to me was the part involving motion. It seemed like having 88 actuators, one for each key, would be expensive and unnecessary, since a human can produce excellent music with only ten fingers. I briefly considered options that involved fewer than 88 actuators, but none of them seemed any easier than reducing the cost of each actuator enough that having one per key would be acceptable. I eventually decided to use solenoid actuators, which convert electrical energy into kinetic energy by creating a magnetic field that exerts a force on a ferromagnetic plunger. The solenoid actuators that I could find from reputable manufacturers weren’t likely to work for one reason or another. Some were too big, others weren’t rated for enough power or didn’t produce enough force, and most were too expensive for me to consider². I saw a good opportunity to learn how to model and design a solenoid for a specific application, and this post is the culmination of that effort over about six months.

Along the way, I found the Player Piano Build Community Discord server, where several people are discussing how to approach this problem, and a few are actually doing it for themselves. I was surprised that such a community even existed, and I think it’s wonderful that the internet makes it possible. Without it, the handful of us working on this kind of thing would be unlikely to find each other, and we’d be doomed to work alone. The Discord was founded by Brandon Switzer, who completed his own player piano in 2019. Brandon’s work, as well as that of others on the Discord, has given me useful knowledge and ideas for how to proceed with my own project.

E&M Review

I began this project by reviewing electromagnetic theory. I studied this topic a few years ago, but I had definitely lost a lot of detail in my understanding. I found an inexpensive textbook a while ago called Fundamentals of Electromagnetics with MATLAB, 2nd ed., by Lonngren, Savov, and Jost (ISBN 1-891121-58-8). This book seemed to be a good mix of fundamental theory and practical simulation. My initial goal was to work through all exercises in the first three chapters, which cover basic vector calculus, static electric fields, and static magnetic fields. I collected my solutions into a git repository. I didn’t achieve my goal, but I did complete the exercises in the first chapter as well as about half in the second chapter (not posted as of writing). I also read through all three chapters and partially refreshed my understanding in all three areas.

I think part of why I didn’t finish all the exercises is that I realized that solving the solenoid problem I was interested in with purely analytical techniques would be difficult. The chapter in Lonngren about static magnetic fields didn’t seem to cover enough of how ferromagnetic materials behave to give me the tools to work this all out on paper. Also, as I did more reading online about how other people approach this problem, computer simulation became more and more attractive. Eventually, I gave in and switched fully to the computer.

This fundamental review was still useful because it refreshed my knowledge enough to get me started. The textbook’s focus on MATLAB also helped me later on because it had been several years since I last wrote anything in MATLAB/Octave. I also refreshed and expanded my knowledge of LaTeX as a result of typing up my exercise solutions. It was a good use of my time overall, even though it didn’t turn out how I’d imagined. I will probably return to this book in the future because it covers much more material that’s interesting to me, such as transmission lines and antennas.

Experiments and Iteration

Designing via Simulation with xfemm

It became clear to me that simulating my designs in software would be the most practical way to proceed. This allowed me to quickly and inexpensively move throughout the design space and estimate the importance of different parameters. There were cases when the simulation matched reality closely enough that it was possible to estimate the absolute importance of each parameter, but even when this wasn’t true it was still useful to compare their relative importance. I developed an intuition for the problem by tweaking values and observing the results. I ended up considering the following independent design parameters:

• coil
  • number of turns
  • gap between coil interior and plunger exterior
  • maximum voltage
  • height
  • wire diameter (both the conducting portion and the insulation)
• plunger
  • material
  • radius
  • length
  • vertical position with respect to coil
• frame (for focusing the magnetic field lines)
  • material
  • geometry (thickness, position, etc.)

The model, which I describe below, takes these independent parameters along with some fixed values and produces the following dependent design parameters of interest:

• maximum force
• current at maximum force
• current at key holding force (about 0.7 N)
• coil resistance
• physical size (particularly overall radius)
• plunger mass
• total cost

I didn’t generate these lists at the beginning. It took several weeks of thinking and tweaking to build up the model and figure out what matters in this problem. After I realized that it was useful to think of independent and dependent parameters, I factored them out in the code and started running a process that I call “poor man’s gradient descent”. In this process, you start somewhere plausible in the design space and then modify each parameter by a small amount. Then, you compare the new output to the old output and record the change somewhere. Repeat for all independent parameters, and you have the gradient at that design point. Then, it’s a simple matter of moving along the gradient and repeating. The only difference between this process and real gradient descent is that there’s a human in the loop, which I think is a little annoying but also probably improves the result with significantly less compute and software scaffolding. This approach also probably minimizes attraction to degenerate solutions (i.e., solutions that can’t work for reasons that aren’t in the model).

I wrote the model in GNU Octave using xfemm to do the actual E&M simulation. I had to draw the line somewhere in this project, and implementing my own E&M finite element analyzer that was correct, fast, etc., seemed a little silly. I might as well make my own silicon wafers at that point. The code that I wrote more or less follows a few xfemm and FEMM examples by building up a problem structure, solving it, and then querying values of interest from the solution. My model seems to run in about half a second on my machine, which is plenty fast enough for the iteration procedure I described above.

The model code is here.

Notable Rules of Thumb for Solenoid Design

• The best way to increase force is to increase power. The plunger moves because of the magnetic field that the solenoid generates, and the magnetic field forms because of the current flowing through the turns of wire. More current means more magnetic field, which usually means more force. Since the coil acts like a resistor at DC, the only way to get more current flowing through it is to reduce the resistance or increase the voltage. Both of these increase power as well. Just be careful not to exceed the fusing current of the wire in the coil or the overall thermal capacity of the system.
• More turns doesn’t mean more force. It may seem like increasing the number of turns in the coil should increase the force on the plunger. This would be true if the extra turns had zero resistance, but they don’t. Copper has a fixed resistivity for most purposes, which produces a particular resistance per unit length for a given wire diameter. Above a certain number of turns, adding more simply increases the total resistance of the coil, decreasing current and power and usually decreasing force. The extra turns end up further away from the coil, so their magnetic effect is reduced, while their electrical effect is always the same.
• Maximum force occurs when the plunger is halfway out of the coil. I don’t know why this is the case, but I guess it has to do with the maximum amount of plunger material intersecting with the most effective portion of the solenoid field. For this application, I aligned the plunger and coil such that the plunger is halfway out of the coil when the key is in the down (pressed) position. This allows the actuator to dissipate the least power while holding the key down, which can go on for several seconds in some cases.
• Magnetic focusing material is best spent near the plunger. Most solenoid designs, including my own for this project, include some kind of casing made out of a material with high magnetic permeability, such as steel. The casing gathers the magnetic field lines as they exit the ends of the solenoid and causes them to intersect with the plunger. This produces more force for the same input power. When deciding where to put this material, put most of it on the end where the plunger is, as well as the sides. Focusing material that’s far from the plunger doesn’t do much good.
• Increasing plunger length is usually an inexpensive way to increase force. Steel rods are cheaper than thicker wire or a bigger power supply.
• Minimize the gap between the coil and the plunger. Just don’t exceed the tolerances of your fabrication process.
• Wind the coils as tightly as possible. Inefficient coil packing reduces the coil’s ability to produce a strong magnetic field near the plunger. This is because turns that are further from the plunger suffer more from the inverse-square behavior of the magnetic field intensity around the wire.

PWM Driver Circuit

After the solenoid actuator, it seemed to me that the most uncertain part of this project was the driver circuit. By “driver circuit” I mean more or less all of the other electronic parts of the system, but in particular I mean the parts that convert MIDI into corresponding amounts of power being applied to the correct solenoids. I wanted to prove that it was possible to control all 88 solenoids in a satisfactory way without having to actually build them. This is all about reducing uncertainty and risk. I think this was valuable because my ideas for how to approach this problem changed a lot, and if I’d blindly pushed forward with my original idea then I would have ended up with something suboptimal or even broken.

The two most important concepts supporting the driver circuit are pulse width modulation (PWM) and time division multiplexing (TDM). PWM solves the digital-analog interface between the microcontroller and the solenoids, and TDM allows a hobbyist microcontroller to play 88 keys without 88 output pins. I’ll explain both of these concepts in order.

MOSFETs are good at switching lots of power without any moving parts. They are a natural choice for this application because they switch quickly (nanoseconds) and don’t dissipate much power when driven correctly. They’re also inexpensive and small. (For a primer on MOSFETs, see this video.) At first, I thought I would need to find a way to apply just the right amount of voltage to the gate in order to get the desired current through the load, but that isn’t a good approach. MOSFETs are meant to be driven into their saturation region, where they conduct as much current as they can for a given drain-source potential. I say that they’re “meant” to be driven this way because they have the least drain-source resistance in this region, so they’re maximally efficient. Keeping a MOSFET in its linear region is bad for heavy loads because it heats them up. Also, controlling the gate potential precisely enough to modulate the output power would have been quite difficult, I think.

PWM is the solution to this problem. PWM only requires a digital signal, which is good for the microcontroller and good for the MOSFET. The catch is that both sides need to switch at the PWM frequency. I initially designed this frequency to be a comfortable 100 Hz or so, thinking that the solenoid body would absorb this low frequency. I was completely wrong about that, and my first attempts basically produced a loud buzzer that also happened to push piano keys. The best way to fix this is to push the frequency much higher, above the audible range for most humans (20 kHz)³. Having done that, I also realized that I’d need to include a flyback diode to avoid destroying the MOSFETs⁴.

That solves the interface problem, but we still don’t have enough pins to drive 88 keys on a typical MCU. Here I took some inspiration from Brandon’s design. He uses discrete shift register ICs in his system between the MCU and the MOSFETs. If I’m honest, I don’t fully understand their purpose⁵, but it gave me the idea to use ordinary parallel register ICs to buffer the MCU’s output. A sufficiently fast microcontroller can set the appropriate values for all the keys by iterating through each IC and setting the correct pin states at the proper times. This is the main principle of TDM. This also moves the burden of keeping 88 persistent output bits away from the microcontroller (where pins are relatively costly) to cheap register ICs.

To explain this more clearly, let’s examine the circuit in the diagram below, which focuses on a single key but is expandable to all 88.

I selected the Teensy 4.1 for its speed, number of pins, and ability to act as a USB device, which will be useful later in the project for receiving MIDI. (I also had one lying around.) The IC in the middle is the 8-bit register (datasheet). Whenever the register sees a rising edge on the CLK pin (pin 11), it reads the binary values on each of the D pins on the left (pins 2–9) and copies them to the Q pins on the right (pins 12–19). In this circuit, the first data pin is connected to digital pin 0 on the Teensy, and the clock pin is connected to digital pin 13. When the Teensy wants to set the value of 1Q, it first sets the value of 1D and then sends a pulse to the CLK pin. The register then copies the value from 1D to 1Q.

The Teensy is a 3.3 V device, but the MOSFET I’m working with right now works best with a higher gate voltage. In the future I might switch to a different MOSFET without this property or just try 3.3 V directly and see what happens. For now, I’ve included a BJT common-emitter amplifier that uses the output of the Q pins on the register IC to switch a 5 V signal from the Teensy. (The VIN pin is nominally at 5 V when the Teensy is powered by USB.) Notably, this inverts the signal, so I have to account for that in software.

This design is overkill for a single key, but my intention is to expand it to 88 keys. To do that, I’ll first have to connect the remaining 7 bits to some digital pins, and then I’ll add another 10 register ICs with the same connections. They’ll all share the same data pins, but each will have a separate clock pin. In total, only 19 pins are needed on the Teensy—eight for the data pins, which are shared among all registers, and 11 clock pins. The Teensy can set the data pins to any values, and the register ICs will ignore them until the Teensy sends a pulse on any of their clock pins. This allows the Teensy to reuse the data pins between all registers over time, dividing its attention among all the keys.

Playing One Piano Key

See the video at the top.

In the video, I’ve temporarily set up the solenoid to press a single key by clamping it to the piano. The driver circuit is on a breadboard, and I’ve set up the code on the Teensy to read the state of a push button and use that as input for the key. The code can currently handle 32 simultaneously pressed keys, although I haven’t tested this limit, so it may be more or fewer in reality. In this test, I set the velocity to 64 out of 127, and anecdotally the sound is in the moderate range. It’s probably possible to adjust the force profile across the velocity spectrum to give any desired behavior.

Here are the design parameters for the solenoid in the video, which is the best design I’ve come up with so far:

• 280 turns of 22 AWG magnet wire
• 3/8” (9.525 mm) 1018 steel plunger, 42 mm long
• 32 mm coil height
• 2 mm 1018 steel plates on the top and two sides
• 1.35 mm gap between coil and plunger (0.6 mm of which is plastic wall)
• 24 V
• ~0.8 ohm coil resistance
• 14 W holding power
• at holding force, coil reaches 65 °C from room temperature in about two minutes

This design is too wide by about 2 mm, so I need to trim it slightly in a future iteration, but I don’t anticipate that being an issue. This will probably reduce the force somewhat, but I think that’s acceptable in exchange for being able to pack all the solenoids in a tidy row.

Known Issues and Future Work

The solenoid rattles when it hits its top or bottom position. There are two likely causes. One is that the plunger sits on top of a plastic plunger extension, which the plunger pushes out the bottom to move the key. The plunger and its extension are not rigidly connected, and there isn’t any padding between them, so their small collisions make a clicking sound. Similarly, the bottom of the plunger extension is bare plastic, so it clicks slightly when it contacts the key surface. I think it will be easy enough to fix the second problem with some stick-on felt circles that are usually meant to prevent chair legs from scratching floors. I’m not sure yet what the best solution might be for the plunger/extension interface, but I’ll probably start with ordinary glue and see how that performs.

I printed the non-metallic parts in PLA with a 0.6 mm nozzle and 0.3 mm layer height. The most practical way to print these parts puts the layer lines perpendicular to the motion of the plunger, so I think it’s possible that the plunger could catch on the layer lines and get stuck. I’ve observed this on benchtop force tests but not on the actual piano. If it becomes an issue, I’ll probably have to switch to a different material. That would help with a related problem, which is that PLA begins to soften around 60 °C. It’s possible—even easy—to reach that temperature after a few minutes of continuous use, at which point the solenoid structure warps and makes it difficult for the plunger to move. I might explore using nylon tubing for the central cylinder section and printing the rest, or something like that.

Overall, I’m happy with this solenoid design, but I know it can be even better. I want to spend a bit more time optimizing it before I commit to building the full system. I’ll probably do a test with a single octave as a midpoint between a single key and the full keyboard. Also, in the next part of this project I’ll improve the driver code further and try to add support for USB MIDI so I can send music from my laptop.