Direct steer

[Furious]

I agree that in real life you steer with torque. You use the (force x radius of the steering wheel=) torque to put the wheel in THE ANGLE YOU WANT. And it's the same thing everywhere. We can also say that "direct angle " mode is really also the "give me the torque" mode. Why? Cause if the FF works fine ( calculates the forces on the handlebars depending on the bike dynamics, tires friction ect) and you still want to turn that wheel by using force, you can calculate the force you are working with with the following variables:
- Force produced by FF
- derative by time of angle value.

Sure, except that doing time derivatives of noisy signals is messy: if there's too much noise or the signals changes too fast, you end up with extremely large torque signals or, in order to filter them, with delays in the loop. Could be bad.

And I still claim that in proper simulator you need the "turnable" handlebars as they turn in RL

Oh I think you've misunderstood my post (my fault maybe, maybe it wasn't that clear).

You are right. I Misunderstood and I agree now. I think the subject is cleared and I'm happy w both understant eachothers perspective. We shouldn't go "off topic" no more in this thread. Maybe some moderator can split it or something.

[doubledragoncc]

Hi guys.

@Max

Quote :- In what I was saying, the bars would be turnable, of course (no sense otherwise). The difference would be that the bars output is a torque (and not an angle).
The torque is directly read by a torque sensor, instead of being computed from an angular measurement in an indirect manner.

The bar position will be "set by the game" (more precisely, the control device will have a control loop that will track the target bar position computed by the sim). Of course, applying a torque on the bars will alter the bar angle, as the applied torque is simply added to the "environment" torque by the sim in order to compute the evolution of the (target) bar position.

In a conventional system, the control device sends an angle to the sim and the sim sends a force (feedback) to the control device.
In what I was saying it's the opposite: the control device sends the torque to the sim and the sim sends an angle to the control device (angle that will be implemented by the device, i.e. the bars will turn in this case too). This mimics more naturally the physical model of the bike.

Most likely, generating a torque and reading an angle (usual systems) is cheaper than generating an angle and reading a torque. But the end result may not be the same.
In principle, they are equivalent, in practice it may be a different story.

To a certain degree it is the same difference you can have on these two pedal (or lever) brake systems:

    The usual system: you have a spring of known stiffness and a position sensor (usually a potentiometer): from the position sensor and the stiffness you can compute the force applied.
    The better system: a load cell, where there's no actual movement (past a certain point) and a torque is directly read.

Unquote


I thought I would add a bit of actual testing with load-cells and other ways to implement real life physics into a control system. I have been testing for a long time and the truth is that the way you think about it is almost impossible to simulate correctly. The biggest problem is that when using a load-cell for torque output to the sim, it is FAR to sensitive when just sitting  in a room. I will try and explain it as best I can, but it is something you need to FEEL to really understand. With a load-cell you have practically only a few millimeters of movement at most, now imagine if the thumbstick on a gamepad which most use for steering, could only move 1 to 2mm each left or right, it would be impossible to control the steering of the bike. Not only this but with load-cells would need to have one for the left and one for the right inputs, this would take 2 axis on a controller to input to the sim. A load-cell has to go through a load-cell accelerometer to be able to communicate to the computer as a load-cell has 4 connections but every control board for analog input works on a 3 connector system and also has to have the measurements from the load-cell interpreted to a voltage output for the control board to send the signal to the computer, then to the sim the right way.

I hope this clears the point of how difficult it is to simulate just one input needed for Direct Steer, as it all leads back to the difference of sitting in a room and riding a real bike. I am working on new designs and have just contacted Leo Bodnar about making a bike system together. He is very interested and if there is anyone who can find an electronic answer to this problem it will be Leo.

I think this is the only true way to have the control of the bike, but wonder if it is leading away from reality as to the fact that too many are expecting a sim to be able to be 100% like in real life when in reality you can NOT simulate the forces of nature sitting in a room as apposed to being on a real bike. There has to be a point of limitation and many forget that a sim should be for everyone not just the experts at it.

This is a great thread and very helpful to understanding how you are all dealing with direct steer. The more posted here the more it will be able to help each user of it.

Keep it sunny side up guys

DD   

[HornetMaX]

