• Welcome to PiBoSo Official Forum. Please login or sign up.
May 18, 2021, 12:32:53 AM


World Racing Series beta14 available! :)

Project Realistic Rig

Started by speedfr, December 08, 2017, 02:10:31 PM

Previous topic - Next topic


Quote from: h106frp on April 15, 2018, 03:02:04 PM
You need a dll to link into GPB (dlo) and place the data in memory (the easy bit surprisingly, you can do it with codeblocks C) then some sort of host PC application to send this data to the arduino at a decent rate.

The host application also lets you scale the values, range check and limit (a must if you do not want the bars going berserk) and the ability to drive other stuff like a dash. I used microchip PIC and USB.

Hello there !

Coming back on h106frp words, i found that...

That will be a perfect device to FFB the both axis, X for steering as an example and Y for leaning.
That takes us back to my first post design. And if i understand well enough, that could be the good friend for DSA or DST (but mostly angle measuring than torque, because i'm thinking of potentiometers and not torque system) and then go closer to reality.

But there's a question... : Is GPB able to separate the axis in the FFB response ?
Does somebody has a answer for that ?
Will it be possible to"filter" FFB to avoid the wooble and shaking all the ways at it does with full FFB on ? i'm not running with FFB, just the fact that the axis is cinstantly trying to go back to center (which is not like a bike at all but...).
Each time i tried to work on FFB behavior, the soft i found are not working (Forcetest, simFFB) and if i put the FFB on in the "Settings" panel, when you gear up, it shakes, when you have woobles, it shakes and it's too much affecting the behavior of the handelbar. If i reduced enough not to feel it, i don't feel the handlebar "grinding" anymore... like a dog who try to byte his own tail...

So if anybody tried this kind of system or knows better about what GBP can/can't do, i'll be more than happy to continue my Graal quest !  ;D
Missing Gp500 (Microprose)  Testing EDTracker Pro on YT   R7-3800X/16Go/GTX1080/1440p/Full WC


The output will supply a lean angle and a steer angle that are the product of your steer input.

you just send the lean angle to your rig roll axis - nothing more to do there

the steer output will go to your steer servo and by adjusting the servo controller steer torque to something comfortable you get your force feedback. As you push or pull on the bars it creates an error in the servo centering so the output from the potentiometer supplies both the game controller input and feedback measurement for the servo controller which will be trying to set the bars to the angle set by GPB to close the loop (so a resultant force to oppose) - it all works surprisingly well. I would recommend you take a look at hall devices for the feedback pots as you need these to be noise free with good resolution, I described some cheap home made ones in my controller post.

You will need physical limit stops and limit switches to operate safely! The forces and response speed of decent servo drives are considerable - not sure if you have seen my test video of a rig in motion?

From experience you may find you need an electronic servo brake/snubber that will prevent back emf from the servo motor tripping the over voltage on the switch mode supply output and it also improves the servo dynamics, its basically a big capacitor and a comparator circuit driving a MOSFET switch to a load resistor.


May 16, 2018, 10:12:59 PM #107 Last Edit: May 16, 2018, 10:21:14 PM by speedfr
@h106frp : Many thanks for the reply and yes, i've been through the entire post before i started my rig with Allan MTE parts and design instead of what i had in mind at first. And after i draw the first principle, i went to go through your entire topic, and realized you were doing it, but language barrier, complex concept in specialized or slang texts put me out fast so each time, i'm sneaking what i can understand, but i'm too far away to be sure of the question i have to ask... But if i could, i would  ;D

Your answer might be super clear but ...

Hall devices instead of potentiometers ? is that it ?
And what i don't understand is if you steer at first, let's say out of your pit box, then around 50ish km/h, the torque on the vertical axis (Y) will increase and block this axis so if you counter-steer on the handlebar, the horizontal axis (X) will get more free; the X servo will be "ordered" to let go more. How can it be read by the arduino, send to the Pc, and interpret by GPB, then goes back to the both servo motor, constantly to give you the bike sensation...
I mean, once you connect a servo motor to each axis and design the "monster", you have to use a card to drive the shield or mosfet for the motor (DC ? pwm ? step-by-step ? <- these are powerfull) and to be connected to the USB port. Then you go in the settings, after putting DSA active in the .ini file i guess.
But can you assign X and Y to the leaning and steering axis ? And the reading and sending instructions to the card to drive the servomotor is already there in GPB ? What are we suppose to do to connect the "monster" to the game and it runs like a charm ?

You see, i'm full of question and a little bit stubborn when i'm looking for something. Anyway thank you for all the times you spend answering me. I'm gonna go through your video and topic again, try to catch more of it.

Edit : Why limit switch ? physical limit as on a real bike but why a electric signal ? For what device ? to cut the DC motor ? i don't get it... sorry.
What is it that you call "emf" ? And actually i don't get a word of the entire sentence... i can see you talk about over voltage and improving the way the servo motor acts... but why a load resistor appear ? like a load cell ? i'm kind of lost in here  :-[
Missing Gp500 (Microprose)  Testing EDTracker Pro on YT   R7-3800X/16Go/GTX1080/1440p/Full WC


May 16, 2018, 11:08:51 PM #108 Last Edit: May 16, 2018, 11:30:54 PM by h106frp
Easy ones first  :)

A hall effect device senses magnetic fields and ouputs a signal representing this. The device in my post will sense the field direction passing through it from a magnet so as the field rotates it will give a very accurate proportional volage.
The problem with potentiometers using a DC supply is they tend to output a very noisy signal, wear quickly with repeated rotations and are prone to mechanical failure in this type of application.
My home made device;
Hall devices instead of potentiometers ? is that it ?  Yes  :)

