Sensor fusion makes lots of noice

JanWeber

Im using the MetaMotionR mountet on a bike. The angles from the sensor fusion makes sometimes very much noise (horizontal angle changes -/+ 30/40 degress when objects makes no angular changes). When bringing the bike to a stop, it seems that the sensor fusion is calibrated again and angles seems right again. How to avoid this behaviour? Does the sensor needs re-calibration or?

Any input is welcome.

Eric

• Where on there bike are you mounting the sensor?
  
• How are you configuring the senor fusion algorithm?
  
• Which fused data are you recording?
  
• Please provide some sample data that illustrates this problem
  

JanWeber

Hi Eric. The sensor is placed at the front fork on the bike. We are reading pitch, yaw and roll. Im not sure how the fusion algorithm is configured (maybe just using the default - I will check). The problem is that the horizontal angle of the bike position (0 when on a flat road) sometimes increases to like 30 degress (when still on a flat road),' and only reads around 0 again 1-2 seconds after bringing the bike to a stop. At the moment I do not have stored data on this, but just observed it multiple times. Anay suggestions regarding the configuration of the sensor fusion? Thanks for the help, and I will try to collect data if its needed

JanWeber

The sensor runs in NDoF mode and returns euler angles pitch, yaw and roll

Eric

• How is the sensor oriented on the bike and can you describe in more detail what exactly is happening in your bike test?  
  
• What is the code you are running to configure the sensors?  
  
• Trying using quaternions instead of Euler Angles
  

Until I can see the data that demonstrates this issue, all I can do is provide general tips and ask for more details.

JanWeber

To Eric: 

- The sensor is placed on the top of the bike frame between the steering and the seat with the bottom pointing up.

- The sensor runs in NDoF mode and logs euler angles. No further configuration is done.

Its not every time the sensor gives this issue and it only happens occasionally. It seems to happen the most when the bike is moving and has been moving for some minuts. I can monitor the vertical angle on the bike during riding using an app and sometimes it seems that the angle has dropped although the angle of the surface is unchanged. When bringing the bike to a stop, the angle seems to be corrected again. 

I have data (acc, gyr and euler) for an (small) example of the issue. Around 170sec the angle drops and between 180-190sec the angle seems to be stable (but around 10degrees lower than the surface) and after bringing the bike to a stop around 190sec the angle corrects again. When doing af Low pass filter on the ACC and a high pass filter on the GYR and a complimentary filter on both I do not get the same issue. 

Other times, the sudden shift in angle is more like 20-30-40 degrees. So the issue is that the estimated angle is too low until bringing the bike to a stop, where the angle is corrected again. 

For data please have a look at this file: https://www.dropbox.com/s/lnkyly8h4bt5o65/DataEricMbient.xlsx?dl=0

JanWeber

To Eric:

This file contains data for a longer bike run and better illustrates that the angle (see the ROLL) changes a lot even though the surface grade is close to 0%. My simple complimentary filter shows an angle varying around 25 degrees, whereas the ROLL from the sensor fusion changes significantly and are close to 80 degrees during some periods. Could the be the magnometer being affected by the bike-frame?

link: https://www.dropbox.com/s/ozdxoo4j1gk9xoy/DataEricMbient_LONG.xlsx?dl=0

Eric

Hrm, I wonder if this is simply just a misunderstanding of which axes are pitch, roll, and yaw, see:

https://mbientlab.com/community/discussion/comment/4632/#Comment_4632

JanWeber

Hi Eric. No, I’m positive that this is not the case. I have done several test that works well and as expected, but sometimes it doesn’t work well at all.

Eric

Can you try to isolate what the differences in your tests were that resulted in the different Euler angles?  I've forwarded the data to the firmware developer so maybe he can provide more insight to this issue.  It would also be interesting to see if you run into the same issue when using quaternions.

Matt

@JanWeber

Does the test bicycle have a steel frame?  This would probably have to be true for it to be interfering with the magnetometer.

I have been studying the point of interest in your short data set.

Of note is the large change in yaw, and the corresponding large changes in the gyro data.  Accel data is stable and similar before and after what I assume was a 90 degree turn.

If you study the sensor fusion and gyro data up close, the roll does track the gyro changes fairly well.  Studying the gyroy (which corresponds to roll angle) it does not appear that the bike returns to its initial position -- it is spending much more time rotating in one direction. gyrox (pitch) also changes significantly through the turn.

