Saturday, October 29, 2011

Arduino, Wire, and I2C part 5b: Data Analysis and gnuplot

I've been using a feature of gnuplot lately that until yesterday I hadn't really given much thought to its potential. Gnuplot has a curve fitting tool which can be used to come up with those parameters to the sinusoidal functions in the previous post. It's not magic in that it won't necessarily always give you the right answer every time, but it can help with cleaning up estimates. Here's an example. First, define the function you're trying to fit to. In this case, I'm trying to fit to a simple sinusoidal function:
gnuplot> f(x)=a2*sin(omega*x+phi)+d2
This is the function described in the previous post, in gnuplot syntax. Now, you can try and fit the data to the function. The total data set isn't a consistent wave form so I'm going to reduce the data set to points between 150 and 250.
gnuplot> fit [150:250] f(x) "spin.dat" using 0:7 via a2,omega,phi,d2
The above instructs gnuplot to execute an iterative process, attempting to derive the values for a2, omega, phi, and d2 in the function defined as f(x). Gnuplot will output the results in various stages of the process. The most critical results are the final ones of course, which I reprint here:
Final set of parameters            Asymptotic Standard Error
=======================            ==========================

a2              = 0.774445         +/- 11.02        (1423%)
omega           = 0.973404         +/- 0.4104       (42.16%)
phi             = 6.881            +/- 82.27        (1196%)
d2              = -66.2102         +/- 6.535        (9.871%)
You may notice two things:
  1. The equation parameters are quite different from those that I posted previously, and
  2. The standard error percentage of the parameters is quite high (even the lowest, 9% is pretty significant).
You can "prime" the fit algorithm by seeding the parameter to reasonable approximations, i.e. give the fit a good starting point (there's probably a mathematical term for this but I'm not a mathematician). Using the parameters guessed at in the last post:
gnuplot> a2=93.5
gnuplot> d2=-75.6
gnuplot> omega=1/4.6
gnuplot> phi=-6
gnuplot> fit [150:250] f(x) "spin.dat" using 0:7 via a2,omega,phi,d2
Which ultimately resulted in:
Final set of parameters            Asymptotic Standard Error
=======================            ==========================

a2              = 90.8588          +/- 1.735        (1.909%)
omega           = 0.220797         +/- 0.0006131    (0.2777%)
phi             = -8.0615          +/- 0.1239       (1.537%)
d2              = -74.2817         +/- 1.185        (1.596%)

gnuplot> plot "spin.dat" using 7 axes x1y1 t "mag y" with lines, a2*sin(omega*x+phi)+d2

Which looks like a fairly good fit, with less than 2% error. A better fit could be made using equations with more independent variables, however, gnuplot's curve fit feature is limited to 5, of which the above already was using 4. I don't think there is much chance of refining this estimation any further using the fit feature of gnuplot.

Saturday, October 15, 2011

Arduino, Wire, and I2C part 5: Data Analysis and Modeling

Now that I've managed to reduce noise levels in the sensors to a mostly manageable level, it's time to record some data and try and model the board. It's worth reiterating what it is I'm attempting to achieve here: a hand-held underwater metal detector. Magnetometers can be a great way to achieve this, but this particular device is measuring the strength of the magnetic field.

I'm fairly confident that linear movement of the magnetometer is not going to significantly change the sensor measurements. This is because Earth's magnetic "lines of force" don't change particularly rapidly. You would probably have to move hundreds of miles to be able to see any significant change in the magnetometer's measurements, and can you really say you've moved in a "straight line" by then? More than likely you'll have been moving in an arc relative to gravitational center of the earth, which would be even less likely to show a significant change in measurement. Therefore, I'm going to ignore ADXL measurements.

The drawing above shows the board and the axes of measurement for each device. Unfortunately, sparkfun mounted the magnetometer such that it is 90° out of phase with the other devices. This means that the positive X axis of the accelerometer and gyro is the positive Y axis of the magnetometer, and the positive Y axis of the accelerometer and gyro is the negative X axis of the magnetometer. An inconvenience, but hopefully just a minor one.

Data capture was achieved using a common spice rack. I wanted something that didn't have much, if any, metal in it, while having sufficient space to throw the entire test apparatus on. The sensor board is roughly centered (it's a little hard to see given that the tape holding it down is a similar color to the spice rack, but you can see the connector to it above the battery pack), with the power pack and the Arduino UNO, XBee shield and XBee around the edges. Data was transferred via the XBee radio to a PC running Linux. Data loss made it necessary to make the data processing software a bit more robust.

