Messages

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

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.

[applying LLAC twice]

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.

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!!!!

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.

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.

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

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.

OK, let me give another try:
As far as I have tested plugin lateral acc (m_fAccelerationX) combines all lateral accelerations that is going to suffer the bike, it includes:

• Lateral acc due centripetal when cornering
• Lateral acc due the lateral shift of CG when leaning
• I suppose it includes lateral acc due skidding (not tested)
• Maybe someone else...

Same way I tests pluggin vertical acc (fAccelerationY) combines all vertical accelerations:

• Vertical acc due the vertical shift of CG when leaning
• Vertical acc due wheelie & stoppie
• Vertical acc due track changes of slope
• Maybe someone else...

Now try to imagine a movement platform with unlimited yaw & pitch DOF, let's say it can move +/- 80º, enough to simulate wheelie & stoppie & any lean angle:

All listed accelerations must be splitted out because, for example, lateral & vertical accelerations due CG shift during cornering should not be applied to a platform such that, because they are already being simulated with real pitch & yaw platform DOF. The same about wheelie & stoppie.

I believe knowing the dynamic CG I could manage with it.

Vel and Acc are of the CoG, but the CoG itself is not currently passed to the plugin.

Right, I can see it at plugin interface, but going beyond, the question also means if it is a fixed point that can be taken from bike data files, or it is a moving point because bike changing conditions (suspensión lenghts, fuel, etc).

[it is the answer to thread subject]

The m_fPos values represent the center of the chassis ( 0,0,0 in the Bike Editor ), not the center of mass.
Would it make sense to use the chassis CG instead? Or maybe the CG of the whole bike? 

After playing with Bike Editor I understand what you meant and it closely matches what I was looking for: m_fPos reference (0,0,0 at BE) seems to match ground reference at some given suspension lengths.

HornetMaX was also right because it cannot be taken as fixed ground point due suspensions lengths and tire contact patches… besides wheelie & stoppie

I am not sure if it is going to solve my problem but it is the answer to thread subject but, before closing it I got one more question:

Is there any way to know the point where m_fVelocity & m_fAcceleration are referenced? (it is CG as directed at plugin comments)

You are right, bad example, if m_fPos data is coherent with origin of bike 3D model, it would necessarily appear at it correct place in the world once translated to m_fPos and rotated with m_aafRot. In fact it works very well with my external Visual System without any other action.

So let me give another try, focusing with m_fAccelerationY (vertical) I am assuming it combines 3 accelerations:
1) Vertical acceleration due bike lean
2) Vertical acceleration due bike wheeling
3) Vertical acceleration due terrain slope changes

If having a platform with 'unlimited' 6 DOF, first 2 acc are useless because they are going to be reproduced just leaning & wheeling platform to real angles, but last acceleration needs to be splitted out to be reproduced with platform vertical DOF.

If using GPB as a simulator sub-system, there are many reasons to know where the ground is, here you have an easy example: To drive an external Visual System.

Actually, I already developed my own Visual System (based on OpenSceneGraph), which is fed with plugin position & attitude data. But to work it properly, ground reference is mandatory so that I can put the ‘world’ at its place and tires patches appear all the time on the ground.

As I said, once knowing m_fPos is referenced to Bike Editor (0,0,0) I think I have information enough to sort this problem out  Just give some time…

Even when I haven’t tried bike Editor yet, if you say that mfPos represent Bike Editor (0,0,0), then  it is easy to know all the time where the ground is having attitude data and bike geometry

So, ‘Bike Editor’ and (0,0,0) is the answer, thank you. Let me play with it and I will post the results.

Actually, what I need is to transform m_fPos to ground reference. Is there any public bike reference for a transform such that?

Example: with current m_fPos, if cornering on flat horizontal surface m_fPosY is going to vary because Chassis Center moves down & up with bike lean angle. Same thing happens with m_fAcclerationY, it moves because Chasis Center dispalcement, when acceleration Y at ground point would be always =0 unless climbing a slope or bike wheeling.

Any other method of knowing where the ground is would be welcome. I am sure it is available, I am afraid I have to work with bike editor (I have to confess I haven´t tried yet) because my problem seems to be just a matter of bike geometry.

Can anybody confirm that CG point is the key 'chassis_mass' found at  *.geom file inside bike files (ie: varese_v594.geom)

Just in case anybody wants to check vibrating data just follow this:

Enable telemetry output (http://forum.piboso.com/index.php?topic=19.0)
Run GPB and, as HornetMaX said, slam the bike (1st gear, having gear and clutch in manual)
Wait until bike stops; wait few more seconds to record telemetry with bike stopped.
Exit GPB
Edit file “GP Bikes\gpbikes\logdata.csv”, go to the end of file and see how numbers are dancing at columns 8 & 9 ("LatAcc","LonAcc")

NOTE: see that vibration is 10 times bigger because logdata.csv acceleration is in G’s, but it needs to be converted to m/s2, in coherence with pos & vel, for any sort of use.

Before continuing, let me apologize because I had to start by introducing myself, that was because I already did it with PiBoSo by private mail, I'm sorry again.

I am developing a simulation project with the skill of faithful reproduce all bike environment cues. Compared with any other kind of simulator here we find 2 hard nuts to crack: physics model and movement platform.

For both subsystems I would prefer to act as integrator of existing parts but, about physic model there is nothing similar to rFactor for bikes, finding that GPB closely match what I need, starting with its interfacing hardness.

About platform does not exist anything able to reproduce bike accelerations in terms of intensity and sustainability, so I am developing a new platform & 'motion cues algorithm', which can reproduce all bike accelerations with no limit of time.

Mentioned algorithm includes a lot of post-processing. While I have tried to use GBP output interface 'as it is', I found that I need some other data, or maybe I can get them by transforming available ones. Example: I would need pos & vel & acc based on 'ground reference' instead CG, but I hope I can get them by undoing the transform to CG.

But, in any case, a more stable data would help, do not forget that vibration occurs even with bike stopped and engine off (stalled).

From this point let me do some more tests to manage both problems: vibration and getting needed data from available ones, and I will post my results.