• Welcome to PiBoSo Official Forum. Please login or sign up.
 
September 22, 2020, 05:33:09 PM

News:

World Racing Series beta14 available! :)


Countersteering Controller Suggestion

Started by August1, October 12, 2016, 06:31:11 AM

Previous topic - Next topic

grimm

A ton of my stunt riding video I put out was using DST with the Klax settings all the way around. It allowed control of the sim that I never thought possible, it felt like netBike with the twitchy behavior of a real machine.

RC45

Quote from: grimm on October 16, 2016, 04:24:36 PM


Even after a bunch of thought on the matter, I just can't see why load cells wouldn't work for left-right rider movement (not steering). One on each side of the tank of a sit on system so when you are full hang off and a leg is hooked over the tank pushing a panel with a load cell, it would deploy the knee and get the rider out off the side of the bike, rather than letting the auto lean deal with it as I currently do with the desk top system I mess around with from time to time, also allowing for you to counter weight the bike out of a power slide or stay tucked into the bike at high speed cornering if you desire such a movement to improve upon a lap time that is being held back by the rider hanging way off causing instability. If I ever get around to digging up my spare frame and all the associated bits and bobs for it to build a full sit on system I may attempt it just to see how it work, worst that happens is I just tick the auto lean box again and give up.  ;)

This may be the better a better use for load cells. I was just thinking the nature of load cells needing constant pressure, which is what we do when we lean or counter steer - we apply a varying amount of steady state pressure.

They just seem to be the appropriate input sensor for these types pf actions - in my mind at least.

doubledragoncc

That is totally possible grimm, for rider movement but you will want loadcells with quite a low pressure sensing.

DD

GPBOC Live Streams: https://www.youtube.com/c/IASystemsComputerControls; i7 7700 4.8GHz z270 ASUS Maximus Code Mobo 16GB 3866MHz DDR4 RAM ASUS Strix RTX2070 OC 8GB DDR6 Kraken X62 AIO Cooler ROG Thor 850w PSU in ROG Helios Tower Case.
https://paypal.me/IASystems

HornetMaX

October 17, 2016, 09:37:03 AM #33 Last Edit: October 18, 2016, 10:41:25 AM by HornetMaX
Quote from: RC45 on October 17, 2016, 09:00:53 AM
This may be the better a better use for load cells. I was just thinking the nature of load cells needing constant pressure, which is what we do when we lean or counter steer - we apply a varying amount of steady state pressure.
This is the point that I can't manage to explain to you.

Let's say you're leaning at 20deg in steady conditions (stable lean angle, constant speed, constant track and tyre conditions): at this point your bars are at a given angle (not necessarily zero, but smallish) and you have to apply a torque to the bard to hold everything steady. The torque you have to apply is usually not big, but it depends on the bike overall geometry (bike, tryres, masses, ...). It could even be zero in some conditions. Let's say the torque is 2Nm (Newton/m).

Now let's imagine you want to lean more, to 30deg. What you say is: I want to lean more so I need to apply more torque. You're kind of expecting that there's fixed amount of torque (let's say 3Nm) that will make you go to 30deg lean and then, to hold that lean, you have to hold the 3Nm torque. That's wrong.

Most of the time you'll have to apply some extra torque (e.g. 3Nm) to make the bar turn, then the bike will start leaning more and once you're at 30deg, you'll have to reduce the torque,
Once you're at 30deg it may be that to hold that lean you'll only need 2Nm, just like at 20deg (or maybe more or maybe even less !).

There's no simple link between a steady steering torque and a steady lean angle, at least not on a real bike.

