## OpenWave #5 : The displacement calculation problem

This post will examine the steps currently being used to go from vertical acceleration data to vertical displacement and the issues involved.

### Step 1: Getting acceleration data

The first step is to setup the rotating arm with the IMU attached, rotate it for a fixed amount of time, say 60 seconds and capture the raw linear acceleration data for the z-axis which is the vertical axis. See below video for an example of the rotating arm.

Note that this video is just an example of the arm rotating. All of the data used in this post was obtained with the arm set to a 40cm diameter and a rotation speed of approximately 0.2Hz. The recorded z-axis acceleration data looks something like this:

### Step 2 : Filtering acceleration signal

As it is, this signal is too noisy to work with and so it is first filtered before any other signal processing steps occur. The low-pass filtered signal is shown in orange below:

### Step 3 : Peak detection

Now that we have a relatively smooth signal to work with, peak detection is relatively simple. The orange x marks on the graph below mark the peaks and troughs of the signal.

### Step 4: Break signal into chunks and double integrate each chunk

These peak detection points are used to break the signal into chunks where each chunk is separately integrated twice to go from acceleration chunks to displacement chunks. The displacement chunks can then be graphed which looks like this:

One issue is that changing the integral reset point has a drastic impact on the end displacement result. The above image was obtained by detecting the minima and maxima in the acceleration signal and breaking it into chunks at those points. If you break the signal at just the minima you get the following displacement graph:

By using the maxima to reset the integration you get this graph:

Remember that the actual arm diameter was 40cm so we should see a maximum displacement of 40cm. Take the above image for example. The first blue line on the left goes from approximately 0.2m down to -0.5m which is a total displacement of 0.7 meters. The rightmost blue line goes from 0.2 down to -0.2 which is exactly what the expected result would be. More testing is necessary to try and narrow down the cause of this issue.

## Some observations on vertical displacement:

Getting displacement data from an acceleration signal is possible by double integration. This double integration causes issues as any error present in the original acceleration signal will accumulate at an exponential rate in the displacement signal.

A python script is being used to perform analysis on the Z-axis (vertical axis) acceleration signal.

The script performs the following steps:

1. Analyse the Z-axis acceleration data and identify the local minima of the data.
2. Split the Z-axis acceleration data into seperate chunks of data using the local minima as breakpoints.
3. Double integrate each of these z-axis acceleration data chunks seperately and return an equal number of displacement data chunks.
4. Stitch the displacement data chunks back together to get a continuous time series of data .
5. Plot the stitched displacement data.

The stitched together displacement data looks like this:

The values of displacement in this graph to not match the diameter of the rotating arm. After researching other academic articles about inertial wave measurement devices, it is apparent that the accuracy of the measurement is inversely proportional to the frequency and the amount of acceleration involved. This is one possible explanation for the discrepancy. Experiments over the next few days will involve modifying the speed of rotation of the arm and the length to see how that affects the accuracy of the height measurements.

Some papers online mention using the zero crossings as integration reset points instead of local maxima or minima. The results from the zero crossing method is shown below:

This graph doesn’t look anywhere near as good as the first and the values are completely different compared to the minima detection method. The separate displacement chunks that have been stitched together do not match up perfectly meaning the last point of one chunk is quite far away from the first point of the next chuck. This artificially adds high frequency components into the data. As the frequency content of the data is really important , this method may not be viable without adding in more steps to stitch the displacement chunks together in a smoother way.

The current parameter of interest is maximum displacement. This should be equal to the diameter of the rotating arm which is currently 1.5 metres. This parameter is calculated by looking at each of the displacement chunks and finding the maximum displacement by subtracting the absolute value of the largest displacement from the absolute value of the smallest displacement value in a given chunk. I do this for all of the displacement chunks and average out the maximum displacement value from each.

When using the peak detection method this value of maximum displacement comes out as 1.81 meters.

With the zero crossing method this value of maximum displacement is 1.83 meters.

This represents roughly a 20% error for both methods of measurement. The exact cause of this issue is not known and will require further experiments to try and diagnose the problem.

## OpenWave #3 : First rotating arm test results

The breadboard circuit has been attached attached to the end of a rotating arm and it’s streaming data back to a PC.

So just as a recap, the breadboard contains a teensy 3.6, a BNO55 9DOF IMU sensor and a serial bluetooth adapter. At the moment the only values  streaming to the computer are linear acceleration for the x,y and z axis. In the image above, the z axis is perpendicular to the surface of the BNO55 breakout board (parallel to gravity).The z-axis will be the main focus for initial signal analysis in order to try and get vertical displacement measurements. Before we get in to the signal analysis, check out this video of the arm rotating:

It’s useful to first see how the breadboard moves as the rotating arm rotates. It doesn’t stay perfectly horizontal which may not be a bad thing as it is slightly closer to real world data.

First lets take a look at the z-axis linear acceleration:

This graph contains acceleration data from about four and a half rotations. The good news is you an see a clear periodic element to the data which does roughly coincide with how long the rotations take (for this set of data each full rotation was around 4 seconds).