I think it could clean up the raw data considerably to consider the optimal positioning and alignment of the sensor on the bicycle.  Getting the device closer to the center of mass and center of rotation of the bicycle would reduce cross axis measurements in turns.  Getting the XYZ axes well aligned with the pitch, roll and yaw of the bicycle should likewise help.  Being closer to the center of mass would also reduce the noise picked up by the sensor during road bumps.

Without having raw magnetometer data it is hard to comment on whether there appears to be a problem.  If you do more data capture I think the mag data would be more helpful in debug than the accelerometer.

JanWeber

@Matt

Yes, where the “noise” has been the lagres the sensor has been placed on a alu frame. I still experience some issues when the bike has been in speed for some time, and I will try to collect some better data. The sensor is now being placed at the center of the bike and on tha mail frame. Let me see if this will work better.

Thanks

JanWeber

By the way; Can the magnometer be disabled in the sensor fusion?

Eric

Yes, use IMUPlus mode.

JanWeber

Hi Eric and Matt

I have placed the sensor the "correct" way, so the axis should fit. I still experience sharp decrease/increase in pitch angles, which are not true. 

For this data, I been riding the bike for 2-3 minutes with normal speed (around 20kph). I noticed that the pitch was suddenly around 88 degrees where the pitch should be around 34 degrees. When bringing the bike to a stop, the pitch angle dropped to the correct pitch angle. I was riding a flat road going straight ahead when this happened. 

During my entire ride I experienced this a couple of times, so it not just a one time error. 

I have data from the sensor in dropbox: https://www.dropbox.com/s/pvxdd4kc8mi8nk4/ErrorInPitch.xlsx?dl=0

and a picture of the placement of the sensor on the bike (carbon frame!) here: https://www.dropbox.com/s/p8bri4m9df34czd/SensorBike.jpg?dl=0

Eric

In your latest experiments, does this behavior consistently happen or is it random?

JanWeber

It seems random to me. It happend maybe 5-6 times during a ride of 1 hour (of what I noticed). However, it is consistent that the angle is corrected when bringing the bike to a stop.

JanWeber

One of my team members made a test today with the sensor. It seems that placing the sensor away from the bikes frame and other parts gives a better result (for example placed on the helmet). He drives an aluminium bike frame. When using the IMUplus mode the angles are much much more stable when the bike is moving.

So, what could cause these fluctuations in pitch when the bike is moving - and why is pitch corrected when the bike stops?

Matt

@JanWeber

Is there any chance you have a data set that shows the transition from correct pitch output to the incorrect output?  The last data set shows a nice transition from incorrect to correct output but not the other way.

Of note in that dataset is that the magnetometer is stable the entire time compared to the accelerometer and gyro.  This suggests that noise in the accelerometer or gyroscope data may be the issue, not the magnetometer.

Having the issue present on both aluminum and carbon suggests it is not related to metal in close proximity to the magnetometer.

Do carbon frames absorb more vibration energy than aluminum (I know that steel frames do)?  This could suggest aluminum frame showing worse results is related to accel/gyroscope noise.

Placing the sensor on the helmet would reduce motion noise (human bodies are great shock absorbers).  This is another indication towards motion noise.

IMUplus being more stable than NDoF indicates acc/gyro noise may not be a problem, and that it is in fact the magnetometer.  Although, the modes may have different sensor settings, which could reduce noise in acc/gyro and improve the readings.

The issue arising during straight line riding I think also suggests raw sensor noise.

The correction occurring during a stop -- which has very low noise -- also supports the noise theory.

Bicycle speed and bumpy ride relative to a typical use case indicates this as well.

It seems to me that most indicators are pointing towards noise in the raw sensor data being an issue.  I would love to see the transition event from good to bad with mag data included to potentially definitively rule out mag problems.

I will review the default sensor settings for IMUplus and NDoF to see if that could be contributing a noise reduction.  If we can narrow this down to motion data noise, we can provide further recommendations.

JanWeber

Hi Matt

I will collect data for you from good to bad angles.

We want to be able to read the bumps of a ride - this is the idea. So placing the sensor on the helmet/body is No option.

When I do a simple complimentary filter with HP and LP filter for respectively gyro and acc, the angles seems much better that the sensor fusion. But I wil try to do this on a data set with angles going from good to bad and to good again.

Thanks for analyzing this - this is a major concern for us.

Matt

@JanWeber

NDoF and IMUplus use the same settings for Accelerometer and Gyroscope, so there should be no noise difference in the raw data between these modes.

