Mechatronic Violin-Bow Testbed
The introduction to this project needs to be rewritten, and there's more to come, but here's the gist. One of my grad students (a professional violinist) is building a data-acquisition system for measuring the position and angles of a violin bow while playing. Proper posture is essential, and violinists spend a lot of time practicing in front of a mirror to maintain it. His thesis project is to build a system that keeps track of the motions automatically. The data-analysis and reporting portions of the work are still to be determined, so this page currently focuses on the data-acquisition portion only.
The first stage is to support calibration. The software he's developing needs to record the state of the inertial measurement units (IMUs). In order to make the hardware and software agree, a lot of tweaking with magic coefficients is necessary. It's crucial to have known test configurations. He can't just swing the bow around and say look, here are lots of numbers; they must be correct.
He needs a specialized testbed for controllable, repeatable experiments. (Modeling, simulation, visualization, and analysis via scientific method are the foundation of my teaching and research, so I "encourage" my grad students to embrace it.) His first approach was a milk bottle with a protractor taped to it (picture coming). This was certainly better than nothing, but it was on only one axis, and it didn't control for speed and acceleration, only angle.
The testbed is in support of his thesis, not his actual thesis work, and it's also a significantly complicated and expensive project, so it wasn't reasonable to expect him to make this himself. I figured it would be useful for him, fun for me to build, and I can probably get a couple publications out of it down the road. I've already done something similar with the gimbal project.
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.