Science hack day Portland was, without a doubt, my favorite hackathon event I’ve ever attended. So many things to love about it:
- Slack channel invite a few days before to get on the same page/find teams
- lots of real scientists attending, some bringing real problems
- generous spread of hardware
- not organized 100% by dudes
- food was amazing
I signed up thinking I might make some simple electronic whatnot or maybe some kind of ‘science-related’ complete project. Like a… weather station? Those are still a thing, right? Thanks to the slack channel set up beforehand, I found a scientist who was trying to get a real piece of lab equipment made, and even had an open-source project that they were basing their project on. So I’d be making a tool to carefully manipulate a probe. As it pushes into… an animal’s brain.
Science hack day had officially gotten real.
The version that Daniela Saderi wanted for her lab wasn’t going to grind bone like the open-source original, it was just going to handle a probe, moving only on one axis. The good news was that she already had an Electrical Engineer and Machinist on the project, otherwise the coupling between the probe and the stepper motor would have taken me the whole weekend.
So she was bringing all the necessary parts, and a stepper motor connected to a probe manipulator, all I needed to do was design some software to control the thing.
The Huge Mistake
I decided to try and control the system with a Raspberry Pi. This was a huge mistake for reasons I’ll get into, but I picked it for what seemed like good reasons:
- Mozilla had generously donated 35 of the buggers to the event.
- the user (Daniela) wanted a lot of customization on the tool. Adjustable speed, depth, pausing and restarting, all needed to be controllable.
The question I got asked throughout was ‘why not use the Arduino?’ And I did my usual scoff at this kind of question: there’s always a better tool out there, just let me use what I have dammit!
But really, motivation was the complexity of the interface Daniela wanted. I knew that displays and button inputs existed for the Arduino, but I didn’t really know much about them, I didn’t have the hardware necessarily, and I felt like the programming would be more complex.
Prompting the user to enter a speed and depth on a command line interface is easy for me, but making some little LCD display data and handling button input both sounded… hard.
Why that was a mistake
a PC is a PC
In the end, I never got Johnny-Five to work on the Pi, and ended up having to write the Raspberry Pi controls in Python. I’d never written any Python, so that wasn’t super.
Also the thing about using a super-compact computer to be your computer is it just took so much time getting that fukkin’ PC to work. I was all excited about a tutorial that would let me get the Pi on WiFi and let me SSH over to it, but one of the steps was to update the OS. Of course, the OS update took half an hour, and with other little problems with hardware and video it was noon before I was even really working on my Pi.
Compared to setting up a full-blown new PC 3 hours isn’t terrible but it really shows why people prefer making simple projects on the Arduino.
just one letter separates ‘networking’ from ‘not working’
One thing that REALLY bit me: I followed a lovely tutorial on getting the Pi set up for SSH and Johnny-Five development, and the last few steps did not work right. First, I couldn’t get Mongo to serve the Pi at a hostname, and wrestled with that for a while.
After that, I couldn’t get the fileshare set up with the method they described, and ended up having to use… something else (I’m sorry, I’m sorry, I have no idea what it was and all the results I found were for Samba and smb and that did not work for me)
Once I had that done, I was able to remote into the Pi and write code from there. With the fileshare I could use Atom on my laptop and not be stuck with whatever weird IDE the Pi had. Great right? Not so much.
Since I didn’t get Samba set up right, I was accessing the Pi by its IP address, and this got reassigned by the network once or twice during the event. When this happened my attempts to load new code failed silently, and the sequence I was triggering would fail because it was running code from 10 minutes ago.
When I write code and it doesn’t work, network issues preventing the system from getting the latest version of the code are not my first guess about the cause. As a result this cost me an hour of debugging before I figured out the real problem.
Oh Johnny why you gotta do me like you do
After all that, possibly related: I couldn’t get Johnny-Five to work. I would get a few steps forward and then hit new roadblocks. The final version would run the code and throw me into a REPL. Was that it working? It sent the signals. But by throwing me into the REPL I couldn’t do console logging like I expected. It sent me some error messages that I… couldn’t understand.
But don’t knock the Raspberry Pi
One thing I heard a few times, even read from some people who were writing hardware control software for the Pi, is that the Pi can’t control a stepper motor. This concern turned out to be quite overblown, I’ll explain:
A stepper motor is a wheel of magnets surrounded on four sides by electro magnets. As the magnets around the edge switch off and on, the wheel inside moves forward.
for precision, they’re the dominant design, since at low speed it’s a bit like rolling a square wheel: you’re never unsure exactly how many times that wheel has turned.
If you’re curious: steppers aren’t the best at everything since they’re very power inefficient. They also require a ton of power to stay still (this wasn’t a problem for me since our motor had a gearbox that required force to move, so our probe wasn’t just wobbling around when the motor was off.)
All of this to say: controlling a stepper motor directly requires you to turn off and on these magnets around the edge. Obviously, the switching has to be really precise to ‘drop’ the wheel from one magnet and ‘catch’ it with the next.
the Raspberry Pi is a cut down PC, and it lacks a bunch of hardware involved with timing.
Here a sidenote: the chips on a normal PC that precisely control timing and allow for multiple tasks to work on in parallel while remaining in sync is called a ‘clock chip’ and is unrelated to telling time. My Father has worked for several decades making this exact part for a large semiconductor company.
Since the Pi can’t sync up its signals perfectly, it can’t handle controlling these magnets.
Okay, but these are really strong magnets, surely we’re not going to run them with power directly from the board, right? At the very least, you’d want a transistor to let a little bit of current from your controller direct a bunch more to the motor.
And here’s where we come to a basic thing with hardware hacking: powering LED’s or getting button input are all things that these controllers can do directly, but for more complex stuff you have a choice!
* design your own fancy circuit
* send simpler signals from your microcontroller to specialized hardware.
These are the famous “shields” for the Arduino. A lot of them aren’t necessarily required to do whatever, but they make it a ton easier to write the software to control whatever.
In this case, there exist stepper motor drivers that take very simple signals instead of requiring you to control each magnetic coil. Set up right, these ‘drivers’ will just take signals on 2 pins: a ‘step’ signal and a ‘direction’ signal, and handle all the fiddly “turn on this magnet, then turn on the next one right away, no, NOW”
By the by, we borrowed a Stepper Motor Driver from… someone… on the day of the event and I haven’t actually found another one that works just like this. I’ll figure it out eventually, but anyway!
doing too much at once makes debugging a nightmare
At my job, where I’m using a library I’m very familiar with, I still rarely write more than a few lines of code without checking some debug output. Trim a string of a few characters, escape it for HTML, and then send it in a JSON object? I’ll often
console.log() both the input and the escaped string before I move on to step 3.
The first attempts to turn the motor was 27 lines of code. Not even counting the other tools, this was extreme.
After an hour of frustration, I disconnected the Pi from the motor, and went back to basics: trying to make the Pi blink some LED’s
It was doing the easiest possible task that revealed that Johnny-Five wasn’t working correctly, and that Python was.
In the end
The hackathon was a single day. By the end of the day I had the actual probe hardware moving the exact right distance in, pausing, and then moving back out. This wasn’t really a minimum viable product, since it needed to wait on input before going to the next stage. Still pretty cool to know the hardware setup and the Pi could manage such precise control, to move a probe just 2mm in 100 seconds!