DIY drum triggers… reading the sensor scientifically
I’ve learned so much about piezos, microcontrollers, serial data capture, graphing. All from people I’ve never even met in person. Tod E. Kurt’s work on the Arduino MIDI drum kit lead me to want to replicate the project for myself, and I’ve been running into some very tricky problems with the sensors triggering samples two or three times. I got a boost of confidence that I was detecting a real problem thanks to the fine work done by mschaff’s Ardrumo project. Now, thanks very much to Tom Igoe’s article on Sensor Graphing using a tiny arduino sketch, the terminal, and grapher.app, I can actually scientifically diagnose the reason why this is happening.
Using the DIY kick pedal that I’ve been working on…
I was able to capture and graph the data that the sensor is outputting. Here are a few screenshots of the highlights:
This first screenshot shows a good peak, right at the beginning of the strike. Then the ringing begins. If, for instance, I had the threshold set to 500, this would trigger not just one, but *three* midi notes. Ok, but what if I had set the threshold to closer to 750? a big problem with that is that I’m losing a lot of the dynamic quality of the kick pedal. I’d have to hammer on it just to register above the minimum value, and then there’s no way to play it quietly. Every kick would end up being 750 or higher.
But wait, there’s more! Here’s another reading:
Wow, so even if I had set the threshold to 750, I’d *STILL* get three notes off this one kick pedal strike! And then just to mix it up even more:
Here is yet another pattern of the data. a short hop at the beginning well under a reasonable threshold of 250, and then a reading over 500, and then an even higher reading on the “second wave”…
So, the question still remains… how to get a clean sensor reading? Here’s my current idea:
Charting it out helps. Now I just need to try to write the code so it follows this to test it out. Comments and suggestions are welcome. 
Technorati Tags: ardrumo, arduino, DIY, drum, e-drum, mschaff, tigoe, todbot, trigger
Wyatt:
Hello there,
I am trying something very similar (making a drum controller ‘brain’ using Arduino), and I am in search of a solution to this problem. How well does your flowchart algorithm work for this?
I am currently thinking that a hardware buffering solution may be better for my needs, but that may depend on how well (and efficient) this sort of approach works…
Cheers
18 February 2008, 1:58 pmdshay:
I’ve seen a software fix for this. A simple set/reset variable that wouldn’t allow a retrigger for an amount of time defined by user. I tried to look it up but I couldn’t find it. Basically, if you look at your graph, you’d be set if you didn’t allow double triggering for about six milliseconds or so. The code I saw allowed the person before dumping the code to enter in from 0 to 25 ms the amount of time before the particular pad can trigger again.
25 February 2008, 1:41 pmfabi:
Hi there, i love your pedal, and this weekend i’m planning to build one, but i’m really intrigued by your spring mechanism to return the pedal. Did you take it from a real drum pedal?
I’ve made a basic drum-trigger, but i solved this issue with some extra hardware: a peak-detector followed by an op-amp. Basically i took the idea from Paia’s web:
http://www.paia.com/ProdArticles/drumsens.htm
You can use a greater capacitor and experiment with some resistor values. I also think it could be improved with some other RC and a transistor, but i’m not very deep in electronics. I’ve commented this out in tod’s blog too.
Good luck!
26 February 2008, 7:34 pmwaek:
Hmm. I think you could just pull off doing an envelope follower / detector in software in the Arduino itself. Low-pass filter the input signal to smooth out most of the ringing / ripple (a simple first order lowpass would do, should not chomp too many cpu cycles nor is hard to understand). After that, only allow a new note trigger when the low-passed signal has dropped below certain treshold (hysteresis). Or something like that.
I’m sure I’ll find a major flaw in the above thought after I think more about it, but it’s still an idea. Obviously the lowpass filter would also make the first hit transient rise up slower, so there might be some additional delay in triggering - but that’s one thing you have to tweak in env followers in any case. I guess I’ll have to order Arduino, get some piezo triggers and put my money where my mouth is… I’ve been interested in the DIY trigger idea in any case and actually stumbled upon this while searching for information.
27 February 2008, 5:17 amsteve cooley:
Hey, all. Thanks very much for your comments! I just realized that there’s been activity here because my spam filter has been overly aggressive.
I think it’s probably just time that I step up and just take a look at hardware solutions. The software solutions are good if you only want to have one sensor capturing data, but my current theory is that I’ll want at least 4 concurrent sensors reading values and sending midi information (one for each of my appropriate appendages). So shutting down the arduino’s ability to do anything while it’s just waiting for N milliseconds to pass seems like it might introduce problems. Hardware seems to make a bit more sense, and will push me just a little further. I just need to maybe dig up the electronics learning kits I have and see if there’s any baby steps I can make to figure out how to go from circuit board diagrams to actual circuits. I unfortunately don’t do this enough for that to be an easy task.
As far as the spring mechanism goes, I did prototype this and realized I had a recoil problem to solve for. I really didn’t know what I was going to do. I figured there’d be a spring in there somewhere, but didn’t really know what it was going to look like. I did make a trip to Guitar Center’s drum area and looked at a few pedals.
Why reinvent the wheel? I had plenty of fabrication issues to solve for outside of the overall design help that I ascertained from observation.
Basically, if you do something like I did, I would recommend fabricating some of the parts out of metal. Specifically the spring block. It has a set screw that needs to really wedge down on the axel in order to create a good solid grip for the spring to counteract on. I tried several types of wood, all of which completely disintegrated along their grain lines. Using a hardwood, I ended up drilling two small holes along the entire height of the piece, perpendicular to the grain, and ran some 4/40 bolts through them to make sure the wood grain wouldn’t fail. It works, but metal would probably be a higher build quality if you can get access to a milling machine.
I do now, but.. I’ve already solved the problem acceptably, so ..
why bother, I say.
27 February 2008, 1:58 pmedrum:
Look here: http://www.edrum.info
6 March 2008, 5:14 pmWyatt:
As a followup to my previous post, I have made a great deal of headway on this project, and currently have a working prototype, with PCBs on order.
If anyone is interested in my approach, take a look at my web page http://drummaster.thecave.homeunix.org. My final solution the filtering problem above was to use a diode, a capacitor, a couple of resistors, and an op amp (for impedance matching) to filter out the ripples, and ensure a quick voltage dropoff after the hit. On the site are schematics as well as some graphs showing the effectiveness of the filter circuits.
Cheers
5 June 2008, 2:36 pmpatrick:
hi,
found this topic very interesting. here’s what i can share about it:
http://probing.wikidot.com/piezo-analysis-oscilloscope
also it really depends on the impact (surface, where on the piezo / pad).
i am not sure how to implent it (pseudo-code) for an atmega. my goal is your goal: no lag with good velocity response. should i consider using a PIC18F and interrupts?
pat
22 July 2008, 7:38 pm