It’s a bit puzzling the way the acceleration dips a bit before increasing and then dropping down to around -4m/s^2. One possible explanation is this occurs when the IMU is near the top of the rotation, the mount does not stay completely horizontal as there is some friction with the rotating arm. This causes the rotating mount to rather quickly flick from one position to another when near the top of a rotation. This flicking action may momentary cancel out the z-acceleration before the imu starts to properly descend once again. This action can be seen in the video above. Another contributing factor may be that the rotating arm is weighted in an unbalanced way. If the counterweight is a bit heavier than the breadboard it would have a slight catapult effect when the IMU is near the top part of the rotation.

In the graph above, the minima where the acceleration drops to around -4m/s^2 represents the IMU at the lowest part of the rotation (6 o clock on a clock dial).

So if we integrate from one minima to a neighboring one this will give us the instantaneous velocity for each point in one rotation. For the displacement data experiment, the acceleration was taken from one half rotation which was from the 6 o clock position to the 12 o clock position. In reality it was a bit off so it’s a bit more than one half but it doesn’t really matter as you will see in the graphs below.

If we integrate this velocity once more, displacement can be obtained.

See below for the graphs of acceleration, velocity and displacement:

This initial test has shown quite encouraging results. The length of the rotating arm is 1.5 meters and the IMU is mounted right at the end of the arm. This means going from the 6 o clock position to the 12 o clock position, the IMU will travel through a vertical distance of 1.5 meters which you can see is roughly the maximum displacement on the displacement graph.

### The Integration Problem:

From the graph above you can see the issue related to absolute 3d position tracking with IMU sensors. The fact that to get velocity you have to integrate an acceleration measurement means that even tiny errors will accumulate. Then performing another integration of the velocity to get displacement means that any errors in the acceleration measurement are integrated twice and so the error accumulates in an exponential fashion.  As a result, the general consensus is that IMU devices are not suitable for absolute 3d position tracking.

The reason why wave sensors can get away with this is they use a statistical measurement approach. Measuring the height of a single wave may have a relatively large error margin but measuring the heights of say 1000 waves and reporting the significant or average wave height has been achieved by many commercial wave sensors. One step needed is to periodically reset the integration counter. In the first graph in this post of z-axis acceleration, the minima stand out on the graph as easy spots to reset the integration counter. This means that any error that accumulates would only have around 4 seconds to do so.

### Next Steps:

It’s early days in terms of algorithm development. This post is a quick record of some analysis on the first data set of linear acceleration from the rotating arm.

## OpenWave #2 : Rotating arm and breadboard circuit started

Some decent progress has been made since the last blog post. See the image of the breadboard below which shows the current state of the electronics: The small blue pcb with the four mounting holes is the BNO55 breakout board from adafruit. The vertical standing pcb is a serial bluetooth adapter and the green pcb on the far right is a teensy 3.6. The whole thing is powered by 4AAA batteries because I’m intending to put this on the end of a rotating stick and don’t want power cables getting in the way.

The Teensy communicates with the BNO55 via I2C and also can send serial data via one of it’s UART ports which is connected to the bluetooth serial link.

At the moment I’ve got some euler values streaming via bluetooth serial to my computer as an initial test:

## I had a motor in my parts bin that has a built-in gearbox and a good amount of torque. The issue was connecting the shaft of the motor to the rotating arm. In the end a laser cut bracket made out of acrylic did the job and allowed me to make a good connection between the motor shaft and the rotating arm as seen here:

##  The rotating arm is 1.5 metres in length, that seemed to be about the longest the motor could handle and it also fits in my room which is nice. For testing that the motor had enough torque I taped 100g weights to either end of the arm and thankfully the motor was still able to rotate the arm without too much difficulty. See the video below for the rotating arm in action:

As you can see from the video, the speed of the arm is not constant as it rotates around. When the arm is vertical or approaching vertical the law of the lever makes things a bit easier on the motor so it is able to accelerate a bit, when the arm is horizontal that is the hardest part of the cycle for the motor and so the arm slows down. Hopefully this won’t be an issue down the line , the data will reveal all!

The end goal is to have the breadboard circuit with the batteries, bluetooth adapter, teensy and BNO55 attached to the rotating arm. The one detail that will require extra attention is that the electronics need to stay more or less horizontal as the arm rotates. This will require some kind of mount that can rotate freely and has a bit of weight towards the bottom so as the arm rotates the mount stays horizontal.

Having the electronics rotate with the arm would make the IMU calculations way more difficult. I’m not saying it’s impossible, it would just add a layer of complication that is totally unnecessary for the current application. Once the electronics is mounted to the arm I can start thinking about how to approach the software for the project. My thoughts at the moment are that it might be easier to get the raw IMU data for a couple of rotations, store that in a CSV file on my computer and try to develop some algorithms using that data. Once I get something working on the PC I can then go back and try to run it on the microcontroller. I think this approach will be fastest but I’ll give it more thought over the next few days.