After that, you can try to use a load cell to dictate the target lean angle to GPB (after all that's not any crazier than using a joystick angle).
But the justification for that cannot be "because that's what we do on a real bike", because it's not.

[EDIT: Nm for torques, I must have been seriously on the rush]

RC45

October 17, 2016, 06:19:19 PM #34 Last Edit: October 17, 2016, 06:35:35 PM by RC45
Quote from: HornetMaX on October 17, 2016, 09:37:03 AM
Quote from: RC45 on October 17, 2016, 09:00:53 AM
This may be the better a better use for load cells. I was just thinking the nature of load cells needing constant pressure, which is what we do when we lean or counter steer - we apply a varying amount of steady state pressure.
This is the point that I can't manage to explain to you.

Let's say you're leaning at 20deg in steady conditions (stable lean angle, constant speed, constant track and tyre conditions): at this point your bars are at a given angle (not necessarily zero, but smallish) and you have to apply a torque to the bard to hold everything steady. The torque you have to apply is usually not big, but it depends on the bike overall geometry (bike, tryres, masses, ...). It could even be zero in some conditions. Let's say the torque is 2N (Newtons).

Now let's imagine you want to lean more, to 30deg. What you say is: I want to lean more so I need to apply more torque. You're kind of expecting that there's fixed amount of torque (let's say 3N) that will make you go to 30deg lean and then, to hold that lean, you have to hold the 3N torque. That's wrong.

Most of the time you'll have to apply some extra torque (e.g. 3N) to make the bar turn, then the bike will start leaning more and once you're at 30deg, you'll have to reduce the torque,
Once you're at 30deg it may be that to hold that lean you'll only need 2N, just like at 20deg (or maybe more or maybe even less !).

There's no simple link between a steady steering torque and a steady lean angle, at least not on a real bike.


After that, you can try to use a load cell to dictate the target lean angle to GPB (after all that's not any crazier than using a joystick angle).
But the justification for that cannot be "because that's what we do on a real bike", because it's not.


It seems you assume I do not understand or know much about motorcycle control. Note how I stated:

we apply a varying amount of steady state pressure.

I understand exactly how motorcycle control works and that we need to over come various steady state conditions by various inputs.

The discussion is about the suitability of load cells as the input sensor of choice, and if the load cell needs to have dynamically applied filtering to the input and perhaps even output signals, filtering that is driven by yet another set of signal analysis based on lean angle, speed etc. then so be it and that is the subject of the final controller design.

But if I as the player have to provide both the input and resistance as I saw my way around the corner like we did before quality Force Feedback controllers on the car side of sim-gaming then I may as well keep using the XBox or PS2 controller.

If we are actually trying to overcome/counter forces presented to the rider by the bike, then we should at least have them brought to the table by the bike and not simulated by our own controlled responses to the dynamics of the situation - and as far as I understand GP Bikes is able to represent the forces presented by the bike in this equation very well.

I also understand passions run high and any 'new comer' on the scene will rile up the locals that have rehashed these subjects ad infinitum :)  Just throwing my idea in the ring :)

HornetMaX

Quote from: RC45 on October 17, 2016, 06:19:19 PM
It seems you assume I do not understand or know much about motorcycle control. Note how I stated:

we apply a varying amount of steady state pressure.

I understand exactly how motorcycle control works and that we need to over come various steady state conditions by various inputs.
I'm ready to assume you know exactly how bike controls work (and sorry if it seemed I implied the opposite), but what is a "varying amount of steady state pressure" ?!  :o

Quote from: RC45 on October 17, 2016, 06:19:19 PM
The discussion is about the suitability of load cells as the input sensor of choice, and if the load cell needs to have dynamically applied filtering to the input and perhaps even output signals, filtering that is driven by yet another set of signal analysis based on lean angle, speed etc. then so be it and that is the subject of the final controller design.
Wow, that would be utterly complicated to put in place and tune. But there's little need, see next.

Quote from: RC45 on October 17, 2016, 06:19:19 PM
If we are actually trying to overcome/counter forces presented to the rider by the bike, then we should at least have them brought to the table by the bike and not simulated by our own controlled responses to the dynamics of the situation - and as far as I understand GP Bikes is able to represent the forces presented by the bike in this equation very well.
Exactly. GPB's FFB signal is exactly the torque applied by the bike (actually, the bike and environment) to the handlebars. Said otherwise it's the torque you would feel if your hands were really on the bars. Now if you had a device capable of sensing a torque applied by you, then you could input that to GPB using Direct Steer Torque. The problem with that is that the bars of the input device will either not rotate at all (as in your propose setup) or have an angle not aligned to GPB's in-game bars. Bad.
The alternative is to use Direct Steer Angle: with that the alignment of real/virtual bars is granted and you still have FFB on your bars. That's why I'm saying that, in principle, it's the best solution. In practice though, it's not granted.

