• Welcome to PiBoSo Official Forum. Please login or sign up.
 
March 28, 2024, 06:11:03 PM

News:

World Racing Series beta14 available! :)


Pos & Vel & Acc & Attiude (roll,pitch,yaw) data have a lot of vibration

Started by afarre, February 17, 2017, 01:48:28 PM

Previous topic - Next topic

afarre

For example this is what I get for acceleration at plugin (m_fAccelerationX/Y/Z) once converted fron G’s to m/s2 WHILE BEING STOPPED at pit lane:

Tm:10.651  Acc: -0.03854,  0.04696,  0.02026
Tm:10.661  Acc:  0.03568, -0.01455, -0.01586
Tm:10.671  Acc: -0.01369,  0.00086, -0.06813
Tm:10.681  Acc:  0.05925, -0.01978,  0.00242
Tm:10.691  Acc: -0.11423,  0.11189,  0.07062
Tm:10.701  Acc:  0.10622, -0.10067, -0.08319
Tm:10.711  Acc: -0.03617,  0.04870,  0.04864
Tm:10.721  Acc:  0.00575, -0.03101,  0.00218
Tm:10.731  Acc:  0.01728,  0.05173,  0.02555
Tm:10.741  Acc: -0.02552, -0.04527,  0.00980

It is a lot, see how sometimes vibration is of tenths of a m/s2. It is annoying for example for connecting any sort of movement platform.

It can be removed by applying a Low Pass Filter but it is to introduce important delays (latency). I am wondering how people using movement platforms are dealing with this problem.

Also I have to ask if is possible to remove that vibration from GPB output data.


afarre

sorry, I mean meter/seconds^2 (plugin GPB acceleration * 9.81)

HornetMaX

Well, a bike does have vibrations when the engine is on. Does the output vibrate that much when the engine is OFF ?

afarre

I have to confess that I have no idea how to turn the engine off, but in crashed status, once the engine sound is off, vibration data remains.
I hope it is equivalent to turning the engine off and means that data vibration at plugin has nothing to do with engine rumble.

HornetMaX

Quote from: afarre on February 17, 2017, 06:24:03 PM
I have to confess that I have no idea how to turn the engine off,

Slam the bike in 1st gear, engine will stall.

PiBoSo


Which output frequency are you using?

Do you still have the vibration while riding along the track?
If this is the case, an option could be to apply the low pass filter only under a threshold bike velocity.
"La perfezione non è il nostro obiettivo, è la nostra tendenza".

afarre

Quote from: HornetMaX on February 17, 2017, 07:39:53 PM
Quote from: afarre on February 17, 2017, 06:24:03 PM
I have to confess that I have no idea how to turn the engine off,

Slam the bike in 1st gear, engine will stall.
Ok, thanks, then I did it right, at the end the only way to stop the engine is crashing :)

afarre

Quote from: PiBoSo on February 17, 2017, 08:50:35 PM

Which output frequency are you using?

Do you still have the vibration while riding along the track?
If this is the case, an option could be to apply the low pass filter only under a threshold bike velocity.

Hello PiBoSo, tested with al frecuencies (10, 20, 50, 100Hz) with same results.

Please find attached a couple of graphs (second one is a zoomed part of first one) recorded at 50Hz.

Red graph = m_fAccelerationZ * 9.81
Blue graph = m_fSpeedometer

Data recording secuence:
Record 1-80: bike stopped
Record 80-352: max throttle, 1st gear, until bike reaches 20m/s speed
Record 352-456: max breaking until bike stops
Record 456-625: bike stopped

See at zoomed graph how vibration is even present while increasing velocity.
See how vibration is even worst during breaking.
See when bike is stopped again, suddenly appears some heavy acceleration peak values.

Because the problem is present at all velocities, it does not seem that an Adaptive LPF as function of velocity is going to help.

afarre

