# Accounting for Mechanical Vibration in Accelerometer Readings

I am very new to DSP so please forgive any ignorance within this post.

I am working on a device which has a 6-axis IMU measuring acceleration and rotation. The device itself is attached to a physical bracket and is calibrated on a desk. During calibration, the system waits for a state of motionless, which is defined by a change in 1.5 degrees in any axes, before proceeding.

Because of the bracket, I've noticed it is susceptible to mechanical vibration. For example, when resting on a desk and people are walking by, the device can sometimes report movement in 2-5 degrees in some axes.

I've thought about relaxing that threshold from 1.5 deg to something higher, but thinking about it this past weekend I realized I don't want to do that. If the system is calibrating, it shouldn't be experiencing any notable motion during this step, or that won't truly be 'calibrated'. That would lead to errors for anything relying on that calibrated state.

I've thought about running some accelerometer readings (as in the lsb's) through an FFT to see if there are specific frequencies that appear when people walk by that I can filter out. I talked myself out of this since I think the vibrations itself would appear random due to differences in body weight, height, and stride of a human being.

The state of motionless mentioned above is determined by the difference between the current orientation and previous orientation for each axis. So, it's a old/new angle comparison really. The algorithm used is a median filter.

1) The new angle is the output of a median filter with window size of three. A new reading is rolled into the median filter at 100Hz (10ms), then the filter is sorted and the middle value is taken. The actual IMU samplings occur much quicker, but for this step (every 10ms) we using take the latest sample. I believe this is essentially down-sampling?

2) The old angle is simply the previous 'new' angle.

3) If new - old is greater than 1.5 degrees, the system considers itself to be under motion (rightfully so in my opinion).

Is there any way to account or compensate for this mechanical vibration in software? I am pretty lost as to where to go forward from this point. Any help would be appreciated.

EDIT I should probably mention the IMU is mounted rather well. The issue lies with the overall device, not the mounting of the IMU to the device PCB.

## EDIT2

As requested, I've gotten around to collect some data surrounding my problem. Sorry this took so long, other priorities were shifted.

I collected two sets of data:

1) Natural vibration of the system during calibration

- pastebin.com/bEN0Fc0r (Raw)

- pastebin.com/kyi5eET3 (Median Filter)


2) Vibration observed while people were walking nearby

- pastebin.com/XvahfKP3 (Raw)

- pastebin.com/kJDPWrg0 (Median Filter)


Raw accelerometer data was sampled at 100Hz for about 12 seconds. I also saved the median-filter result (sampled at same frequency and period). I wrote a python script (dependent on scipy & numpy) to process both sets of logs. What's shown below is as follows:

1) Raw 3-axis accelerometer data (in g's)

2) Median-filter output of 3-axis accelerometer data (in g's)

3) FFT of raw 3-axis accelerometer data (in g's)

4) New/Old Angle Deltas (in degrees)

• Any measurement above 1.5 degrees would be considered to be in motion.

The first set of figures was collected when the physical bracket was set on the desk and allowed to naturally vibrate. You can see that it eventually settles but it does take several seconds. This was without anyone moving nearby.

In the natural vibration set, there were a few spikes around 6-7 Hz, 11-12 Hz, and 20 Hz. Their amplitudes were fairly small so I'm not sure if this would be significant (read as: I don't know).

The second set of figures was collected while myself and 2 other people walked around nearby.

* In the people-walking-nearby set, the same frequency buckets are shown but with a much smaller amplitude. Unfortunately it's still picked up by the system as shown in the deltas in the next diagram.

I'd like to add that once a state of motionless is achieved (<1.5deg in all axes), the system waits one full second before calibrating. If a state of motion is entered (>1.5 deg) during this period, the system must reenter a motionless state, and then another full second waiting period occurs. In the diagrams shown above, the calibration takes place right around the 12s mark.

• The approaches you dismissed would be some of the techniques that would be suggested otherwise. Have you tried, Moving your apparatus away from people traffic. A sand bag here and there. Signs asking people to walk softly. Foam padding. There are technical solutions like active vibration control but these will depend on your requirements and available resources. – Stanley Pawlukiewicz Sep 4 '18 at 21:18
• Unfortunately I cannot move the apparatus away from people since people are guaranteed to be around. It's just in this one specific orientation it is more susceptible to vibration. There are two other orientations which are physically much more stable due to different brackets, and work well with that median filter solution. Would active vibration control be implemented algorithmically? I'm interested in software-based solutions, if possible. And since I have your attention, do you think the FFT investigation I described above would be worthwhile? I may be naively dismissing it. Thanks. – soplu Sep 4 '18 at 23:01
• The FFT idea should be explored unless you have a better idea. You can post back here what you find, actual data. There are a number of data junkies here who like these kinds of problems. – Stanley Pawlukiewicz Sep 4 '18 at 23:20
• Well that's been my best idea so I'll give it a try. It may take me a couple days but I will definitely report back. Thank you Stanley for hearing me out. – soplu Sep 5 '18 at 0:09
• You are welcome when you post your data, thank you for giving us all an opportunity to learn. – Stanley Pawlukiewicz Sep 5 '18 at 0:24