The biggest problem is that when using a load-cell for torque output to the sim, it is FAR to sensitive when just sitting  in a room. I will try and explain it as best I can, but it is something you need to FEEL to really understand. With a load-cell you have practically only a few millimeters of movement at most, now imagine if the thumbstick on a gamepad which most use for steering, could only move 1 to 2mm each left or right, it would be impossible to control the steering of the bike.

Hi DD,

I mentioned load cells only as an analogy, for a steering input they may not be the right solution (what one would really need is a torque sensor).

Notice however that theoretically in my configuration the load cell is mounted on the part that realizes the angle, so the whole thing would move even if the load cell has zero movement intrinsically.

MaX.

[doubledragoncc]

Thanks for that Max.

OK, so now we have 1 axis input for left torque, 1 axis for right input torque, 1 for lean angle left and right and still no rider lean!!! Thats 3 physical inputs for 2 actions and no software to support it not even GPB I think?, as his coding for the torque is for only one input axis if L am correct, or not?

With this said you also have to consider the actual movement you are making with the bars and having to separate the 2 actions, your talking a lot of work and money for this to happen and be reliable, precise, and realistic as possible. I have been working on a design that actually has this, but it is something that would have to be very very robust, pretty heavy and expensive. I reality, in order to have a controller work realistically, the sim would have to be written so that it has an axis input for left and an input axis for right when it come to a measurement for torque or any kind of pressure input as they can only be measured individually. The only possible way l have been playing with is pure accelerometers and gyros, but not found one yet that is quick enough for the right signal for steering response.  I am hoping that Leo Bodnar will be able to help with this. I am working on new designs with Direct Steer as a main point and am putting a proposal together to send Leo next week.

All your thoughts are of great help Max, you give so much to this community, thanx buddy

DD

[doubledragoncc]

OH l just had a brainfart..........

What if l used 2 load-cells and wired them some way that one gave a possitive reading and the other a negative to on axis, and while both were not being applied pressure the axis would be centered, then depending on which load-cell received pressure, the axis would think of a left or right input?

I am not an electronics guy to that degree, but as far as l know load-cells work only one way, BUT maybe l can think along this line more, what you think MAX?

DD

[HornetMaX]