Some extra information:
I tried to get acceleration from pos (m_fPosX/Y/Z) or from velocity (m_fVelocityX/Y/Z), with same result, or even worst because 3 issues:
Pos or Vel data come in world coordinates which need to be converted to bike-local by applying bike-attitude matrix which is build also from vibrating data roll/pitch/yaw.
Even using double precision matrix introduces vibration because it is built with single precision data (float).
Acceleration coming from GPB already has some sort of filtering (averaging).

HornetMaX

Quote from: afarre on February 18, 2017, 08:38:44 AM
Ok, thanks, then I did it right, at the end the only way to stop the engine is crashing :)
No need to crash. You can stall the engine without crashing, like on a real bike.

Quote from: afarre on February 18, 2017, 08:49:18 AM
Red graph = m_fAccelerationZ * 9.81
You probably meant / 9.81, just to be sure.

Quote from: afarre on February 18, 2017, 08:49:18 AM
Because the problem is present at all velocities, it does not seem that an Adaptive LPF as function of velocity is going to help.
What PiBoSo proposed is to have some filtering active only below a certain speed, but that was if the problem was visible only with the bike stopped.

Anyway, unless there's a way for PiBoSo to "fix" this, why is this bothering you ? What are you trying to do with the acceleration signal ?
I'd tend to think that for most applications, simply using a moving average should help you in smoothing it.
It's probably unintentional, but the signal looks like one coming out from a noisy sensor :)

afarre

Quote from: HornetMaX on February 18, 2017, 11:37:15 AM
You probably meant / 9.81, just to be sure.
Nope, m_fAccelerationZ comes in G's, so it should be multiplied by 9.81 to be converted to m/s2.

afarre

Quote from: HornetMaX on February 18, 2017, 11:37:15 AM
Anyway, unless there's a way for PiBoSo to "fix" this, why is this bothering you ? What are you trying to do with the acceleration signal ?
I'd tend to think that for most applications, simply using a moving average should help you in smoothing it.
It's probably unintentional, but the signal looks like one coming out from a noisy sensor :)
I am in the midlle of development of a new movement platform and, as any simulation movement platform, it is fed with acceleration data. As stated at very begining, high frec noise can be filtered out but it always is going to create delays increasing simulator latency.

I don't know about GPB internals, but based in my experience I can say that this problem is very similar to 3D apps handling data in single precision (float) instead doubles, mainly when there are matrix products in between.

HornetMaX

Quote from: afarre on February 18, 2017, 11:57:56 AM
Quote from: HornetMaX on February 18, 2017, 11:37:15 AM
You probably meant / 9.81, just to be sure.
Nope, m_fAccelerationZ comes in G's, so it should be multiplied by 9.81 to be converted to m/s2.
Oups, right.

Quote from: afarre on February 18, 2017, 12:09:57 PM
I am in the midlle of development of a new movement platform and, as any simulation movement platform, it is fed with acceleration data. As stated at very begining, high frec noise can be filtered out but it always is going to create delays increasing simulator latency.
True but would that make a difference (the delay I mean) ? Did you try ?

Quote from: afarre on February 18, 2017, 12:09:57 PM
I don't know about GPB internals, but based in my experience I can say that this problem is very similar to 3D apps handling data in single precision (float) instead doubles, mainly when there are matrix products in between.
That's why I'm not sure it can be "fixed".

afarre

Quote from: HornetMaX on February 18, 2017, 04:51:23 PM
Quote from: afarre on February 18, 2017, 12:09:57 PM
I am in the midlle of development of a new movement platform and, as any simulation movement platform, it is fed with acceleration data. As stated at very begining, high frec noise can be filtered out but it always is going to create delays increasing simulator latency.
True but would that make a difference (the delay I mean) ? Did you try ?

Quote from: afarre on February 18, 2017, 12:09:57 PM
I don't know about GPB internals, but based in my experience I can say that this problem is very similar to 3D apps handling data in single precision (float) instead doubles, mainly when there are matrix products in between.
That's why I'm not sure it can be "fixed".

I can deal with this  :)
I just wanted to warn about this issue just in case it could be a bug.
About delays, just say that latency is always a hard nut to crack in simulation, so keeping it as low as possible is always a good practice  ;)