Hi guys,
Let's admit you have built your own controller with FFB system. Would GP Bikes recognize it and allow the force feedback to be enabled?
Or is it mandatory to use an official (modified) racing wheel?
Another question: is it possible to use a controller that is connected with 2 USB ports? Actually, I'm thinking about adding a kind of FFB system on a standard gamepad...
The gamepad would use 1 port. The FFB system would use a 2nd port.
What do you means by ffb ? cause i don't get how a ffb could work on a game pad ..... for the question, gpbikes output ffb, it's a question of the controller who listen to it and translate it to your ffb motor.
GP Bikes does not always output the ffb.
You need to enable ffb.
But the option is greyed with standard controller.
I've seen people making their own racing wheel with Arduino. If I do something similar, will GP Bikes allow ffb in the settings?
The 2nd question is: I use a standard gamepad, I "want" to add an Arduino and a mini motor that affects the joystick movements, in order to create a sort of ffb effect.
I will end up with 2 connections (USB): 1 for the gamepad, and 1 for the ffb system. Any chance for it to work?
When i say gpbikes output ffb, i mean you can extract ffb data via arduino for example, as you can extract lot of telemetry data, wich is used for exemple in the MaxHud plugin or even in motion playseat. So the answer is yes.
For the second question, yes GPbikes can handle multiple input. for exemple here :
I've used 2 cheap controller for the steering and the pedal and then my phone's gyroscope and virtual joystic as a third input to control rider lean ! So the answer is also Yes !
Good to know!
I'll try to find the ffb info in the udp message...
Thank you !
This is my force feedback system for a standard gamepad (DS4):
I can now feel the wobbling and the grip losses directly in the gamepad!
:D
Hahaa, a wonderful little piece of ingenuity! Good job!
What did you end up using? Udp or HID?
thank you...
I used UDP, as I already had the code I made for the dash...
Cool, hadn't seen your dash either!
Hats' off!
Wow :o !
That's crazy man. Please show us how to build that.
This could be a gamechanger. Proper feedback from the bike without needing an expensive handlebar controller.
Have you thought about selling this as a kit with the programmed chip?
Yes I am building a 3D printed version instead of Lego.
Once finished (soon), I will think about selling it. ;)
YEAH BUDDY!!!!!!
Will you make a version for the Xbox gamepad, too?
Also, can you still use the right stick properly with this construction?
Man, I can't imagine how awesome it must be to actually feel when the front slips or the rear steps out. Truely next level. You have to follow through with this :D :D
Yes you can use the right joystick without any problem. (I don't use it).
I may build something similar for the Xbox controller. Let me realease this one first... ;D
Ok, just sayin' because there is probably much greater overall demand for an Xbox version.
This is V2: more compact and more ergonomic. I still use Lego gears, racks and axles.
Hi
Can you give me your thoughts about the following?
If I can extract the FFB output instead of the steering angle, and I send it to the servo, I may be able to use Direct Steering (DSA/DS2) with the gamepad.
Of course, I will have to replace the springs by stronger ones.
(I will also have to find a solution for rider tracking, as automatic rider lean will be disabled with direct steer, but that's another story...)
I tried to look for the FFB in the UDP message, I found the steering torque.
I'm no sure this is the real FFB output.
Even if it is, the value is very unstable in every
riding situation (when going straight, turning, braking,...).
I did not find anything else.
My questions are:
1. Is the FFB really sent via UDP like other data?
2. Why is the "steer torque" value so weird?
Hopefully I don't force a new debate about realistic controllers and comparison with real life...
I don't have the answer to any of that, but I use direct steering with my FFB (USB, "normal" FFB) rig and that signal could explain the extreme chattering I get when going straight, braking and turning. Strangely enough, sometimes the chatter goes away when leaned over at a specific angle...
Out of curiousity I constructed a rather simplified steer potentiometer/feedback servo rig and found exactly the same issues. Quite a nice feedback effect but the steer torque glitches to very high magnitudes and ruins the overall feedback effect. The magnitude seem unbelievable high if it really is in Nm as you would expect it to wrench the bars from the riders hands and its odd that it does not manifest as pulses in magnitude on the steer angle parameter.
Looked through the list of parameters available and I cannot see anything else that would be particularly useful so I suspect that force feedback is just formulated from the steering angle + some function of steer torque.
I have not tried any filtering of the signal but I guess it might be worth plotting the data available from the UDP tacho app to see if we have a good enough sample rate for a filter to work on.
Inspired work you are doing with getting something that can actually be applied to a standard controller.
Does this happen also with "normal steering"?
yes, I found that the steertorque value is unstable in both cases: standard gamepad with normal steering mode, or racing wheel with FFB and Direct steer mode.
Quote from: maggikk22 on March 11, 2020, 10:01:02 AMyes, I found that the steertorque value is unstable in both cases: standard gamepad with normal steering mode, or racing wheel with FFB and Direct steer mode.
Yes, but what I meant is;
Does it affect the ffb when using normal steering in the same way it does the direct steering ffb, or are the two different equations?
Could the new P/D-settings for direct steer in the bike config help remedy the problem in that case?
hard to say...
I would say they are different equations, because FFB output is very different if you choose direct steer or normal mode.
But in both cases, the steertorque value is oscillating a lot.
Not sure I answer the question...
Trying to tune the P and D seems to be a good idea...
Are you guys using Direct Steer Angle or Torque?
I use angle, torque doesn't make much sense on my ffb controller.
Played around with the P/D settings today, but I can't get it to make much difference at all.
I (try to) use angle too.
so, apparently the "steer torque" output value cannot be modulated with the P/D settings...
I don't know what values to use though..
The standards are:
P= -250
D= -40 ( I think)
Tried different values from 0 to 1000 at FFB at 90%, but nothing stopped the insanity. Next step would be to try the same at 60-70% FFB.
At under 40%, FFB is not as noisy.
hmmm... if the steer torque value is less noisy when you decrease the FFB strength, I wonder if there's a way to reduce that noise when FFB is not active at all.
As I use a gamepad, I will not be able to enable FFB. Instead, I wanted to use the UDP data to generate the FFB.
At least, if the steer torque value is actually impacted by the FFB strength, then we are sure that we extracted the right info from the UDP message...
As the magnitudes and periods are so extreme I wonder if we have 'raw' non-damped torque values.
Applying a damping function to simulate the steer system i.e. f(x)=X sin(torque) might give a more useful output. For this linear example the torque would be 'squished' between y=-X an y=+X. a sort of S curve crossing at zero.
So I tried it with my test set-up and the result is pretty good (madness constrained), this was the arduino code so far;
if (m_iCrashed != 1 ){
m_fSteerTorque = m_fSteerTorque / 2; // roughly in the range 0 to 100Nm as observed from data
float SteerTorque = constrain (m_fSteerTorque, -90.0 ,90.0); //limit to equivalent of +-90 degrees
float dampedtorque = 20 * (sin((3.14/180) * SteerTorque)); // damping equivalent to 20 degrees
servopos = 90 + int (m_fSteer + dampedtorque); //centre servo at 90 and add steer and torque
servopos = constrain (servopos, 45 ,135); //constrain servo max angle
myservo.write(servopos); //position servo
Serial2.write(188); //update debug LCD
Serial2.print("servo : ");
Serial2.print(servopos);
}
else {
servopos = 90; // centre servo
myservo.write(servopos);
}
Need to play with damping coeff X or add a sensitivity pot adjuster to arduino analogue in so you can do it dynamically
It would be nice to have the joystick input position go to the arduino as well to help with servo tracking, at low speed fsteer is pretty good but at higher speed fsteer is not a vey good indication of how much stick input has moved so you start to feel the spring force - next development ::)
I've just tried with a rolling average of the received value and the results are similar to yours.
I tried with standard steering mode.
The damped value makes sense: I can see clearly that it pulses (up to around 200Nm) when I suddenly change direction.
It is quite stable when you ride quietly.
For the dynamic tuning, prior to sending to Arduino, I use Processing so I can adjust in real-time the sent value using virtual buttons.
You're right about the joystick position, I hadn't thought about that yet...
Looks like we're on the good way.
Thank you for the help!
Then this may be further proof that the virtual rider is causing stability issues and needs to be tuned to be less tense and more smooth.
Additional analysis would be great, though.
If you want to control the bike/physics simulation directly, you need to use DST. With DSA the virtual rider is still part of the equation.
The joystick position is a bit of a pain as its not in the UDP output or memory interface, I really do not want to try and add a cal routine to arduino (using ethernet shield so I do not have an intermediary PC host app.) The scaling is in the calib file (documents\piboso) so maybe that might be useful.
Thinking a bit more about it I do not suppose it matters what GPB thinks the value is for my arrangement, on startup I could just index the servo full lock left, mid and right and record the pot voltages to use as servo offsets.
@vini, at the moment I am just trying for a nice genuine feedback feel and more out of idle curiousity than any practical controller; but I guess if that works you would be halfway to a 'better' DST controller mode. Using the hall force sensor in the other thread as the stick input you might get pretty close.
updated..
So.. a couple of wires from the pot to the analogue in, some extra code and the joystick position feedback is implemented. A big difference in feel and a reduction in jitteryness. The feeling now is that you are pushing against the inside bar with a nice kick when you bump a kerb or step a tyre out.
I am very surprised just how well it works, now its all 'under control' I think a bigger servo could be used to replace the mini MG90S currently in the rig.
very interesting,
Can you share some pictures of your system?
This is just a test jig for the ffb so nothing very fancy.
Trying to sort a throttle and brake to make testing easier and then I will try and post a pic.
Think I need one of you guys to help as I dont know anything about FFB and my new design has dual axis on the steering for countersteering feel and body movement.........bit hard to explain but it works lol............just dont have FFB for it and real simple mecanicaly.
Anyone want to try and help?
DD
Do you have separate inputs from the counter steering and the lean, or are they blended?
Do they operate independently?
If they are independent I would probably use something like h106frp describes and hook the handlebar torque up to a servo that is connected to the counter steering axis and another servo or motor that feeds the lean angle back to the tilt part.
DD,
I read both the steering and the lean angles that GP Bikes sends via UDP, using Processing. I calculate a servo position depending on both values and send it to an Arduino. I can adjust both sensibilities in real time to get a good feeling. I do not use the torque output. (I tried it with direct steering, it works, but I don't like it with a gamepad.)
On the previous videos, I was only using the steering angle, so I could only feel wobbling and grip loss. Now I can feel the weight of the bike too.
Of course, i have a single axis.
But the principle is the same: read 2 values, and send each one to 2 different servos.
Hope this helps...
Quote from: Vini on March 12, 2020, 06:24:38 PMThen this may be further proof that the virtual rider is causing stability issues and needs to be tuned to be less tense and more smooth.
Additional analysis would be great, though.
Resurrecting this just to say that the steering torque signal has always been extremely noisy/spikey/hig-freqey in GPB: you can easily see this using telemetry.
It sounds too easy to be true, but I'll say it anyway (again, I think I already asked this multiple times long time ago): PID controllers (like the virtual rider) may have high gain at high frequencies, depending on how they are tuned. In usual applications, the PID is followed by a lowpass filter of some sort to avoid that. Not sure if GPB has anything similar.
Of course the design of the filter is not exactly trivial as it shouldn't interfere with the behaviour of the PID in the freq range where it matters (i.e. shouldn't affect the stability of the whole system and the general response).
Also notice that in some industrial applications the filter may not be there but often this is due to the fact that the actuator has its own "filter" inside (i.e. it behaves like a lowpass above certains frequencies). Again, not sure what GPB does about that.
I'm pretty sure GPB only uses a PD filter, hence the noise..
Resurrecting the topic to show you an interesting gamepad that may have a built-in force feedback system on the sticks (and on triggers):
https://nextrift.com/dell-concept-nyx-game-controller-features-adaptive-thumb-sticks-fingerprint-sensor/
Oooh, looks like a next gen bit of kit! The were most likely inspired by you!
;D haha, maybe...
There's another one called FS-Pad, but none of these prototypes end up with a release:
https://github.com/KAIST-HCIL/FS-Pad (https://github.com/KAIST-HCIL/FS-Pad)
My "proto with no release date":