OpenWave #3 : First rotating arm test results

To give a quick summary of where I’m at with this project, I’ve got my breadboard circuit attached to the end of a rotating arm and it’s streaming data back to my PC. I’ve performed some basic analysis on this data and have double integrated the z-axis acceleration to get displacement and this displacement value roughly matches the length of the rotating arm.

Breadboard Circuit On Rotating Arm

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 I have streaming to my 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. I’ve chosen the z-axis to perform some signal analysis on as it is the vertical displacement I’m interested in. 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 is actually a good thing as this means it is slightly more accurate a representation of a real life data buoy.

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

Z-axis linear acceleration graph

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 my displacement data experiment, I took the acceleration from one half rotation which was from the 6 o clock position to the 12 o clock position. In reality I 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:

Graph of Z-axis acceleration for one half rotation

Graph of z-axis velocity

Z-Axis Displacement during half rotation

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:

Example of integration drift with velocity measurement

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. For the next week I will try to develop the algorithms further, Hopefully to the point where the starting point is a set of linear acceleration data and a program that can just spit out a value for maximum vertical displacement. Wave direction is another important parameter and the next few days will be spent thinking about how to approach that problem. Once these basics are taken care off, I can start to introduce statistical analysis and frequency domain representations of the data.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply