This guys, we need community to utilize those inSim features and see what AI's can do.
Yeah, just use a deep learning neural network with about 1 billion neurons and it will beat Gabor every time. Just one tiny problem, to run it in real-time you'll have to use a quantum computer with at least 1k qubits.
Jokes aside, optimizing such AI is a huge task that goes outside of LFS itself. Compromises have to be made and the right combination of different techniques, maybe even including small neural networks could be a thing, but all this is in the far future of LFS.
Jokes aside, optimizing such AI is a huge task that goes outside of LFS itself. Compromises have to be made and the right combination of different techniques, maybe even including small neural networks could be a thing, but all this is in the far future of LFS.
Last edited by rane_nbg, .
How about this - let AI drive some car and you put air restriction in your. That way, you can fine tune AI to your pace.
Hi, I'm working on Arduino FFB firmware for quite some time - it's open source and free. It does exactly what you need, you may check it out. There are 2 parts, one is arduino firmware that turns it into an ffb joystick and the other is the GUI for PC to adjust settings. You will need to make a differential amplifier and use 2 external dac's - this will be your analog torque input for the driver. I've provided all documentation, wiring and manuals.
https://github.com/ranenbg/Arduino-FFB-wheel
https://github.com/ranenbg/Arduino-FFB-gui
https://github.com/ranenbg/Arduino-FFB-wheel
https://github.com/ranenbg/Arduino-FFB-gui
Last edited by rane_nbg, .
Very good suggestions and well written. I support.
Hi, we will use this one for our 2-hour event this Sunday. I'd appreciate it a lot if you could address some critical issues.
I propose 2 following fixes:
[1] lower center of gravity (the car can roll very easily)
[2] shorten the upper arm of the rear suspension (it needs camber gain on compression for better turning)
Otherwise, the car is very well made, thank you very much.
I propose 2 following fixes:
[1] lower center of gravity (the car can roll very easily)
[2] shorten the upper arm of the rear suspension (it needs camber gain on compression for better turning)
Otherwise, the car is very well made, thank you very much.
Last edited by rane_nbg, .
I'm reporting that a new option for bump stop works as expected also on my Arduino firmware (joystick). Tnx very much.
It's just a matter of fine tunning the spring constant in endstop spring effect (if he implemented it as a spring). Maybe it's just very stiff at the moment. Usualy all ffb wheel firmware allow you to set this, but that will not be automatically applied in lfs, because it creates this effect independently. But some time in the future, an option to adjust how strong lfs endstop is, could be a thing.
Here it clearly says generic desktop and joystick. This is exactly the same as how I have it my firmware, but lfs reports is as joystick. I'm not sure why your wheel is seen in lfs as first person controler.
Anyway, that's not gonna be relevant anymore once we get the override button.
Anyway, that's not gonna be relevant anymore once we get the override button.
This is in the case where one intentionally pulls the joystick all the way until the mechanical stop, where the end-stop force is maxed out. Obviously, letting go of the stick in such a situation will not end well.
But you are right, it should be kid-safe.The ability to manually override the controller type in lfs is all we need. A simple override button + a short description of what it does is enough. We don't need an entire selection of all other types, we just need the one that makes the end-stop forces work, therefore one button instead of a drop-down menu list. For example, your auto button is renamed to override, once pressed the type will be set to wheel. Unpressed will show the original device value from the HID descriptor.
edit. the quote from SIMUCUBE is exactly what I'm thinking. I'm using such DIY project to create a wheel and having it defined by simulation controls is very limiting, because then many wheel features would not be available. Those are for example D-pad hat switch, X, Y, Z axis and so on.
Last edited by rane_nbg, .
Yes, those generic HEX values are what you need. There is an HID descriptor tool that can decipher easily their meaning because this is part of the DirectX standard. You can get it from here:
https://usb.org/document-library/hid-descriptor-tool
You first select USAGE_PAGE (generic desktop or simulation controls), then under USAGE, you will see available types and properties like axis and so on. Once selected it will show the HEX representation and you may find if anything matches with the values you got from USBTreeView.
https://usb.org/document-library/hid-descriptor-tool
You first select USAGE_PAGE (generic desktop or simulation controls), then under USAGE, you will see available types and properties like axis and so on. Once selected it will show the HEX representation and you may find if anything matches with the values you got from USBTreeView.
Last edited by rane_nbg, .
Yes, let's not go off-topic now with FFB peak forces. Filtering, limiting, and compression can be done but let's leave that for some other time.
I understand well your rationale behind the decision to disable endstop forces other than wheel controllers. My point was that endstop force is not one that can cause the joystick or whatever to oscillate from side to side - actually, the ones that do are autocenter spring force or damper for example. Anyway, I respect your decision if you want to keep it that way.
Thank you for tackling the issue. What exactly will this selection of controller type do? I mean, a simple controller-type override button is enough. By default, you can leave it inactivated and the user can choose to enable it in order to get end-stop forces working.
I understand well your rationale behind the decision to disable endstop forces other than wheel controllers. My point was that endstop force is not one that can cause the joystick or whatever to oscillate from side to side - actually, the ones that do are autocenter spring force or damper for example. Anyway, I respect your decision if you want to keep it that way.
Thank you for tackling the issue. What exactly will this selection of controller type do? I mean, a simple controller-type override button is enough. By default, you can leave it inactivated and the user can choose to enable it in order to get end-stop forces working.
Last edited by rane_nbg, .
Tnx for this info Scawen, it is very useful as it reveals the specific lfs requirement for HID descriptor of an ffb device. Manufacturers use various values for USAGE, it can be wheel, joystick or gamepad, sometimes also first person controller. I will play with my firmware and see if it makes a difference if I change the usage in HID descriptor.
In my oppinion, endstop forces are not dangerous, because this is in essence a spring force. It's intensity depends on axis position, so the user can simply stop pushing against "spring" when ever he wants and it will not fight back. The dangeous forces are the actual ffb signals, where you for example smash the car into a wall which creates a huge peak in ffb one can't do anything about, as it's often quite unexpected.
In my oppinion, endstop forces are not dangerous, because this is in essence a spring force. It's intensity depends on axis position, so the user can simply stop pushing against "spring" when ever he wants and it will not fight back. The dangeous forces are the actual ffb signals, where you for example smash the car into a wall which creates a huge peak in ffb one can't do anything about, as it's often quite unexpected.
MOZA also just uses direct input API. If you can have a look at wheelcheck or DI view and expand the part which describe the ffb features, see what they have defined in HID descriptor. Would be interesting to see which ffb effects they have implemented. I'll show the examples of t300 and my arduino firmware soon.
I also noticed after some lfs update that I can't anymore feel endstop force generated by lfs on logi G29 wheel. Before that particulair update from a few years ago I could feel end stops in cars that had less rotation than 900deg (I used 1.0 wheel turn compensation).
However, on thrustmaster t300 I have the endstops. On my custom arduino firmware for ffb wheel, I also don't have enstops, so I have no idea what's going on. In all cases I'm using 2 ffb controlers plugged in, one of the comertial wheels + my arduino wheel firmware that I use only for load cell brake pedal. On its own, only t300 has working endstop from lfs, in its driver I have it set to 1080deg and lfs does the rest as it should.
edit.For ffb neard eyes only - the problem seems to be related in how lfs creates the endstop force. Some wheel firmware like the one in t300 which just use direct input API for ffb actualy have a few ffb effects alocated for this purpose called axis barrier and angle barrier. I have no way of telling if lfs utilizes those or just uses constant force effect to create the ilussion of endstop. In my custom arduino firmware, I can clearly observe that lfs send only constant force ffb effect. But there is nothing being sent at the moment where a full lock of particulair car is reached, this is before the wheel's actual lock (where it applies its internal endstop). If we could get more details from lfs devs about this matter, I could then test it in details and report the findings which may lead to some solution. Just like we did for issue where lfs would only send one sided ffb in some new wheels.
However, on thrustmaster t300 I have the endstops. On my custom arduino firmware for ffb wheel, I also don't have enstops, so I have no idea what's going on. In all cases I'm using 2 ffb controlers plugged in, one of the comertial wheels + my arduino wheel firmware that I use only for load cell brake pedal. On its own, only t300 has working endstop from lfs, in its driver I have it set to 1080deg and lfs does the rest as it should.
edit.For ffb neard eyes only - the problem seems to be related in how lfs creates the endstop force. Some wheel firmware like the one in t300 which just use direct input API for ffb actualy have a few ffb effects alocated for this purpose called axis barrier and angle barrier. I have no way of telling if lfs utilizes those or just uses constant force effect to create the ilussion of endstop. In my custom arduino firmware, I can clearly observe that lfs send only constant force ffb effect. But there is nothing being sent at the moment where a full lock of particulair car is reached, this is before the wheel's actual lock (where it applies its internal endstop). If we could get more details from lfs devs about this matter, I could then test it in details and report the findings which may lead to some solution. Just like we did for issue where lfs would only send one sided ffb in some new wheels.
Last edited by rane_nbg, .
I only see this work in situations like KY1 or similair tracks where one side of the car is heavily loaded while on the other side tires stay always cold. Maybe it would be worth a try to have asymetric tyre compound placement option included when togling it on for tyre pressure..
Would be good if we could also remove the missplaced reaction, not so easy to pinpoint a tiny thing with a finger on a small phone screen.
We're gonna be driving your škoda felicia kit car in our mod shakedown on this sunday. We'd love to see you there as an honorary guest.
I'll have to vote -1 for this idea.
Also check if you are not pressing brake slightly all the time due to bad pedal calibration.
I can't say that, since our team is the origin of airio. Just browse the forum a bit.
Last edited by rane_nbg, .
You have to utilize inSim for such features. There exist many apps that can do it, but most probably you saw airio. One can still find free version of airio with those basic functions.
Did you make an exception in lfs.net hosting? You have to allow an IP address from which you're hosting airio. Ideally, this would be static IP given by your ISP, otherwise you're gonna have to keep repeting the same process each time your IP gets changed dynamicaly.
Post your controler settings from lfs.
Last edited by rane_nbg, .
Tnx man. I assure you that your mod will be used at some point in our AA Mod shakedown event.
FGED GREDG RDFGDR GSFDG