Notice that in your setup (fixed bars with a torque sensor), you're not presented with the torque generated by the bike: if we forget the tiny torsion of the solid bars, you're presented with a torque that at any instant in time is equal to the one you apply (and opposite in sign), as your bars do not move. If in game the front starts shaking like in a tank slapper, you will not feel it with your proposed setup. With DSA or DST on a FFB device you would.

Quote from: RC45 on October 17, 2016, 06:19:19 PM
I also understand passions run high and any 'new comer' on the scene will rile up the locals that have rehashed these subjects ad infinitum :)  Just throwing my idea in the ring :)
Don't worry, infinity + 1 is still infinity :) And any reasoning on this is welcome, especially if it comes from somebody with some understanding of this stuff.

RC45

October 17, 2016, 08:47:45 PM #36 Last Edit: October 17, 2016, 08:53:06 PM by RC45
 "varying amount of steady state pressure" is the easiest way I have of describing how I ride when explaining counter steering concepts to newbie riders I have met over the years who don't realize what they are doing when riding. What we are doing is not violently yanking the bars or see-sawing - we apply varying steady state-like forces to the bars.

Who said my ideal design would have fixed bars?

I would envision the "rigid" state of the bars to be provided by the countering force of an electric motor setup. At rest that force is zero and the bars are free to turn. As you speed up, the gyroscopic stability of the rotating wheel is simulated by the stiffening force applied to the steering stem as fed back from the game (which is the source of the force notification in our scenario).

The current state of the bars would be driven by feedback from GP Bikes - this is what I was unsure about, whether GPB was setup for this very scenario.

In essence, if the game can setup the bars state and attitude and the player can then respond as they would in real life we might just have the perfect match.

Granted this prototype controller would need $1000+ worth of load cells, USB interface boards and FFB motors on top of the actual construction - quite the commitment :)


HornetMaX

Quote from: RC45 on October 17, 2016, 08:47:45 PM
Who said my ideal design would have fixed bars?

I would envision the "rigid" state of the bars to be provided by the countering force of an electric motor setup. At rest that force is zero and the bars are free to turn. As you speed up, the gyroscopic stability of the rotating wheel is simulated by the stiffening force applied to the steering stem as fed back from the game (which is the source of the force notification in our scenario).

The current state of the bars would be driven by feedback from GP Bikes - this is what I was unsure about, whether GPB was setup for this very scenario.

In essence, if the game can setup the bars state and attitude and the player can then respond as they would in real life we might just have the perfect match.

Granted this prototype controller would need $1000+ worth of load cells, USB interface boards and FFB motors on top of the actual construction - quite the commitment :)

OK let's rephrase the above to see if I get you right: you would like GPB to dictate the bar angle of the input device. The input device will sense the (net) torque applied by you on it and send it to GPB. Right ?

If yes, that has already been discussed here a long ago (guess by who :) ). It would be interesting to try, but it has a few drawbacks:

  • Your device would need to be an input and output device at the same time (input because it reads your torque and sends it to GPB, output because it reads GPB bar angle and realises it on the device's bars). That' snot a big deal as a normal FFB wheel is already an input and output device. But FFB is somehow standardised, while in your setup you'd need dedicated software/driver (actually and output plugin in GPB could do the job for the angle, DST will do the torque part).
  • The device will need to have a feedback loop to drive the motor to realise the bars angle (no matter the torque you apply). Not rocket science, but requires some tuning.
  • Sensing the torque with a strain gauge (not really a load cell) is a bit messy as the torque seen by the gauge would be the overall effect of the torque provided by you and the one provided by the device (in order to realise the bars angle).
  • In principle it may be possible to even avoid the strain gauge (and deduce the torque applied by you with an estimator, knowing the dynamic model of the motor and control loop), but that's not exactly trivial.

DSA is much simpler: you dictate an angle and send it to GPB, while GPB computes two things: the torque necessary to implement the bars angle (in-game) and the torque applied by the environment on the bike (to be sent to the device as a normal FFB signal).

This is much simpler because first, your device is a "simple wheel with FFB" (no need of exotic devices/drivers). Second, the GPB part that converts your target bars angle into a torque command "to be sent to the virtual bars" is something that GPB already has in the form of the virtual rider (even if in the usual setup it converts from target lean angle to bar torque and not from target bar angle to bar torque). Even if that virtual rider would need some tuning, it would be much easier to tune it than to tune a dedicated hardware feedback loop. And less risky too :)

