Other ideas and plans

Even though the EnsembleBot project already is far too big, we can still dream of other instruments we simply must have. Some plans and ideas are more theoretical and far out than others. Other ideas are absolutely serious candidates, coming soon in an EnsembleBot near you!


Currently, the EnsembleBot master circuitry is placed on the backside of the small bell/glockenspiel/percussion cabinet and works as both controller for all these instruments as well as a communications master for the entire EnsembleBot. While this setup sort of works, it’s not without drawbacks.

Structurally, we’d like a more strict separation of functions, though that is more nice-to-have than need-to-have. But having to re-program the master controller every time we change the MIDI mapping or when we wish to temporarily disable/enable instruments is not exactly ideal. Also having the host computer connected to the EnsembleBot through long USB cables is quite annoying.

With a dedicated master we can place it closer to the host computer, and connect it to EnsembleBot through CAN bus, just like all the other instruments are connected.

EnsembleBot overview with dedicated master controller

There’s really no limit to what we could do with a more powerful dedicated controller. We could have a touch display and a user interface to dynamically enable, disable and re-map instruments. We could remove the current restrictions on the slave instruments where they are individually hardcoded for specific MIDI channels. We could implement a kind of service discovery protocol, where the master scans the CAN bus for instruments, who then in return responds with a unique identifier (not MIDI channel), an instrument name and maybe even some standardized MIDI range information. We could use the master for registration of manual “stops” for playing directly on the EnsembleBot with a MIDI keyboard. And so on.

Best of all, we won’t even have to change a thing in the existing master circuitry hardware. The “old” master Arduino controller will just have to be reprogrammed (or dumbed down) to act as an instrument slave controller for the cabinet instruments. The only change would be a general overhaul of the A-side power lines to ensure more standardized and safe power and ground across the EnsembleBot.


This is an awesome robotic project. The history of the hurdy-gurdy (or Drehleier)  is very long, with roots back to medieval times. Over the centuries it has evolved to an immensely complex instrument. One could characterize it as an evolutionary dead end. But, in the hands of a master player, a good hurdy-gurdy can produce a fantastic, interesting and rich sound.

The hurdy-gurdy is a string instrument like the violin or cello. However, instead of a straight bow the strings are made to vabrate by turning a rosined, hand-cranked wheel against the strings. The instrument is played by cranking the wheel and pressing keys on a keyboard.

Concave string bridge on a mandolin

We are going to base the hurdy-gurdy on an existing instrument – a cheap mandolin. We’ve done some tests replacing the flat bridge of a mandolin with a violin bridge reshaped into a concave string arrangement and replacing the strings with cello strings. Placing a rotating and carefully rosined wooden whell above the strings can easily make the instrument sing (or scream, if you like) like a hurdy-gurdy.

Here is a very crude test of the concept:

Where a normal hurdy-gurdy has the wheel inside the instrument body, we are going to place it outside the body and above the strings. The wheel will most likely be cranked by a Nema17 stepper motor or a strong and highly geared DC motor.

The test used 5 strings, and we will most likely use 3 or 4 of the strings as drones (or mouche/bourdon) and the 1 or 2 strings as melody (or chanterelle). The melody string(s) will be controlled with a number of tangents that essentially shortens the vibrating length of the string, thus changing the pitch.

The EnsembleBot Hurdy-gurdy will not feature a trompette/chien or sympathetic strings.


Take two small organ pipes tuned a third apart, submerge the open ends into water and sit back and listen to the nicest bird whistles and songs. This is basically the recipe for a so-called Nachtigall (or nightingale, Vogelschrey, bird whistle or a million other names) stop. It’s a rather special sound effect in baroque pipe organs.

A more precise design of such a setup is hard to find, but it may not be more than described above. It could be a fun supplement to the zimbelstern.


Why not combine robotics with the world’s first electronic instrument? The theremin is in principle a very simple instrument, unique in that it’s probably the only instrument played entirely without touching it. Instead, the player moves his or her hands in the air close to a pair of antennae. One antenna controls the pitch – the closer the hand to the antenna, the higher the pitch/note. The other hand controls the volume.

