Messages

For the front I haven't been expecting anything to detect on my side, as it's too hard to recover anyway. I want to focus only on the rear.

Hence the idea of using iCrashed variable to disable slide effect of the rear when going into a wheeling. + some smooth effect when wheel comes back on the ground.

Currently not possible and unlikely it will ever be. As said, reason is: replay file size.

Please correct my statement if calculation is wrong, but assuming payload is 220 bytes for SPluginsBikeData_t struct, and that we set the telemetry rate at 50hz.
That should be 220*50= 11000bytes per second, so 11000*120 = 1320000 bytes for a ~2 minutes lap, i.e. 1320000/1024 = 1289 kBytes = 1.25MBytes per lap.
By replay file size being too big, were you referring only to telemetry data storage or to something else?

Some telemetry tools allow to inspect the telemetry while showing a recording of the lap, but you'll need to sync them properly to use them effectively, that can't really be automated.

Did you try to use MaxTM ? As it shows where the bike is on the track, you should have little need for the video.
To be honest, I don't think in real life riders do look at the video: the telemetry should be enough.

Not yet but that's one of the first graphical plugin I want to try very soon (my gaming computer isn't always powered nor usable at the moment).
My backup plan was to find a way to record telemetry data payload, then hit the replay and record a video of it, then try to find a good marker to sync both video + telemetry and display them side by side or with some overlay.
For the time being, my use case is more about understanding and spot-checking some ideas on how to use some data to make my rig's move realistic and consistent, like about the relation between variables and what happens visually, in order to validate or correct my thoughts.
A bit out of scope the regular need for telemetry while debriefing your lap to improve driver's best time.

BTW, for in game recording, try OBS studio (free): unless you have a very low-spec PC, it should be the best solution around (for CPU-based encoding). If you have a weak CPU but a good GPU, you can try the GPU-based encoders (Nvidia has NVenc, AMD has similar one, forgot the name). I think these encoders are also available in OBS Studio.

Yep I've been currently using OBS studio for recording the video
Unfortunately my gaming rig is a bit obsolete as of now regarding the CPU & GPU power: Xeon W3520 (~Q6600), 12GB DDR3 (too much for GP-Bikes ... ), HD5870, Crucial BX500 500GB SSD. Even with mid-quality settings I really see and feel the slower framerate while recording.

i mean you have throttle and brake inputs via MaxHUD plugin.

I don't want only these, but all the values given by Telemetry from SPluginsBikeData_t struct in https://www.gp-bikes.com/downloads/gpb_example.c

It's been a while since this thread has been created, but I have currently the same need than initial post.
I was also expecting the replay to actually re-shoot the telemetry but it seems it's not yet the case in beta15.

And I might answer to your question Max:

Right now I'm trying to see and understand different variables of telemetry against the bike behaviour.
My current solution is to play and record a video footage with telemetry shown on some other screen or window, aside GP-Bikes.
While I play + record, my framerate decrease noticeably and that's actually annoying for the gameplay.

Having the possibility to record and replay both video (with possibly different angles) + live telemetry of the replay would enable a much easier debriefing after a lap.

You're doing something wrong guys, m_fSteer is the steering angle ...

You're the expert, and I'm glad you chimed in, but how are our observations wrong? That variable seems to respond exactly as the rear slide would. It doesn't matter what it's supposed to represent. The variable stays at 0 degrees most of time and only fluctuates approximately 4 degrees(usually  less then 4) in turns depending on braking and acceleration. When the rear loses traction, that variable seems to go to a maximum angle of 25 degrees in either direction before the bike crashes. Why does this need to be more complicated?

+1
While I agree and understand that reflecting *exactly* the real behaviour of the bike should take much more variables and use a more complex calculation than just using steering angle as the trigger, eventually I personally aim to get the feeling the rear is sliding, not necessarily get the perfect scale of the slide.
Depending we play with 1 or more LCD screens or a VR headset, scale of the move can even be less than expected.

I have gathered some studies/papers from IEEE, Springer and ACM digital libraries talking about the subject, I'll try to dive in later this week and gather some data that could be used to improve a bit the detection model, while trying to keep it understandable though.

If you have a FFB wheel and you use DS1/DST: this makes no sense at all. The position of your wheel is not at all related to the steering angle in-game. How realistic it is if the wheel handlebars you're holding in your real hands is not aligned to the in-game handlebar ?!

Exactly, hence my statement: it would make no sense to use regular force feedback (the one you would enable with DS2) on a DS1 mode.

If you absolutely want to dictate to GPB the steering torque (DS1/DST) you'd need something complex, like a FFB steering wheel with a torque sensor on the steering axis. The device will send to GPB the torque, not the angle (the angle would stay unused), while GPB will send to the device the FFB signal, as usual.
What's complicate with that is the torque sensor sees not only the torque your hands apply to the wheel but also the motor torque (the FFB torque).
Theoretically you could take the difference between the torque sensor reading and the FFB signal to get the steering torque, but I'd expect this to be more a bit more triky in practice.

