• Welcome to PiBoSo Official Forum. Please login or sign up.
 
March 28, 2024, 12:26:48 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

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

PiBoSo


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?  :-\
"La perfezione non è il nostro obiettivo, è la nostra tendenza".

afarre

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.

afarre

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.

HornetMaX

Quote from: PiBoSo on February 20, 2017, 11:14:17 AM

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?  :-\
In general, I'd say yes, CG of the chassis would be better (not of the whole bike, as it may vary).
At least it would avoid situations in which the center of the chassis is defined in weird manner.

Quote from: afarre on February 20, 2017, 11:53:46 AM
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.
But what do you mean exactly with "ground reference " ?
It seems to me you want to know where the bike is on the horizontal plane: this is ill defined. The CoG can be somewhere while the contact patches of the tyres are somewhere else.

afarre

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…

HornetMaX

Quote from: afarre on February 20, 2017, 01:46:06 PM
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...

I still don't get what you're trying to do. If you want to know "where the ground is" in GPB, you'd have to parse the entire GPB 3d model of the track (as a very minimum). But what for ?!

It seems to me you're trying to figure out the "ground position" (whatever that means) from the bike's position (whatever that means). Not sue it makes sense.

Also, tyre patches are not all time on the ground: when wheeling or braking hard with the front and lifting the rear, some patches are not even there.

From what you're saying it seems you hope to take GPB telemetry output and do the rendering of the 3d world yourself (can't figure out why, but whatever).
To do that you need to render the track by yourself and then put the bike in your 3d world: for that you need the bike (CoG) position in world reference frame and the bike attitude matrix, plus a bunch of data about the bike state (suspension state, steering angle, even flexibility but this can probably be ignored for a visual representation).

afarre

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.

HornetMaX

The acc signal reported by GPB in is the bike's frame, so the 3 axes (X,Y,Z) are always aligned to the bike and they move (and rotate) with it.
If you need acc in some other frame, you'll have to convert to it (either using the roll/pitch/yaw angles or using the given rotation matrix and another one that you'll build yourself, from the world frame to your own frame).

afarre

Quote from: PiBoSo on February 20, 2017, 11:14:17 AM

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)

HornetMaX

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

afarre

Quote from: HornetMaX on February 22, 2017, 09:42:24 AM
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).

HornetMaX

Quote from: afarre on February 22, 2017, 11:06:51 AM
Quote from: HornetMaX on February 22, 2017, 09:42:24 AM
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).
As vel/acc data comes from physics, I'd say it's a moving point. It probably even changes due to chassis flexibility (albeit not by much I guess).

But I'm still unclear on what you want to achieve with all that.

afarre

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.

HornetMaX

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 ?

P.S.
What do you mean with "knowing the dynamic of the cog" ? The way GPB works, there's no explicit formula for that.