Whoops. It came to my attention that last year when I changed gears I didn't actually mention anything in this thread. The Artificial Intelligence in Racing Simulations project is not dead, but I am taking an extended break from it (clearly, already been away for 8 months).
The project is something I'm still genuinely interested in and wanting to return to, but I've come to the conclusion that at present time working on it takes away from other goals and things I desire a tiny bit more; like building my own racing simulation and independent games.
I stream my work regularly and will continue streaming the work on AIRS when the time comes to return to it or take a break from other things. It isn't completely dead, I can still return to the code-base and work from it quite readily, but it doesn't move other goals forward.
Until then I'll keep it simmering. Sorry for the delay in letting everyone know this.
The project is something I'm still genuinely interested in and wanting to return to, but I've come to the conclusion that at present time working on it takes away from other goals and things I desire a tiny bit more; like building my own racing simulation and independent games.
I stream my work regularly and will continue streaming the work on AIRS when the time comes to return to it or take a break from other things. It isn't completely dead, I can still return to the code-base and work from it quite readily, but it doesn't move other goals forward.
Until then I'll keep it simmering. Sorry for the delay in letting everyone know this.
Yea, you are correct, The direction (X,Y,Z) is going to be a normalized vector in the direction the node is pointing. I don't know where exactly it is, but there was more documentation somewhere, probably InSim.h that probably explains a bit further.
To get rotation around a particular axis you could use that axis and a dot product with the direction vector. (1, 0, 0) dot (X, Y, Z). With normalized vectors this will give a result from -1 to 1 with 0 being perpendicular to the axis, and 1 or -1 being parallel.
To get rotation around a particular axis you could use that axis and a dot product with the direction vector. (1, 0, 0) dot (X, Y, Z). With normalized vectors this will give a result from -1 to 1 with 0 being perpendicular to the axis, and 1 or -1 being parallel.
Well, great news. After much thinking, and pondering, and deleting and rewriting from a fresh slate. It looks like I've got the corner phase tracking to work correctly with overlapped brake points. This means if there is a brake point in the midst of a corner prior to it, the driver will continue braking!
This was, as far as I'm aware, the reason the driver started failing at many tracks once Corner Detector v2 was written and used since CDv2 wound up created many more corners, some of them fairly close.
I already watched the driver mess around at FE1R and beat a PB in XFG.
Also I have completed the initial pass of data collection about cornering capabilities, though I still have not been able to process it just yet.
Tomorrow (Wednesday) night won't be making any progress as it is race night for me, which will be streamed starting around 5:15pm to likely around 9:00pm at www.twitch.tv/timbeaudet however I do have some good ideas and look forward to getting DLv3 started, which I keep talking about. There is still a fair bit of work before it can really get underway, and I already see the main challenge is going to be making the driver do any sort of speed.
The first component I'll be working on will be the RoutePlanner. In general this will be pointing directly at the racing line, but at first I'm going to set it to do some weird sine wave near the center line, or some other odd pattern just to; 1) prove it is actually dynamic, 2) watch the driver follow a different line to test the accuracy of the trajectory stuff.
Once the RoutePlanner is ready I think I will start on DLv3, but it will likely be limited to a super ridiculous speed, like 30-40mph, at least until I find a way to make the driver guess at the speed he needs to go at. There may be some useful code for a starting point in the old DLv1 stuff since that happened before corners were detected. I think the end goal will be creating a massive collection of data for various trajectories. Most of LFS tracks are super flat so this might work out fairly well. Another idea I have is to use the learned speeds from DLv2 as inputs. Essentially, DLv2 would become 'learning' mode, but then the driving logic would swap over to DLv3 for other modes. The risk here is that DLv2 uses angles to a point on the desired line, while I think DLv3 will be using the trajectory information.
---
Upon watching the driver there is also more room for improvement in his learning the corners of DLv2. If he winds up entering a corner over a limit, say slight oversteer from heavy braking, then he won't lift the corner speed- which could cause him to brake less and go faster through the whole corner. Not sure exactly what to do here, perhaps ignore the first moments after corner entry, much like I did for the trajectory data collection.
Thoughts. So many thoughts.
This was, as far as I'm aware, the reason the driver started failing at many tracks once Corner Detector v2 was written and used since CDv2 wound up created many more corners, some of them fairly close.
I already watched the driver mess around at FE1R and beat a PB in XFG.
Also I have completed the initial pass of data collection about cornering capabilities, though I still have not been able to process it just yet.
Tomorrow (Wednesday) night won't be making any progress as it is race night for me, which will be streamed starting around 5:15pm to likely around 9:00pm at www.twitch.tv/timbeaudet however I do have some good ideas and look forward to getting DLv3 started, which I keep talking about. There is still a fair bit of work before it can really get underway, and I already see the main challenge is going to be making the driver do any sort of speed.
The first component I'll be working on will be the RoutePlanner. In general this will be pointing directly at the racing line, but at first I'm going to set it to do some weird sine wave near the center line, or some other odd pattern just to; 1) prove it is actually dynamic, 2) watch the driver follow a different line to test the accuracy of the trajectory stuff.
Once the RoutePlanner is ready I think I will start on DLv3, but it will likely be limited to a super ridiculous speed, like 30-40mph, at least until I find a way to make the driver guess at the speed he needs to go at. There may be some useful code for a starting point in the old DLv1 stuff since that happened before corners were detected. I think the end goal will be creating a massive collection of data for various trajectories. Most of LFS tracks are super flat so this might work out fairly well. Another idea I have is to use the learned speeds from DLv2 as inputs. Essentially, DLv2 would become 'learning' mode, but then the driving logic would swap over to DLv3 for other modes. The risk here is that DLv2 uses angles to a point on the desired line, while I think DLv3 will be using the trajectory information.
---
Upon watching the driver there is also more room for improvement in his learning the corners of DLv2. If he winds up entering a corner over a limit, say slight oversteer from heavy braking, then he won't lift the corner speed- which could cause him to brake less and go faster through the whole corner. Not sure exactly what to do here, perhaps ignore the first moments after corner entry, much like I did for the trajectory data collection.
Thoughts. So many thoughts.
Sometimes the LFS PTH files are not the best solution for actual track edges, at AS7R, this blue line shows the left edge, about a meter into the grass;
No he has no concept of restrictions or weight/mass of the car. Actually he doesn't even know how much power the engine makes or the mass of the car at all right now, and I have considered giving this information to him in hopes he could make more informed decisions about how to approach throttle usage; for instance XRG you want to slam the throttle down and go for it, but the LX6, FO8 etc requires a little more, finesse.
That said, if he is in "learning" mode he will modify his corner memories; braking points and entry speed, and usually will start braking later or such if the car had less power, so in that sense he does recognize it.
That said, if he is in "learning" mode he will modify his corner memories; braking points and entry speed, and usually will start braking later or such if the car had less power, so in that sense he does recognize it.
Great news. I've got a super uncalibrated, untuned, poor example of the understeer detection unit working.
I've somewhat DETECTED UNDERSTEER for the drivers car!! This is something I had long written off as something that would never be added. It definitely requires a LOT more tuning and data processing. But it has appeared and it even slowed the driver when placed in a specific LX4 set that induced serious amounts of understeer, created by Michal.
Now to use this with the current driving logic will likely slow his times, maybe in a rare situation it could speed him up, not entirely sure, but it would help those corners which he just drives straight off track or far wide of his computed racing line, and that in itself would be worth it even if his personal best laps would be slightly slower using it.
----
That said, the overlapped braking point detection in the corner phase detector is a bit of a painful bug to fix, I may need to rewrite that code yet again, for the third or fourth time. Also added a few minor improvements like notifying the server when the driver is changing cars, tracks, admin assisted reset, and I fixed the issue that kept his last lap from being displayed - I'm sure I've forgot a few other minor additions.
I've put him into data collection for the final few cars. I say final few cars, but it is highly likely that more data gets collected for those points nearer the center position of the steering wheel. Also, for a click here for a very detailed report of everything I've done regarding Calibrating Car Cornering Capabilities I think it is presented a little better/neater than the bits scattered throughout the forum.
----
Another neat thought I've had, ever since modifying his shifting behavior to be faster off the clutch he has some issues in some cars with burning up the clutch. Actually it reminded me that I purposefully made it slow before because of that exact issue, however I don't really like want to undo those changes, although it would make him less likely to burn a clutch. I have a brilliant idea for collecting some data on the car that would actually allow the driver to know if he is slipping the clutch or not. A quick run down, put him in a car, have him accelerate through each gear slowly. Measuring / collecting data, go figure, on: speedometer/physical speed vs engine speed (rpm). Collect enough data to create a line that would be the expected values. If the engine speed is then above the rpm speed it should be for a given speedometer / physical car speed then the driver would know he is slipping the clutch and should release the throttle a bit.
Not sure I like that idea completely though I think it could work pretty good, it isn't really how you or I drive - although, I would tend to lift when "hearing" the slipping, so maybe it isn't such a bad idea? Thoughts on this matter? I probably won't jump on improving the clutch issue anytime soon, as I really want to get Driver Logic v3 started, I'm really excited about the prospect of following a line that is planned on the fly in an accurate fashion.
Thanks for reading, leave some comments about the shifting, and be sure to check out the link for the calibrating capabilities article if interested!
I've somewhat DETECTED UNDERSTEER for the drivers car!! This is something I had long written off as something that would never be added. It definitely requires a LOT more tuning and data processing. But it has appeared and it even slowed the driver when placed in a specific LX4 set that induced serious amounts of understeer, created by Michal.
Now to use this with the current driving logic will likely slow his times, maybe in a rare situation it could speed him up, not entirely sure, but it would help those corners which he just drives straight off track or far wide of his computed racing line, and that in itself would be worth it even if his personal best laps would be slightly slower using it.
----
That said, the overlapped braking point detection in the corner phase detector is a bit of a painful bug to fix, I may need to rewrite that code yet again, for the third or fourth time. Also added a few minor improvements like notifying the server when the driver is changing cars, tracks, admin assisted reset, and I fixed the issue that kept his last lap from being displayed - I'm sure I've forgot a few other minor additions.
I've put him into data collection for the final few cars. I say final few cars, but it is highly likely that more data gets collected for those points nearer the center position of the steering wheel. Also, for a click here for a very detailed report of everything I've done regarding Calibrating Car Cornering Capabilities I think it is presented a little better/neater than the bits scattered throughout the forum.
----
Another neat thought I've had, ever since modifying his shifting behavior to be faster off the clutch he has some issues in some cars with burning up the clutch. Actually it reminded me that I purposefully made it slow before because of that exact issue, however I don't really like want to undo those changes, although it would make him less likely to burn a clutch. I have a brilliant idea for collecting some data on the car that would actually allow the driver to know if he is slipping the clutch or not. A quick run down, put him in a car, have him accelerate through each gear slowly. Measuring / collecting data, go figure, on: speedometer/physical speed vs engine speed (rpm). Collect enough data to create a line that would be the expected values. If the engine speed is then above the rpm speed it should be for a given speedometer / physical car speed then the driver would know he is slipping the clutch and should release the throttle a bit.
Not sure I like that idea completely though I think it could work pretty good, it isn't really how you or I drive - although, I would tend to lift when "hearing" the slipping, so maybe it isn't such a bad idea? Thoughts on this matter? I probably won't jump on improving the clutch issue anytime soon, as I really want to get Driver Logic v3 started, I'm really excited about the prospect of following a line that is planned on the fly in an accurate fashion.
Thanks for reading, leave some comments about the shifting, and be sure to check out the link for the calibrating capabilities article if interested!
Auto Shift issue with spinning tires
I did a quick search and couldn't find this mentioned, I never knew about it until a player on my AI project server/stream mentioned it as I was attempting to fix some logic in how my AI driver handled shifting the car under wheel spin conditions. (Previously he would shift up because rpm matched)
--- back to bug ---
Enter LX6 (likely other cars, didn't test), and set Gear Mode to Auto, "eeewww"!
Press in the clutch and get the gear into first with sequential shifter, "aaaahhh"!
Floor the throttle, bounce off the rev limiter then drop the clutch.
Result: Transmission shifts to second, then drops back to first.
Expected: Transmission to remain in first.
Note: This won't reproduce if not bouncing off the rev limiter, even a few hundred RPM down seems to solve it. Pretty minor, but I hadn't seen it mentioned...
--- back to bug ---
Enter LX6 (likely other cars, didn't test), and set Gear Mode to Auto, "eeewww"!
Press in the clutch and get the gear into first with sequential shifter, "aaaahhh"!
Floor the throttle, bounce off the rev limiter then drop the clutch.
Result: Transmission shifts to second, then drops back to first.
Expected: Transmission to remain in first.
Note: This won't reproduce if not bouncing off the rev limiter, even a few hundred RPM down seems to solve it. Pretty minor, but I hadn't seen it mentioned...
Finally finished data collection on the BF1, I've put him into race mode while I work on a few things. May start a stream later, not sure. Come say hello on the server. 
Well, I'm not entirely sure what is happening - but his test run in the BF1 is extremely long. Luckily I don't actually have to worry about fuel like I initially thought. He does burn up the clutch a bit, but I'm not sure it will be something that has to be worried about. (It was about half red after >8 hours of testing). That bears repeating: GREATER THAN EIGHT (8) HOURS OF TESTING. Not sure what is going on that makes this one take so much longer, my theory is the limited steering lock means more tests get stopped by going to the edge, it seems to be what happens from my debug text.
So far, in greater than eight (8) hours of testing, he has collected data for 33 of 128 data points. That is, he is barely 25% complete. In theory he should get faster and faster since he should start reducing the frequency of ending tests by the edge (since his tests involve turning the steering wheel more). But I suspect he still has at least 4 or 5 hours left on the best case scenario.
Luckily fuel is not an issue, he still has 95%. I was expecting the BF1 to have an issue with fuel during this test because it is usually guzzles quickly. He doesn't use much throttle, maybe 6-8%, - not enough to get off the clutch more than 10%, hence the clutch issues. But like I said, after >8 hours of testing he still hadn't burned the clutch completely.
For now I'm letting him run in single player mode, since I think it would just be annoying to the community to join the server only to find he is being a complete moron, going super slowly and collecting data.
So far, in greater than eight (8) hours of testing, he has collected data for 33 of 128 data points. That is, he is barely 25% complete. In theory he should get faster and faster since he should start reducing the frequency of ending tests by the edge (since his tests involve turning the steering wheel more). But I suspect he still has at least 4 or 5 hours left on the best case scenario.
Luckily fuel is not an issue, he still has 95%. I was expecting the BF1 to have an issue with fuel during this test because it is usually guzzles quickly. He doesn't use much throttle, maybe 6-8%, - not enough to get off the clutch more than 10%, hence the clutch issues. But like I said, after >8 hours of testing he still hadn't burned the clutch completely.
For now I'm letting him run in single player mode, since I think it would just be annoying to the community to join the server only to find he is being a complete moron, going super slowly and collecting data.
Sorry guys, wasn't really able to do much streaming earlier today, wasn't feeling so well. Hopefully I will feel better tomorrow. I've noticed a lot of people had joined the server over the past few days and I've felt a bit bad not being around to answer questions and to have the driver remaining in data collection mode. The good news is he has now collected data on most of the cars I think only 6 cars remain at this point in time.
The more unfortunate part of this is, as I've already mentioned several times, the data being collected now is likely not as useful. It is highly likely that the driver needs to collect better data. The best way to explain this would be data, so forgive me that this will be a bit crude:
1 2 3 4 5 6 7 8 9 10
----------------------------------------------------------
3.2 3.3 3.4 3.5 3.8 4.2 5.8 7.9 12.2 30.6
Well, that was a little more crude that I intended... but hopefully you get the idea.
That is made up example data but it should get my point across. This here would be 10 points on the steering wheel, (say 1 is full left, and 10 is nearly centered), and the bottom row is the radius expected at each of those wheel positions. As you can see, columns/positions 1 through 5 are nearly exact, that is half the range of motion and almost all identical values. While from 8 to 10 we can see a giant change in the data. That is because a single degree of change while moving nearly straight is more meaningful than a single degree of change while near the edge of being fully left or right.
So, I think I am going to need to come up with some way to collect data for many more wheel positions (smaller wheel rotational delta/change) closer to "going straight". Something like 64 points for the first 90 degrees of rotation, 32 points for the second 90 degrees and 32 points for the following 180 degrees. Which isn't his full rotation, 450* each direction, but I'd attempt to combine the new, more dense, data with the data I've nearly finished collecting to make a complete set.
I've also found that he rarely, while actually driving, turns more than 90 degrees, though I have on occasion seen 150 and greater - which is another reason what that first 180 degrees, left or right, are the most important points.
The more unfortunate part of this is, as I've already mentioned several times, the data being collected now is likely not as useful. It is highly likely that the driver needs to collect better data. The best way to explain this would be data, so forgive me that this will be a bit crude:
1 2 3 4 5 6 7 8 9 10
----------------------------------------------------------
3.2 3.3 3.4 3.5 3.8 4.2 5.8 7.9 12.2 30.6
Well, that was a little more crude that I intended... but hopefully you get the idea.
That is made up example data but it should get my point across. This here would be 10 points on the steering wheel, (say 1 is full left, and 10 is nearly centered), and the bottom row is the radius expected at each of those wheel positions. As you can see, columns/positions 1 through 5 are nearly exact, that is half the range of motion and almost all identical values. While from 8 to 10 we can see a giant change in the data. That is because a single degree of change while moving nearly straight is more meaningful than a single degree of change while near the edge of being fully left or right.
So, I think I am going to need to come up with some way to collect data for many more wheel positions (smaller wheel rotational delta/change) closer to "going straight". Something like 64 points for the first 90 degrees of rotation, 32 points for the second 90 degrees and 32 points for the following 180 degrees. Which isn't his full rotation, 450* each direction, but I'd attempt to combine the new, more dense, data with the data I've nearly finished collecting to make a complete set.
I've also found that he rarely, while actually driving, turns more than 90 degrees, though I have on occasion seen 150 and greater - which is another reason what that first 180 degrees, left or right, are the most important points.
Well, I wrote the previous post then while watching the driver collect data, I had a moments and before you knew it, I jumped back in and started adding some stuff to the user interface that would be nice-to-have when I start working on the upcoming Driving Logic v3, some of these items could be used for DLv2 as well, so I hooked them up.
Because the driver was in the midst of data collecting, 4 hours into the run, I wasn't about to restart to test the UI changes. Earlier today I did get to see the new UI, showing the drivers desired/current speed, wheel position in degrees, and future desired/current trajectory information. Current trajectory is hooked up already.
Anyway back to my point, the new information flashed a light, much like the sun, and the issue the driver has been having with braking points and corners being near, the whole "he fails to drive most tracks after updating CDv2" issue... This appears to be because even though the driver has the correct information about corner/overlapping brake points, he does NOT handle something correctly and the desired speed can suddenly lift.
That is a breakthrough!
This whole time I thought his corner phase/overlapping brake point detection was broke or wrong, it was fairly dense code and rewritten at least three times attempting to get it right. Turns out, I was on the wrong track! Pun always intended.
I attempted a few quick fixes and oddly made matters even worse. I'll continue watching him do laps and learn during the day and collect data at night, I'd ultimately like to see this issue resolved and get DLv2 with CDv2 working as smoothly as CDv1. Next few days will likely be less developments; but I should be streaming developments again on Sunday afternoon.
Because the driver was in the midst of data collecting, 4 hours into the run, I wasn't about to restart to test the UI changes. Earlier today I did get to see the new UI, showing the drivers desired/current speed, wheel position in degrees, and future desired/current trajectory information. Current trajectory is hooked up already.
Anyway back to my point, the new information flashed a light, much like the sun, and the issue the driver has been having with braking points and corners being near, the whole "he fails to drive most tracks after updating CDv2" issue... This appears to be because even though the driver has the correct information about corner/overlapping brake points, he does NOT handle something correctly and the desired speed can suddenly lift.
That is a breakthrough!
This whole time I thought his corner phase/overlapping brake point detection was broke or wrong, it was fairly dense code and rewritten at least three times attempting to get it right. Turns out, I was on the wrong track! Pun always intended.
I attempted a few quick fixes and oddly made matters even worse. I'll continue watching him do laps and learn during the day and collect data at night, I'd ultimately like to see this issue resolved and get DLv2 with CDv2 working as smoothly as CDv1. Next few days will likely be less developments; but I should be streaming developments again on Sunday afternoon.
Well hopefully this time around the data will be good to go, I've started him in the XRG yet again, seriously like the 10th time here. It is seeming that my motivation has starting sliding a bit backwards already. This could be from the data collection process and failures or that I have other things that I want to work on.
Can't say for sure if I will be taking a full blown break or not.
I will let the driver continue collecting all the cornering capability data, and who knows that may provoke or inspire me into jumping onto some small fix or edits.
In other news it looks like Driving Memories v2 and Learning v2 may prove necessary for DLv3, though this still involves a lot of thought. Please feel free to respond to this thread after a few weeks if I wind up in a long break, those responses, questions and comments tend to bring me back and can inspire me to keep going.
Until later, have a good one!
Can't say for sure if I will be taking a full blown break or not.
I will let the driver continue collecting all the cornering capability data, and who knows that may provoke or inspire me into jumping onto some small fix or edits.
In other news it looks like Driving Memories v2 and Learning v2 may prove necessary for DLv3, though this still involves a lot of thought. Please feel free to respond to this thread after a few weeks if I wind up in a long break, those responses, questions and comments tend to bring me back and can inspire me to keep going.
Until later, have a good one!
Well data collection is hard. I decided to let him collect and save the raw data so I could process it later in hopes to speed things up and not need to run the collection action so many times.
Especially when it takes FIVE OR MORE HOURS to complete a calibration run. I've ran him in the calibration state in the XRG several times now, and so far have not produced useful data, I've figured out a new reason each time. This last run I attempted to collect less data to have a quicker turn around, but that didn't appear to happen - anyway, I think I've got the issues resolved and will run another calibration collection action tonight.
I did make the InSim controller check the wind condition of the track and automatically turn it off if it ever got turned on. I have always, tried my best anyway, turned wind off before joining track, but now I don't need to think about it.
Server is up and I'm letting him learn more tracks.
This link will likely break someday, but for a detailed explanation of how I'm collecting the data for cornering calibration read: https://www.timbeaudet.com/por ... rnering_capabilities.html
If you are reading this in the future, and the link is breaking - let me know. If I am able I will attempt to fix it, (the file will likely move).
Especially when it takes FIVE OR MORE HOURS to complete a calibration run. I've ran him in the calibration state in the XRG several times now, and so far have not produced useful data, I've figured out a new reason each time. This last run I attempted to collect less data to have a quicker turn around, but that didn't appear to happen - anyway, I think I've got the issues resolved and will run another calibration collection action tonight.
I did make the InSim controller check the wind condition of the track and automatically turn it off if it ever got turned on. I have always, tried my best anyway, turned wind off before joining track, but now I don't need to think about it.
Server is up and I'm letting him learn more tracks.
This link will likely break someday, but for a detailed explanation of how I'm collecting the data for cornering calibration read: https://www.timbeaudet.com/por ... rnering_capabilities.html
If you are reading this in the future, and the link is breaking - let me know. If I am able I will attempt to fix it, (the file will likely move).
Didn't get a huge amount done this weekend, however I did get the CalibrateCorneringCapabilitiesAction mostly complete - I haven't yet found a good way to use the data yet, but that will be the next challenge. I am letting the driver collect a lot of data to reduce outliers from pulling it around. The driver breaks the steering range into 256 different positions, excluding absolutely straight. That is 128 points to left and 128 points to the right. The driver will collect steady-state corner trajectory information for 15 seconds before finding the median value of this data, which is then processed a bit further with logarithms and rounding to create data that would be reproducible should I ever need to run the calibration again, I don't think that will be happening.
I've left him running to collect the data as I expect it to take a fair while, 20 cars, 256 steering points, and 15 seconds on each - not including the time to setup each test, and the minimum 350ms dropped to reach the steady state cornering.
However...
I started him in the UF1 FOUR HOURS AGO and he still has 20 some points to test! The good thing is he has used a total of 5% of his fuel tank, hopefully this fuel savings continues on cars like the BF1 or I will need to modify a fair bit of that code to run the full collection correctly.
I've left him running to collect the data as I expect it to take a fair while, 20 cars, 256 steering points, and 15 seconds on each - not including the time to setup each test, and the minimum 350ms dropped to reach the steady state cornering.
However...
I started him in the UF1 FOUR HOURS AGO and he still has 20 some points to test! The good thing is he has used a total of 5% of his fuel tank, hopefully this fuel savings continues on cars like the BF1 or I will need to modify a fair bit of that code to run the full collection correctly.
I just went through and ready a fair bit of my previous posts, not all of them, actually I stopped sometime early 2016. A few things to note, it is quite interesting how the project formed, started, almost failed and then really took off. Actually despite being over 8 years old, almost all of the major improvements have been added in the last 3, prior to that the driver could barely limp around a track. I was looking back at the excitement when XRG at FE1 was hitting 1:02.xx times! And then when he first broke 1:01.xx it was big news, and finally less than a minute at 59.99!
A great history here. I'm seriously considering posting this in my blog, and more importantly writing a small recap of each of the different components/actions that have made this project come to life. I am not going to list those here, but an outline of such a 'book' reached nearly two complete pages and I'm sure I've forgotten stuff. It is also interesting that in 2016 I've started collecting and showing more data on the changes, I like this approach and should make efforts to continue with that.
I want to again take a moment to thank the entire LiveForSpeed community and especially the developers for all the support and help in this project. Without the simulator this project would not have got off the ground, and while some users are excited just for a different type of AI driver, I've been excited to overcome so many of the different challenges. Your thoughts, comments and questions do keep me going. I often spew lots of dense, sometimes technical, information here and it is great when someone offers a thought on it, or questions an idea/meaning.
There was a moment, in 2015 I think, where I had not been working on the project but someone had mentioned things in the thread and/or asked some question about the project - I always get notifications of any reply in this thread, and do my best to respond at the next available moment - and the response to that user jumped me back into working on the project for a solid amount time and improvements. So if you witness that I've taken a fair break, a simple comment or question might be what brings activity back into the project.
That said sometimes I have needed a break, this is a brute force learning project for me, I'm not a pro with artificial intelligence programming, though I've learned SOO MUCH. I tend to try thinking of ways to solve the problems without looking for solutions, although on occasion I do look to resources for additional help or ideas.
--------
As of super recently work has commenced on DrivingLogic v3, something that I first mentioned and discussed almost (or more than?) two years ago! Essentially DLv3 will go back to the roots of DLv1 - it won't use the Corner Detector or learn by modifying brake points/entry speed. It will actually likely be slower than DLv2 by a fairly significant amount, but the target is to drive with precision. I'm hoping it will be faster than DLv1, so at least a 1:01.xx at XRG@FE1 - hopefully I remain in the 58s. Still a lot of data analyzing and tweaking to happen.
A great history here. I'm seriously considering posting this in my blog, and more importantly writing a small recap of each of the different components/actions that have made this project come to life. I am not going to list those here, but an outline of such a 'book' reached nearly two complete pages and I'm sure I've forgotten stuff. It is also interesting that in 2016 I've started collecting and showing more data on the changes, I like this approach and should make efforts to continue with that.
I want to again take a moment to thank the entire LiveForSpeed community and especially the developers for all the support and help in this project. Without the simulator this project would not have got off the ground, and while some users are excited just for a different type of AI driver, I've been excited to overcome so many of the different challenges. Your thoughts, comments and questions do keep me going. I often spew lots of dense, sometimes technical, information here and it is great when someone offers a thought on it, or questions an idea/meaning.
There was a moment, in 2015 I think, where I had not been working on the project but someone had mentioned things in the thread and/or asked some question about the project - I always get notifications of any reply in this thread, and do my best to respond at the next available moment - and the response to that user jumped me back into working on the project for a solid amount time and improvements. So if you witness that I've taken a fair break, a simple comment or question might be what brings activity back into the project.
That said sometimes I have needed a break, this is a brute force learning project for me, I'm not a pro with artificial intelligence programming, though I've learned SOO MUCH. I tend to try thinking of ways to solve the problems without looking for solutions, although on occasion I do look to resources for additional help or ideas.
--------
As of super recently work has commenced on DrivingLogic v3, something that I first mentioned and discussed almost (or more than?) two years ago! Essentially DLv3 will go back to the roots of DLv1 - it won't use the Corner Detector or learn by modifying brake points/entry speed. It will actually likely be slower than DLv2 by a fairly significant amount, but the target is to drive with precision. I'm hoping it will be faster than DLv1, so at least a 1:01.xx at XRG@FE1 - hopefully I remain in the 58s. Still a lot of data analyzing and tweaking to happen.
Wow I feel like an idiot. I was wondering why nobody had joined, or commented on the stupid driver, and only to find out. I was in Single Player mode from testing last night - which is really strange. I remember being in MP, but I also vaguely remember clicking SP, so I think it was because of the lack of sleep - anyway, server up, come say hello. Stream may start shortly.
Wednesday night I did a lot of thinking and I've made the decision to skip the development of Driving Memories v2 and further Learning Logic iteration plans that I had been planning the last time I was working on the project, I had also been planning on the corner capability and hoping to create a more accurate driving by path which would eventually lead to handling other cars on track.
Well, after thinking upon it, I think Corner Detection v2 and thereby Driving Memories v2 may wind up getting snipped out completely - assuming Driving Logic v3 is fast enough to complete cut DLv2 out the window.
"Blah blah blah, Tim you're boring us!"
Okay, let me get to the meat and potatoes, instead of using the corner logic, the driver will follow a set path and use trajectories along that path. I've been messing around on the server for a bit detecting the trajectory the car is currently traveling, and it should be relatively easy to;
1) Compare the current trajectory with the expected trajectory from the racing line or: planned path.
2) Modify the current trajectory to more closely match expected, hopefully more accurately following said lines.
The trick will be making the driver as fast, or even nearly as fast as he currently drives. I am certain I won't be breaking any old personal best laps once I start DLv3, but it might surprise me. I'm aiming for 70% of his current times, but even that may be too ambitious. Anyway there are many new components to DLv3, the first of which being a brand new action "CalibrateCarCapabilitiesAction". In this state the driver will act INSANE. Trust me, I've been developing this state all night because I couldn't sleep and it is ridiculous.
The general concept is for the driver to drive really slow, I currently have him aiming between 15-18mph, but I think that may be too fast and will try slowing him down even further later. Slower is better in this situation because he needs to be able to figure out what happens to the trajectory of the car without tire slip. Or as little as artificially possible! (See what I did there, I made a joke! Not funny?
I've actually finished this stage but now I need to make sure the data is sane, and more importantly; reproducible. I should be able to put him in a car in this action and get the same data back every time, or at least something super close to that same data- currently this is not happening.
------
Oh, did I mention I also got him to reset when a car contacts him, he touches and object or wall? This is amazing! Ever since this change the number of times I've had to manually reset him for stupid actions or getting stuck has plummeted to near 0.
------
So CarCalibrating action will give me some trajectories to expect the car to be able to do, but that is only the very beginning, and for a large portion of this I am still in the unknown, but I am hoping to be able to take this table of data that I'll have and be able to detect understeer! That is actually pretty exciting as long, long ago I determined that impossible with the information given.
If you wind up joining the server at all while I'm sleeping or working, you may find the driver being SUPER ODD. This is expected, and I'm trying to collect data to get a good set. I'm hoping once I finish tweaking this that I can run him in each car, automatically.
Automation is the key here because it is super boring to watch. The funny first few seconds wears off pretty quickly. I'm guessing the process will take a solid 20-25 minutes; PER CAR.
I'm not sure if I'll have to run it all per track, - I don't think so, I think a flat, wide track would be best - so I have him in training at AS2/AS2R.
Until later!
Well, after thinking upon it, I think Corner Detection v2 and thereby Driving Memories v2 may wind up getting snipped out completely - assuming Driving Logic v3 is fast enough to complete cut DLv2 out the window.
"Blah blah blah, Tim you're boring us!"
Okay, let me get to the meat and potatoes, instead of using the corner logic, the driver will follow a set path and use trajectories along that path. I've been messing around on the server for a bit detecting the trajectory the car is currently traveling, and it should be relatively easy to;
1) Compare the current trajectory with the expected trajectory from the racing line or: planned path.
2) Modify the current trajectory to more closely match expected, hopefully more accurately following said lines.
The trick will be making the driver as fast, or even nearly as fast as he currently drives. I am certain I won't be breaking any old personal best laps once I start DLv3, but it might surprise me. I'm aiming for 70% of his current times, but even that may be too ambitious. Anyway there are many new components to DLv3, the first of which being a brand new action "CalibrateCarCapabilitiesAction". In this state the driver will act INSANE. Trust me, I've been developing this state all night because I couldn't sleep and it is ridiculous.
The general concept is for the driver to drive really slow, I currently have him aiming between 15-18mph, but I think that may be too fast and will try slowing him down even further later. Slower is better in this situation because he needs to be able to figure out what happens to the trajectory of the car without tire slip. Or as little as artificially possible! (See what I did there, I made a joke! Not funny?
I've actually finished this stage but now I need to make sure the data is sane, and more importantly; reproducible. I should be able to put him in a car in this action and get the same data back every time, or at least something super close to that same data- currently this is not happening.
------
Oh, did I mention I also got him to reset when a car contacts him, he touches and object or wall? This is amazing! Ever since this change the number of times I've had to manually reset him for stupid actions or getting stuck has plummeted to near 0.
------
So CarCalibrating action will give me some trajectories to expect the car to be able to do, but that is only the very beginning, and for a large portion of this I am still in the unknown, but I am hoping to be able to take this table of data that I'll have and be able to detect understeer! That is actually pretty exciting as long, long ago I determined that impossible with the information given.
If you wind up joining the server at all while I'm sleeping or working, you may find the driver being SUPER ODD. This is expected, and I'm trying to collect data to get a good set. I'm hoping once I finish tweaking this that I can run him in each car, automatically.
Automation is the key here because it is super boring to watch. The funny first few seconds wears off pretty quickly. I'm guessing the process will take a solid 20-25 minutes; PER CAR.
I'm not sure if I'll have to run it all per track, - I don't think so, I think a flat, wide track would be best - so I have him in training at AS2/AS2R.
Until later!
Great glad you've been enjoying the server Gareth, also thanks for contributing the LaptimeToMilliseconds function, I've got it in use though it hasn't got an official job quite yet (it will sometime soonish though).
My computer just crashed, so everyone that was on the server, sorry! I will keep it off for the night though as I don't have any test to run. Lost a tiny bit of code in that crash as I was hooking up a way to collect contact events to trigger a car reset action, will continue that later though.
Tomorrow is my race day, so the server will be up while I work but I will take it down for me to go racing which I stream live Wednesdays and (usually Saturdays) at www.twitch.tv/timbeaudet - I also sometimes stream AIRS development.
I also worked on displaying yellow/blue flags for the driver but I only get the yellow flag when the driver himself is causing the yellow. I see that I can use some information in the MCI packets to tell what nodes the cars are in on the track and could make something that if any car is causing a yellow in a node 'near' the driver it shows the yellow flag, but I am a little surprised there isn't an easier way to see when LFS displays "YELLOW FLAG" messaging - or is there one that I haven't found or seen? It isn't a huge deal since the driver is currently blind to other cars, but it would be neat to have the information for when he isn't so blind.
Lots of little steps moving forward.
My computer just crashed, so everyone that was on the server, sorry! I will keep it off for the night though as I don't have any test to run. Lost a tiny bit of code in that crash as I was hooking up a way to collect contact events to trigger a car reset action, will continue that later though.
Tomorrow is my race day, so the server will be up while I work but I will take it down for me to go racing which I stream live Wednesdays and (usually Saturdays) at www.twitch.tv/timbeaudet - I also sometimes stream AIRS development.
I also worked on displaying yellow/blue flags for the driver but I only get the yellow flag when the driver himself is causing the yellow. I see that I can use some information in the MCI packets to tell what nodes the cars are in on the track and could make something that if any car is causing a yellow in a node 'near' the driver it shows the yellow flag, but I am a little surprised there isn't an easier way to see when LFS displays "YELLOW FLAG" messaging - or is there one that I haven't found or seen? It isn't a huge deal since the driver is currently blind to other cars, but it would be neat to have the information for when he isn't so blind.
Lots of little steps moving forward.
The smallest of differences go a really long way, the run has finally finished, and he was typically .4 to .5 seconds faster every lap. There was a little oddity with the first few laps, and I suspect this is because learning was disabled and the better shifting resulted in faster entry speed than the memories anticipated; something I was afraid of. But 3 or 4 laps in and it proved better, I guess with the warmed up tires.
Anyway here is the old inputs:
And here is the new:
The only change was to the timing before shift when pressing clutch and releasing throttle, and more so the post shift release clutch and pressing throttle. Preshift time went from 60ms to 50ms and Postshift time dropped from a slow 180ms to 80ms. I want him to remain at human like speeds, so rather than just set the position of everything immediately I used timing values from some data I analyzed of myself and Michal shifting.
Because the XRG can safely shift without lifting I'm going to try having him run a, shorter, session without lifting the throttle, clutch use will remain the same, so no need for a screenshot, but imagine the green line staying at the top.
---
After only a few laps of no lifting, (same unmodified driving memories), he is down in the 1:43.8Xs and essentially about 0.8s faster a lap than the test runs the night before.
Anyway here is the old inputs:
And here is the new:
The only change was to the timing before shift when pressing clutch and releasing throttle, and more so the post shift release clutch and pressing throttle. Preshift time went from 60ms to 50ms and Postshift time dropped from a slow 180ms to 80ms. I want him to remain at human like speeds, so rather than just set the position of everything immediately I used timing values from some data I analyzed of myself and Michal shifting.
Because the XRG can safely shift without lifting I'm going to try having him run a, shorter, session without lifting the throttle, clutch use will remain the same, so no need for a screenshot, but imagine the green line staying at the top.
---
After only a few laps of no lifting, (same unmodified driving memories), he is down in the 1:43.8Xs and essentially about 0.8s faster a lap than the test runs the night before.
Last edited by blackbird04217, .
It has been a busy weekend and a good bit of time has been gained from the launching action I essentially rewrote. I think there was a logic bug, at least from reading through the code it had seemed so to me, so I changed it, and this action "OnGridLaunching" starts the moment the light turns green until the car is reliably traveling 15mph - meaning not under severe wheelspin.
I hacked together a way to collect telemetry data from a RAF file, convert some things to CSV/TSV text format then use google to make pretty graphs, I DID say HACKED together, right?. Anyway, it allowed me to see that Michal and myself typically drop the clutch in somewhere near 100ms. The artificial drivers old logic took somewhere just over a full secondish for the initial drop, and during any wheel spin issues the driver also dallied around with the pedals, so he now changes pedal input much faster.
This shows the difference in his throtte and clutch inputs of old and new, notice the new inputs travel up/down more sharply sloped.
----
This led me to start working on a way to collect and view telemetry in real-time, something I've wanted for this project for quite sometime and analyzing the launch data made me want to do more. For the first part of this project I simply collected the data and threw it into a csv and into google sheets, that is where the data in the above image is from. But I've started making it so it will export to a custom format, similar to though much less data than the raf format supplied by LFS. I computed that it would take about 4mb for 5min of data, so I figured keeping 10 laps in history will be sufficient; approximately ~40mb. I still need to make a viewer and the interface for it, and I am hoping that I could just add markers on the fly and be able to open this in the AIRS window to monitor / pause and review. I have ideas, it just takes a bit more work.
Some of that work has prompted me to do more interface work, the AIRS window now has little displays much like the InSim interface shows on the server, these tend to update faster on airs, as I don't want to flood insim messages (and probably am doing that already), but it is pretty nice. Among these changes I even added more information for longitudinal/lateral G forces including peak values. I also added the raw values used to compute his limits, and was reminded that those were just arbitrary numbers picked out of thin air. I plan to run through some RAF files of WR laps that Michal kindly collected in order to try getting a better number for the oversteer detector, I suspect this should be upwards of 12 or 15 degrees slip angle where as I am currently using; 9.
----
I think I could make a few more very quick changes to how the driver shifts the car, he is fairly slow on/off the clutch/throttle as he was in his old launch action. I have a feeling that could improve laptimes even slightly, and I've started running a long test now, I've turned off his ability to learn for the moment and have him running laps in racing mode, so they should remain super consistent. I have him at BL2 and overnight he should do a few hundred laps to get a reasonable lap average to look at and compare to.
----
I also, yes I was a bit busy, now collect and store some session information in each race car, being the last split time, last lap time, current number of laps, current split, if the session is finished, etc etc, and I've hooked it up to the telemetry tool, (though not in a way that is yet useful beyond a print out and tracking the lap data). This data even included blue/yellow flags that the driver should be noticing. Of course he is blind to other cars and will but until I finish Driving Memories v2, Learning Algorithm v2. - I've been super tempted to jump straight into Driving Logic v3, instead of messing with memories or learning, and I'm undecided because DLv3 may change drastically how the driving happens including a possible new unit: Route Planner, instead of following the racing line so strictly I'd like him to gain more awareness of track space, and potentially the other cars. I am getting ahead of myself though.
----
Side note: I may start writing these posts on my BLOG, although undecided. A lot of history in this thread, though it is more a blog than a conversation... Hmm. Maybe the content can go in both places?
I hacked together a way to collect telemetry data from a RAF file, convert some things to CSV/TSV text format then use google to make pretty graphs, I DID say HACKED together, right?. Anyway, it allowed me to see that Michal and myself typically drop the clutch in somewhere near 100ms. The artificial drivers old logic took somewhere just over a full secondish for the initial drop, and during any wheel spin issues the driver also dallied around with the pedals, so he now changes pedal input much faster.
This shows the difference in his throtte and clutch inputs of old and new, notice the new inputs travel up/down more sharply sloped.
----
This led me to start working on a way to collect and view telemetry in real-time, something I've wanted for this project for quite sometime and analyzing the launch data made me want to do more. For the first part of this project I simply collected the data and threw it into a csv and into google sheets, that is where the data in the above image is from. But I've started making it so it will export to a custom format, similar to though much less data than the raf format supplied by LFS. I computed that it would take about 4mb for 5min of data, so I figured keeping 10 laps in history will be sufficient; approximately ~40mb. I still need to make a viewer and the interface for it, and I am hoping that I could just add markers on the fly and be able to open this in the AIRS window to monitor / pause and review. I have ideas, it just takes a bit more work.
Some of that work has prompted me to do more interface work, the AIRS window now has little displays much like the InSim interface shows on the server, these tend to update faster on airs, as I don't want to flood insim messages (and probably am doing that already), but it is pretty nice. Among these changes I even added more information for longitudinal/lateral G forces including peak values. I also added the raw values used to compute his limits, and was reminded that those were just arbitrary numbers picked out of thin air. I plan to run through some RAF files of WR laps that Michal kindly collected in order to try getting a better number for the oversteer detector, I suspect this should be upwards of 12 or 15 degrees slip angle where as I am currently using; 9.
----
I think I could make a few more very quick changes to how the driver shifts the car, he is fairly slow on/off the clutch/throttle as he was in his old launch action. I have a feeling that could improve laptimes even slightly, and I've started running a long test now, I've turned off his ability to learn for the moment and have him running laps in racing mode, so they should remain super consistent. I have him at BL2 and overnight he should do a few hundred laps to get a reasonable lap average to look at and compare to.
----
I also, yes I was a bit busy, now collect and store some session information in each race car, being the last split time, last lap time, current number of laps, current split, if the session is finished, etc etc, and I've hooked it up to the telemetry tool, (though not in a way that is yet useful beyond a print out and tracking the lap data). This data even included blue/yellow flags that the driver should be noticing. Of course he is blind to other cars and will but until I finish Driving Memories v2, Learning Algorithm v2. - I've been super tempted to jump straight into Driving Logic v3, instead of messing with memories or learning, and I'm undecided because DLv3 may change drastically how the driving happens including a possible new unit: Route Planner, instead of following the racing line so strictly I'd like him to gain more awareness of track space, and potentially the other cars. I am getting ahead of myself though.
----
Side note: I may start writing these posts on my BLOG, although undecided. A lot of history in this thread, though it is more a blog than a conversation... Hmm. Maybe the content can go in both places?
Good day fellow racers,
I plan to make some small improvements on this project, and I've even came up with a crazy idea to be capable of determining understeer conditions, not sure if it will work or not, but I suspect it will do okay. First things first I'm going to focus on how Jared, the artificial driver, launches the car from the starting line.
When comparing to players or the LFS AI drivers, Jared is awful in this particular area. I don't have any immediate ideas on how to improve this behavior of his, but it shouldn't be terribly hard to collect and analyze some data. Michal and I ran a few rudimentary tests and it seemed like Jared was losing a solid .5 second on AI driver, and even more on a player. So, the first step in this improvement is to collect some data in the RAF format. I may come back asking for some help on that.
I am going to make something that will analyze the RAF data for a few seconds after a launch, which is going to have to be made up because it is impossible to export RAF data at the dragstrip, or single lap layouts, see this thread, so I'll probably have to use a nice long flat straight, or build a layout that could work for this purpose. The idea is to collect information about what is happening within the first few seconds of launching the car. It could be that the drivers over throttle sensor is playing tricks on him, or even that it may not be sensitive enough - hard to say, but this seems like a byte sized task that could show improvements and maybe boost motivation that I keep losing due to the corner detector v2 and learning algorithms having issues together.
-------
Regarding the understeer thoughts. I am considering making a driving mode where Jared essentially goes out on the track and follows the center-line at a super slow pace, say 15mph or 20mph, maybe even slower. Slower the better. I don't want the tires to be slipping in this driving mode. The idea would be for him to turn left/right into steady state cornering conditions while observing two things: steering wheel angle/position, and the radius the car trajectory takes. That way Jared could come to expect turning the wheel 5 degrees results in turning a corner with radius 700' or something, or turning the steering wheel 45 degrees results in a 70' radius. The critical thing is to keep him on the track, going slow, and pulling the readings during steady state conditions.
Then once he gets to speed he can compare what is actually happening to what he expects to happen and that should be able to give an understeer value. For instance if he turned the wheel 45 degrees but the car trajectory remains at a 140' radius (or greater) then clearly there is some severe understeer happening.
-------
Unfortunately neither of those improvements will fix the fact that he keeps failing at tracks during the learning process. Fact of the matter is the learning algorithm needs to be updated. But I'm holding off on that because I want the driver to have better set of memories per corner as previously mentioned containing best exit speed, best corner time, etc etc.
EDIT:
Well I have found a few gains to make for the driver launching in XRG but those improvements will certainly make him worse at say FO8, which for FO8 and other higher powered cars Jared will dip the clutch back in slightly, and/or dip off throttle a bit to prevent wheel spin. Essentially the moment he detects wheel spin he reacts in a somewhat reasonable way, but way too slowly- also the initial clutch drop probably needs to get MUCH faster, I haven't been able to measure how long he takes currently, but I did measure some fake starts I performed in the XRG and it should take 110 to 140ms to release the clutch, let the wheels spin a tine bit without reacting; in XRG I keep throttle flat out and that works best. Obviously that won't work in FO8 or BF1 without traction control, so I still have some learning to do.
Regarding the issues with "learning" that he seems to have, it isn't _exactly_ a learning issue as much as a giant bug, which I've always felt would get fixed with other efforts. I spend a bit of time trying to wrap my head around it after Michal made a comment early this evening. Regarding a failure the driver had at XRG@AS2R, which oddly enough he is running that combo absolutely fine right now. Michal's comment was, "he was braking for T1, but the braking point for T2 was moved before T1 and he seemed to start ignoring it."
What I find really odd about that is the amount of time I spent attempting to make sure that the driver would be capable of handling this. Essentially because CornerDetector v2 split some corners into smaller sections, I knew these issues would be appearing. I started digging through that code and I must say, it is pretty dense, I'll keep trying, because it is possible that a small fix can make decent gains. Not really gains in speed, but in consistency/less failed combos.
Anyway, time for sleep.
I plan to make some small improvements on this project, and I've even came up with a crazy idea to be capable of determining understeer conditions, not sure if it will work or not, but I suspect it will do okay. First things first I'm going to focus on how Jared, the artificial driver, launches the car from the starting line.
When comparing to players or the LFS AI drivers, Jared is awful in this particular area. I don't have any immediate ideas on how to improve this behavior of his, but it shouldn't be terribly hard to collect and analyze some data. Michal and I ran a few rudimentary tests and it seemed like Jared was losing a solid .5 second on AI driver, and even more on a player. So, the first step in this improvement is to collect some data in the RAF format. I may come back asking for some help on that.
I am going to make something that will analyze the RAF data for a few seconds after a launch, which is going to have to be made up because it is impossible to export RAF data at the dragstrip, or single lap layouts, see this thread, so I'll probably have to use a nice long flat straight, or build a layout that could work for this purpose. The idea is to collect information about what is happening within the first few seconds of launching the car. It could be that the drivers over throttle sensor is playing tricks on him, or even that it may not be sensitive enough - hard to say, but this seems like a byte sized task that could show improvements and maybe boost motivation that I keep losing due to the corner detector v2 and learning algorithms having issues together.
-------
Regarding the understeer thoughts. I am considering making a driving mode where Jared essentially goes out on the track and follows the center-line at a super slow pace, say 15mph or 20mph, maybe even slower. Slower the better. I don't want the tires to be slipping in this driving mode. The idea would be for him to turn left/right into steady state cornering conditions while observing two things: steering wheel angle/position, and the radius the car trajectory takes. That way Jared could come to expect turning the wheel 5 degrees results in turning a corner with radius 700' or something, or turning the steering wheel 45 degrees results in a 70' radius. The critical thing is to keep him on the track, going slow, and pulling the readings during steady state conditions.
Then once he gets to speed he can compare what is actually happening to what he expects to happen and that should be able to give an understeer value. For instance if he turned the wheel 45 degrees but the car trajectory remains at a 140' radius (or greater) then clearly there is some severe understeer happening.
-------
Unfortunately neither of those improvements will fix the fact that he keeps failing at tracks during the learning process. Fact of the matter is the learning algorithm needs to be updated. But I'm holding off on that because I want the driver to have better set of memories per corner as previously mentioned containing best exit speed, best corner time, etc etc.
EDIT:
Well I have found a few gains to make for the driver launching in XRG but those improvements will certainly make him worse at say FO8, which for FO8 and other higher powered cars Jared will dip the clutch back in slightly, and/or dip off throttle a bit to prevent wheel spin. Essentially the moment he detects wheel spin he reacts in a somewhat reasonable way, but way too slowly- also the initial clutch drop probably needs to get MUCH faster, I haven't been able to measure how long he takes currently, but I did measure some fake starts I performed in the XRG and it should take 110 to 140ms to release the clutch, let the wheels spin a tine bit without reacting; in XRG I keep throttle flat out and that works best. Obviously that won't work in FO8 or BF1 without traction control, so I still have some learning to do.
Regarding the issues with "learning" that he seems to have, it isn't _exactly_ a learning issue as much as a giant bug, which I've always felt would get fixed with other efforts. I spend a bit of time trying to wrap my head around it after Michal made a comment early this evening. Regarding a failure the driver had at XRG@AS2R, which oddly enough he is running that combo absolutely fine right now. Michal's comment was, "he was braking for T1, but the braking point for T2 was moved before T1 and he seemed to start ignoring it."
What I find really odd about that is the amount of time I spent attempting to make sure that the driver would be capable of handling this. Essentially because CornerDetector v2 split some corners into smaller sections, I knew these issues would be appearing. I started digging through that code and I must say, it is pretty dense, I'll keep trying, because it is possible that a small fix can make decent gains. Not really gains in speed, but in consistency/less failed combos.
Anyway, time for sleep.
Last edited by blackbird04217, .
Sorry to bump this one, but RAF data from drag races would be great to have, as would (wishing here) a way to export RAF files from every lap of a session without needing to perform the ritual each lap.
Not exactly working on the project again, but I did boot it up as I have some new ideas in the works. I'm a bit disappointed now with Corner Detection v2, although it definitely detects the corners better it causes some weird edge cases I'll need to solve for the "learning" behavior, not to mention the learning behavior is rather crap right now.
Maybe that is a side effect of taking a break, maybe I'm thinking it is worse. I can clearly see from the data collected that Jared is indeed faster, so that is a clear improvement. But at some specific point he becomes slower, and or can't even complete laps anymore.
---------------
When I left the project the plans were to revamp the way driving memories were stored, to allow memories (per corner) for best exit speed, best elapsed time, best lap, etc etc, and after doing that attempt to improve his learning behavior and after that take a serious look at his "precision" of following the line, even at the cost of making him slower.
Those plans may change by the time I get back around to working on it again, and these plans may as well, but I'm considering changing how the memories/corners work entirely. Going back to the goals of taking the "human" approach, we don't exactly stare at the speedometer going through a turn and modulate the throttle input if the speed is lower/higher than desired. We also don't star at the speedometer while braking to slow to target entry speed, but I think I'll let Jared continue doing that.
My revelation came from watching him a bit around some high-speed corners. He was lifting his desired speed +5mph, +5mph etc but a human would probably know (pretty quickly) that the long sweeping corner is likely full throttle. And even if you are cautiously learning a new track you might start with 25% throttle and the next lap add more, and more until full throttle. So I think instead of a desired "speed" Jared will get a desired "throttle amount".
Another major problem is curbs and walls. Some cars/sets can ride over curbs just fine, others can't. Sometimes the LFS path information includes heavy usage of the curb (and sometimes it doesn't). Driving precision could help with this, (more closely following the desired racing line), since some cars follow the outside of the turn and others far inside (like the fox). I think Jared will need a way to modify this as he learns, but I'm really not sure how to do that since it effects a few things that happen in the "track walk" processing time.
Also made note that Aston North has some serious issues with the sharp hairpin, the racing line goes crazy. Understeer detection would be amazingly useful, but still I feel like I don't have all the information I need. Jared just keeps pushing the UF1 tires beyond their limits.
Anyway, just some random thoughts.
Maybe that is a side effect of taking a break, maybe I'm thinking it is worse. I can clearly see from the data collected that Jared is indeed faster, so that is a clear improvement. But at some specific point he becomes slower, and or can't even complete laps anymore.
---------------
When I left the project the plans were to revamp the way driving memories were stored, to allow memories (per corner) for best exit speed, best elapsed time, best lap, etc etc, and after doing that attempt to improve his learning behavior and after that take a serious look at his "precision" of following the line, even at the cost of making him slower.
Those plans may change by the time I get back around to working on it again, and these plans may as well, but I'm considering changing how the memories/corners work entirely. Going back to the goals of taking the "human" approach, we don't exactly stare at the speedometer going through a turn and modulate the throttle input if the speed is lower/higher than desired. We also don't star at the speedometer while braking to slow to target entry speed, but I think I'll let Jared continue doing that.
My revelation came from watching him a bit around some high-speed corners. He was lifting his desired speed +5mph, +5mph etc but a human would probably know (pretty quickly) that the long sweeping corner is likely full throttle. And even if you are cautiously learning a new track you might start with 25% throttle and the next lap add more, and more until full throttle. So I think instead of a desired "speed" Jared will get a desired "throttle amount".
Another major problem is curbs and walls. Some cars/sets can ride over curbs just fine, others can't. Sometimes the LFS path information includes heavy usage of the curb (and sometimes it doesn't). Driving precision could help with this, (more closely following the desired racing line), since some cars follow the outside of the turn and others far inside (like the fox). I think Jared will need a way to modify this as he learns, but I'm really not sure how to do that since it effects a few things that happen in the "track walk" processing time.
Also made note that Aston North has some serious issues with the sharp hairpin, the racing line goes crazy. Understeer detection would be amazingly useful, but still I feel like I don't have all the information I need. Jared just keeps pushing the UF1 tires beyond their limits.
Anyway, just some random thoughts.
I agree virtual mirrors are not realistic, but I don't think they should be forbidden by servers. This isn't quite the same as force-cockpit view. They may/may not be an "unfair advantage" when compared to using real mirrors, but on a single screen there is only so much screen space, so the virtual mirror can help with car awareness.
With that perspective, some would consider a triple monitor setup an unfair advantage because of the advantageous peripheral view.
With that perspective, some would consider a triple monitor setup an unfair advantage because of the advantageous peripheral view.
Very nice, I'll get that downloaded here shortly and check out the mirrors! Now that you have that test patch out, here is a light reminder:
A few feature requests:
- A command to add an AI car of set difficulty, might be tricky now that there is /ai name, but I'd really like the ability to: "/ai easy /ai hard" or even use a number.
- In the back of my head I was digging into making a realtime telemetry tool, it sure would be nice if OutGaugePack had included steering wheel angle, but I suspect that is a PAIN to change since it would effect others using it by changing size.
- Any chance of an InSim message, or a command to print the locally used setup? I know you can see it on F12, but that doesn't help my AIRS driver safety check that it used the correct setup. To be fair I understand if that would be a waste of your time since I'm probably the only one to find this useful. I had hoped that it was in Display2[] on OutGuagePack but no such luck. (I have now found and use the /setup command when changing car, still might be useful info)
A few feature requests:
- A command to add an AI car of set difficulty, might be tricky now that there is /ai name, but I'd really like the ability to: "/ai easy /ai hard" or even use a number.
- In the back of my head I was digging into making a realtime telemetry tool, it sure would be nice if OutGaugePack had included steering wheel angle, but I suspect that is a PAIN to change since it would effect others using it by changing size.
- Any chance of an InSim message, or a command to print the locally used setup? I know you can see it on F12, but that doesn't help my AIRS driver safety check that it used the correct setup. To be fair I understand if that would be a waste of your time since I'm probably the only one to find this useful. I had hoped that it was in Display2[] on OutGuagePack but no such luck. (I have now found and use the /setup command when changing car, still might be useful info)
FGED GREDG RDFGDR GSFDG