h106frp

I did make a start on exactly this type of control loop - one day it may even be finished if i find the time among other projects ::)

https://www.youtube.com/v/YfeA1X4z21s

I did get the steering stem instrumented as a working and very sensitive torque transducer and the roll and steer are driven directly by GPB's telemetry.
... actually not a lot needs doing to finish it

The saga;
http://forum.piboso.com/index.php?topic=1997.0


HornetMaX

Interesting !

Will it be possible to use it (also) the "other way around" ? (i.e.  GPB in DSA mode, GPB's FFB driving the steering motor with it's FFB signal, the steering angle being passed to GPB)

That should allow some interesting comparison.

Strain gauge on the steering stem ?



h106frp

GPB drives the roll servo and the steer angle servo.

The stem is indeed strain gauged as a classic torque transducer :)

So this allows true torque steer with DSA feedback, i think when we discussed this previously we decided this would be the most faithful reproduction of the steering process

HornetMaX

October 18, 2016, 08:53:49 AM #41 Last Edit: October 18, 2016, 10:36:23 AM by HornetMaX
Quote from: h106frp on October 18, 2016, 07:24:12 AM
GPB drives the roll servo and the steer angle servo.

The stem is indeed strain gauged as a classic torque transducer :)

So this allows true torque steer with DSA feedback, i think when we discussed this previously we decided this would be the most faithful reproduction of the steering process
Ouch, I'm confused again now. Lean is clear (GPB outputs the lean, your roll servo realizes it). For the rest:

Option 1: GPB using DST,  your torque sensor sending its output to GPB "steering" input and GPB's FFB signal sent to your steering servo.

Option 2: GPB using DST, your torque sensor sending its output to GPB "steering" input and GPB sending its steering bars angle to your roll steering servo (GPB's FFB signal not used !). [EDIT : typo]

Option 3: GPB using DSA, your steering angle sensor sending its output to GPB "steering" input and GPB's FFB signal sent to your steering servo (your torque sensor not used !).

Which one/ones are you going for ?



h106frp

Option 2 but the steering bars angle goes to the steer servo.

Roll is just a product of the GPB physics engine output so is just driven from the telemetry signal to the correct lean angle.

I am not sure how i would use GPBs FFB signal and i am not even sure what parameters are used to compute the DirectX controller style FF signal.

HornetMaX

Quote from: h106frp on October 18, 2016, 09:08:45 AM
Option 2 but the steering bars angle goes to the steer servo.
OK (I fixed the typo in my post above, of course it was the steering servo, not the roll one :) ).

Quote from: h106frp on October 18, 2016, 09:08:45 AM
I am not sure how i would use GPBs FFB signal and i am not even sure what parameters are used to compute the DirectX controller style FF signal.
The FFB signal is just the value of the torque to be applied to the bars, it's computed by GPB. It should drive your steering servo: 0% = generate no torque, +/-100% = generate max torque left/right (max torque = the max torque your device can /is allowed to generate).

Easiest way to pick it up for you is probably to use an output plugin just like you do for roll: in the telemetry data you have m_fSteerTorque (Nm).

GPB likely sends the FFB signal to the device via DirectX: you could do that too, but it's probably more complicate (as a bonus, in GPB you have a slider to set FFB strength, but that's not a big deal, your output plugin could have this "gain" as parameter or a slider in its UI).

Vini

you have to finish building that controller some time, h!!!
an accurately simulated steering axis would be incredible.