Visualizing vibration data from accelerometer

update: link to source code for IMU to Matlab connection

The next steps for the wave buoy project involves collecting accelerometer and gyroscope data from the onboard IMU and filtering/processing the data with a laptop to determine orientation and position. The math needed to perform these computations is too much for an arduino alone, so for now I plan to transmit the IMU data to my laptop with an Xbee and let the laptop do all the heavy lifting. Later on, the laptop will be replaced by a Raspberry Pi or other Linux based computer board, but for now it easier for me to develop everything in Matlab and then convert the code to C/C++ or something else in the future. Just personal preference.

Screen Shot 2016-02-07 at 11.27.05 PM

Schematic of arduino + Xbee + acceleroemter

I started by incorporating an arduino + xbee + accelerometer and wirelessly sending the data to my laptop for a class project. Some of the steps were covered in a previous post, which also had links to very helpful videos. Sine learning how to send data with the Xbee to Matlab over serial, I created a program to measure mechanical machine vibrations for a graduate level Advanced Manufacturing Technologies class. The goal of the class project was to build a wireless sensor that could be mounted inside a machine in order to detect an undesirable  phenomena called “chatter” that occurs during drilling, turning, and milling of metals. You may be familiar with chatter if you have ever heard a high pitched noise when drilling into a piece of steel or using a milling or turning machine and the cutting tool began to vibrate uncontrollably. Example video of chatter at 0:24 min.

Screen Shot 2016-02-07 at 11.27.21 PM

CAD model for the wireless sensor unit, milled circuit board, and assembled prototypes for testing.

To visualize this vibration data and have the program alter the operator when chatter was detected, I created a graphical user interface (GUI) in Matlab to plot the acceleration data in near real time on the laptop. There was a slight delay between transmitting serial data with the Xbee and plotting the data in Matlab, so it was as close to running in “real time” as I could get, given the hardware limitations and time restraints.  The GUI gave the operator the ability to choose two filtering methods, a simple moving average (SMA) and a exponential moving average (EMA), before calculating the vibration frequencies and their relative magnitudes using a Fast Fourier Transform (FFT). These two filters options were replicated from this video. In this way, it was possible to determine if the measured vibrations were typical mechanical vibrations due to the movement of the machine, or undesirable chatter vibrations due to the tool and workpiece interacting close to the natural frequencies of the mechanical system.

Screen Shot 2016-02-07 at 11.38.15 PM.png

Matlab GUI for mechanical vibration measurement class project.

From the image above:

a. option to filter incoming accelerometer data

b. if filter selected, use slider bar to set filter setting

c. near real-time visualization of accelerometer data (note it is noisy, thus filtering usually needed).

d. option to upload a saved CSV file from historical measurements for analysis

e. visualization of discrete Fourier transform showing magnitude and frequencies calculated from filtered accelerometer data

f. milling process parameters used to calculate the expected theoretical chatter freq.

g. threshold line to set minimum required magnitude before the chatter alarm was triggered

i. based on detected chatter, algorithm would suggest the closest optimal spindle speed to eliminate chatter problem

h. visual alarm: blue for no chatter, turns red to indicate chatter was detected

The significance of this project is that it gave me a chance to brush up on FFT calculations in Matlab and also create a GUI to visualize the accelerometer data steaming from the Xbee. I plan to use similar GUI for testing various IMU sensors when benchmarking their performance so having this code already built will save time. Additionally, dominant wave height and wave period can be calculated from FFT calculations, so this may also be beneficial to a later stage in the project once the IMU data has been filtered and corrected for buoy tilt.

The presentation slides and the class report are included below. The report has more details about the project as well as the Matlab and arduino codes.

MAE 298_Final Project Report

MAE298_Final Project_NRaymond_2015



