Can anybody confirm that CG point is the key 'chassis_mass' found at *.geom file inside bike files (ie: varese_v594.geom)
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? :-\
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.
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.
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.
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…
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).
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.
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).
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)
Vel and Acc are of the CoG, but the CoG itself is not currently passed to the plugin.
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).
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.
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.
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.
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.
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
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.
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 ?!
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.
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.
I still think you're trying to do something that doesn't really make sense. But hey, it's your project :)