Current Sensing and Visualizing with LabVIEW for Arduino Controlled Robotic Arm

Posted by

In my last post, I talked about using an RC filter to get rid of some of the noise in the current signal I was getting from the Arduino. While this worked okay, I still wasn’t super happy with the results, and the elbow motor on the robotic arm seemed to require different RC values than the shoulder motor, and there was a lot of guessing and testing going on. Some comments on the posts suggested using the Teensy with the Teensyduino software since it has a faster data rate, which could work, but the libraries I’m using for the Adafruit Motor Shield and the current sensing are not compatible, and the hardware itself would have to be rewired and it’s not clear to me exactly how I would wire a Teensy to an Arduino shield without it getting messy pretty fast. Another suggestion was to follow in the footsteps of some of the Arduino oscilloscope projects that use digital or lower level commands to send the data, but I have to admit I just really don’t understand what the code is doing there and I won’t just copy and paste code that doesn’t make sense to me.

So, basically my idea was to do enough filtering in hardware that the ~200Hz print rate from the Arduino gave me data that was smooth enough to actually work with.

I’ve been trying to avoid using LabVIEW and find an open source alternative to visualize the incoming data to confirm my RC values are working. One thing that sort of worked is using a DSO Nano instead of a fancy oscilloscope, but adjusting the DSO Nano to find the signal every time I changed RC values got tedious very fast. I also didn’t want to bug my friends in the lab down the hall every time I needed to use their multi-thousand dollar scope. So, I realized I do have a student edition of LabVIEW and a NI USB-6008 DAQ board that I bought a while ago. So, I decided to just use LabVIEW as my scope and the DAQ to read the current and allow me to test the RC values faster, while the Arduino did its thing in the background.

Getting started with LabVIEW is WAY harder than getting started with Arduino. Once you assemble the USB-6008 and put the stickers on, then read through the other documentation, you can plug something in like this:

NI USB-2008

The black ground wire is plugged into the same ground as Arduino, and the red wire coming from AI7 (analog input 7) is connected to the RC filtered output of the shoulder motor current sensor (A2 in the image here). Through the Measurement & Automation Explorer that comes with the software install, we can get a quick glimpse of what is going on by just choosing the correct analog input port:

This is great, but I want a way to scale the graph and tweak more things than I can tweak here, as well as save the output to a file when I need to. In order to take advantage of the capabilities of the DAQ, you have to install the NI-DAQmx software that comes with it, which takes approximately forever. The examples given and tools available in the student version are not always that helpful, but after some playing around, I got this:

The screenshot shows two graphs: the one on the left is the RC filtered signal, and the one on the right is the raw output of the op-amp software filtered with a 3rd order Butterworth low pass filter in software using the same exact cutoff frequency as determined by the R and C values of the hardware filter (7.234 Hz), so I can compare them. I knew I wanted a low pass filter, but as for those other details, they were just the defaults and seemed to work well. The graph on the right is definitely smoother, so there is clearly something that the software filtering can do that I can’t do with just a simple hardware filter. This does not bode well for choosing an RC filter and just using the 200 Hz data from the Arduino to map the current consumption. More to come when I work through this issue.


  1. A small note. Your single stage RC filter has a very gentle or gradual cutoff. That is, it reduces the amplitude of higher frequency values more than low frequency, but that reduction only kicks in slowly as frequency increases. The cutoff frequency calculated in earlier posts (eg: 7.234 Hz) can be calculated very precisely, but if you looked at the curve (frequency vs amplitude) you would be hard pressed to find anything interesting happening at precisely that frequency; it’s like determining where the “top” of a hill becomes the “side” to within inches, when it gradually increases slope.

    There are multi stage filters – hardware and software – which can have sharper corners – the slope drops faster at the cutoff frequency. You can get almost arbitrarily sharp BUT there are undesirable side effects; you can read a filtering book to find out more. Your 3rd order Butterworth is an example of a sharper cutoff.

    Anyway, being the “exact same” cutoff isn’t very meaningful. I would have said that the RC filter had a cutoff of roughly 7 Hz, even while knowing that 6.5 and 7.5 Hz passthough would look very similar (say, look at pure sine waves at each of those frequences after the filter and see if you can tell that one is more reduced than the other).

Comments are closed.