• Welcome to PiBoSo Official Forum. Please login or sign up.
 
March 28, 2024, 04:09:40 PM

News:

GP Bikes beta21c available! :)


Direct steer

Started by PiBoSo, April 28, 2013, 08:53:11 PM

Previous topic - Next topic

HornetMaX

Quote from: passerBy on April 21, 2017, 09:33:13 AM
I shift my weight to a side (using the rider L/R lean), the bars drop to that side. Also, on a slope the bars tend to turn into the direction of the slope.
That's normal: bike leaning, the front tends to fall inside, so GPB will send to the wheel a torque to make your bars turn accordingly. If you don't compensate that exactly with your hands, your bars will turn. I see no issue here.

Quote from: passerBy on April 21, 2017, 09:33:13 AM
You really need to give the DS2 + FFB a try, Max. I know you won't believe me that it is this good, but at least give it a try when you can (remember to keep the steering ratio 1:1, though).
I never said it's not good. I actually proposed it to PiBoSo as an alternative to DST. I've always told to others that DSA/DS2 is on paper a better approach with the input devices we have (joypad and FFB wheels).

Quote from: passerBy on April 21, 2017, 09:33:13 AM
QuoteOn paper there may be a "dual" strategy but it would need an input device that today does not exist: GPB sends the bars angle to the wheel and the wheel tries to align to that angle (fighting your input, using a control loop like the PID in DSA). At the same time the wheel reads the torque you apply to it (only that torque, net of the torque it generates by itself) and sends it to GPB (that's hence DST/DS1). But again, there's zero warranty that would be any better than DSA/DS2 and we have no such device available.
I'm pretty sure that's exactly how the directeer=2 mode works. Except, it takes the resulting angle and derives the torque you apply from it.
What DS2 does (as explained by PiBoSo) is very different from what I describe above.

passerBy

Now I remember what my idea looked like back at the time.
Make the controller wheel behave like the wheels-fork-handlebars assembly scaled down to the abilities of the FFB. Based on the current wheel angle (and probably its turning rate), compute the summary torque acting on the fork from "that side", divide it by the torque value considered maximal (while still retaining enough dynamic range) and let the user handle the "fork" as the user sees fit. That will most likely lead to the angle change. Rinse and repeat.

In other words, a physical real life object would be turned into the solver itself, i. e., no post-processing virtual to real angle matching through torque (aren't the FFB spikes related to the matching effort?).

What's wrong with my proposition then?

HornetMaX

Some tracking will always be needed, no matter what.
You have 2 options: the controller can send GPB a torque (DST/DS1) or an angle (DSA/DS2).

If the controller sends an angle, then GPB needs a control loop (the PID PiBoSo mentioned) to align the virtual handlebars to the angle sent by the controller. Also, it will send back to the controller the FFB signal (torque acting on the virtual handlebars minus the rider-generated torque). This is what you are doing with your wheel and DS2/DSA. Nice and simple.

If the controller sends a torque, GPB will apply that torque to the virtual handlebars (that's DS1/DST) and send back the FFB signal just like before (torque acting on the virtual handlebars minus the rider-generated torque). The problem is that the angular position of your wheel will diverge from the angular position of the virtual bars, unless you put in a control loop somewhere. Here you basically have two options: either this control loop is done in GPB (but that would require GPB also receiving then wheel angular position and being aware of the wheel physical params like the inertia, to tune the control loop), either you put that control loop in the controller itself. In that case GPB sends back to the controller the angle of the virtual bars and the controller will try to track it. In any case, it's very messy.

There's no possible solution without any tracking, unless you're ready to accept that your wheel angle will not match the virtual bars angle (which, of course, is not good at all).

passerBy

I would still try my 3rd option if I could.
Again, simply take the current controller's angle as the angle of the virtual fork that will be used to compute the forces acting on the front wheel, that will be converted into the resulting torque on the fork. This torque will be divided by the value taken for a maximum possible torque (everything above that will be clipped-out) and sent to the controller. After that the user has to deal with the resulting controller torque, with the controller ending up at some new (or the old) angle. This angle is not used as a guide to turn the virtual handlebars to, but is simply taken as the new virtual bars position.

Yes, it's possible to get ridiculous with the bars like this due to the controller usually not providing adequate FFB. The user needs to keep that in mind and don't do anything stupid like turning the controller to full lock at speed. However, the better the controller at least in terms of the sheer FFB torque is, the more natural result should be.

HornetMaX

Quote from: passerBy on April 22, 2017, 10:26:29 AM
I would still try my 3rd option if I could.
Again, simply take the current controller's angle as the angle of the virtual fork that will be used to compute the forces acting on the front wheel
Can't do. The physical model does not take an angle as input. The angle is a state variable, not an input.

passerBy

Quote from: HornetMaX on April 22, 2017, 04:39:10 PM
Quote from: passerBy on April 22, 2017, 10:26:29 AM
I would still try my 3rd option if I could.
Again, simply take the current controller's angle as the angle of the virtual fork that will be used to compute the forces acting on the front wheel
Can't do. The physical model does not take an angle as input. The angle is a state variable, not an input.
Rather "can't do using the current approach and algorithms".

HornetMaX

Quote from: passerBy on April 23, 2017, 09:00:18 AM
Quote from: HornetMaX on April 22, 2017, 04:39:10 PM
Quote from: passerBy on April 22, 2017, 10:26:29 AM
I would still try my 3rd option if I could.
Again, simply take the current controller's angle as the angle of the virtual fork that will be used to compute the forces acting on the front wheel
Can't do. The physical model does not take an angle as input. The angle is a state variable, not an input.
Rather "can't do using the current approach and algorithms".
No, sorry.

Quote from: passerBy on April 22, 2017, 10:26:29 AM
Again, simply take the current controller's angle as the angle of the virtual fork that will be used to compute the forces acting on the front wheel, that will be converted into the resulting torque on the fork.
Up to here, it's more or less DSA/DS2: the PID computes the "the forces acting on the front wheel", but only the rider-generated part of these forces, in fact.
The rest, the torque applied to the front by the environment (bike dynamics, road , gravity etc) is computed by the overall physics.

Quote from: passerBy on April 22, 2017, 10:26:29 AM
This torque will be divided by the value taken for a maximum possible torque (everything above that will be clipped-out) and sent to the controller.
Hmmm ... let's say you apply 1N right, the environment 1N left. What do you have as FFB torque ? GPB returns 1N left (environment torque). I'm under the impression you expect 2N left.

Quote from: passerBy on April 22, 2017, 10:26:29 AM
After that the user has to deal with the resulting controller torque, with the controller ending up at some new (or the old) angle. This angle is not used as a guide to turn the virtual handlebars to, but is simply taken as the new virtual bars position.
And that's what you can't do.

The equation is Torque = Inertia * acceleration = : you can't set the velocity to whichever input you receive.

That's why DSA/DS2 does what it does: get an angle as input, compute the torque via the PID loop so that this input angle is tracked, followed reasonably close. This is doable because the input angle is NOT the real angle (just like in the normal steering mode, the lean input is not the real bike lean, but the target that the virtual rider tries to track).

passerBy

Quote from: HornetMaX on April 23, 2017, 09:26:57 AM
Quote from: passerBy on April 22, 2017, 10:26:29 AM
Again, simply take the current controller's angle as the angle of the virtual fork that will be used to compute the forces acting on the front wheel, that will be converted into the resulting torque on the fork.
Up to here, it's more or less DSA/DS2: the PID computes the "the forces acting on the front wheel", but only the rider-generated part of these forces, in fact.
The rest, the torque applied to the front by the environment (bike dynamics, road , gravity etc) is computed by the overall physics.
Well, I understood that. It's just that I'm not happy with the spikes in the FFB, and I have reasons to suspect they might have something to do with the PID. Wanting to eliminate it from the loop is the reason behind my proposal.

Quote
Quote from: passerBy on April 22, 2017, 10:26:29 AM
This torque will be divided by the value taken for a maximum possible torque (everything above that will be clipped-out) and sent to the controller.
Hmmm ... let's say you apply 1N right, the environment 1N left. What do you have as FFB torque ? GPB returns 1N left (environment torque). I'm under the impression you expect 2N left.
If we are talking about my system, it would look different to that. GPB would compute an FFB effort of 1 N*m CCW and send it to the controller. If I wanted the bars/wheel to stay at the same angle, I would have to counter the FFB with 1 N*m CW.

Quote
Quote from: passerBy on April 22, 2017, 10:26:29 AM
After that the user has to deal with the resulting controller torque, with the controller ending up at some new (or the old) angle. This angle is not used as a guide to turn the virtual handlebars to, but is simply taken as the new virtual bars position.
And that's what you can't do.

The equation is Torque = Inertia * acceleration = : you can't set the velocity to whichever input you receive.
You could store the current angle value and the delta between this angle and the one from the previous step. That way you'd have the angular position, the rotational velocity and the rotational acceleration information.

QuoteThat's why DSA/DS2 does what it does: get an angle as input, compute the torque via the PID loop so that this input angle is tracked, followed reasonably close. This is doable because the input angle is NOT the real angle (just like in the normal steering mode, the lean input is not the real bike lean, but the target that the virtual rider tries to track).
That is not something I don't know already.

HornetMaX

Quote from: passerBy on April 23, 2017, 03:00:08 PM
Well, I understood that. It's just that I'm not happy with the spikes in the FFB, and I have reasons to suspect they might have something to do with the PID. Wanting to eliminate it from the loop is the reason behind my proposal.
The torque you feel in the FFB does not come from the PID.
That said, when I look at the telemetry data, the values of the steering torque (with usual steering) looks high and very noisy.

Quote from: passerBy on April 23, 2017, 03:00:08 PM
Quote
And that's what you can't do.

The equation is Torque = Inertia * acceleration = : you can't set the velocity to whichever input you receive.
You could store the current angle value and the delta between this angle and the one from the previous step. That way you'd have the angular position, the rotational velocity and the rotational acceleration information.
And what would you do with these (even overlooking the fact they would be very noisy) ?!
Try to write down the equations, you'll see what you're asking to do can't be done.

Lee-h

Dose direct steer work with gp bikes beta 13 because I just tried it and the bike just keeps falling over like it has no balance

poumpouny

The virtual rider doesn't work in Direct Steer mode, you have to do the balance yourself, like in real life. That's exactly the point with Direct Steer !

Lee-h

January 26, 2018, 09:24:19 PM #56 Last Edit: January 27, 2018, 04:23:53 PM by Lee-h
Thanks for the info, after some practice I can know say this is the best GP Bike Game ever I love this mode using my old Thrustmaster Freestyler Bike controller nice one PiBoSo Great Job  :)

Chris_Beeves

Quote from: PiBoSo on April 28, 2013, 08:53:51 PMLike in "directsteer=1" mode, it is possible to set the proportional and derivative controller parameters adding a file named "directsteer.cfg" in the bike folder.
The only difference is that the "torque" section is ignored.

What does this mean in-game?
P: A higher number means more sensitive to the difference between in and out value? A lower number smoother and "slower"?

D: Anticipation of what is to come, but how would that effect the actual steering?

These settings will be helpful when trying to tune in the "feel" of a bike (big&heavy or light&fast) or help making directsteer easier to use?
I had to try..

Chris_Beeves

Tested directsteer.cfg but I don't understand what it does.

Can't really tell the difference. What range are the values in? -255 to 0?

@Piboso, could you include some sort of specification in the first post?
I had to try..

Chad Smith

I'm trying to get direct steer to work with a wheel
I have entered the direct steer code
[hardcore]
directsteer=2
directsteer_maxangle=20

It works when in pit stall except I can not turn out of pits.
I have tried leaning while steering and nothing.

I also am not able to find a directsteer.cfg in the bike folder.

I am running the demo does that anything to do with it?