For sure a single load cell is "one direction only".
Combining two is theoretically possible (not sure it's easy in practice).
But again, I don't think that load cells on a steering axis are the way to go.

To be honest, doing what I described may turn out to be very complex, which would explain why it hasn't been done yet.

MaX.

[doubledragoncc]

Too true buddy.
 
The one thing that l still dont know though is the fact that, is direct steer more realistic than normal steering only because of the physics behind it in real life, or is normal steering still realistic, but not requiring so many inputs. Put another way. Does this mean normal steering in GPB is wrong so far as the physics go, ei: not realistic from input to how the bike reacts? meaning that normal steering is just an arcade input as apposed to a sim?

To put it plainly. Is it necessary to have a complicated controller or one that gives the same end effect, the right input and feels good, but everyone can afford?

[HornetMaX]

Personally, I think it's hard to say if direct steer or normal steer is more realistic.
Theoretically, with direct steer you have the same input (handlebar torque) as on a real bike.
But in practice normal steer seems to be closer (in terms of ease of use, at least) of what you experience on a real bike.

MaX.

[h106frp]

An old thread, reading due to some servo stuff i am tinkering with(force feedback tinkering) and noticed a misunderstanding in the thread. Do this all the time at work so...

To measure torque the sensor required is a strain gauge bridge attached to the steering tube, the elements are at 45 degrees (to the long axis of the tube) to sense torsional stresses only (the twisting)  in the tube. The output is resolved using a whetstone bridge formed by the strain gauges, 2 wires supply the constant voltage supply, 2 are the output. The sensor gives + and - magnitudes for clockwise and anticlockwise torsional loads so only 1 'sensor' is required. The output is small and requires an amplifier to raise the signal to something suitable for a microprocessor, you can get a higher output using semi-conductor gauges rather than the more usual foil type gauges. All very standard engineering and could easily be applied to extract the torque in the steering tube.

Restraining the force feedback force will create an output from the sensor which will be your total steer input.

Yes, i do have a 'nerdy' day job 

[HornetMaX]

Indeed. But in GPB the torque input (using DST) is not the total steer input, it's just the rider-generated torque, so you should "subtract" the force feedback from the output of your sensor and feed that into GPB. That may prove to be a bit tricky to do properly.

In your experience, how would such sensor perform in terms of resolution, response time, noise etc ?
Would it be OK for our purpose ?

MaX.

[h106frp]

The sensor has incredible resolution and is only limited by the noise level in the complete system, probably the AD converter of the microcontroller, band width at the sensor is theoretically infinite using DC excited bridge, the limit will be the microcontroller sampling rate, it will be well beyond the response of the servo system anyway as this will be the response time limit due to the motor inertia.

Using shielded cables and shielding the sensor grids the noise level can probably be ignored for this application, the trick is to raise the torque locally by reducing the shaft cross section where the sensor is mounted and use a reasonable exciting voltage say 10 or 12 volts, the voltage is limited by the gauges ability to sink the heat into the substrate, using an aluminum tube and a gauge with a decent grid area lets you sink quite a bit of power without the gauge heating and possibly drifting - we are in the world of instrumentation quality measurements at this point and probably far more accurate than we require for a controller.

As an aside, side sticks for combat aircraft use strain gauge technology as a more reliable method of measuring input forces rather than just displacements.

Last time i looked you could get foil type gauges from RS, low noise, low offset, high input impedance op-amps are cheap and easily available these days, so its doable for home engineering.

The sensor could be used to generate the servo demand vs torque base calibration as well to give you your base values to offset rider input.

Google 'strain gauge shaft torque measurement' to get an idea of the arrangement, its not as complex as it sounds and has been used for years.

The big advantage of this approach is you get a true torque measurement, trying to use load cells you will have to resolve the turning moments and you get errors from bending forces etc.

edit:You can get strain gauge bits on the but, but noticed these..
http://www.hella.com/microsite-electronics/512.html
They use the 'skin effect' to sense the stresses in the steering tube and output angle and torque for electric steering systems, looks like you could pull one from a scrasp car to try, seems vauxhalls and fiats use them in the power steering system so i guess many others as well, some on the bay for merivas have the complete mini colum so would probably be a good starting point.

[HornetMaX]

Very interesting. I guess the real reason why none of this has already reached the game market is that there's no software accepting torque as an input. Except GPB, of course

Also, probably car sims do not really need that, the feeling is good enough with classical input devices with FFB. But no one realy knows that for sure, until somebody tries this out.

MaX.

[h106frp]

Thinking a bit more, the strain gauge will measure rider input only as its the reaction to the FF trying to obtain bar angular position, if you release the bars - no torque generated in the steer tube. As long as the end stops are on the input gear and not the bar end it would always work as the motor would not produce any torque in the steer tube above that generated by the inertia of the bars/top yoke.

Might be the way to go, shall have a look on the junk shelves at work after Christmas and see what fruit the can bear

Need to get a bar system working first though, just snagged prilla RS125 bars on ebay, they have the top yoke and bars as one unit so easier to work with and just got a servo working properly from a scooter motor, gearing system is the next hurdle. Just going to try and get the steer axis working first as this seems the most important for proper feel.

Happy Christmas to all.. time for turkey and sprouts

[HornetMaX]

Thinking a bit more, the strain gauge will measure rider input only as its the reaction to the FF trying to obtain bar angular position, if you release the bars - no torque generated in the steer tube

Hmm .. that would be the case if the the angular position dictated by GPB was perfectly implemented by the device (i.e. infinite torque, infinite bandwidth, or let's just settle for "big enough"). Or, in a practically useless case, if the handlebars were fixed, not movable.

Imagine this: the motor applies zero torque, the rider 1Nm. As the bars are rotating freely (or almost), the strain gauge will measure nothing at all. So they don't measure directly the rider torque, but something that depends on both, rider torque and motor torque.

I'm under the impression you will have to go down a more complex way (something like what described in what you posted a while ago: http://forum.piboso.com/index.php?topic=1781.msg25111#msg25111).

Essentially, you know the torque applied by the motor, you know what the strain gauge sensor sees: you now have to compute the rider-applied torque. Even if the strain sensor is "near-perfect", you have to keep the motor dynamics into account.

MaX.

[h106frp]

But if the force feedback is 0 torque the rider cannot input a torque either, just displace the bars, only a reaction between both creates a resultant torque