The mechanical stops are physical limits to how far your rig will rotate to stop you breaking your wrists. If you get any sort of problem with either the output from GPB or your equipment you must prevent excessive rotation of the rig. The limit switches  (microswitches) are pretty much a standard item to interface to the controller and give a 'soft' limit control and should activate before the mechanical limits.

Back EMF occurs when you suddenly reverse or stop the field on the drive motors. As the magnnetic field collapses it generates a large reverse voltage spike (the same way an ignition coil works to drive a high voltage to a spark plug) which will appear across the power supply. Switch mode supplies (like a PC power pack) usually have an over voltage cut out sensor that will activate and cause you power supply to operate eratically. The snubber circuit absorbs the back EMF spike before it can disturb the power supply.

The axis of your drive motors should use GPB output of lean and steer as their target positions. Any influence you add at the bars are then used as the input to the game and the control loop will be closed. This would be the most simple system similar to most commercial controllers and is our basic building block

If you want to build a torque based system you will need to incorporate a seperate torque sensor in the steer column. This would then become the control input to the game so instead of forcing a change in controller deflection you would apply a torque and allow GPB to calculate the new angles for the servo position.

The closed loop nature of control input to calculated bike and steer rotation automatically creates the steer solution. The values from GPB fed to your servos automatically adjust to the external influence created by the rider through speed and steer input. You need to think in ths 'closed loop' way even if it appears contradictory at first it will make sense once you get started.

GPB only outputs the calculated values - you must write your own code to drive the servo controllers. I used a PIC micro and analogue output chips to supply a scaled DC voltage to drive the servo position.

DLO to get the values from GPB and into memory
A visual C program to grab thhe values from memory, scale them and send them by USB to
A PIC micro that outputs suitable control voltages to the servo controllers
Dedicated servo controllers that have limit switch, torque control and PID
24 volt servo motors with worm drive gearboxes
Hall effect feedback/position sensors
Provision for torque sensing in the steer column
Steering damper on the steer axis to limit violent oscillations  :o   

Hve you checked out;

You could try simtools - this should simplify the programming aspects

So it can be made to work and is intended for arduino and H bridge card


I'm still persuaded that a 2 Axis steering / Leaning controlled by you hand IS NOT the solution, as i sayed in the first page, the problem is that you will realise it, only when you finished your project and trying to ride with it. In real life, you input the steer angle with your hand (not the leaning, just the steering) the it result in the leaning angle. Then you make the bike balance with you entire body (starting the bike, changing direction, braking, making wheelie etc .....) you are not leaning with you body (2nd axis with you controller) (yes but a very little input so it is negligeable) you just balance the bike. IMHO, the best far yet solution is a steering axis (with FFB), coupled to a head tracking device. The best demonstration of that is try to ride in DST or DSA with a FFB wheel and an Head tracking device, you really mimic your realife position when starting the bike, balancing the bike with you body movement .


I completely agree.  :)

The roll axis on my rig was only intended as feedback and has significant holding torque applied from the controller (hence the big servo and worm drive), you will not move it as an input.

It was always intended to simulate normal/counter steering type input hence the extra torque sensing strain gauges on the steeering stem.  :)

Many years ago I had a trustmaster bars conntroller which allowed both axis to move but you could only select 1 as input - a horrible system that felt nothing like a motorcycle control


May 17, 2018, 01:34:22 PM #111 Last Edit: May 17, 2018, 02:00:18 PM by speedfr
I still have this old thrusmaster bike controller... its in the attic now taking dust for years, even my sons didn't want that piece of s...  ;D

Thank you h106frp for the long explanation.
I think i understand now the loop concept of input/output through the reading of the GPB value (a little bit as a simmanager system or Motec) but yes, it needs programming both ways, to catch the value and to interpret them correctly...
The good thing is you define yourself the value, the axis and the response. Great idea.
I thought maybe GPB was able to dispatch the output to the servomotor if X and Y was binded in the settings but that was "the regular" FFB and yes, all the shaking are going to come with.
Your system (if i understand well) catch only the steering/leaning info and forget about the rest which is perfect.
But it requires a lot of DIY in domains that i'm away from.
I'll look at that with my electronician friend when i'll be able to, but i think its going to be a long term work.

And Poumpouny, even if i seat on the bike seat and have the same "attitude" when riding GPB, i'm never gonna lean on the side in my office, i'm gonna finish on the floor after a while for sure, so the best is to simulate the feelings in hands not in the entire body, and with this well known feeling i can adapt my driving in the screen.
Otherwise you need a GPlean system with hydraulic actuator and it's not what i can/want/will do in DIY.

Thanks again guys, need to dig more on this way to go for that.  :o

edit :

@h106frp :
you had to install a steering damper as on a real bike to avoid the woobles effect ?
What is it that you call "provision" for torque sensing ? are you saying that you are going to add a torque sensor later on ?
The "good" Arduino to use is the Leonardo which is detected as a native joystick by Windows ?
Missing Gp500 (Microprose)  Testing EDTracker Pro on YT   R7-3800X/16Go/GTX1080/1440p/Full WC


I added the steering damper to take out some of the sudden deflections by adding a bit of resistance to work against the servo. Using powerful servos you can get quite a large shock loading through the steer feedback which is very unpleasant, another option would be to add some averaging or damping in the interface software. The system I built is very powerful, the steer servo (small one) would easily bend a 6mm high tensile screw used in the physical stop system.

I used strain gauges on the steering stem for torque sensing  :)  (I do this sort of stuff for work)

Any controller that has the USB protocol as a software library would be the way to go - its quite fiddly on the windows side when you need to send data to the device.



ok, but usually the devices that comes with Com port and a kind of Prolific driver, it's a mess, last time that happen with the AT2560 from my 3D printer, never been able to control the printer through USB whatever i did or change the driver. Nothing. On 2 different machines so that's why Leobodnar or Leonardo are good for me cuz they connect and are active right away.
I understand you are an electronician or electrotechnician.
And filtering the feeback from GPB is exactly what i tried to do with simFFb or Testforce but it seems that it only works with DirectX Input device so one solution will be to use X360CE.
I'll continue digging !!!

