Messages

Thank you Max !

As always, fast and efficient 

But i disagree on the Licence.ini file that i saved anyway before doing anything and it is stored in Piboso\GP bikes under My Docs as i can see before i do anything.

Right, my bad (I don't use the PiBoSo folder at all so mine is in the gpbikes folder).

[(EDIT)]

_Do i need to erase the Piboso directory under \My documents ?
__ If not, what needs to be replace ? Is just the new install going to replace the "good" files ? How does it work ?

Not really needed to delete.
However in your profile directory you have bike setups and these can work weirdly and/or make the game crash (if something in the bike physics has changed).

The only thing you absolutely need to move around between different installs is your license.ini (which is not in the PiBoSo directory anyway). (EDIT)

Most of the times I move my profile across versions (to keep the settings, controller setup etc), but I'd advise to delete the bike setups.

But my question is : How is supposed to be the way directories are installed inside ?

Is it : \mods\Bike, \mods\Tracks and so on ?

Yes.

Try to look at existing libraries for low-level stuff like handling of serial ports, it's always easier.
For a past project, I used this: https://www.teuniz.net/RS-232/

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?

Telemetry is more or less all is needed, including for replay. For full replay purposes GPB should also log the exact rider lean and, if we want to be over-picky, head orientation. But thta's minor.

Overall it's not huge, but keep in mind GPB has to write this while you're actually playing: it may lead to stutter.

Anyway, I just think PiBoSo considers telemtry one thing and replay another, separate one. But if he's OK to change that then it would be easy to do something with it.

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).

Try it as soon as possible. You may find out that's all you need (I mean a telemetry tool in general, not necessarily the one I made).

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

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

Some telemtry tools allow to inspect the telemtry 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 tink in real life riders do look at the video: the telemetry should be enough.

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 enconding). 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.

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?

The steering will go to max angle not only when you lose the rear: it will go to max angle in any other occasion the bike crashes (e.g. when you lose the front) and maybe even when wheeling hard. I thought you wanted to detect *only* a rear slide.

[V2.1.4 out (2019/05/08)]

V2.1.4 out (2019/05/08)

• Improved HUDECU (GPB only) on suggestion from Myst1cPrun3
• No chenages for MXB, KRP and WRS

[V2.1.4 out (2019/05/08)]

V2.1.4 out (2019/05/08)

• Improved HUDECU (GPB only) on suggestion from Myst1cPrun3
• No chenages for MXB, KRP and WRS

I dont undrestand what you mean by : "the bar must have a feedback loop to track the angle provided by GPB". Of course it need that feedback, like all normal wheel. the ffb motor will be a normal FFB motor like any wheel, it just need to not be "turned by the user by inputing angle, but torque, even if of course the handle bar will turn when you input torque".

A normal FFB driving wheel has no feedback loop on the angle (in it).
Again, GPB (or any other car sim) sends the FFB signal to the wheel, not the angle. The angle is read by GPB.
That way it's up to GPB to "sync" the in-game steering angle with the steering angle on the input device.

Why whould be the FFB torque be a problem cause when it is static then the torque calculated is just the torque you apply on the loadcell witch is a separate input on the handle bar (nothing to do with the ffb motor or sensor). if the ffb return angle that may be caused by curbs or whooble then you just need to apply more torque, just like in real life .......

Because the bar acts (i.e. generates a torque) on the very same ais as the FFB signal/motor.
And in general, nothing is static.

Edit : Car sim is not comparable, cause you turn your wheel way larger in angle than a bike handle bar. That's why apply in torque is more intuitive and natural then turning and applying angle .......

It's totally comparable, unless you're saying that your DST device will have a fixed bar on which you measure the applied torque with a strain gauge. But in this case there's no FFB at all: you'll only feel the torque you apply and not the torque the bike/environment applies back on you. Bad.

Edit 2 : It just like when you use head tracker to controll rider lean wich influance the bike lean ........just replace the ed tracker by the loadcell and the bike lean by steering angle .....

It's not the same at all, as your head tracker measures *only* your body movement, and not the sum of your body movement and the bike lean.

Hornet Max : i've respond to you in the other threand about you asking why people insist about DST, when you've compared it with car simracing .......

And why are you so sceptic about DST ? have you tried to build something and failed or are you just assuming it will never work ?

I'll reply in the other thread.

I guess you're aware of the Telemetry tool I've made for GPB, right ?
Inspecting the evolution of the angles over a lap can help understand what they are.

Maxhud? Haven't tried it yet. Will though.

No, MaxTM

[*the*]

What would perfectly mimic the real world with DST 1 (torque) will be :

- A handle bar with torque sensor (load cell) which you push when you want to lean, and which will sent torque input to gpbike
- Then Gpbikes calculate the appropriate steering angle resulting from that torque, and then re send it to a FFB motor in which is attached the handlebar. (the motor need to be powerfull enough to not receive "false angle" when you push on it ) this loop need to have the smallest latence possible. So you think your turning your handle bar when actually you just input torque.

Your load cell will measure at the same time the input torque and the FFB torque, separating the two may not be as trivial as it seems.
Plus, for GPB to send the angle to your bar, the bar must have a feedback loop to track the angle provided by GPB.

