News

After a recent post on current sensing, I talked to a couple of friends at NYC Resistor (my usual sounding board) and got some great advice (as usual).

One thing I didn’t remember was the difference between passive and active filtering, and that it might take more than a simple RC circuit to filter out the noise I was seeing. I was pointed to a few good reads:

http://ww1.microchip.com/downloads/en/devicedoc/41233A.pdf

http://www.maxim-ic.com/app-notes/index.mvp/id/1762

http://www.swarthmore.edu/NatSci/echeeve1/Ref/DataSheet/IntroToFilters.pdf

But before I got too far into digital signal processing land and making hardware based 2nd or 3rd order filters, I wanted to see if there was a better way. I got in touch with JD Warren, one of authors of Arduino Robotics. One of the projects in the book used a custom built motor driver with a hall effect current sensor. I’ve shied away from these until now because they seemed to be more voodoo than the more intuitive current sensing resistor method, but after reading parts of his book and talking with JD, I ordered up some ACS712s and some surface mount to breadboard adapters from Digikey. He always had good luck with them so hopefully that luck rubs off and they’ll be less noisy than the method I’m using now.

I also did some more research and found that the L298 h-bridge, basically the next step up from the L293 that comes on the Adafruit Motor Shield, has current sensing already built in! Luckily both the Sparkfun Ardumoto Shield and the Arduino Motor Shield use this h-bridge, but only the Arduino shield has those pins broken out. So I ordered both, figuring I could hack the Sparkfun one by cutting the traces and soldering some little jumper wires if necessary (I studied the schematics for quite a while before convincing myself this would be possible). From what I can gather from the datasheet, I still need to add a current sensing resistor, and it uses basically the same method I was using before, but something about the integrated solution I suppose could make a difference. We’ll see.

First Test: Arduino Motor Shield
The documentation on this shield is a little spotty, but from the schematic and Eagle files, I figured out that the current sensing resistors were already integrated along with an op-amp that presumably amplifies the tiny voltage drop. The hardware page says the resolution is 1.65 A/V, so it looks like they did the math already on what resistors and what gain was used to get an actual current rating from a detectable voltage drop. So I wrote up some code (below) and after a little tweaking got this:

Isn’t that beautiful?!? A little jumpy still but might be good. I think it’s time to swap this in where the Adafruit Shield is now and see what happens with the robot arm.

   
/*
Curent sensing with the Arduino Motor Shield: http://arduino.cc/it/Main/ArduinoMotorShieldR3
 
 One small DC motor attached to screw terminal block A
 External power from a 4 x AA batter pack
 
 CC-BY-SA
 by Dustyn Roberts
 6/12/2012
 */

// declare pins used on channel A
int directionPin = 12;
int pwmPin = 3;
int brakePin = 9;
int currentPin = A0;

int switchPin = 2; // motor on/off switch
// connect one side of switch to power, the other to ground through a 10k resistor
// read the switch state where the switch and resistor meet into digital pin 2
// similar to this lab: http://itp.nyu.edu/physcomp/Labs/DigitalInOut

// constants
float volt_per_amp = 1.65; // resolution according to hardware page

// variables
float currentRaw; // the raw analogRead ranging from 0-1023
float currentVolts; // raw reading changed to Volts
float currentAmps; // Voltage reading changed to Amps

void setup() {
  pinMode(directionPin, OUTPUT);
  pinMode(pwmPin, OUTPUT); // necessary according to forum post http://arduino.cc/forum/index.php/topic,89468.0.html
  Serial.begin(9600); 
}

void loop() {
  // read the switch input:
  if (digitalRead(switchPin) == HIGH) {
    // if the switch is closed:
    digitalWrite(pwmPin, HIGH); // necessary according to forum post http://arduino.cc/forum/index.php/topic,89468.0.html
    digitalWrite(directionPin, HIGH);
  }
  else {
    // if the switch is open:
    digitalWrite(pwmPin, LOW); // necessary according to forum post http://arduino.cc/forum/index.php/topic,89468.0.html
    digitalWrite(directionPin, LOW);
  }

  currentRaw = analogRead(currentPin);
  currentVolts = currentRaw *(5.0/1024.0);
  currentAmps = currentVolts/volt_per_amp;

  Serial.println(currentAmps);
}