I still suspect noise as the primary cause.  If it is, the solution would be increase filtering before feeding sensorfusion -- this would go against your goals of capturing "bump" data by applying additional low pass filtering.

From a data perspective, you may want to stick to working with the raw sensor outputs.  This will allow you to capture high frequency data for the purpose of bump analysis, and also apply custom filters for calculating angles.  If your bump analysis is simple enough to use a peak detector for example, then you could probably stick with sensorfusion and get reasonable results.

JanWeber

Thanks. I still think there is more to it than just the noise. The data send to you is from a ride on a pretty smooth surface, so should bump noise really make sich an impact. I have been working on an own sensor fusion, and its not that easy to get it to work nicely. Actually, the sensor fusion works very well most of the times.

When I think back, it may be that the bad angles mostly occour when ridning smooth surfaces.

I wil try to collect some further data (the good to bad situation), and maybe we could have a talk after that regarding a possible solution.

We use raw sensor accelerometer data and the angles.

JanWeber

Hi

I have collected some more data to you. This is a ride (still same placement of the sensor on the frame) without the magnometer on a smooth and flat road. Angles looks much more stable then with the magnometer, but is still shows that the pitch rises gradually and then "corrected" when stopping the bike. In this ride the effects is only 5-10 degrees, but that is still significant. When doing a simple complimentary filter (High pass and low pass on gyro and acc), this is not the case (however, pitch is just more unstable, but doesn't have the same "drift" as the sensor fusion).

It should be possible to avoid this drift in angles and get a more stable fusion.

https://www.dropbox.com/s/r0x0svxu5e6o5mz/SensorFusionNoise.csv?dl=0

JanWeber

Hi Matt and Eric,

Did you get the chance to have a look at the new data?

Feel free to give me a call at +45 20342366 for a talk on the very important subject to us.

Thanks

Matt

@JanWeber

Could you confirm that the drift in this data sample is in the pitch data and not the yaw data?

These is not any obvious change in data when the drift begins.  It is very clear that the noise is 3-4x+ higher in magnitude than any visible signal.

As soon as the bike is stationary, the noise falls off and sensor fusion recovers.

We would expect high noise on a bicycle due to speed and vibration.

The next step should be to filter raw inputs to reduce noise and increase signal.

There is some basic filtering integrated into the accelerometer and gyroscope which can reduce the 3dB frequency to 1/2 or 1/4 of the default. This would provide a relatively quick method of testing the sensor fusion system with filtering.  Unfortunately, it is not yet directly exposed by the APIs so we will need to make some changes to enable this.

Which platform are you on, so we can advise on how to proceed?

JanWeber

@Matt

We are looking at drift in pitch. We are using our own iOS app. As I understand, you would make changes to allow for a different filtering on the Acc and Gyr data? This could might work and worth testing.

If you need a mail, is jwo@trailsense.dk

Eric

Yes, we will update the SDKs to provide access to the BMI160's digital filters.

Eric

Our iOS dev has pushed an update to the Swift SDK that enables configuring the BMI160 digital filters. This update isn't public yet so you will need to update your pod file to point to the GitHub repo:

pod 'MetaWear', :git => 'https://github.com/mbientlab/MetaWear-SDK-iOS-macOS-tvOS.git', :commit => 'f7d43e4'

The AccelerometerBmi160 and GyroBmi160 now have a filterMode property:

// Set accelerometer settings
if let accelerometerBMI160 = device.accelerometer as? MBLAccelerometerBMI160 {
    accelerometerBMI160.fullScaleRange = .range8G
    accelerometerBMI160.filterMode = .OSR4
}
// Set gyro settings
if let gyroBMI160 = device.gyro as? MBLGyroBMI160 {
    gyroBMI160.fullScaleRange = .range1000
    gyroBMI160.filterMode = .OSR4
}
// Set sensor fusion settings
device.sensorFusion?.mode = .nDoF
// Start the sensor fusion stream
device.sensorFusion?.eulerAngle.startNotificationsAsync { (obj, error) in
    // ... use obj as needed ...
}.failure {
    print($0)
}

JanWeber

Perfect! When is this official?

Eric

These features are only a quick fix to help you test the sensor fusion algorithm and should be considered as experimental SDK changes.

Being marked "official" is irrelevant given that it does not affect your ability to use the features.

JanWeber

Hi Eric &Matt

Any idea how to test different filter settings just using stored raw sensor data? Maybe a git library or any other way to feed sensor fusion with raw data and have the possibility to change filter settings?