FFB on DS1 would be permanently a direct effect of physical engine telling exactly what should be the actual position of the steering. I'd dare to call this "Stepper Motor FFB" in this case.
It would actually not be a resistance effect given like the DS2 FFB, but just position as it should be.
Of course one could think the player would feel a huge/stall resistance through handlebar, as he is not controlling in any way the steering angle from that axis, but only with torque applied and read through load cells on handle grips that indirectly but very very quickly are computed by the GP Bikes physics engine.

So here for DS1 I'm not even thinking of getting anything more than a stepper motor + rotary encoder. There wouldn't be any torque sensor reading directly steering axis. you would actually only get a non-null torque value from the handlebar if the player fight against the steering angle given from the game.

And even if you sort this out you have a final problem: the in-game steering angle is not tied to your wheel angle (as we said, the angle is not sent to GPB). So even if you manage to do all the savvy computation to align everything (assuming this is even possible) in terms of open-loop, without a feedback loop the thing will drift and your wheel angle will be different from the in-game steering angle. Imagine how fun that would be ...

I'm not sure to understand your statement here.
Do you mean m_fSteer isn't reflecting the steering angle of the front wheel against the chassis?

In my case the rotary encoder on the stepper axis would just be a guarantee to be sure the stepper position is 100% correct, no matter a jump has occurred. This wouldn't be used to return the read angle of the steering to the game but would stay local to the stepper driver controller.


In TL'DR: my concern is to know whether DS2 + regular calibrated FFB would result in the same real effect than a DS1 + resulting "direct FFB from stepper motor".

Another way of asking the question: How is regular FFB values/behavior shaped usually in games? I know there are a lot of calibration settings on multiple sides: game &/or controller driver. But eventually what does that look like from the game to the driver? Is it just a scale? or are they different "profiles" of vibrations/effects?


But from an implementation point of view, I totally agree that DS1 mode looks like bringing much more challenge and less guarantee than going with DS2 & regular FFB, though.

Yep this is the variable I was talking about indeed ^^

I have been re-thinking this today.
If we put aside aforementioned factor to make a relation between steering angle & speed to set a "sliding" value, there is another issue: wheeling at high speed.

In that situation, we would have our front wheel touching the ground with potentially a positive or negative angle.
Although we can set an if statement based on Front wheel material (0= no contact so sliding factor calculation is paused), what would happen when the wheel touches the ground with a right/left angle? We would get a direct & fast slide that wouldn't have much sense actually.
However, this could be smoothed by postponing the recovery of our sliding factor by 1 second for instance, just enough time for the wheel to go back ~straight.

Assuming all of this is known, I don't see (for now) any other situation that would cause an issue with such way of calculating the slide factor.

Please correct me if I'm wrong, as I'm still trying to understand some difference between DS1 (elderly called DST) & DS2 (elderly called DSA).

(I may repeat with different words what has been already said earlier on this thread, so my apologises in advance for the redundancy)

I'm not sure to understand all the things about DS1 & DS2 as I have never tried it with a handlebar, but will try some day with my xbox controller, *just for science*.

My current understanding is:
- DS1 gets as input a torque value from the game controller, i.e most likely a handlebar with some load cells or any alternative sensor able to measure the torque applied on the handgrips (presumably without force feedback, but see the * further).
- DS2 gets as input a steering angle from the game controller, i.e most likely a handlebar with force feedback feature.

Assuming the force feedback effect we usually talk about (like here and in any other racing game) is calculated from GP-Bikes and sent to the controller, and because the force feedback has a direct effect on the steering angle at anytime (turning resistance but also wobble effect), it would put pressure against driver hands on the handlebar and provide complete random and irrelevant values read from a load cell, therefore it would make no sense to use regular force feedback with DS1. Is that phrasing correct?

Assuming what has been stated above is correct, there is still one thing I don't fully understand and that I have read in multiple times on the forum: "DS1 can't be played with force feedback".