"Obviously my rig ambition outweighs my capacities..."   ;D
Missing Gp500 (Microprose)  Testing EDTracker Pro on YT   R7-3800X/16Go/GTX1080/1440p/Full WC


Coming back to a "regular" simple axis device with no FFB, here is a "teaser" for the coming-soon video, my "bike" is ready.  ;D

Missing Gp500 (Microprose)  Testing EDTracker Pro on YT   R7-3800X/16Go/GTX1080/1440p/Full WC


May 21, 2018, 03:26:23 PM #115 Last Edit: May 21, 2018, 03:31:23 PM by speedfr
Hello to who ever follows that topic.
And the rest too but they won't know it  ;D

@h106frp (and DD or other if interested) :
As i realize and wrote in humoristic way (at least on my side), my rig ambition need more capabilities than i have so, even if the princip is probalby the closest to what i'm looking for, i'm gonna do as in Rugby, i'm gonna avoid the problem to turn around it.  ;)

And start from what i have, a leaning device, no steering ok, but at the speed we're going steering doesn't count that much.
Starting from that fact, the thing i'm looking for is what the FFB does when i'm riding and how to implement it BUT keep my leaning though the Leo Bodnar because it's in 12bits, so it is a lot more accurate than any regular wheel that you reduce from 900° or even 270° rotation angle to something like 60°.
When you do so, you loose a lot of accuracy and i've been struggling for a week or two with that.
And decide to come back to Leo Bodnar for the leaning instead of the wheel potentiometer reading and it's simple, really simple :
At Imola, on Moto2, 1.56 best ever time with the wheel reading and one time or two maxi, impossible to reproduce and do 3 laps without falling.
Using the Leo Bornar reading, 1.51 right away and constantly around 1.52, doing 15 laps without a crash...
It says the thing by itself.

So, i went to the Whishlist and put a new topic : filtering FFB in case i'll go for a FFB wheel adapted to the rig one day but i actually didn't use the FFB cuz it shakes constantly and the shaking is not really smooth or smoothable (!!) i mean you cannot set that and it's too strong. Feels like riding a electric Buffalo in Las Vegas where you have to stay the longest possible on it...
So for now FFB is out the circuit.

So, there's is your solution h106frp but it requires programming and good electronics capacities that i don't have. I'm a IT guy but mostly a "computer mechanic" nothing to do with programming, the only code i "own" was TurboPascal to set the fabulous Num760T for digital milling machine. But it was 25y ago and programming was on carboard   ;D

Then, i decide to find "my" solutions that will not go to the both axis for now.
Keep the rig as it is and trying to find better.
And here is what i found and gonna do :

1. add a second potentiometer to the end of the rig (the solid part attached to the desk) to read my angle position.
2. putting that into a chip (something like a Arduino) so the Arduino will order through a H interface a DC motor to constantly go against the angle. Meaning if i go right, he is forcing left, and keeping the angle i set. Forcing both ways constantly.
That's not hard to do and my electronician friend is already doing the plan of the part i'll need and how to link them between themselves.
Second thing is a increase of the strength from the DC motor as soon as i brake. So, using the stop light switch on the front brake to command the DC motor with more opposition force until the brake are released.

That solutions requires parts but almost nothing to program (Arduino kind of things are easy to program with a GUI system) and DC Motor as a Mabushi 575 is cheap, easy to find, the power supply will be a laptop one, 19v at 4.5A that will be enough. And i can 3D print the gearing to give the motor enough torque.

This system is completly independant, doesn't need to be hook to the Pc, doesn't need driver or reading from GPB, doesn't need to "steal" the info from the game and doesn't interfere with whatever from the Leo Bordnar so no risk of surge or high current going back to the USB card.

So, yes, h106frp, i know it's an "average" solution, not the top one as you did with you rig. But at least on the paper, it's easy, cheap and simple to do. And to reproduce (i reminds you that i have to do a second rig for Mister William that keeps jumping on mine as soon as he can).

