Author Topic: Direct steer  (Read 14893 times)

HornetMaX

  • Hero Member
  • *****
  • Posts: 5590
    • View Profile
Re: Direct steer
« Reply #45 on: April 21, 2017, 10:44:45 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.

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
On 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

  • Full Member
  • ***
  • Posts: 164
    • View Profile
Re: Direct steer
« Reply #46 on: April 21, 2017, 02:47:37 PM »
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

  • Hero Member
  • *****
  • Posts: 5590
    • View Profile
Re: Direct steer
« Reply #47 on: April 21, 2017, 08:36:10 PM »
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

  • Full Member
  • ***
  • Posts: 164
    • View Profile
Re: Direct steer
« Reply #48 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, 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

  • Hero Member
  • *****
  • Posts: 5590
    • View Profile
Re: Direct steer
« Reply #49 on: April 22, 2017, 04:39:10 PM »
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

  • Full Member
  • ***
  • Posts: 164
    • View Profile
Re: Direct steer
« Reply #50 on: April 23, 2017, 09:00:18 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

  • Hero Member
  • *****
  • Posts: 5590
    • View Profile
Re: Direct steer
« Reply #51 on: April 23, 2017, 09:26:57 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.

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.

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.

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

  • Full Member
  • ***
  • Posts: 164
    • View Profile
Re: Direct steer
« Reply #52 on: April 23, 2017, 03:00:08 PM »
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
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
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.

Quote
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).
That is not something I don't know already.

HornetMaX

  • Hero Member
  • *****
  • Posts: 5590
    • View Profile
Re: Direct steer
« Reply #53 on: April 23, 2017, 03:14:05 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
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.