He's using two MPU-9150 inertial measurement units, one on the bow and one on the violin. Each provides nine degrees of freedom for yaw, pitch, and roll with accelerometers, gyroscopes, and compasses. I'm using something similar for my helicopter machine-learning project.

His original attempt at a calibration rig was admirable, but it worked only on the yaw axis and couldn't account for speed or acceleration. The base is the top half of a milk jug.

The pan-and-tilt platform provides known pitch and yaw angles for the bow. It's an off-the-shelf commercial product from Trossen Robotics. As much as I wanted to fabricate my own, it would have ended up operating effectively the same way. Still, it's hard to overcome the "not invented here" syndrome and buy somebody else's solution when it's so much fun to make your own.

Despite being off the shelf, it still requires some assembly. The platform is only part of the system.

Here it is assembled on the top left. The rest of this (and more not shown) is for the drive assembly.

In particular, the choice of motor was crucial. It was difficult to specify in advance which one to use in terms of torque and speed because this is a research project. It's not at all clear how far and fast the bow is supposed to move, for example, or even how long it would be. But there are a lot of options. A huge part of engineering is playing what-if games.

This one from Pololu met the expected requirements.

A nice aspect is that the motor comes with its own quadrature encoder to help keep track of its position and speed. At least I didn't need to do this myself. It's not difficult, but would have entailed additional electrical and mechanical components, and time that I didn't have.

The signals on the scope weren't remotely this clean without filtering, which is partially why the final control board is more complicated.

In the earlier stages of specifying parts, it seemed promising to have lots of flexibility in controlling the motor for the bow, so I got this nifty board.

It provides options for everything imaginable, like acceleration, velocity, position, and braking, with screens and screens of configuration and monitoring. There's even a built-in PID (proportional-integral-derivative) closed-loop position controller.

Despite the potential for this controller, it was overkill for what my grad student needed. We might revisit it later, but for now, it was more appropriate to build my own controller. There are lots of sophisticated H-bridge controller chips available, but under the time constraints, ordering one wasn't an option. I did have a simple related chip, so this was the first attempt. All my board does is direction and speed. Position is handled on the software side through an open-loop controller, although the board does some of the signal processing.

And immediately the complexity started to rise, as always.

It worked, but the power requirements of the motor pushed the limits of this design. And since I couldn't control what my student would do with his tests, I figured it was guaranteed that this chip would die (while I was on vacation). So I built my own pulse-width-modulated H-bridge from scratch.