7 thoughts on “Visualizing vibration data from accelerometer

  1. Would an Arduino 101 be able to run the code and dump it to an SD card? Its got a 32mhz Intel curie which has an on board 6 axis gyroscope/accelerometer and i believe RTOS.

    • Hi Mick,

      I recently upgraded to the BNO055 IMU breakout board from Adafruit. Just finished soldering together a ProTrinket + BNO055 + Xbee together for testing this weekend. The BNO055 will output orientation data in the form of Euler angles or Quaterions which is great, but that information would still need to be processed to create 3D position data if you wanted to directly measure a change in sea surface elevation. I am looking forward to bench-marking this sensor and learning more about it.

      The data mentioned in this post was pure accelerometer data, so a fusion calculation would be needed to correct for tilt of the sensor relative to the earth reference frame in order to calculate the true heave acceleration for the wave buoy project. There are many ways to go about this, below are two ideas that I have been thinking about tackling the problem but I am always interested in learning about other ideas too.

      Idea 1: have a microcontroller in the buoy process all the data and then only send wave height and period data to a base station at 10 – 30 minute intervals. The benefit is that less energy is used by the radio, likely one of the biggest power drains, since a small amount of data is being sent out every 10-30 minutes. The raw orientation data could be saved on an SD card in the buoy to create a historical record, which could be accessed after the buoy was retrieved. This is the more conventional method, I believe, used for long term deployment with til corrected accelerometer data being sampled ever 2-10 Hz, so the microcontroller can sleep when not being used to save power.

      Idea 2: Another idea is to have the microcontroller in the buoy continuously send orientation data to the base station. The benefit is that you can process all the data at the base station and have access to the raw data at a much faster rate compared Idea 1. Downside, the radio will eat up lots of power since it is continuously sending data to the base station, so you may need solar panels and bigger batteries to store energy on-board the buoy. This may be more advantageous for short-term environmental monitoring projects or applications where multiple buoys are deployed in a relatively small area for high resolution data capture. If all the buoys can steam data to a central base station, that base station can compile the data together and calculate other parameters other than wave heights and periods, so the system would be more flexible. This might be ideal if the sensors were only deployed for a few weeks or maybe even a few days until the batteries drained (assuming power from small on-board solar panels was not enough to maintain power for continued operation).

      For testing/development I have found that it is more useful if I can test a setup more similar to Idea 2, so that I can see in near real time the acceleration or orientation data streaming from the sensor. This way I can quickly identify is there are any weird issues rather than waiting 10 minutes for the system to collect historical data before processing. This is the system that was developed as part of my class project.

      For long term, I would like to create a system more similar to Idea 1.

      Thanks for the suggestion regarding the Teensy. Looks like another viable option to embed inside the buoy. I would be very interested in comparing the power consumption and computation performance of the Pi Zero, Arduino 101, Teensy 3.2, and Protrinket to correlate calculation speed with power consumption.

      I hope that addressed your comment, if not please let me know.


  2. According to your Idea 2 , almost 20 seconds of accelerometer data is enough to determine wave height. Every three minute transmission can give you 1/3 of the time values.
    As i was checking if anyone manged to measure wave height ,i happened to encounter that someone accomplished that using a cellphone.

    Conditions Necessary for a Fully Developed Sea at Given Wind Speeds, and the Parameters of the Resulting Waves
    Wind Conditions Wave Size
    Wind Speed in One Direction Fetch Wind Duration Average Height Average Wavelength Average Period and Speed
    19 km/h (12 mph) 19 km (12 mi) 2 hr 0.27 m (0.89 ft) 8.5 m (28 ft) 3.0 sec 9.3 ft/sec
    37 km/h (23 mph) 139 km (86 mi) 10 hr 1.5 m (4.9 ft) 33.8 m (111 ft) 5.7 sec 19.5 ft/sec
    56 km/h (35 mph) 518 km (322 mi) 23 hr 4.1 m (13 ft) 76.5 m (251 ft) 8.6 sec 29.2 ft/sec
    74 km/h (46 mph) 1,313 km (816 mi) 42 hr 8.5 m (28 ft) 136 m (446 ft) 11.4 sec 39.1 ft/sec
    92 km/h (57 mph) 2,627 km (1,632 mi) 69 hr 14.8 m (49 ft) 212.2 m (696 ft) 14.3 sec 48.7 ft/sec

  3. Pingback: Buoy design – 95mm diameter | Open Source Ocean Data Buoy Project

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s