So I’m teaching and participating in ITP Camp this month, and one thing on the schedule for today is a 1 in 1:

• Start and complete a creative project in 24 hours (you don’t need to work on it through the night – but nobody will be surprised if you do.)
• It can be anything creative – there are no rules here
• The Counselors will be around to help you out with tutorial and brainstorming
• Each project needs a name and documentation posted by Monday morning – you can document it in the Campers Blog!
• You’re encouraged to exhibit your completed project at ITP during the week!

Okay okay so cleaning up my Windows laptop so it boots in less than 15 minutes isn’t exactly creative, but it’s meant to enable creativity for the rest of the month by freeing up space and making things faster. This might be one of my problems…

I also have a Windows machine at work that’s almost as full. This will all change in the next 24 hours. If you have any tips on cleanup/defragmenting/cloud services/backup software/etc., please leave them in the comments! I’ll spare you the updates since I’m fairly sure you can imagine how this ends.

In a nice departure from a normal week day, I got to accompany the Makerbot team to the Metropolitan Museum of Art yesterday for their “3-D Scanning and Printing Hackathon” event.

We used 123D Catch to grab scans of some of the sculptures, cleaned them up, then uploaded models to Thingiverse and printed some out on Replicators both at the Museum and back at the Botcave in Brooklyn. Here’s a screenshot of a 123D Catch of a sculpture I shot called Queen Marie-Amelie that was printing out when I left the museum yesterday:

Thanks to Jonathan (former Makerbot Artist-In-Residence) for taking the scan and cleaning it up to make an .stl file for printing! Can’t wait to see how it turns out. The Makerbot team is still there wrapping up, so make sure to check out their blog, Thingiverse, etc. for all the updates.

In my last post, I talked about sensing the current of the motors in a robotic arm, which was a necessary step in determining energy consumption for the robot. But in order to calculate the energy being used by each motor, I need not only current data but also angular velocity. To get angular velocity, I just need to know the angle and the time, since angular velocity = (angle now – last angle)/(time now – last time). However, the map() function I used in Arduino to turn the potentiometer signals into degrees only deals in integer math, so I was losing a lot of data and getting 0 as my angular velocity a lot, which was really messing up the graph of shoulder speed (see below for an early screenshot – ack) and therefore messing up the energy consumption graph.

I figured I wasn’t the first person to come across this issue, so I posted on the forum and used the feedback to create a custom map_double function:

   
float map_double(double x, double in_min, double in_max, double out_min, double out_max)
{
  return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}

then just replaced map with map_float everywhere I had it in my original code. Yeah! More to come on the energy consumption of the entire system…

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:

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.

So after some comments on my last post, some great comments on my Adafruit forum post about the actual robotic arm project I’m working on, some help from Twitter followers and some awesome fellow NYC Resistors, I realized there were a few more things I needed to do before getting meaningful current data from this robotic arm. I looked at the signal with a fancy oscilloscope with the help of a friend at NYU-Poly, and there was a great looking signal beneath the noise. So…

Step 1) Filter the noise
It was pretty clear from the comments that I would need to do some hardware filtering even before I worked with software filtering, so that meant creating an RC low pass filter. In order to verify that the RC filter was working, I finally had a good reason to figure out how to use my DSO Nano v2. I watched this video that talks through updating the firmware and getting started. There’s also some good info on the forum. I used a “real” oscilloscope from another lab here as a sanity check that what I was seeing on the DSO Nano was real. This is what the current for the robotic shoulder motor looks like with no filtering:

I then used an RC low pass filter at the output of the op-amps to get rid of some high frequency noise. From some limited experience, I decided to shoot for a cutoff frequency of around 45 Hz – that should take care of any ambient 60 Hz noise from lights, etc. Using Adafruit’s awesome Circuit Playground app, I chose values of components I had on hand (R value of 330 ohm and a C value of 10uF) and designed the circuit to have a cutoff frequency of 48.229 Hz. That’ll do to start.

So the 48 Hz low pass filter was better, but not great. I then decided to use the R and C values suggested by coffey in the Adafruit forum post above (R = 570 ohm and C = 47 uF) to create a cutoff frequency of 5.941 Hz. I didn’t have those exact values, so I kept the 10 uF caps in and swapped the resistor for a 2.2k ohm to get a cutoff frequency of 7.234 Hz.

Much better! Now let’s see what it looks like if I log this data through Cool Term as fast as Arduino is spitting it out:

Great! I graphed the Cool Term data in Excel quickly and you can see that even at the slow speed that I can log data with (about 265 Hz in this trial) I’m getting a pretty representative signal.

I’ll update this or make another post when I’ve finalized all the filtering, scaling, and math about it, but it’s getting pretty close to done.

I have been working with Greg Borenstien for a while now on creating an open source tool for visualizing human movement data. You can see all his code here on github. We needed some data that had x, y, and z positions of human joints over time during a certain task, as well as angular velocities and joint torques. The only freely available source we found that had all of this kinematic and kinetic data was the appendix of Biomechanics and Motor Control of Human Movement by the late David Winter. There was a helpful thread on the Biomch-L forum that led to some digital versions of this appendix. However, there was never a comprehensive Excel file posted with all the data.
So, here it is: Winter_Appendix_data.

It’s just the right leg and a torso point, but Greg got a visualization up and running quickly:

Biomechanic Leg Visualization from Greg Borenstein on Vimeo.

Thanks to Jaymes Dec for inviting me to talk at the Marymount School! Here are my notes:

Who I am and what I do… Dustyn Robots
Honeybee Robotics
Making Things Move
SADbot
Robotic hand
Robotic arm

And here are some pictures of the crowd:

Greg, a former student of mine and current friend/colleague/author/resident researcher at NYU ITP put together this animation within hours of meeting with him to talk about the human movement visualization work needed in the Applied Dynamics & Optimization Lab at NYU-Poly I work in.

Biomechanic Leg Visualization from Greg Borenstein on Vimeo.

It’s just a glimpse of what is to come! This is the kind of thing that happens when you pair up artists and engineers. I fed him some data from Biomechanics and Motor Control of Human Movement by David Winter, and he put this together in OpenFrameworks (and a version in Processing).

Hello world! We are looking to hire one or two students in the lab I work at within NYU-Poly: the Applied Dynamics & Optimization Lab. Ideally this will take the form of project for academic credit – a Master’s project, undergraduate research credits, internship credit, independent study, etc. The credits would officially be for Spring 2012, but we’re looking to hire as soon as possible. So you if you think you have the skills to get the job done, or know someone who does, please get in touch! The position(s) will be at NYU-Poly, but students from other universities with internship credit mechanisms are welcome to apply. We will consider students for each project separately but of course if you think you can cover both of the projects that’s even better.

Battery Monitor project:
By utilizing existing technology and/or developing a small custom circuit, the student will develop a real time battery monitor. The battery monitor will measure the capacity of a battery before, after, and during a load-related task (e.g. while a motor is running for several minutes) to quantify the total energy consumption and the energy consumption rate. The monitor will work with different battery sizes (AA, C, D) and different battery chemistries (alkaline, NiMh, LiPo, etc). The ability to log the relevant data through Processing, MATLAB, LabVIEW, or other tool is essential, and real-time visualization is desired. Knowledge of custom PCB creation – both design in EagleCAD and actual fabrication – is also a plus.

Human Movement Visualization project:
The student will investigate the ability of OpenSim – an open source human movement simulation software – to model custom generated human movement trajectories. Familiarity with C++ and Java is desired but not required. If OpenSim proves to be a useful platform for this research, the student will need to familiarize themselves with all aspects of the software and develop the capability to load custom data and output an appropriate visualization of the movement. In parallel with the OpenSim evaluation, the student will evaluate the use of Processing – another open source visualization tool – in the same way, starting with an existing simplified human model. The goal of the project is to identify and/or partially develop a freely available and easy to use tool to visualize human movement data generated from our lab