My first post about Science Hack Day covered the fits and starts of working on the hackathon day and covers why the raspberry Pi turned out to be way less than ideal. This post is drawn from the last part of the hackathon, when we were driving the stepper, and what I learned about accuracy, and timing, in that experimentation
caveat: I am 100% not a mechanical engineer
Dozens of concerns were mentioned to me about the design of this tool, and I found a few others with a little googling, that implied we might have difficulty while trying to ‘drive’ the tool at the right speed with sufficient accuracy. None of these turned out to be actual problems, but I’m so ignorant on the subject I might not even have the right terms as I try to describe them. Sorry!
Okay what does this device even look like?
The process we’re talking about is stereotactic surgery, where bones are used to lock in a coordinate system for finding an exact point in soft tissue. The term could refer to any kind of surgical procedure, but usually we’re talking about the brain, since the skull is such a convenient ‘hard point’ to start your coordinate system.
To perform surgeries like this, they use a tool like this one:
The part of this that really matters are the two ‘knobs’ you see at the top left. The scientist twists these to move the probe. If you’ve ever worked with a 3d printer, this probably looks familiar. You’re looking at a hand-cranked 3d control system.
The upgraded version of this tool looks like this:
This version should look very familiar to someone who has worked with either a 3d printer or a CNC: the hand cranks are now motors, and a controller for those motors is hooked up to PC control.
The paper that Daniela found was about building a full 3d tool with open source hardware at a significant cost saving. She would find such a tool useful someday, but for the moment she just wanted one that moved on the Z-axis automatically, with manual controls for the X and Y.
So this whole goal is to build something that uses a stepper motor to turn a single knob.
Again, I had the advantage of a machinists’ work before the hack day to build the mechanical connection between motor and tool.
My concerns about the motor
The probe needs to move ‘in’ by a total of 2mm over the course of a minute. Since we’re doing this in a surgery, it’s prooooooobably not good to end up moving 2.1mm. The ‘stepper’ part of stepper motor means it moves forward in discrete steps. My big fear was that the right distance would be between steps. If the system moved 3mm in 17 steps, there wouldn’t be a right number of steps to go exactly 2mm. Thankfully, since we were using a ‘geared’ stepper motor that steps down the speed of turning with a gearbox, this wasn’t a problem. A full rotation of the motor took a few thousand steps. Plenty of resolution.
Again taking the example where the stepper moves the whole length over a dozen or so steps, this motion might look smooth to the naked eye, but microscopically they’d look like separate thrusts, which might not look good. Again, the resolution of steps resolved this.
I knew there were ways to look at the machines involved and calculate the expected distance of movement but 1) I didn’t know how to do that and 2) it sounded hard so I came up with the clever idea of just making the tool move, measuring the distance, and ‘calibrating’ to find the right number of steps to go 2 mm. At first I thought it would be tough to measure these tiny distances, but the version of the tool that Daniela brought had little dial readout of the distance of movement. In the end this was super easy!
Speed and sync
The stepper driver in use probably had a spec available somewhere of the maximum rate it could accept instructions. The controller (raspberry Pi and/or Arduino) also have a maximum accuracy with which they can send signals out. One request from Daniela was that the probe move faster coming back out than it did going in, and I was worried that this higher speed might end up with signals ‘lost’. If you send ‘step’ signals faster than the motor can actually get them, you could miss steps and end up not moving the full distance.
I tested this extensively by throwing a ton of steps at the system at speeds much higher than required. Even with the Pi, which should have much more difficulty sending signals at high frequency, had no trouble. This wasn’t that surprising, after all we were going super slowly.
Stepper motors eat up a lot of current. Both the motors themselves and the stepper driver get really hot
Where a lot of the other problems I came up with were obviated by the slow speed and high number of steps, energy usage and concomitant heat buildup are actually worse for a more accurate tool.
Stepper motors can accept a big range of voltage. The more voltage, the stronger the grip of their magnets and the more accurate each step would be. That meant we ran our stepper at its max allowed voltage. We actually killed two of the tiny ‘cute’ stepper motor drivers in our testing.
We ended up using a version of the driver above with a huge heatsink. The motor itself also got pretty hot hot. Similar rigs to do 3d printing have cooling fans mounted on the frame to cool the motor itself. But I calculated that on the hack day we moved the probe more distance, at a higher speed, than it would move over a year of use. The system didn’t melt, we were okay.
stuff other people mentioned
If you turn off all current to the coils of a stepper motor, it should allow the wheel to turn freely. This would be super duper bad if the surgical probe just started moving around during a procedure. Normally this is handled by the hardware/software driving the stepper motor: giving it no instructions actually leaves one coil on holding the motor. I started to do a bunch of checks on this before I tried just turning off the power to my motor entirely. It turned out that the gearbox and the probe hardware presented way too much resistance for the thing to move on its own
I’m not going to go to deep on this, but when you try to move back the way you came, there’s some ‘slack’ in the gears that needs to be taken up, losing you some steps. This difference proved too small to measure, and the probe gets ‘zeroed’ before every procedure anyway, so a problem can’t build up over a bunch of procedures.
timing from the Pi
See my previous post: the Raspberry Pi was totally capable of running the driver.
what we learned
Optimization of a system, whether that system is electical, mechanical, or software, is only really meaningful after you have a working prototype. Problems like heat on the stepper motor driver are easily predicted and are worth handling early. Other problems should come up in trial runs, and if not, any time spent preventing them was largely wasted.
So build, and test! When you test, test a lot of stuff. Try your best to simulate uses more extreme than the real world should throw at them, and document what you find and notice.
the next and final post about science hack day will cover the control software I wrote for the arduino, and why an open-source stereotactic surgical might not be that great an idea.