For my next installation I’m going to connect 8 piezo sensors onto an acoustic drum set to detect hits on the different pads.
On my current installation I’m using pressure sensitive sensors in the floor. Those are connected via Arduino to openFrameworks.
Now, although I’m very satisfied with te low latency between the sensors and the actual visual feedback. I’m wondering if I can make it even more responsive.
Since I’m not that educated about performance between external devices and c++ I’m wondering if you guys have some great tips to lower the latency (if possible of course).
The real question why I started this topic is: are there any boards/aternatives/… to Arduino that focus even more on performance and throughput?
I only know Arduino (a bit), but nowadays there are so many alternatives, it’s pretty hard to navigate the landscape. Especially for the beginner.
Thanks in advance for your answers!
I think the first task is to see where your latency is. If you can film the action to hit the pressure sensor and the screen that can run a simple app receiving the data, (like just changing a single colour for a frame or even printing a timestamp to the console) and play back the footage frame by frame (this will work well with a new iphone with the 240fps filming). This should give the latency of your electronic system and its communication with your OF code and you can separate that from the latency that comes from the visual system.
It also depends on your arduino code, are you doing any smoothing on the inputs- this will give delay as well, and then how the arduino is communicating with the OF app (even baud rate can add a tiny change, do you use interrupts and or callbacks)
Projectors and LCD tv’s also have a delay- sometimes projectors can add quite a lot, especially if the scaler is on (ie you are sending a different resolution to the native res of the projector), you can test the projector latency in the same way as above - by filming duplicated screens at a high frame-rate.
In a system that uses electronics to trigger visuals I would guess that the bottle neck is not in your Arduino (hardware but maybe software) but is adding up further down the chain. I would analyse all the components in the chain and try get accurate delays and then see where the biggest bottle neck is.
Apologies if you have already done this and have narrowed to the Arduino itself.
Hey @fresla, great response. I really like the iPhone fps approach.
Some very good suggestions on where to look for the bottlenecks.
In my current installation I don’t feel that much lag, but since I’m preparing for a bigger one, so I can definitely use your feedback to track down bottlenecks.
My question was indeed related to these external microcontrollers like Arduino, but I’m getting a feel there isn’t that much of a difference between them? (I only know Arduino).
Anybody have any comparisons or general pointers in which cases i shouldn’t choose Arduino?
Arduinos are not homogeneous in terms of what hardware they are using, so that might be good for us to know. There are the older, standard Arduinos like an Uno, Leonardo, or similar with an ATMEGA microcontroller. Newer Arduinos, like the Due, have a ARM microcontroller. The ATMEGAs are slower than the ARM microcontrollers, but it will only really start to matter if you are doing a lot of calculations.
Microcontrollers have really low latency, at least in terms of the hardware (software can mess things up). Where they struggle is with throughput, that is, doing lots of calculations. If you are detecting a button press or something very simple like that, the latency can be really low because very few calculations need to be done. If, on the other hand, you are doing something more complicated, like reading a capacitive sensor and trying to determine whether a hand is near, you might need to do enough calculations that the throughput of the microcontroller will start to matter (probably not, but maybe).
It is possible that the software running on the microcontroller is really inefficient or does things like input smoothing or software debouncing that will increase latency. For example, with debouncing, software might worry that a button press isn’t real and wait for 10 ms and check that the button is still pressed before sending a signal. In that case, 10 ms latency just got added. You will need to understand what exactly your microcontroller code is doing in order to know if these kinds of things are a problem.
Wow! Awesome post. Really good advice, thanks for sharing!
Are you streaming the sensor values from the Arduino to OF or are you having the Arduino send a flag when a drum has been triggered? The latter is definitely better. No need to clog the serial connection with tons of data if all you need is a single trigger that tells you which one was hit.
When it comes to best practices with code, make sure you use blocking calls like delay() as little as possible. There’s nothing you can do with delay() that you cant do with some non-blocking timer code. If your sketch is running as fast as possible (which is best for the short pulses from piezo disks) you should still be able to get away with a little bit of smoothing to filter the noise/harmonics piezo elements are famous for.
Also it’s a bit obvious but, you’ll want to keep the connection wired, wireless will always add latency.
Also, if you HAVE to do a lot of other stuff on your microcontroller (like signal processing or interfacing with other slow modules, etc.) then maybe you’ll want to work with some hardware interrupts. Basically, these are pins that the microcontroller can listen to for triggers asynchronously from your main void loop() code.
If you keep your code minimal you shouldn’t need interrupts, but if you absolutely have to do a lot of other stuff you could check it out. You’d probably need an Arduino Due or Zero since you have 8 different drums and the UNO only has a few pins capable of interrupt service routines.