*
If we consider we use DS1 with a big&powerful stepper motor and optionally a rotary encoder (it's out of scope regarding the topic but still .. I would prefer a close loop though).

DS1 example would be:
You want to lean the motorcycle on the right, so you push on your right handlegrip and/or pull the left one. Call this moment A.
Automagically, your perfect calibration of load cells input is sent as a torque input to GP-Bikes and the physical engine makes its calculations and as a result turns slightly the handlebar (call this moment B) and lean the bike's chassis until you have reached expected lean angle. Call this moment C.
While this was happening, in parallel your steering handlebar has slightly moved as well in real life (moment B) and chassis has leaned as well (moment B too).
Then you release any pressure on your handlebar, and the absence of torque input lets the physical engine put the steering angle to 0 degree again (or close from that) (moment C).

In this scenario, I assume we would feel directly the force through the stepper motor, without using any regular "force feedback" input from the game, but actually a direct effect on the steering handlebar, isn't it?
I'm thinking as well such FFB mode would affect as well torque input, but that would be exactly like in real life.

I'm not sure I have been clear on the 2 different force feedback I'm talking about, as I have actually no precise clue how a regular force feedback is presented from a game to a game controller (int? float? array of float?). If I'm not wrong, I don't think such value is given through telemetry data shared from DLO memory.

EDIT: re-reading my post shows me it can be felt contradictory about the "regular" force feedback and the "stepper motor" feedback.
In other words (again): I'm wondering actually whether the regular force feedback given through DS2 mode is as accurate and as real as the one we would feel through DS1 with a stepper motor controlling the steering.
Hence my statement "therefore it would make no sense to use force feedback with DS1" ...


All that post to say that I have only a very small in-game practice and that I'm trying to see what path I should take to develop my own rig: DS1 or DS2?

With a joypad (or, more precisely, without force feedback) DSA/DST make no sense.
You should address this only at people with FFB devices.

Saying "I tried DST/DSA with a joypad and it didn't work" is like saying you tried to dig yourself out of alcatraz with a toothpick and you didn't enjoy it. It's expected.

Totally agreeing (and btw I like this Alcatraz example  )
Root cause why I haven't voted yet, as my only experience so far is with lean angle input & an xbox controller ... but I'm not liking it from the first day as it's not natural at all.

Therefore your poll should leave 2 options for DS modes: DST & DSA

[m_fYaw]

Hi guys,

I'm currently working on my own rig (with a scaled version first, thanks 3D printing  ).

I'm going to skip the rig presentation for now as it's still in a very draft-ish state.
But basically I'd like to dedicate yaw axis for rear-wheel loss feeling, aka low side but also high-sides (in a limited way...).
For that I'm thinking to use some pinion & curved rack for rig's rear side.

Referring to official gpb_example.c, m_fYaw is the variable I was expecting to use.

Although pitch and roll data from telemetry can directly be used on the rig axis, unfortunately yaw axis data seems to be not that interesting for sensing the loss of grip on the rear wheel. Looks like this tells what is the relative orientation of our motorcycle chassis against the track map.
That actually makes sense of course, but I was thinking naively it could be used for my yaw effect purpose.

So I have tried to look at other variables from telemetry:
- rotation matrix: As explained in UDP Proxy thread, this seems to be just another shape for presenting yaw/pitch/roll data, so just an alternative to m_fYaw, m_fPitch & m_fRoll.
- m_fYawVelocity: Based on my personal understanding, this value seems to be the derivative of YAW position (i.e. m_fYaw).
When I put myself (voluntarily or not  ) to lose the rear, I do see this value becoming higher than on a regular turn without losing grip.
However, how strong is the turn is also affecting this value without even losing the rear, and therefore I don't think I could use this as a "flag" or reference.
- m_afWheelSpeed: So far so good, this is the only variable where I consistently see a delta becoming greater when I lose the rear.
In normal condition (straight line or slight turn), I only have a delta of 1 or 2 at the max between front & rear wheel speed.
However when I start to feel I lose the rear, I can easily see in telemetry a gap/delta of ±8 between front & rear.
Again, it's not a consistent gap, just a greater one than usual.

- Eventually, maybe by crossing m_fPosX & m_fPosY and/or their velocity with m_fVelocityX & m_fVelocityY, against yaw velocity I could make a delta that express somehow the "instantaneous" yaw moment of the chassis, relatively to its center point on the track. Would that make sense?

Aside these paths, I'm a bit lost right now to know how to detect such "event" with a graduation scale.

Thanks in advance for anyone trying to provide some help

EDIT: Got a suggestion from poupou59890: he had a good idea of using steering angle as a trigger/reference to know whether rear side is sliding or not.
So far so good, I think this is the best option for now. I have quickly rechecked some in-game video footage + telemetry aside and that seems usable.
However one should add some linear/exponential/logarithmic factor that would moderate this effect when we run a low speed (hairpin bend turn).

However I'm still open to any advice, idea, suggestion, etc from anyone !

Excellent topic!

I have been trying to think about such usecase myself some times ago, as I'm also *trying* to make my own motorcycle simulator for some time.

Here is a diagram of what I think could be interesting to give a try .. one day ^^

You cannot see attachments on this board.

Of course that would be far away of being as realistic as GP-Bikes driving experience, thanks to its open telemetry.
But that might be enough for getting some realistic behaviour of the motorcycle and eventually enjoying the moment, on something different than a dummy-spring-based platform (LeanGP or other).

Fixed parameters such as weight, wheel dimensions etc would directly be impacting the "gyroscopic" effect (or whatever name we call it), calculated from the custom program and its own algorithm.

At this point, I have honestly no particular purpose in using such matrix for now, but mostly curious to understand how the one given from the telemetry should be read and/or translated.
However, as seen on many websites, it seems a 3x3 rotation matrix should have the same spots for the same axis. I'm still wondering how this one is supposed to be read. but that won't be a blocking milestone in my case as hopefully all axis values are already given in alternative format.

I was not expecting to use UDP on very long term, but it has been my easiest way to decode the data so far, compared to shared memory using the DLL/DLO method (I'm a very newbie with that in programming).
Ideally I'd like to read that through Python, and have read it seems doable as well, but haven't spent time enough on learning how to do it though.

However, my intent in last post was mostly to get how to read & understand the rotation matrix values.