• Welcome to PiBoSo Official Forum. Please login or sign up.
 
March 28, 2024, 12:31:26 PM

News:

GP Bikes beta21c available! :)


Transforming plugin CG referenced data to ground referenced

Started by afarre, February 20, 2017, 10:29:06 AM

Previous topic - Next topic

afarre

Quote from: HornetMaX on February 22, 2017, 12:18:32 PM
But, what would you need these "splitted" accelerations for ? If your platform uses its DOF to simulate roll/pitch movements of the bike, what do you do with the acc data ?

Because besides of 3 attitude DOFs, there are other 3 position DOFs to simulate acceleratios.
Example:
lateral acc (m_fAccelerationX) is made up, among others, of lateral cenripeta when cornering and lateral acc due the lateral shift of CG when leaning. First one is to be simulated with roll DOF, second one is to be simulated with lateral position DOF.
Similar way happens with pitch DOF and vertical DOF to handle merged components at m_fAccelerationY.

afarre

Quote from: HornetMaX on February 22, 2017, 12:18:32 PM
P.S.
What do you mean with "knowing the dynamic of the cog" ? The way GPB works, there's no explicit formula for that.

Noooo, I meant the cog moving point, I meant knowing cog in real time, for example as an extra data to SPluginsBikeData_t.

BTW: I am not sure I really need it, just give some more time to play with available data ;D

afarre

I have been thinking over for a while on this subject, reaching following conclusion:

  • GPB plugin acceleration data is correct, nothing to say, nothing to add. Actually it is very similar to what we get when recording real telemetry: just 3-axis acceleration data.
  • Acceleration data is meaningless without its origin point. Comparing once again with real telemetry, we are to get different recordings at sensors located at different bike positions.
The same for position and velocity but, about position, PiBoSo already clarified that it is relative to Bike Editior 0,0,0.

HornetMaX

Quote from: afarre on February 22, 2017, 03:01:04 PM
I have been thinking over for a while on this subject, reaching following conclusion:

  • GPB plugin acceleration data is correct, nothing to say, nothing to add. Actually it is very similar to what we get when recording real telemetry: just 3-axis acceleration data.
  • Acceleration data is meaningless without its origin point. Comparing once again with real telemetry, we are to get different recordings at sensors located at different bike positions.
The same for position and velocity but, about position, PiBoSo already clarified that it is relative to Bike Editior 0,0,0.
Good conclusion :)
Notice however that in real telemetry you have the acc of a fixed point on the bike, while GPB gives you the acc of the (varying) CoG.

Quote from: afarre on February 22, 2017, 01:38:39 PM
Because besides of 3 attitude DOFs, there are other 3 position DOFs to simulate acceleratios.
Example:
lateral acc (m_fAccelerationX) is made up, among others, of lateral cenripeta when cornering and lateral acc due the lateral shift of CG when leaning. First one is to be simulated with roll DOF, second one is to be simulated with lateral position DOF.
Let's assume (wild simplification) that instead of a bike we have a single wheel that can lean (something like an unicycle), always touching the track.
the wheel is running straight, being vertical, at constant speed.
Now the wheel leans right and starts a right turn. What you say is: I have two acceleration components, one due to the trajectory of the contact patch (the turn) and one due to the lean.

You would like to make your platform roll with the "trajectory" component and move (left/right) with the "lean" component ? I'm not sure it makes any sense. The rider feels one accelaration, no two (or more).

Also, I don't see how your "lateral DOF" can possibly simulate an acceleration, especially if the acceleration is sustained. What would you have , a 30cm movement to the right each time the bike rolls right ?!

afarre

Quote from: HornetMaX on February 22, 2017, 03:20:10 PM
Let's assume (wild simplification) that instead of a bike we have a single wheel that can lean (something like an unicycle), always touching the track.
the wheel is running straight, being vertical, at constant speed.
Now the wheel leans right and starts a right turn. What you say is: I have two acceleration components, one due to the trajectory of the contact patch (the turn) and one due to the lean.

You approached quite well. Second one is because during leaning CoG is moving towards the center of turning. If you stay in a constant turn, second one is to disappear (from this point we better give it a name, let's say Leaning Lateral Acc Componenent LLAC). Similar thing happens in vertical axis because CoG is going closer to ground.

Quote from: HornetMaX on February 22, 2017, 03:20:10 PM
You would like to make your platform roll with the "trajectory" component and move (left/right) with the "lean" component ? I'm not sure it makes any sense. The rider feels one accelaration, no two (or more).

If applying lateral acceleration as it comes from GPB to platform lateral position DOF and leaning to roll angle (platform roll DOF), it will result on applying LLAC twice.

Because we know roll angle, LLAC can be removed from m_fAcclerationX... but we need to know CoG!!!!

Quote from: HornetMaX on February 22, 2017, 03:20:10 PM
Also, I don't see how your "lateral DOF" can possibly simulate an acceleration, especially if the acceleration is sustained. What would you have , a 30cm movement to the right each time the bike rolls right ?!

You are right, it is impossible... unless a platform based on centrifuge. It is the core of my development; it includes sophisticated algorithms against collateral artifacts like coriolis or yaw torque. One more reason to know about CoG.

afarre

Quote from: afarre on February 22, 2017, 01:41:26 PM
Noooo, I meant the cog moving point, I meant knowing cog in real time, for example as an extra data to SPluginsBikeData_t.
BTW: I am not sure I really need it, just give some more time to play with available data ;D

Answering to myself I have to confess that I can manage without CoG: just using m_fPos and roll/pitch/yaw; ignoring m_fAcceleration.

It is because origin of m_fPos is already known.

HornetMaX

I still think you're trying to do something that doesn't really make sense. But hey, it's your project :)