Data capture was successful, and the graph to the right is a plot of the gyro measurements. As you can see in the graph, the rotation was primarily occurring around the Z axis, which matches the diagram of the axes and the picture of the apparatus. What you can't really see very well in the graph is that the Y and X axes were also showing measurable rotation. Those measurements show the same oscillation that can be seen on the Z-axis measurements. This is always going to be the case in any real-world measurements. You're simply never going to be able to get all the axes completely lined up and the axis of rotation perfectly aligned with the Z-axis (or whichever axis you're picking as "up"). You might get a lot closer than what I achieved with some really expensive lab equipment. The Z rotation is negative, indicating that the rotation was in a counter-clockwise direction around the Z axis.

Before looking at the magnetometer data, it's time to take a quick excursion back (for me at least) to Euclid and his geometry, though for the sake of simplicity, I'm going to stick with a 2-dimensional geometry for now. When translating between polar coordinates (angle and radius) and Euclidian coordinates, the following formulae apply:
$\begin{array}{rcl}x_{1} & = & r \cos \alpha,\\y_{1} & = & r \sin \alpha.\end{array}$

where r is the radius and α is the angle. In Euclidian geometry, your axes are always orthogonal, meaning they're at angles of 90° to each other. As such, the trigonometric operations sine and cosine are also 90° out of phase with each other. This phase offset shows up clearly in the recorded data. Given that the experiment was intended to rotate the board at a reasonably constant rate around the Z axis, the X and Y magnetometer measurements will look like sinusoidal waves 90° out of phase with each other. The following two graphs demonstrate. The first graph is the actual data, while the second graph is a simulation of the data set using only cos and sin functions, which are scaled to the appropriate mean and amplitude.
Recorded Measurements
Simulated with Trig functions


The "simulation" in the second plot is of the following functions in standard form:
$\begin{array}{rcl}y_{1}(t) & = & A_{1}\cdot \cos (\omega t + \varphi ) + D_{1},\\y_{2}(t) & = & A_{2}\cdot \sin (\omega t + \varphi ) + D_{2},\\A_{1} & = & 82,\\D_{1} & = & 15.73,\\A_{2} & = & 93.5,\\D_{2} & = & -75.6,\\\omega & = & \frac{1}{4.6},\\\varphi & = & -6.\end{array}$
Note that the frequency (ω) and phase (φ) are the same for both equations. Only the amplitude (A) and center amplitude (D) are different.

One important thing to note (in fact, pretty much the whole point of this post) is that ω is almost certainly a function of the Z-measurement of the gyro. In the simplified environment of a perfect rotation about a co-axial Z axis for the two sensors, this might be expressed as:
$\omega = \gamma z_{g}$
where γ is some constant. The reason for this is that the gyro is measuring some Δα, that is, the rotation rate around a given axis. This is, in fact, the frequency ω. It only needs some scale factor applied to it to match the measurements to the model. The value of that constant scale factor can probably be derived from the data, but I probably need to take a few more sample runs at various speeds of rotation before I can feel comfortable quantifying it.

More to come...

Thursday, October 6, 2011

Arduino, Wire, and I2C Part 4b: Noise reduction

Following the manufacturer's recommendations, I put a 1μF capacitor in the circuit to decouple power supply noise at VS. This meant replacing the .1μF capacitor that sparkfun had put there. Not a particularly big deal, and well worth it as you can see in the attached graph.

The down side is that the vertical axis, whatever that happens to be, remains fairly noisy on the accelerometer and to a lesser extent, on the magnetometer, but clearly the non-vertical axes have had significant reductions of noise. For the purposes of comparison, I did offset the 1μF data set so that the two sets of data shared a common mean value. The 1-sigma error shading is computed solely from the .1μF data set, however.

Sunday, October 2, 2011

Arduino, Wire, and I2C Part 4: Noise and analysis

These weekend I spent some time recording sample data sets from the sparkfun SEN-10724 and looking at it. I'd say I was analyzing the data, except that might give the impression that I actually have a good idea what I'm doing.

The recording of data, I actually set up using the sparkfun "ethernet pro" board, which is basically an Arduino with built-in ethernet and seemingly poorly designed voltage regulation (it gets pretty hot if you power it with the intended voltage levels). I felt more comfortable using the ethernet rather than serial-over-USB since I would be sending more data than was reasonable for the 9600bps that the Arduino UNO is fixed at (over USB - the firmware for the atmega8u2 that handles the USB-to-serial interface is programmed such that it will only operate at 9600bps).

After finding a few errors with decoding the data (mostly in the PC side, the microcontroller was programmed to send the raw measurements as-is), I found that the ADXL345 accelerometer has noise levels way out of spec. I've plotted the measurements and attached images of said plots at the end of this post. The XYZ measurements of the ADXL345 all had significant levels of noise (RMSD 5-12 LSBs) and the magnetometer had noise on the X-axis only (RMSD 9 LSBs). During the test data recording, the sensor board was in a breadboard sitting on my desk with no significant sources of vibration.

One concern I had is that the schematic for the SEN-10724 had two .1μF capacitors "near" the ADXL345. The datasheet calls for a single .1μF capacitor between ground and VDDI/O, and for a 1μF tantalum capacitor at VS, with an optional 10μF tantalum capacitor in parallel.

If the circuit instead only has a .1μF capacitor at VS, that might explain why the measurements look so noisy. In-circuit measurement of the capacitors is impossible, and I don't have a stockpile of SMD capacitors (strangely enough, after the 3 separate LED cube builds) to replace it with. Time to email customer support.