That is indeed something to keep in mind, thanks for the reminder. I don't think LFS physics changes like that as I am pretty sure they are not using Pacejka's model, although, what the hell do I know about the physics used, not like I've ever seen the code! I was using 1mph as an example, but 20mph might start pushing into understeer for some steering angles.
I will try taking the car out for a spin myself to see if the idea works. It is possible the radius at 5mph is far different from 30mph even without being at the limit, and that wouldn't work so well.
EDIT: Regarding G-forces, he is aware of them in his physics sensor. But I've yet to find a reliable way to use it to detect understeer. He is also aware of the yaw forces acting on the car, which I think would be more reliable than lateral-g's, however there is no way to know from yaw forces alone whether understeering. It is complicated. And that doesn't say enough.
LATER: Just found a bug that any player joining causes an error message box to appear and this takes focus away from the AI driver. I will dig deeper into this and see if it should instead be a warning, or find a fix. But currently I've limited the server to run just the AI driver to prevent the issue from occurring until I can look at it.
I will try taking the car out for a spin myself to see if the idea works. It is possible the radius at 5mph is far different from 30mph even without being at the limit, and that wouldn't work so well.
EDIT: Regarding G-forces, he is aware of them in his physics sensor. But I've yet to find a reliable way to use it to detect understeer. He is also aware of the yaw forces acting on the car, which I think would be more reliable than lateral-g's, however there is no way to know from yaw forces alone whether understeering. It is complicated. And that doesn't say enough.
LATER: Just found a bug that any player joining causes an error message box to appear and this takes focus away from the AI driver. I will dig deeper into this and see if it should instead be a warning, or find a fix. But currently I've limited the server to run just the AI driver to prevent the issue from occurring until I can look at it.
Last edited by blackbird04217, .
Left the driver running over night but it appears to have mishandled some player IDs when someone joined to race along side him. So I woke to him sitting in a corner. I'll need to dig into that are of the code, or at least handle failure cases better, if I can.
I've recently been reading Going Faster! by the Skip Barber Racing School, part of what lifted my motivation for the project, and the first part of the book hammers in how important the line, corner exit speed and braking distances are. In that order. Yesterday I watched the driver while working and noticed he is actually REALLY bad at following the racing line he believes is best.
I think I'm going to create a completely new state for the driver for "Car Training". I'm hopeful that at anytime I could send a command like !traincar to the driver and have him automatically change track to either the autox area or skidpad. Here he would drive to the widest opened space and proceed to drive in circles. Which led me to the discovery that we humans don't think of the steering as an axis from -1 to 1. (We do pretty much think that way with throttle, braking and clutch though, I was 10% on the throttle is like saying 0.1 throttle.) So I am going to add an additional function to set steering position by angle.
Then the driver will be able to SetSteeringByAngle(10degrees) and drive in circles to get a reading on what the radius of the circle is when the steering wheel is 10 degrees to the left (or right, doesn't matter which). That is a good start to learning the capabilities of the car given any setup, vs the hardcoded values it has currently been using. There are a few problems:
1) The radius driven when the wheel is at 10 degrees will change if going 1mph or 50mph. (See below).
2) The driver has no sense of understeer. Currently I have not found a reliable way to detect it with the information I have. Hoping this helps.
I am hoping 1 and 2 can be resolved by driving the first circle(s) slowly. I think if I start at 1mph, (or at least below say 5mph), the radius of the circle will be the "expected" radius for that steering angle. After getting this reading, the driver can then start increasing speed, slowly, until the radius starts to grow. When it does start to grow, the driver will have found (and exceeded) the ability of the car.
The driver will do this over and over for several steering angles, and collect minimumRadius and maximumSpeed values for each inputAngle. With that I -THINK- I could get the understeer sensor working? Maybe? But I'm really hoping I can use it to drive the car closer to the ability of the car.
First I must see if the driver training in the car like this will be at all valuable. Then I'll implement it, and it still won't do much until I find out how to use it.
I've recently been reading Going Faster! by the Skip Barber Racing School, part of what lifted my motivation for the project, and the first part of the book hammers in how important the line, corner exit speed and braking distances are. In that order. Yesterday I watched the driver while working and noticed he is actually REALLY bad at following the racing line he believes is best.
I think I'm going to create a completely new state for the driver for "Car Training". I'm hopeful that at anytime I could send a command like !traincar to the driver and have him automatically change track to either the autox area or skidpad. Here he would drive to the widest opened space and proceed to drive in circles. Which led me to the discovery that we humans don't think of the steering as an axis from -1 to 1. (We do pretty much think that way with throttle, braking and clutch though, I was 10% on the throttle is like saying 0.1 throttle.) So I am going to add an additional function to set steering position by angle.
Then the driver will be able to SetSteeringByAngle(10degrees) and drive in circles to get a reading on what the radius of the circle is when the steering wheel is 10 degrees to the left (or right, doesn't matter which). That is a good start to learning the capabilities of the car given any setup, vs the hardcoded values it has currently been using. There are a few problems:
1) The radius driven when the wheel is at 10 degrees will change if going 1mph or 50mph. (See below).
2) The driver has no sense of understeer. Currently I have not found a reliable way to detect it with the information I have. Hoping this helps.
I am hoping 1 and 2 can be resolved by driving the first circle(s) slowly. I think if I start at 1mph, (or at least below say 5mph), the radius of the circle will be the "expected" radius for that steering angle. After getting this reading, the driver can then start increasing speed, slowly, until the radius starts to grow. When it does start to grow, the driver will have found (and exceeded) the ability of the car.
The driver will do this over and over for several steering angles, and collect minimumRadius and maximumSpeed values for each inputAngle. With that I -THINK- I could get the understeer sensor working? Maybe? But I'm really hoping I can use it to drive the car closer to the ability of the car.
First I must see if the driver training in the car like this will be at all valuable. Then I'll implement it, and it still won't do much until I find out how to use it.
Woah.
Unfortunately I don't have any -hard- factual numbers to give for my previous PC performance, I know that AIRS was running approximately 16-20fps on average, lets say 30fps on the best case, while LFS was running around 30fps in windowed mode while it was running.
My new PC, woah. I do have some hard, factual numbers to give. AIRS (on the non-upgraded version of my framework) is running at 1650-1700 fps and LFS is at 350-380 fps. I honestly don't know if it is beneficial to run LFS at a faster rate or not, that would depend how the main loop pumps through the InSim/OutSim/OutGuage messages, it is possible letting LFS update freely could reduce lag, it is also possible that it doesn't matter after say 60 or 100fps.
On the AIRS side it will allow the updating of the virtual controller more often and running the logic with smoother data, actually the prediction sensor is actually smooth! That is the first time I've seen that smooth since I first wrote it and made that video. Shortly after (I think it was adding the visual sensor?) the performance dipped and it has been jumping around ever sense.
I may rip out the visual sensor and just give the AI driver his position directly, even though that went against my initial intentions, I know now that he could (if needed) compute this by the visual reference points, although with the extra horsepower this PC has, do I need to do that?
I'm still trying to get the project working on the updated framework, it would make some things a bit easier to deal with and would fix some issues that have been fixed with the framework, but, currently having an issue getting the terrain mesh, and other meshes, rendered to the scene. That and the whole steering issue that occurred somewhere during that update, wtf?
EDIT:
In the project with the updated framework, I finally got the car and track visible again. But I am still chasing the steering issue. The good news is, like before, version control system allows me to check out every different line of code. Unfortunately, a lot of lines changed for the update, so time to hunt down the one that cause the issue.
EDIT2: I claim rendering was working, but the car doesn't rotate correctly, yay. :-(
EDIT3: HECK YEA! WOOT. Got it figured out, and glad my brain had a moment to put 1 and 2 together. Going through every code change would NEVER have found the issue. The issue was a fundamental change months ago in my math framework to use degrees for _all_ rotations, and it had previously used radians for some rotations that were untouched in airs code. Would have looked right over it. Turns out, both issues were the same thing, basically the driver didn't know the direction he was facing because the car transform was a little wonky. All working now with the latest version of the framework, woot!
Unfortunately I don't have any -hard- factual numbers to give for my previous PC performance, I know that AIRS was running approximately 16-20fps on average, lets say 30fps on the best case, while LFS was running around 30fps in windowed mode while it was running.
My new PC, woah. I do have some hard, factual numbers to give. AIRS (on the non-upgraded version of my framework) is running at 1650-1700 fps and LFS is at 350-380 fps. I honestly don't know if it is beneficial to run LFS at a faster rate or not, that would depend how the main loop pumps through the InSim/OutSim/OutGuage messages, it is possible letting LFS update freely could reduce lag, it is also possible that it doesn't matter after say 60 or 100fps.
On the AIRS side it will allow the updating of the virtual controller more often and running the logic with smoother data, actually the prediction sensor is actually smooth! That is the first time I've seen that smooth since I first wrote it and made that video. Shortly after (I think it was adding the visual sensor?) the performance dipped and it has been jumping around ever sense.
I may rip out the visual sensor and just give the AI driver his position directly, even though that went against my initial intentions, I know now that he could (if needed) compute this by the visual reference points, although with the extra horsepower this PC has, do I need to do that?
I'm still trying to get the project working on the updated framework, it would make some things a bit easier to deal with and would fix some issues that have been fixed with the framework, but, currently having an issue getting the terrain mesh, and other meshes, rendered to the scene. That and the whole steering issue that occurred somewhere during that update, wtf?
EDIT:
In the project with the updated framework, I finally got the car and track visible again. But I am still chasing the steering issue. The good news is, like before, version control system allows me to check out every different line of code. Unfortunately, a lot of lines changed for the update, so time to hunt down the one that cause the issue.
EDIT2: I claim rendering was working, but the car doesn't rotate correctly, yay. :-(
EDIT3: HECK YEA! WOOT. Got it figured out, and glad my brain had a moment to put 1 and 2 together. Going through every code change would NEVER have found the issue. The issue was a fundamental change months ago in my math framework to use degrees for _all_ rotations, and it had previously used radians for some rotations that were untouched in airs code. Would have looked right over it. Turns out, both issues were the same thing, basically the driver didn't know the direction he was facing because the car transform was a little wonky. All working now with the latest version of the framework, woot!
Last edited by blackbird04217, .
I'm going to try sharing the password again with those that stay tuned with the thread and understand the project a bit: airs but I will have to change it if I find that people join and mess up the driver/testing. That didn't happen last time so, lets hope it continues!
Password is: airs
If it is ever something different, I'm probably busy testing something else or something that is failing in a way that I don't want other users interfering with.
I am currently developing on the PC so the driver is not running at this very second.
Password is: airs
If it is ever something different, I'm probably busy testing something else or something that is failing in a way that I don't want other users interfering with.
I am currently developing on the PC so the driver is not running at this very second.
Strange, patch Z, I think it was seemed to work flawlessly on Windows 10 before I had updated, so if nothing changed there, let me run more tests and get back to you, maybe something was just failing to save in the config or some other oddity going on.
Nacim, I believe the issue there is actually going to wind up my fault, and something I will take a look at later tonight when I get out of work. I believe the issue is with AIRS spamming insim with messages. I could be wrong, but after some players left the server, the tcp errors I was seeing went away completely and others reported the lag got better. I am almost certainly doing something stupid in there, and I had fixed it once, but I bet I used a frame counter that was frame based and so the problem came back once things ran faster.
Though the clipping thing is something I've seen, rarely in the years I've spent playing in LFS and is not new to this test patch.
Doh, I had set a password on it from previous issues with people messing with the driver when I was away. I've taken it off for now although have to work, so even though the driver is lapping, I'm not really around the server anymore, but the drive is lapping.
There were some complaints the server is laggy, sorry it runs on my PC, although my connection usually streams and races just fine. I suspect there is some issue with my insim message handling / sending. It appears I am getting quite a few TCP errors from it. I suppose this is made more of an issue due to the faster speeds things can run with the new PC, however I had also thought I addressed the issue (could have done so very hackily, likely).
Anyways, seems the driver can do laps again, so that is step one. Step two will be getting things updated to the latest version of my framework, although, honestly, I might skip this. Not sure there is any real reason besides "it would be really nice" to do it. Not sure what I have planned after that.
There were some complaints the server is laggy, sorry it runs on my PC, although my connection usually streams and races just fine. I suspect there is some issue with my insim message handling / sending. It appears I am getting quite a few TCP errors from it. I suppose this is made more of an issue due to the faster speeds things can run with the new PC, however I had also thought I addressed the issue (could have done so very hackily, likely).
Anyways, seems the driver can do laps again, so that is step one. Step two will be getting things updated to the latest version of my framework, although, honestly, I might skip this. Not sure there is any real reason besides "it would be really nice" to do it. Not sure what I have planned after that.
I have, sort of, got something working again. It amazes me how often going backwards allows forward progress. Essentially I undid all changes I tried yesterday with exception of the vJoy interface updates (which were required) and things worked, reasonably well. The driver seems to spin out on FE1, and I don't remember him doing that, but he was able to make it around a few laps. I am not sure why the driver was unable to drive correctly when I had attempted to update to the latest version of my framework, but I must have done something silly in updating that?
I am now trying to get the server setup again. Which means adding all the port forwarding settings, and even, updating LFS. I have now done both of those, but still can't see my server on the master server.
If anyone can try to join, you might be able to find the server or driver:
Server: SRS:TestingGrounds
Driver: airs_artificial_driver
It might not be found at present time, as I'm still trying to get it working again.
I am now trying to get the server setup again. Which means adding all the port forwarding settings, and even, updating LFS. I have now done both of those, but still can't see my server on the master server.
If anyone can try to join, you might be able to find the server or driver:
Server: SRS:TestingGrounds
Driver: airs_artificial_driver
It might not be found at present time, as I'm still trying to get it working again.
Last edited by blackbird04217, .
This is what I get for not following test patches regularly enough.
I'm trying to run 0.6K and will download/install a test patch shortly to see if it is fixed but, in 0.6K I can't position a window with negative coordinates any more. Which means I can't start up LFS on the monitor I want, it seems to default to a config when ever negative position is used for window position in config.
I'm trying to run 0.6K and will download/install a test patch shortly to see if it is fixed but, in 0.6K I can't position a window with negative coordinates any more. Which means I can't start up LFS on the monitor I want, it seems to default to a config when ever negative position is used for window position in config.
Well this concludes the attempt to get the driver running again, at least for the moment. Unfortunately I end with defeat. The terrain, car and other meshs are not renderering, but at the very least I have my visualizations of what the driver things is happening.
Good news, everything there seems to be working as expected.
Bad news, what the hell is with the steering? The driver use to be precise, and get around the lap. I have to assume something with a bad calibration or something of the steering axis lead to this? I've tried multiple cars and settings, attempted to change the steering wheel angle in LFS (although my script was setting this to a specific value so I don't think that should change).
In other words: The driver does not get around a lap anymore. He is lucky to make it beyond the FE pit wall.
Good news, everything there seems to be working as expected.
Bad news, what the hell is with the steering? The driver use to be precise, and get around the lap. I have to assume something with a bad calibration or something of the steering axis lead to this? I've tried multiple cars and settings, attempted to change the steering wheel angle in LFS (although my script was setting this to a specific value so I don't think that should change).
In other words: The driver does not get around a lap anymore. He is lucky to make it beyond the FE pit wall.
Last edited by blackbird04217, .
I remember now why I will never be able to actually release this program for others to use, you know, beyond the other obvious effects of people abusing it in some way or another.
Setting up the virtual controller, and configuring it is the biggest pain in the *** ever. I've been fiddling with it for the last two hours. Still looking at a black screen, so that kinda sucks too. I left the project alone for too long it seems, I will get it working again, but it is being a pain.
Later
Well, finally I got beyond that issue. However, many MANY more hurdles still exist. Seems the drive can start as expected, but doesn't actually drive as expected.
Even Later
So after re-calibrating about 15 more times I finally figured out that I had a script that was resetting the buttons, now that the script is set I can now close and restart LFS(for airs) without worry about reconfiguring again. Unfortunately, it seems the steering is -WAY WAY OFF-. But before I can handle that, I need to get the airs visuals back up. Something with the framework updates have really screwed over what I have going on, so ... I don't know what happened but I may need to update all the rendering code of airs from legacy OpenGL to use OpenGL 3.2 (shaders). I have most of the pieces I need, it will just be a matter of ripping the old and replacing with new, but it will take a bit of time. I was actually expecting to see visuals at this point, but I have a wonderful [i]empty black screen[/b] instead. Almost.
Once the empty visuals is fixed it may require completely retuning all the steering functions. Each of the drivers actions seem to be working except when the driver is attempting to "Drive" he seems to turn the wheel way more violently than before, hard to say without other visuals, but I fear the values I am using were calibrated for a different wheel calibration, like maybe the steering axis didn't use the full range before. I hope I'm wrong and the visuals show me something silly.
Setting up the virtual controller, and configuring it is the biggest pain in the *** ever. I've been fiddling with it for the last two hours. Still looking at a black screen, so that kinda sucks too. I left the project alone for too long it seems, I will get it working again, but it is being a pain.
Later
Well, finally I got beyond that issue. However, many MANY more hurdles still exist. Seems the drive can start as expected, but doesn't actually drive as expected.
Even Later
So after re-calibrating about 15 more times I finally figured out that I had a script that was resetting the buttons, now that the script is set I can now close and restart LFS(for airs) without worry about reconfiguring again. Unfortunately, it seems the steering is -WAY WAY OFF-. But before I can handle that, I need to get the airs visuals back up. Something with the framework updates have really screwed over what I have going on, so ... I don't know what happened but I may need to update all the rendering code of airs from legacy OpenGL to use OpenGL 3.2 (shaders). I have most of the pieces I need, it will just be a matter of ripping the old and replacing with new, but it will take a bit of time. I was actually expecting to see visuals at this point, but I have a wonderful [i]empty black screen[/b] instead. Almost.
Once the empty visuals is fixed it may require completely retuning all the steering functions. Each of the drivers actions seem to be working except when the driver is attempting to "Drive" he seems to turn the wheel way more violently than before, hard to say without other visuals, but I fear the values I am using were calibrated for a different wheel calibration, like maybe the steering axis didn't use the full range before. I hope I'm wrong and the visuals show me something silly.
Last edited by blackbird04217, .
Well.
That didn't work.
I decided to see if I could take a break from work to at least get the airs_driver doing some laps. The answer, no.
It would seem that updating from VS2010 to VS2015 changes enough things to be a pain in the butt. First my debug output seems to be redirected on me for some reason or another, ie, the console is not outputting any of my text. Yay. Second there seems to be a crash. Now, I know I didn't leave the project in a crashing state, although it is very likely in an undesirable state with Driver Logic v2, but now it seems I crash, deep in an unhelpful stack which my only guess is something graphics related nVidia / OpenGL.
I wasn't able to look to far into it, but it is already a steeper hill to climb than I was expecting. I will also need to update the project to use the latest version of TurtleBrains, and since it is using revision #123 and needs to be updated to #478, there are a few changes to make, more than I was able to do in a quick "just get it working" break.
So for now, back to work for me, and a little depressed things didn't "just work". I know when I left the project it was in working condition, but I have since built a new PC and updated the development process slightly.
Thanks for the call out nacim, glad to know others are still interested in my on again/off again project that is the artificial driver!
That didn't work.
I decided to see if I could take a break from work to at least get the airs_driver doing some laps. The answer, no.
It would seem that updating from VS2010 to VS2015 changes enough things to be a pain in the butt. First my debug output seems to be redirected on me for some reason or another, ie, the console is not outputting any of my text. Yay. Second there seems to be a crash. Now, I know I didn't leave the project in a crashing state, although it is very likely in an undesirable state with Driver Logic v2, but now it seems I crash, deep in an unhelpful stack which my only guess is something graphics related nVidia / OpenGL.
I wasn't able to look to far into it, but it is already a steeper hill to climb than I was expecting. I will also need to update the project to use the latest version of TurtleBrains, and since it is using revision #123 and needs to be updated to #478, there are a few changes to make, more than I was able to do in a quick "just get it working" break.
So for now, back to work for me, and a little depressed things didn't "just work". I know when I left the project it was in working condition, but I have since built a new PC and updated the development process slightly.
Thanks for the call out nacim, glad to know others are still interested in my on again/off again project that is the artificial driver!
Today I've booted up LFS again in quite some time. I still have not yet installed or configured the virtual controller, or got the AIRS driver running, but I did start a multi-class crash fest at FE1 to watch the LFS AI run each other over.
This is such an interesting problem space. How to teach the AI driver when to be aggressive and make a move, vs when to hold back. I still need to get him running his line properly, and I am hoping the new quad-core PC will have more horsepower to be more consistent. In order to move forward I will first need to move backwards to understand and fix the issues I created with Driver Logic v2, and possibly do some code cleanup and optimizations.
This is such an interesting problem space. How to teach the AI driver when to be aggressive and make a move, vs when to hold back. I still need to get him running his line properly, and I am hoping the new quad-core PC will have more horsepower to be more consistent. In order to move forward I will first need to move backwards to understand and fix the issues I created with Driver Logic v2, and possibly do some code cleanup and optimizations.
Another bump after long break. I have finally upgraded from my Core 2 Duo, and one of the things on this that had started holding this project back a bit was my old PC chugging while running LFS and AIRS together. I'm pretty confident this new PC would have no troubles at all. I have not installed the virtual controller yet, but I kinda would like to see if the driver is more consistent.
Still a bit low on steam as far as making more improvements though, that Driving Logic v2 with the modified brake points showed a lot of promise but it doesn't quite work properly, which has taken a lot of my energy away.
Still a bit low on steam as far as making more improvements though, that Driving Logic v2 with the modified brake points showed a lot of promise but it doesn't quite work properly, which has taken a lot of my energy away.
Yea, I haven't been running the server, project is currently in a holding pattern, but it will be back when I get some ideas, inspiration and motivation to work on it again. Just watch the thread and the server will be back someday. I am tempted to see what happens with the new Westhill configs, if the PTH and SMX files have been released yet.
I am losing a bit of steam on the project, Driving Logic v2 was not quite as successful as I had hoped and I'm not entirely sure it is worth spending a lot of time tuning. It shows great promise in some ways, as I was expecting, but when it comes to choosing defensive lines, or passing other cars the corner logic won't actually be as useful - although it is closer to what a human would use for reference points, so I am a little torn at the moment and that is causing my to lose momentum on the project.
I've been considering a hybrid of the original logic "follow this line" and the new logic (which still follows the same line except modifies the braking point and entry speed). If I went with this idea, I would use most of the initial code from Driving Logic v1 except that I would make a table of for the angles of the racing track and the safe, risky and very risky speeds at those angles as well as keep track of a safe, risky and very risky braking distance for various speeds. The trick would be getting the driver to build those tables in a manner that is actually safe.
DLv2 was meant to modify the braking point and entry speed only when very safe to do so, but it turned out much more challenging to program that logic than expected. Tuning it more would allow DLv2 to shine more brightly, but that will make it difficult to add passing lines and defensive lines at a later date, unless I restrict passing to the "straights" which I really would like to avoid, that is how the LFS AI currently work.
Just losing some energy, might be time to take another break and work on some other projects for now. Only time will tell though, what I can say is this project is not dead.
As for progress, today I spent a lot of time tracking down the reason for those strange steering issues and finally got to the bottom of it after at least 5 hours of digging. Immediately upon fixing the old, and extremely mysterious issue of driving 10 meters to the left of the line returned. I still don't understand how, but I reverted the code and then readded the changes and the issue was gone. This is extremely confusing to me, had he crossed the line constantly it would make more sense, but to follow the racing line exactly 10m on the outside of the track at all times is something that would need to be coded for, and the debug visuals all indicate he has the correct information... The issue has disappeared again, but it is pretty odd.
I've been considering a hybrid of the original logic "follow this line" and the new logic (which still follows the same line except modifies the braking point and entry speed). If I went with this idea, I would use most of the initial code from Driving Logic v1 except that I would make a table of for the angles of the racing track and the safe, risky and very risky speeds at those angles as well as keep track of a safe, risky and very risky braking distance for various speeds. The trick would be getting the driver to build those tables in a manner that is actually safe.
DLv2 was meant to modify the braking point and entry speed only when very safe to do so, but it turned out much more challenging to program that logic than expected. Tuning it more would allow DLv2 to shine more brightly, but that will make it difficult to add passing lines and defensive lines at a later date, unless I restrict passing to the "straights" which I really would like to avoid, that is how the LFS AI currently work.
Just losing some energy, might be time to take another break and work on some other projects for now. Only time will tell though, what I can say is this project is not dead.
As for progress, today I spent a lot of time tracking down the reason for those strange steering issues and finally got to the bottom of it after at least 5 hours of digging. Immediately upon fixing the old, and extremely mysterious issue of driving 10 meters to the left of the line returned. I still don't understand how, but I reverted the code and then readded the changes and the issue was gone. This is extremely confusing to me, had he crossed the line constantly it would make more sense, but to follow the racing line exactly 10m on the outside of the track at all times is something that would need to be coded for, and the debug visuals all indicate he has the correct information... The issue has disappeared again, but it is pretty odd.
Well, I have implemented the basics of Driving Logic v2 and I am both pretty impressed with what happens and at the same time quite saddened. I've got the driver modifying the braking and entry points, I can go into detail about this if anyone cares to note, it is similar to what I laid out for a plan, although slightly different.
The first lap the driver is extremely cautious with a time of 1:40ish on the first lap and 1:27ish on the second lap. Each corner entry speed is set to a grandma speed of 30 mph, and braking distances are much longer than needed. The driver checks his limit values (need to get understeer working) and will modify the speed as he see's fit. After 5 laps though the speeds and braking points have been modified and he is already in the 1:09s and steadily improving by a second or more a lap, which is pretty neat to watch.
However he isn't modifying his entry speed as safely as I'd like. I've tried a few times to make it be safe and yet he keeps failing at the tight right hand turn before the final chicane/turn complex. I've just modified something else that will hopefully help (he waits until Corner Exit to modify entry speed now, whereas before he was modifying it during apex) but my hopes for this helping is actually pretty slim. I believe he will still find a point that he fails at, it may take longer, or may be a different point - although I suspect it will remain that same failure point (the right hander before the final chicane-turn complex).
It was quite interesting to see him figure out how to drive down to a 59.5x all based on modifying his speed/braking points. But I've lost a little hope in this algorithm because it will be very tricky to make it happen safely.
I've also lost a little hope because when I think about dodging traffic I'll need to modify a line, and although he follows the racing line fairly well, with the driving logic v2 it is more difficult to just modify the line I want him to drive and DLv1 was actually pretty good about following the line with no other information, so I could easily just modify the line and he would (theoretically) follow it just as well. However DLv1 is pretty well coded for the XRG which was something I tried to avoid but found pretty difficult. You want the driver to go fast, and that typically means adjusting values until he does it fast - but then those values don't work for other cars or setups.
Another let down of DLv2 was has been the realization that even once he gets one corner nice and fast, he will push it over the limit and adjust back to a slightly slower speed. I theorize that this will mean (if he was actually doing all corners safely all the time) that he would have very rare best laps and not drive nearly as consistent as the logic in DLv1. I could be wrong with that, but I believe it is what would happen.
I haven't yet tried him with a new car in DLv2 but I suspect that is where that logic will shine - particularly with the cars with slick tires since he feels the limits much better (minus understeering). I'll give that a go as soon as I finish running his current test. 14 laps in and he just did a 1:01.19.
Sad to say but that odd turning glitch seems to have gotten worse. Maybe I just need to restart LFS at this point to fix it, I searched for potential issues and was unable to find something that looked to be a cause.
EDIT: The last changes (including entry phase and apex phase) helped stabilize him in the mid 58 to mid 59s, with a more inconsistent laptime as I was expecting, but at least he could continue driving. I stopped him at 30 laps so I could test a different car. Results for the a different car will be coming soon.
As expected the DLv2 really REALLY shines when it comes to driving the other cars and learning their braking points, this does actually give me some more encouragement but I certainly need to rethink how to go about things, the new driving logic has taken at least 10 seconds off the artificial_drivers personal best time in the FOX, something that would not have been capable with DLv1 without retuning the entire logic. So this gives me some hope, but DLv2 has a long ways to go still.
The first lap the driver is extremely cautious with a time of 1:40ish on the first lap and 1:27ish on the second lap. Each corner entry speed is set to a grandma speed of 30 mph, and braking distances are much longer than needed. The driver checks his limit values (need to get understeer working) and will modify the speed as he see's fit. After 5 laps though the speeds and braking points have been modified and he is already in the 1:09s and steadily improving by a second or more a lap, which is pretty neat to watch.
However he isn't modifying his entry speed as safely as I'd like. I've tried a few times to make it be safe and yet he keeps failing at the tight right hand turn before the final chicane/turn complex. I've just modified something else that will hopefully help (he waits until Corner Exit to modify entry speed now, whereas before he was modifying it during apex) but my hopes for this helping is actually pretty slim. I believe he will still find a point that he fails at, it may take longer, or may be a different point - although I suspect it will remain that same failure point (the right hander before the final chicane-turn complex).
It was quite interesting to see him figure out how to drive down to a 59.5x all based on modifying his speed/braking points. But I've lost a little hope in this algorithm because it will be very tricky to make it happen safely.
I've also lost a little hope because when I think about dodging traffic I'll need to modify a line, and although he follows the racing line fairly well, with the driving logic v2 it is more difficult to just modify the line I want him to drive and DLv1 was actually pretty good about following the line with no other information, so I could easily just modify the line and he would (theoretically) follow it just as well. However DLv1 is pretty well coded for the XRG which was something I tried to avoid but found pretty difficult. You want the driver to go fast, and that typically means adjusting values until he does it fast - but then those values don't work for other cars or setups.
Another let down of DLv2 was has been the realization that even once he gets one corner nice and fast, he will push it over the limit and adjust back to a slightly slower speed. I theorize that this will mean (if he was actually doing all corners safely all the time) that he would have very rare best laps and not drive nearly as consistent as the logic in DLv1. I could be wrong with that, but I believe it is what would happen.
I haven't yet tried him with a new car in DLv2 but I suspect that is where that logic will shine - particularly with the cars with slick tires since he feels the limits much better (minus understeering). I'll give that a go as soon as I finish running his current test. 14 laps in and he just did a 1:01.19.
Sad to say but that odd turning glitch seems to have gotten worse. Maybe I just need to restart LFS at this point to fix it, I searched for potential issues and was unable to find something that looked to be a cause.
EDIT: The last changes (including entry phase and apex phase) helped stabilize him in the mid 58 to mid 59s, with a more inconsistent laptime as I was expecting, but at least he could continue driving. I stopped him at 30 laps so I could test a different car. Results for the a different car will be coming soon.
As expected the DLv2 really REALLY shines when it comes to driving the other cars and learning their braking points, this does actually give me some more encouragement but I certainly need to rethink how to go about things, the new driving logic has taken at least 10 seconds off the artificial_drivers personal best time in the FOX, something that would not have been capable with DLv1 without retuning the entire logic. So this gives me some hope, but DLv2 has a long ways to go still.
Last edited by blackbird04217, .
Here is a quick replay of the airs_artificial_driver doing 5 laps at FE1 in the XRG with full fuel (still using Driving Logic v1)
EDIT: Added airs_artificial_driver doing 3 laps at FE1 with XRG with 2% fuel.
EDIT: Added airs_artificial_driver doing 3 laps at FE1 with XRG with 2% fuel.
Last edited by blackbird04217, .
I didn't get a chance to work on the project today or yesterday, but I haven't really written my updates for the progress of the night before. Which really wasn't that much progress, but I flattened out the angle detection for both steering input and throttle/brake logic.
Doing this for the steering logic allowed him to run at SO3, for some reason the height detector doesn't work as well as expected here. I will need to look into this issue to understand it better, but I fixed the AI logic by ignoring the Y axis (up in airs world) when detecting the angle he is trying to steer towards. This immediately helped him go around the track better, but his throttle/braking inputs were still using some angles that included the Y axis, so I modified those as well.
Someone noticed that I was happy when he broke into the 1:08's at SO2, but after making the throttle/braking changes he got down to min 1:07's! Which makes SO2 his best combination when compared to the WR times. This change didn't effect FE1 quite as much as I initially thought it would. I figured with the light elevation changes ignoring the height in the angle computation would have helped a little more, but the driver is still in the very low 58's, although he can also reach the very low 57's now and again. Almost like he gets lucky every now and again.
I've also noticed the steering issue michal 1279 pointed out happening a bit more often and leaving small rubber marks on the straight. I have an idea to check out, might be an issue if the angle between desiredDirection and forwardDirection is actually 0. I believe this might be the case because ignoring the Y value in the angle computation would increase the odds of this happening. I'll check that a bit later tonight, and hopefully he will stop scrubbing off his speed.
In the handful of laps I've had him do at SO2 it is obvious the fuel load plays more of a role in his lap times at this combo than it ever has at FE1, also after I changed the angle computation for throttle/braking, he started using more fuel.
Doing this for the steering logic allowed him to run at SO3, for some reason the height detector doesn't work as well as expected here. I will need to look into this issue to understand it better, but I fixed the AI logic by ignoring the Y axis (up in airs world) when detecting the angle he is trying to steer towards. This immediately helped him go around the track better, but his throttle/braking inputs were still using some angles that included the Y axis, so I modified those as well.
Someone noticed that I was happy when he broke into the 1:08's at SO2, but after making the throttle/braking changes he got down to min 1:07's! Which makes SO2 his best combination when compared to the WR times. This change didn't effect FE1 quite as much as I initially thought it would. I figured with the light elevation changes ignoring the height in the angle computation would have helped a little more, but the driver is still in the very low 58's, although he can also reach the very low 57's now and again. Almost like he gets lucky every now and again.
I've also noticed the steering issue michal 1279 pointed out happening a bit more often and leaving small rubber marks on the straight. I have an idea to check out, might be an issue if the angle between desiredDirection and forwardDirection is actually 0. I believe this might be the case because ignoring the Y value in the angle computation would increase the odds of this happening. I'll check that a bit later tonight, and hopefully he will stop scrubbing off his speed.
In the handful of laps I've had him do at SO2 it is obvious the fuel load plays more of a role in his lap times at this combo than it ever has at FE1, also after I changed the angle computation for throttle/braking, he started using more fuel.
Last edited by blackbird04217, .
I've taken time now and again attempting to get the driver to successfully drive at other tracks without too much luck, until now! I've finally got him driving another track without issue.
BL1 - he falls off at the end of the straight, doesn't brake in time.
WE1 - he falls off at the chicane, not braking in time and understeering.
AS2 - is a mess with understeer and sometimes touching grass into oversteer.
SO1 - Mostly works but he understeers into walls for some help, damaging the car.
SO2 - Now works pretty well. He kisses one wall trying to take a corner too sharp.
There are still several tracks that I can't test, so I might work on the track processors some more. Actually as of 15 minutes ago SO2 didn't even work. The track processors would fail because the point it started iterating through the track was not considered a straight and the algorithm didn't look for a straight, it just failed. I made it look for a straight and continue again and now SO2 is working.
michal 1279 sparked this interest in new tracks again when he had mentioned that FE3 is pretty similar to FE1, sharing about half the track. I let the track processors use the PTH file and it did work but currently there is an issue with bridges, even if the track doesn't go over the bridge. The racing line height needs to be set to the height of the track and to do this I have a function to compute the heights at each point. It takes a vertical line that is pretty high and pretty low and tests each triangle for collision until it finds one. The algorithm does not continue looking after the first collision. So if a bridge is involved sometimes it will grab high, and sometimes it will grab low.
This was noticed awhile back at AS2, the artificial driver would try steering incorrectly as he passed under the bridge before turn 1. I've had plans to fix it but haven't really paid much attention to it, I think I'll give an attempt at fixing this issue shortly, because with it fixed the driver could theoretically drive FE3 without an issue. I used keyboard input to get him across the bridge and he seemed to do the rest of the track pretty good. The question would be if he brakes properly after the bridge, because that builds up quite a bit of speed and it could be a potential area for him to fall off the track.
In letting him run at FE3 I noticed the corner detectors could use a little work too. I'm not sure how or what I want to do with them, but it seemed obvious to me that the right/left/left/right should not be considered a single corner. It also makes sense on FE1 that the back "straight" becomes some form of corner, even if it doesn't need much braking it may need to be considered a corner in some manner.
Regarding the corner processing there are still a handful of other known issues, such as for KY1 the turns are so subtle that the processor considers them "straights" which causes it not to work and doesn't allow the driver to run on the track - he needs to know about the corners to drive there, certainly will need to once DLv2 gets implemented.
Another issue with the corner processing is finding the apex location, sometimes it doesn't do so well at placing the apex where it makes sense, sometimes it fails to place it at all which is even worse but a known edge case I've left strangling for now. The current logic for finding the apex is to start at the corner exit and work backwards toward the corner entry until the distance to the inside of the corner starts increasing. If the corner entry is found before the increase starts no apex was found.
Now that I've fixed the start straight issue and I see him driving at SO2 I wonder what other SO tracks he might be able to do. I know he doesn't do so well going through the chicane like in SO1, (I haven't tried SO1R), and I wonder if he would like turning up the hill after coming down like in SO5? I'll let him run some more laps, so far SO2 seems to be his best track, best being the closest to the WR time.
---
In one of those why "why does that need to be ..." moments I figured an easier way to fix the steering logic. Why does the steering logic need to care about the height of the racing line, or car? No amount of steering control will fix a difference in height. So I simply set the Y values to zero before doing the steering logic computations and voila the problem has been solved without the need to normalize the heights for bridges and such! For some reason I thought I had done this already but it appears I had not. It would still be nice to normalize the points just so that the AIRS debug visuals make sense, but now the driver doesn't need this for driving. For some reason I'm yet to figure out the racing line at SO3 doesn't really like to work at the top of the hill, it seems to be far under the track, and this is what prompted my thought. So now it works, and in theory should also work at FE3... Just a note, a third drivable track for the airs_artificial_driver in the XRG has become SO3. A few taps through the chicane for turning too tightly, but not enough for damage.
BL1 - he falls off at the end of the straight, doesn't brake in time.
WE1 - he falls off at the chicane, not braking in time and understeering.
AS2 - is a mess with understeer and sometimes touching grass into oversteer.
SO1 - Mostly works but he understeers into walls for some help, damaging the car.
SO2 - Now works pretty well. He kisses one wall trying to take a corner too sharp.
There are still several tracks that I can't test, so I might work on the track processors some more. Actually as of 15 minutes ago SO2 didn't even work. The track processors would fail because the point it started iterating through the track was not considered a straight and the algorithm didn't look for a straight, it just failed. I made it look for a straight and continue again and now SO2 is working.
michal 1279 sparked this interest in new tracks again when he had mentioned that FE3 is pretty similar to FE1, sharing about half the track. I let the track processors use the PTH file and it did work but currently there is an issue with bridges, even if the track doesn't go over the bridge. The racing line height needs to be set to the height of the track and to do this I have a function to compute the heights at each point. It takes a vertical line that is pretty high and pretty low and tests each triangle for collision until it finds one. The algorithm does not continue looking after the first collision. So if a bridge is involved sometimes it will grab high, and sometimes it will grab low.
This was noticed awhile back at AS2, the artificial driver would try steering incorrectly as he passed under the bridge before turn 1. I've had plans to fix it but haven't really paid much attention to it, I think I'll give an attempt at fixing this issue shortly, because with it fixed the driver could theoretically drive FE3 without an issue. I used keyboard input to get him across the bridge and he seemed to do the rest of the track pretty good. The question would be if he brakes properly after the bridge, because that builds up quite a bit of speed and it could be a potential area for him to fall off the track.
In letting him run at FE3 I noticed the corner detectors could use a little work too. I'm not sure how or what I want to do with them, but it seemed obvious to me that the right/left/left/right should not be considered a single corner. It also makes sense on FE1 that the back "straight" becomes some form of corner, even if it doesn't need much braking it may need to be considered a corner in some manner.
Regarding the corner processing there are still a handful of other known issues, such as for KY1 the turns are so subtle that the processor considers them "straights" which causes it not to work and doesn't allow the driver to run on the track - he needs to know about the corners to drive there, certainly will need to once DLv2 gets implemented.
Another issue with the corner processing is finding the apex location, sometimes it doesn't do so well at placing the apex where it makes sense, sometimes it fails to place it at all which is even worse but a known edge case I've left strangling for now. The current logic for finding the apex is to start at the corner exit and work backwards toward the corner entry until the distance to the inside of the corner starts increasing. If the corner entry is found before the increase starts no apex was found.
Now that I've fixed the start straight issue and I see him driving at SO2 I wonder what other SO tracks he might be able to do. I know he doesn't do so well going through the chicane like in SO1, (I haven't tried SO1R), and I wonder if he would like turning up the hill after coming down like in SO5? I'll let him run some more laps, so far SO2 seems to be his best track, best being the closest to the WR time.
---
In one of those why "why does that need to be ..." moments I figured an easier way to fix the steering logic. Why does the steering logic need to care about the height of the racing line, or car? No amount of steering control will fix a difference in height. So I simply set the Y values to zero before doing the steering logic computations and voila the problem has been solved without the need to normalize the heights for bridges and such! For some reason I thought I had done this already but it appears I had not. It would still be nice to normalize the points just so that the AIRS debug visuals make sense, but now the driver doesn't need this for driving. For some reason I'm yet to figure out the racing line at SO3 doesn't really like to work at the top of the hill, it seems to be far under the track, and this is what prompted my thought. So now it works, and in theory should also work at FE3... Just a note, a third drivable track for the airs_artificial_driver in the XRG has become SO3. A few taps through the chicane for turning too tightly, but not enough for damage.
Last edited by blackbird04217, .
Interesting, I do see the issue but I don't know what caused it. Probably just over corrected a value momentarily with the steering logic.
For those wondering, the issue is found on the last turn of the last lap the artificial driver turns steering wheel full left for just a moment.
For those wondering, the issue is found on the last turn of the last lap the artificial driver turns steering wheel full left for just a moment.
I've been thinking about the project some more, go figure, and I'm not entirely sure how to proceed. Should I focus one 1 car? If I am going to focus on a single car I'm going to aim for the LX6, even though this entire time has been spent with the XRG. I am contemplating this because there is a fair bit of these little values that pop up fairly often that need to be tweaked for a particular car: shift points, limit detectors, desired steering points, etc. Even the speed at which throttle can be cranked up or off in certain situations.
An initial part of this project was to get the artificial driver to not require this tuning and fiddling, but I don't think that is possible. Every car has different powerbands, shifting points, and even steering changes. To go around a corner with a 100ft radius in the XRG might only take 15 degrees of steering wheel input, while the same 100ft radius turn in the FOX would take 25 degrees. To make matters worse, it is also greatly influenced by the setup.
So do I abandoned the approach, or start making a table of variables that need tuning for each car? When possible I hope to have the artificial driver figure out the value himself, and the entire project I have attempted to do this: shift points are determined by looking at torqueRPM and powerRPM as I've described several times.
---
Since I started driving logic 2.0 this weekend I've also been thinking a lot on how I want to implement this logic. I've already seen the driver modify his braking points and that is pretty damn amazing. I give him over cautious braking distances and corner entry speeds, so he will start very safe and slow. Then he approaches the turn and modifies the braking point because he reaches the entry speed and still has 100 meters of braking distance before the entry. Works perfectly!
Except when it doesn't. See if he keeps modifying his braking point just like that then after 15-16 laps or so he eventually modifies it too far, and this is not a good thing because then he typically falls off the corner. So my immediate thought was to keep several points of reference for the corners. At a minimum there would be the default, safe, and risky braking points, entry speeds and all other corner information about each corner. The idea being that default never changes, it is what originally got computed. Safe is the last known very safe distance/speed/information, and risky is the one that just changed.
The risky information becomes safe after some number of laps of safely making it through the corner without issue or really breaking the limits too far. That will be tricky to code. The unfortunate thing about this is it will slow down his learning by a significant amount. Luckily what I saw with the first tests modifying the braking distance it only took about 10 to 15 laps before he went from 1:17s to 1:06s with a fairly incomplete set of driving logic.
I need to find a balance. Just modifying the value each lap is unsafe but counting safe laps before modifying the value will slow his "learning" of the track. I don't like to think of this as him learning, because he isn't really learning anything, just modifying his information about the track.
---
The other thing I've been thinking about, related to focusing on a single car or not, is whether I should modify how the driver deals with corners. A few days ago I modified his steering behavior by changing one value, instantaneous drop of 1.25 seconds per lap in most cars, finally allowing him to get closer to the racing line he created. The idea is to follow some idea of "turn points", that would belong in the corner information. Each corner would have some number of these points, about 5 or 10, which would describe the location of the racing line. Instead of finding a point on the racing line 10 meters, 50 meters or 100 meters ahead of the car, the driver would look at those 5 or 10 turn points to know where the line is in that particular corner.
This would actually be a significant change, even though the desired behavior would be very similar. This change should keep him on the racing line, at least for the most part, but would do it in a different way.
If you think of turn one at FE1, and split it into 10 sections from the entry of the turn to the exit of the turn, each section crossing perpendicular to the racing line (maybe centerline) then each of these sections would be a "turn point". Each section would contain information like:
PositionOfRacingLine This is where the driver ultimately wants the car
LeftTrackEdge The furthest to the left of the track, no more space.
RightTrackEdge Ditto for the right edge.
AimingPoint A position that the driver uses to modify the steering behavior, this is the location he attempts to steer towards
With that information I could then later add more:
PositionOfDefensiveLine
PositionOfPassingLine
... etc ...
The primary idea here would be to have the driver modify the AimingPoint of each of these corner sections / points which should make it so I don't need to modify that steering value for each car, because in theory the driver would move the AimingPoint left/right depending on how close he was to the racing line when he crossed that section, making him turn more or less next lap(s) if he was far away.
This wouldn't be very hard to write, but it would take a fair bit of time to deal with. Along the lines of this idea would be to make the driver change his logic along a straight portion of track so that he goes straight for the entry point of the next corner. Unfortunately, some of the straights are not so straight, so that doesn't quite work and adds a bit more complexity that I really didn't want! I'm not entirely sure I will add this turn section/points logic to Driving Logic 2.0 or not, but I'm sharing my thoughts as I have them, as I always have.
An initial part of this project was to get the artificial driver to not require this tuning and fiddling, but I don't think that is possible. Every car has different powerbands, shifting points, and even steering changes. To go around a corner with a 100ft radius in the XRG might only take 15 degrees of steering wheel input, while the same 100ft radius turn in the FOX would take 25 degrees. To make matters worse, it is also greatly influenced by the setup.
So do I abandoned the approach, or start making a table of variables that need tuning for each car? When possible I hope to have the artificial driver figure out the value himself, and the entire project I have attempted to do this: shift points are determined by looking at torqueRPM and powerRPM as I've described several times.
---
Since I started driving logic 2.0 this weekend I've also been thinking a lot on how I want to implement this logic. I've already seen the driver modify his braking points and that is pretty damn amazing. I give him over cautious braking distances and corner entry speeds, so he will start very safe and slow. Then he approaches the turn and modifies the braking point because he reaches the entry speed and still has 100 meters of braking distance before the entry. Works perfectly!
Except when it doesn't. See if he keeps modifying his braking point just like that then after 15-16 laps or so he eventually modifies it too far, and this is not a good thing because then he typically falls off the corner. So my immediate thought was to keep several points of reference for the corners. At a minimum there would be the default, safe, and risky braking points, entry speeds and all other corner information about each corner. The idea being that default never changes, it is what originally got computed. Safe is the last known very safe distance/speed/information, and risky is the one that just changed.
The risky information becomes safe after some number of laps of safely making it through the corner without issue or really breaking the limits too far. That will be tricky to code. The unfortunate thing about this is it will slow down his learning by a significant amount. Luckily what I saw with the first tests modifying the braking distance it only took about 10 to 15 laps before he went from 1:17s to 1:06s with a fairly incomplete set of driving logic.
I need to find a balance. Just modifying the value each lap is unsafe but counting safe laps before modifying the value will slow his "learning" of the track. I don't like to think of this as him learning, because he isn't really learning anything, just modifying his information about the track.
---
The other thing I've been thinking about, related to focusing on a single car or not, is whether I should modify how the driver deals with corners. A few days ago I modified his steering behavior by changing one value, instantaneous drop of 1.25 seconds per lap in most cars, finally allowing him to get closer to the racing line he created. The idea is to follow some idea of "turn points", that would belong in the corner information. Each corner would have some number of these points, about 5 or 10, which would describe the location of the racing line. Instead of finding a point on the racing line 10 meters, 50 meters or 100 meters ahead of the car, the driver would look at those 5 or 10 turn points to know where the line is in that particular corner.
This would actually be a significant change, even though the desired behavior would be very similar. This change should keep him on the racing line, at least for the most part, but would do it in a different way.
If you think of turn one at FE1, and split it into 10 sections from the entry of the turn to the exit of the turn, each section crossing perpendicular to the racing line (maybe centerline) then each of these sections would be a "turn point". Each section would contain information like:
PositionOfRacingLine This is where the driver ultimately wants the car
LeftTrackEdge The furthest to the left of the track, no more space.
RightTrackEdge Ditto for the right edge.
AimingPoint A position that the driver uses to modify the steering behavior, this is the location he attempts to steer towards
With that information I could then later add more:
PositionOfDefensiveLine
PositionOfPassingLine
... etc ...
The primary idea here would be to have the driver modify the AimingPoint of each of these corner sections / points which should make it so I don't need to modify that steering value for each car, because in theory the driver would move the AimingPoint left/right depending on how close he was to the racing line when he crossed that section, making him turn more or less next lap(s) if he was far away.
This wouldn't be very hard to write, but it would take a fair bit of time to deal with. Along the lines of this idea would be to make the driver change his logic along a straight portion of track so that he goes straight for the entry point of the next corner. Unfortunately, some of the straights are not so straight, so that doesn't quite work and adds a bit more complexity that I really didn't want! I'm not entirely sure I will add this turn section/points logic to Driving Logic 2.0 or not, but I'm sharing my thoughts as I have them, as I always have.
Maybe I'll come back on a little later tonight but I think I'm done with my updates for today. I got the basic skeleton of the new Driver Logic going, and even have the driver modifying his brake points - although it is currently unsafe as he can (and does) modify the brake point to a point that he can no longer brake for the corner. He will eventually also modify corner entry speed as well, but for the proof of concept things are looking pretty good!
After running 10 to 15 laps with the new driving logic, modifying only brake points (by large values), he can bring his lap times from the 1:17s to 1:07s. I can't wait until this gets some more development, threshold braking and accelerating and - with any luck driving the corner closer to the limit.
I somewhat feel I've rushed into the new logic though, and that more planning should have taken place because I'm literally just winging it right now, with a "lets see what happens" attitude.
I'm going to leave him running with the old driver logic for the time being so he can do more consistent laps without failing.
After running 10 to 15 laps with the new driving logic, modifying only brake points (by large values), he can bring his lap times from the 1:17s to 1:07s. I can't wait until this gets some more development, threshold braking and accelerating and - with any luck driving the corner closer to the limit.
I somewhat feel I've rushed into the new logic though, and that more planning should have taken place because I'm literally just winging it right now, with a "lets see what happens" attitude.
I'm going to leave him running with the old driver logic for the time being so he can do more consistent laps without failing.
@keling The motionDirection I use is what the actual movement of the cars CG so it would remain 0,0,0 if the car was just rotating in place, and would only be the direction of the linear velocity otherwise. I do get what you are saying, a point on the front bumper of the car will be moving differently than a point on the rear bumper when the car is rotating, if the rotation is fast enough compared to linear motion they would even move in opposite directions.
The Z-Axis in LFS is the Up, so that would be the yaw rotation you are talking about. I don't have any real proof to this either but I would certainly agree this rotation is the real "seat of the pants" feeling one has for detecting the behavior of the car. I am sure the longitudinal and lateral forces also play a fair amount for seat of pants feeling, but probably none is as important at that yaw acceleration.
---
Yesterday and last night progress was a bit slower than it has been. I struggled most of the day with the understeer detector before finally giving up on that. It took a while to get back into the swing of things, I went racing online for a whole 2 races of... wow. It isn't what it used to be.
After finally getting back into the code I decided to modify the shift point code. I made the code much more readable/maintainable than it was before and adjusted both the downshift and upshift points, at least for the XRG. However I still need to come up with a new algorithm for this, as the power range is too different for each car. XRG now shifts at 3700 to 6500 rpm. The UF1 still doesn't downshift because the way this calculation is done. I noticed on the FZ5 (I think) that the upshift point is well above redline, although there is some redline protection in the shifting logic to shift anyway.
For now the shifting logic remains what I wrote before, which essentially computes the range from maximumTorqueSpeed to maximumEngineSpeed and takes a little extra on both sides. (Consider maximumTorqueSpeed to be 0, and maximumEngineSpeed to be 1, the shifting points are -0.5 and 1.35). The obvious flaw here is some cars have a really wide range for this, and -0.5 in the UF1 places the downshift point at like 1500 rpm, same with the upshift point for the FZ5... Some cars, like the XRG, have a smaller range. In any situation the logic needs work in the future, suffice to say I modified the shifting points.
Making that change got me wondering if I could be smarter about the braking logic. The current turning/throttle/braking logic works on several values, these values represent the angle of the racing track at different locations: nearAngle, soonAngle, farAngle and farFarAngle. The farAngle and farFarAngle were introduced to get the driver to brake for T1 after speeding down the straight. nearAngle is the angle of the racing-line where the driver is aimed at driving at the given moment, and soonAngle is some distance in front of that.
I simply adjusted the speeds set for nearAngle and soonAngle, since he goes a little too slowly in the corners, and left the farAngle and farFarAngle speeds the same. This actually dramatically decreased his lap times for the better. With the new corner logic, I also decided to make him not hit the brakes after corner exit, which he would do on some occasions. This made him faster still, although that depends on the car because in some of the higher powered RWD cars he actually invokes too much wheel spin.
After these changes I saw him do a 58.21. It got me really excited, but he still doesn't modify his braking point or entry speed which would really help him speed up, I think. Theoretically it should after several laps anyway. I am still reserved about having the driver 'learn' the track and change his own behavior, but doing it with the reference points and modifying braking point / entry speed seems like a reasonable thought to me because that is how we humans drive quickly.
So I got all pumped up and declared I'm just going to put the new driver logic together with ducktape (hack it up and see if it works) real quickly... And I did start to, but then fell into the trap that I was going to create a giant mess and it would be worse later on, so I moved all the corner logic into a corner manager and made it so the reference points for these corner phases can be moved. I even tested this by moving the braking point back on T1 and the apex back on T1 and T4 of FE1, and they moved as expected. Although the only points the AI currently use/care about is the apex, all others are ignored until driving logic 2.0.
The Z-Axis in LFS is the Up, so that would be the yaw rotation you are talking about. I don't have any real proof to this either but I would certainly agree this rotation is the real "seat of the pants" feeling one has for detecting the behavior of the car. I am sure the longitudinal and lateral forces also play a fair amount for seat of pants feeling, but probably none is as important at that yaw acceleration.
---
Yesterday and last night progress was a bit slower than it has been. I struggled most of the day with the understeer detector before finally giving up on that. It took a while to get back into the swing of things, I went racing online for a whole 2 races of... wow. It isn't what it used to be.
After finally getting back into the code I decided to modify the shift point code. I made the code much more readable/maintainable than it was before and adjusted both the downshift and upshift points, at least for the XRG. However I still need to come up with a new algorithm for this, as the power range is too different for each car. XRG now shifts at 3700 to 6500 rpm. The UF1 still doesn't downshift because the way this calculation is done. I noticed on the FZ5 (I think) that the upshift point is well above redline, although there is some redline protection in the shifting logic to shift anyway.
For now the shifting logic remains what I wrote before, which essentially computes the range from maximumTorqueSpeed to maximumEngineSpeed and takes a little extra on both sides. (Consider maximumTorqueSpeed to be 0, and maximumEngineSpeed to be 1, the shifting points are -0.5 and 1.35). The obvious flaw here is some cars have a really wide range for this, and -0.5 in the UF1 places the downshift point at like 1500 rpm, same with the upshift point for the FZ5... Some cars, like the XRG, have a smaller range. In any situation the logic needs work in the future, suffice to say I modified the shifting points.
Making that change got me wondering if I could be smarter about the braking logic. The current turning/throttle/braking logic works on several values, these values represent the angle of the racing track at different locations: nearAngle, soonAngle, farAngle and farFarAngle. The farAngle and farFarAngle were introduced to get the driver to brake for T1 after speeding down the straight. nearAngle is the angle of the racing-line where the driver is aimed at driving at the given moment, and soonAngle is some distance in front of that.
I simply adjusted the speeds set for nearAngle and soonAngle, since he goes a little too slowly in the corners, and left the farAngle and farFarAngle speeds the same. This actually dramatically decreased his lap times for the better. With the new corner logic, I also decided to make him not hit the brakes after corner exit, which he would do on some occasions. This made him faster still, although that depends on the car because in some of the higher powered RWD cars he actually invokes too much wheel spin.
After these changes I saw him do a 58.21. It got me really excited, but he still doesn't modify his braking point or entry speed which would really help him speed up, I think. Theoretically it should after several laps anyway. I am still reserved about having the driver 'learn' the track and change his own behavior, but doing it with the reference points and modifying braking point / entry speed seems like a reasonable thought to me because that is how we humans drive quickly.
So I got all pumped up and declared I'm just going to put the new driver logic together with ducktape (hack it up and see if it works) real quickly... And I did start to, but then fell into the trap that I was going to create a giant mess and it would be worse later on, so I moved all the corner logic into a corner manager and made it so the reference points for these corner phases can be moved. I even tested this by moving the braking point back on T1 and the apex back on T1 and T4 of FE1, and they moved as expected. Although the only points the AI currently use/care about is the apex, all others are ignored until driving logic 2.0.
I have spent a fair bit of the day trying to find a way to get a number from 0 to N that detects the understeer limit of the car but so far I have been unsuccessful at this task. Too many factors change too many things when it comes to understeering. For instance I had the thought to use the angle between the facingDirection and motionDirection, much like I would be computing oversteer. But compare this angle to what I would expect it to be with certain steering inputs to detect the understeer limit.
I was unable to get results I liked, even with a lot of tweaking, which would again only be useful for the XRG. I believe this is because speed also plays another factor in the understeer limit, more than just steering input and that angle between facing and motion direction. I then had the thought to try longitudinal force, but that force can be quite high, and actually will be just under the real turning limit, when understeering.
I'm taking the server down for a bit and going to do some races to see if some inspiration takes over. Otherwise I may just ignore the understeer limit detection for now, it might not be very important anyway.
I was unable to get results I liked, even with a lot of tweaking, which would again only be useful for the XRG. I believe this is because speed also plays another factor in the understeer limit, more than just steering input and that angle between facing and motion direction. I then had the thought to try longitudinal force, but that force can be quite high, and actually will be just under the real turning limit, when understeering.
I'm taking the server down for a bit and going to do some races to see if some inspiration takes over. Otherwise I may just ignore the understeer limit detection for now, it might not be very important anyway.
I just modified his XRG setup a little bit, I had modified it last night for the Braking limit detection (had to increase the braking force per wheel and shift the braking balance toward the rear (drive wheels). When I came back I noticed the best lap of 240 laps was 1.00.40 (or maybe even 1:01.40 ... which led me to thinking what would happen if I reduced his braking forces ...
Well, he set a new personal best of 59.07 on this set with about 100Nm less braking force than the original set. This makes sense when you add the fact that he was fastest in the FZ5 because it didn't brake as well. Of course this will all change when I get the new driver logic in, I hope to have him complete his braking in the braking zone, and accelerate after the apex, leaving the corner entry for minimal braking/acceleration changes.
I'm really looking forward to that new logic, just want all the pieces ready and to put in some valuable thought before starting it. Hopefully the laptimes will improve further, but it could get worse. My plan is to have him start with ultra safe braking distances and entry speeds, and have him slowly work on entering the corner faster and decreasing the braking distance.
Well, he set a new personal best of 59.07 on this set with about 100Nm less braking force than the original set. This makes sense when you add the fact that he was fastest in the FZ5 because it didn't brake as well. Of course this will all change when I get the new driver logic in, I hope to have him complete his braking in the braking zone, and accelerate after the apex, leaving the corner entry for minimal braking/acceleration changes.
I'm really looking forward to that new logic, just want all the pieces ready and to put in some valuable thought before starting it. Hopefully the laptimes will improve further, but it could get worse. My plan is to have him start with ultra safe braking distances and entry speeds, and have him slowly work on entering the corner faster and decreasing the braking distance.
FGED GREDG RDFGDR GSFDG