The principle is very simple, and so is the electronics making it happen (pretty much just an open-ended heterodyne oscillator), but as a musical instrument it is insanely hard to play anything but funny sci-fi sounds.This is mainly due to the fact that you have no tactile feedback when playing it, as well as a non-linear distance/pitch response. Only a precious few people has mastered the theremin since its invention in the 1920’s.

Our plan for EnsembleBot is not to build a theremin, but to build the robotic “hands” to play it.


Admittedly, the Robro project hasn’t exactly been a great success, so far. Even if full functioning, it would have some serious restrictions compared to a normal guitar, simply by being a slide/steel type of instrument. Now, we chose that solution because of its relative simplicity – a single slide instead of tens of actuators, each working on a single fret of a single string to mimick the action of the guitar players left hand. And it is simpler. But having worked with a lot of different techniques during the last few years, the idea of making a “real” robot guitar is no longer completely out of the question.


Yes, we’re going to need a lot of solenoids (72 just for the first 12 frets, or 96 solenoids for 16 frets), and yes, we are facing a heck of a challenging construction, and yes, we are going to find a practical solution to the heating problem of cheap solenoids (and they have to be very cheap, indeed!). We could use micro-servos instead of solenoids, but that would probably end up being both more expensive and more complex to design and build.

The solenoids don’t have to have a particularly hard attack, but they need to be able to hold their extended position for a while without overheating. In the PipeDream projects we handled this problem by designing special dual-channel driver stages with attenuated holding currents to cope with the 1 A current draw of the ZYE1-0530Z solenoids. Here we can use smaller solenoids, or at least solenoids with higher impedance and lower current.

Switch matrix

Even though we’re going to need maybe 96 solenoids, we don’t actually need as many drivers. Since only one solenoid per string will be active at any given time, we can set up a matrix driver stage with e.g. 6 P-channel MOSFET drivers (one for each string) and 16 N-channel MOSFET drivers (one for each fret).

This principle is shown to the right for a subset of the needed solenoids. Here simple switches are shown in place of the MOSFETs.

The six high-side P-channel MOSFETs and the 16 low-side N-channel MOSFETs can be configured like shown in the partial schematic below. The 16 fret drivers can be driven by a 16-channel PWM driver module, enabling us to switch the driving current to PWM after a few milliseconds to achieve an effectively lower holding current.

Double MOSFET switch
Double MOSFET switch (and, yes, I know one of the MOSFETs is reversed in the sketch above. Sorry)

The common PCA9685-based modules may not be good enough, as their maximum PWM frequency is only about 1.5 kHz, and we’ll most likely need a faster PWM frequency to switch faster than the decay of the solenoid magnetic field. So, a homemade driver based on the similar (but faster) PCA9635 could be an option with a PWM frequency of 97 kHz. This is more than fast enough, and should eliminate any problems with demagnetization and dithering.


But much thinking and testing and designing has to be made, before we start ruining a guitar. Even so, I already designed and had produced a PCB for a PCA9635-based driver moduled.

16-cahnnel stackable PCA9635-based MOSFET driver board

A shout-out to EasyEDA.com is in order here. This is the third time I use them to etch, drill and silk-screen my PCB designs, and every time they’ve done a beautiful job at a very reasonable price. You’re likely to pay more for shipping than production, but you’ll have your PCBs within a week.

The board is to a large extend based on the MCP23015 I/O expander and driver boards made for the PipeMare pipe organs. The N-channel MOSFET part is identical, while the logic part is redesigned for the PCA9635 TSSOP-28 chip. Like the MCP23017 boards, these are also stackable, and even with identically located stacking connectors, making it possible to actually combine these driver boards in the same stack.

Now, these boards are not actually made for this guitar project alone, but as a possible general replacement for the dual-channel principle for driving solenoids, that we used in PipeDream61.  If we ever go ahead with the guitar project, we’ll most likely make another compatible stackable module with MCP23017 or similar I/O expanders and P-channel MOSFETs with gate transistors.

The strings can be picked in the same way as the Robro picks, using micro-servos, but we might try something different, like bi-directional push-pull solenoids. They could be made to work much faster than cheap plastic micro-servos, and they would be much easier to calibrate.

Next: Check the videos of EnembleBot in action

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.