So the video will come later cuz the SAPETOKU #40 is at the workshop  8)
Missing Gp500 (Microprose)  Testing EDTracker Pro on YT   R7-3800X/16Go/GTX1080/1440p/Full WC


Hello everybody,

coming back to you to expose few questions (DD, h106frp and Uberslug) and explaining which and how i'm going to upgrade my rig to have better feelings (still my biggest problem, that i have to "interpret" the effect in my mind and for somebody who is riding everyday, it's kind of loosing me on GP bikes).


At first, this is for both of you :

I post in here two draws, representing a real frame with what i call the V axis (steering with rake angle) and the H axis (leaning).

Then, if i had to reproduce that axis, as my first post mention it with a picture from Sketchup, i would do my V and H axis like that : (maybe put a 20-25° angle for the V axis to be more realistic)

My question is simple :

How you guys can use (via DST for UberSlug or DSA for H106frp) both axis at the same time on GP Bikes who only can use 1 axis (leaning or steering but only one displays in setting) even if Hardcore mode sets the DSA/DST.

So, how you guys can pick this mouvement from either V or H, if the axis in the game is linked to V axis (steering).
Actually, you can read your V and H position through potentiometers (regular or Hall effect doesn't matter)
and after that, the game can only read one of the both axis... So i guess you read the V axis and by pushing (countersteering)the H axis, you lean. But where do you input the H axis value ????

I understood that h106frp "catches" the value from a dll software that can read what the game is sending to USB device in terms of FFB but i'm scratching my head trying to find how the value you get goes back to GP Bikes...

@Both of you : UberSlug, you catch the V axis with your SimExp systems but how do you lean and read this leaning to send it to the game ? Or is leaning an interpretation of your steering angle (torque instead).
Same question for h106frp : you have two ServoMotor, ok, but only one is used to be read by the game (through your Hall effect potentiometer) but how the leaning is being interpreted by GP Bikes ? I will required a load cell to mesure the torque but then it becomes DST and even, you have to add Potentiometers+Loadcell reading to catch the total value, i'm sorry guys, i don't get it.
Might be simple and right in front of me..but i'm blind so far. Thanks in advance.

Now, second subject, the upgrade.
I tryed again with a steering wheel that has FFB.
FFB is good but not filtered and that's annoying.
But i found out with my eletrotechnician friend, that we could actually catch this FFB AND filter it.

Solution is called Leonardo Arduino, 32u4 chip inside, and by replacing the LeoBodnar i have, i could use it for the 5 axis (Throttle, F brake, R Brake, Clutch and Steering) and have the 15 buttons i have on the LeoBodnar.

The thing is, this chip can be known as a HID device natively by Windows and uses a virtual com port.
And through the com port, i could read the FFB and Filter it nicely to get only the leaning/steering effect and nothing about gear up and down or kerbs vibration. Which is what i'm looking for. (in the whishlist i ask to get FFB filtered, only davidboda46 came to say +1 so i guess we are from another planet  ;D )

The rest of my rig remains the same, it's ready anyway, and what i'm missing (feelings from the track) will come with a 3D printed gearings and a couple of 24v DC motor+360W-24v PowerSupply.
And yes, h106frp, we experienced so EMF so it's all filtered by some diode now, don't ask me its my friend who measure and did everything related to electronics.
I have a H bridge already (43 Amp !!) and everything runs fine at the test with the DC motor.
Here is a little capture of the princip of gearing in order to get a 1:58 reduced gearing to have sufficient torque to feel something (FFB wheels have usually a 1:30 ratio and if 1:58 is not enough i could increase easely to 1:104).

I really hope into that because feelings from the track is what i miss the most. 2 sec on inattention and you are away from the line, away from the time and pissed off.

So now, rig is going to the garage and being worked on, i hope i'm back on the track within 2 weeks.

Missing Gp500 (Microprose)  Testing EDTracker Pro on YT   R7-3800X/16Go/GTX1080/1440p/Full WC


You can't have at the same time steering torque (or steering angle) and target bike lean as GPB inputs. It just doesn't make any sense physically.

Bike lean is an output of the physical model and steering torque is the only real input.

In GPB normal mode (not DST, not DSA) you input taget bike lean (note, this is not the bike lean) and steering torque is computed by the virtual rider.
In GPB DSA you input steering angle and steering torque is computed by the virtual rider.
In GPB DST you input steering torque (and the virtual rider doesn't do anything).

In any case, bike lean s an output of the physical model.


Great to see your rig developing but Max has correctly summarised the control options and without using the plugin dlo interface your options are limited. When using GPBs force feedback output you are dependant on PBs estimation of how the bars would 'feel' for the rider. It may be possible to suggest that the interface could be enhanced with some sort of parameter 'mixer' to customise the output feel for the rider.

Not something I have ever tried but the rumble output that Max created for MaxHUD would suggest that you could probably create your own force feedback signal from the dlo outputs and output it to the standard Microsoft HID control interface. If you asked him very nicely he might supply some guidance on hooking into the MaxHUD dlo/interface which would make things much easier.

My rig uses the lean and steer angles computed by the GPB physics engine to set the lean and steer angle of the 2 servo axis, i.e. the rig mimics what you would see in 1P view. The servos have considerable holding torque and 'set' these positions so they cannot be moved at the physical bar inputs.

DST mode which equates to full steering simulation.
The steering stem torque is used as the input to the game and is the product of how much effort (force not deflection) you are using at the physical bars to either oppose or add to the current steer torque set by the servo which will always attempt to maintain the currently computed steer angle, the closed loop nature of the control (via GPBs physics engine) does the rest of the computation work.

DSA mode which equates to a more complex force feedback system.
Optionally I can reduce the steer axis servo torque levels on the controller so that it behaves more like a traditional force feedback system allowing you to control the steering angle and use the feedback potentiometer (hall device in my case) as the input to the game.


Thanks for the reply so fast Max and h106frp.  :)

Quote from: HornetMaX on July 05, 2018, 07:12:05 PM
You can't have at the same time steering torque (or steering angle) and target bike lean as GPB inputs. It just doesn't make any sense physically.
In any case, bike lean s an output of the physical model.
Thanks because even if my expression is wrong way that's what i felt and i was confused about it. I know leaning is a result not an input (IRL).
Except that using your plugin, you collect his result. And then it can be interpreted. that's were i was lost, how a value can be picked and used if it cant be read.
I've seen your Plugin page and the result it gives. great and impressive job.
If racing was more developped in here, i'm sure it will be used more as on car races with Motec-likes.

And yes, you give a nice résumé of what it is, but i guess i'm gonna stick with option 1 for now even if the other ones are running somewhere in my mind. Later.
The feeling in the hands with FFB on the normal mode is not that great but it's there, better than not at all.
And so far it's not at all, very disturbing.

@h106frp, thanks for clearing up your rig invention to me, some point were confusing me. And that makes me write incoherent things sometimes. Specially in Shakespeare language  ;D
And (but don't say that i told you 8) ) if i have to ask very nicely "with sugar on top" to Max, i'll do that on the right time, today will be wasting my last bullet  ;)

If your rig catch what you push with your hand on the handlebar, it has to be very very small angles when being fast, and i guess the steering servo doesn't gives you a lot of frredom angle to do so... then the leaning servo turn the bar onto the H axis, and you "follow" the mouvement as on a real bike ?
And if i understand well, to use DST, it will need a loadcell on the V axis and a motor to countersteer this axis while "freeing" the H axis ?
all of that by reading the dlo output from GPB onto this H and V axis.
Am i good ?
And i think this is the only way to be able to slide on curve as in Moto2, when you see Aegerter, Lowes or Marquez steering at the end of a curve brake.

Real Sisyphe story, each time you think you reaching a point, you realise how far you are...  :o

The story goes on.
Thanks again Messieurs !
Missing Gp500 (Microprose)  Testing EDTracker Pro on YT   R7-3800X/16Go/GTX1080/1440p/Full WC