I’ve been inspired by a number of kinetic sculptures over the years. The first piece I recall being thoroughly mesmerized by was Bruce Shapiro’s “Sisyphus Table”; prior to Bruce’s commercialization of this table, I embarked on a project to build my own version.

While I ultimately abandoned that project, it wasn’t before writing a few thousand lines of code. And while the artistry of the table I ultimately purchased from Sisyphus Industries exceeded what I had in development, the exploration process took me in an unexpected direction. It’s this exploration, and elements of the initial prototyping phase, that I enjoy most of all - it brings me back to some of the joy of Product Management in my earlier roles in the tech industry, the symbiosis of learning and building, bringing something novel to the world that fills a unique niche or solves a unique problem.

This brings me to two recent kinetic sculpture projects that have been piquing my interest. I’ll cover the first - a ceiling-mounted kinetic sculpture - here, and the second with next month’s post.

The Inspiration

Having wrapped up an embedded electronics project in this clock and coming across these amazing (but pricey) servo motors, I stumbled across this art installation in the Munich BMW Museum, made by ART+COM Studios of Germany. It tells the evolution of BMW engineering’s via a grid of balls , where each ball can move vertically via a string from the ceiling in order to “draw” the surface of profile of an object.

Motion Building Blocks

I wanted to reproduce a version of this for myself, but - perhaps not surprisingly - I could not find any software packages that come close to simulating this with user-provided content.

So I decided to build something from scratch, in an area I know reasonably well: algorithms and coding. But I need to learn a bit more about motion control in order to produce the incredibly smooth motion of the balls in the BMW exhibit. From a few Google searches about motion control, I come across concepts of active damping in servo motors, as well as the more basic - but still sophisticated - multi-stage motion profiles.

This will be important so that the balls do not bounce on the string - and so I start out by coding a foundational seven-phase motion profile that allows the definition of not just a max velocity and max acceleration, but also a maximum change in acceleration. Depending on those three maximums, and the target distance to cover, we get a four, six, or seven phase motion curve.

Now with one ball in motion, I can expand that to an arbitrarily large grid of balls moving between two “images” or surface profiles. But there are a few different ways to integrate the movement of all the pieces together, as each ball has a potentially different distance to travel and thus a potentially different arrival time:

1. They can each independently move as fast as the limits allow, so that balls with a shorter distance to travel arrive first;

2. They can all arrive in sync, so that they all simultaneously arrive in the same amount of time that it would take the ball with the longest amount of time to travel; or

3. They can all arrive at their final point at the same time, but each ball can move chaotically subject to the constraints of smooth motion, so that the final image appears magically just at the last moment.

This is all best visualized not by the acceleration and velocity plots above, but by a simulation of where the balls actually are in space, in a demonstration of those three main methods of motion towards a target position. While the text “images” being displayed here not something this type of display is well-suited for, they do demonstrate the differences between those motion paths fairly well.

With the software proof-of-concept done, the next step was to figure out something interesting to animate!

A Gathering Storm

My partner had an interesting idea, of tornados slowly moving in the sky, occasionally merging or splitting. And I played a bit with this, via modeling rotating stacks of ellipses where the stack could shrink or grow and rotate in an interconnected way, but alas I did not get it to achieve a degree of visual interest that would warrant a large installation.

I also tried working with a few 3D models, defining transformations (rotations, translations, etc.) as I moved the surface of the object across the field of pixels. But here as well, while it was a great proof of concept of a continuously-evolving randomly generated image, I did not find the result visually compelling.

I think visuals that have gradually shifting heights like panning gradually over a dynamic landscape, or clouds, or a better-implemented storm / tornado system, might work well in a large space. ART+COM Studios clearly did an excellent job both in the physical implementation, but also - presumably in collaboration with BMW - in developing a compelling story that could be well told with this unique display medium.

Physical Implementation

Which gets me to the next problem: this definitely requires a large (and expensive) installation to achieve anything of interest. A five-by-five grid would not provide much flexibility capability irrespective of the story I arrive at, and yet such a grid is already 25 motors that need to work together; a ten-by-ten grid is the smallest I could imagine building to tell a story. (The BMW one is 714 balls!)

But what motors might I use? I need motors with a lot of positional control: continuous-rotation servo motors are the best bet for something that requires a minimum of fine-tuning, but the high-end Teknic motors I used for my CNC - at $300+/pc - are a non-starter if I need 100 of them! Inexpensive RC servo motors can be had for around $5/pc, and with a chainable I2C controller, I can control nearly 1000 servos for about $600 of electronics attached to a single Raspberry Pi. But my experience with them on other projects suggests that the low cost servos will probably require a lot of calibration to ensure their motion is in sync with each other, and really the only way to do that systematically amongst 100 motors is to add 100 sensors to detect rotation speed, raising the complexity.

Alternatively, I could use stepper motors; a small NEMA17 frame motor can be had for about $10/pc at volume, albeit this comes at a greater cost in electronics complexity with a controller that - for roughly the same $600 in electronics - would only allow me to control 64 steppers per Raspberry Pi. I could potentially bypass the end-of-motion sensors with the steppers, but I would need to get multiple Pi's working in sync to get to 100 motors.

On The Back Burner

So, for lack of a compelling visual, lack of space, and high fabrication cost, this project will remain on the back burner for now.

However, in sharing, I hope that these might serve as a little inspiration in your unique pursuits - or perhaps even highlight a potential area for collaboration on a project! So, if this piques your interest, I’d love to hear from you.