So for your setup you'd have to have a motor with a torque sensor and a feedback loop in your hardware (unless PiBoSo wants to implement it in GPB, which I doubt) plus the logic to make the actual measure of the input tuorque, without the FFB torque.
The alternative is a plain FFB wheel with DSA.
Unless you're very convinced option one has any advantage, I'd stick to option 2.
Once again: car-sim people have been playing with stuff for quite a long time and, to my knowledge, DSA is *the* unquestionned answer.

I don't know if GPbikes can separate the torque input and the steering angle output

Of course it can. The steering torque is always an input of the physical bike dynamic model (no matter if DST, DSA or default steering mode) while the steering angle is a state variable of that model.
The only difference is that in DST the steering torque is an overall input (i.e. the payer provides it to GPB), while in DSA and plain steering the steering torque is computed by the virtual rider (from the steering angle input with DSA, from the lean angle input with default steerig mode).

Intersting post Yes the steering angle is the steering of the handle bars but as the axis of handlebars is the only pivot, it gave also the angle  of the rear tyre compare to the front tyre, So in certain case we can know the value of the slide by this variable but it is not "real" but maybe can give a good feeling I did not test it yet but trying to think about all possible way to have yaw movement under heavy braking or or power slide in turn...

Hmm no. The fact you have some steering (so front and rear are not aligned) doesn't imply you're losing the rear.
How would you compute the "value of the slide" from the steering angle ?

The derivative (within a quite small time span) of YawVelocity should be interesting for this, right?

In principle, yes. In practice you'll likely need to be smarter than a plain derivative. You'll have to play with some sort of high-pass filter to see if this is feasible, on the Yaw or on the Yaw velocity.
To be honest, I expect that won't be enough but it depends on what you really want to do with the "Hey I'm losing the rear" signal.

The tricky thing is that a low-side happens pretty fast ...

How does it read when leaning in a turn? Is it relative to the bike or the ground?
If bike, not interesting, if ground, possibly usable?

I guess you're aware of the Telemetry tool I've made for GPB, right ?
Inspecting the evolution of the angles over a lap can help understand what they are.

They yaw is the "bike direction": imagine a line along the bike frame, project it in the 2d X-Y (horizontal) plane and measure the angle between that projection and a given fixed direction (the "north") and you get the yaw angle.
If there's no lateral sliding (rear or front), then it's the same as the heading, the direction you're moving in.

Not sure what you mean with "relative to the bike or ground".

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

Detecting accurately lateral slipping from telemetry data is not easy. This is why traction control systems (real ones) have only recently integrated the ability to deal with lateral slipping (I think there're only a few top notch road bikes with this kind of TC systems available today).

The trivial approach is to use m_fYaw/YawVelocity and some filtering: the yaw varies when you follow the track, but if your bike starts to lose the rear in a turn, the yaw will vary quickly. Depending on the detection precision you need, filtering could be enough or totally not enough.
If it's not enough you'd have to go ballistic with something way more complex, like a simplified model of the entire bike & tyres to predict a yaw and see when the measured one diverges.

If GPB outputs in the telemetry the tyres (rear and front) sideslip angles then it would probably be easier to do something, but it's unlikely this will happen give that GPB outputs are the outputs one could reasonably expect to see in a real bike (onboard) telemetry system.

[Final words (aka TL/DR):]

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.

Correct. So with a joypad stick, if you push the stick 50% right your sending to GPB:

• 50% of the max steering torque with DS1/DST
• 50% of the max steering angle with DS2/DSA

If you have a FFB wheel and you use DS2/DSA: you try to control the wheel angle with your hands, fighting the FFB that is sent by GPB to the wheel. If you think, this is exactly what happens on a *real* bike (and car too, if we forget about power steering).
GPB reads the wheel angle from the wheel and the virtual rider (a "scaled down" version compared to the virtual rider used without direct steer) tries to align the in-game handlebars to the angle your wheel dictates. This is not perfect but can be done reasonably well once everything is setup properly (e.g. reasonable FFB force compared to your arms').

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

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.

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 hear the question coming: so, why not making a feeback loop on top to somehow keep the two angles aligned ?
Answer: because in the end, that would be equivalent to use DS2/DSA, just much more complex, more expensive to build, way more tricky to fine tune and without even a gram of proof (or hint of proof) it will work any better (if at all).

Some will argue that with DS2/DSA we still have a virtual rider in the loop, so it's not really "as direct as it could be".
That's right but that would be the case in the above setup with DS1/DST too (in order to have the wheel aligned to the in-game bars), so the point is mooth, sorry.

Final words (aka TL/DR): car sims with FFB (including pro-grade ones) all work with DS2/DSA and do not even have the option to use DS1/DST. That should tell something ...
DS1/DST is just a curioisity and for the sake of not confusing future (MCGyver-style) users, I'd argue PiBoSo should take it away. You want FFB: do as Marcel, get a DD steering wheel and use DS2/DSA. From what I've seen of his rig, it works extremely well. And that's exactly what DS2/DSA has been made for.