Unfortunately I've refactored and moved code around that will have effected the test times for the XRT at KY2 with regards to different steering system. Probably okay anyway since I got hung up on one detail and didn't think of an immediate solution so I've put that on hold. By moving this code though, I should be able to give the StartFromStop action the ability to steer the car, which should greatly improve his recover. (Initially that action held the steering wheel straight in hopes the car stayed on a desired path, we all know how well that works: It doesn't).

I have continued working on some debug tools for seeing what the corner computer is reporting back without performing my own track walk. Here is a shot for BL1 with the new TrackMap code, which at this point the code probably should be removed into it's own separate file. Currently grey represents straight areas (including braking zone) and orange represents from corner entry until corner apex. For very observant readers, you may notice the track width varies in the new shot, that is because I now use the left/right edge that I get back from the pth file. Visually, I like the constant width, which is probably why LFS uses that in it's track map.

Looking at this BL1 image you can see it does "okay" for some corners and then completely failed for that final turn complex where you drive past pitlane entry. That should be separate corners, but the current detector gets it all as one.

Trying to improve that with the new detection.

Currently fighting an issue with the display on AS5, looks like it might be more issues with detecting what corner/phase of the track the car is in.

EDIT: I have confirmed it is indeed some issue with the detecting corner/phase. Also, added colors for each phase of the corner, looks pretty neat!

For the regular visitors of the server you may have noticed it is down. This isn't because I've taken another break on the project, not just yet anyways, but rather because work has got quite busy and my free time has become quite limited. I could keep the server up with Jared running laps, but without anything specific to test there is no reason to have him running, and I was finding that I'd become distracted watching him run laps as I watched for things he could improve upon.

So for now the server is down and progress has slowed.

I did continue working on the corner detector with all the data collected, and so far I've been less than impressed. Detecting where track corners are is actually a bit difficult. Values that work okay for some corners, don't work so well for others. And with the way I'm getting the "radius" at a point, (admittedly not the most accurate), sometimes it triggers on a straight.

Take FE1 for instance, some of the start/finish straight has some bends in the center line points as the path widens/narrows, these bends create a low enough radius at those points that a corner gets detected, where the sharpest turn on the track actually has a section where the radius becomes 3km for the final portion just the way the center line points straighten out, despite the track STILL TURNING SHARPLY.

So this becomes quite tricky because the center line isn't smooth enough. I need to find a way to make it smoother, but ONLY on the straight areas. But there is a catch 22 since I need the radius to determine if an area is straight or not, for instance that sharp turn in FE1 should not have the straight section that it does.

Anyway, that is the latest update.

Great efforts in this thread!

However as I state before, I think Googles Deepmind AI has the potential to be the perfect AI driver.


See this:
http://futurism.com/major-brea ... european-go-champion-5-0/

http://futurism.com/googles-ai ... t-ranked-go-player-world/

Even playing 3D games is already possible:
http://futurism.com/google-dee ... -doom-like-3d-maze-sight/

This includes racing:
http://futurism.com/videos/goo ... as-now-moved-to-3d-games/

Well, this sucks. Work has been quite busy and keeping me from the project. I do have a lot I still want to do, primarily with better corner detection and storing the memories for best elapsed time and exit speeds, but other projects (like other racing game/sim projects) are starting to occupy my mind, so I am pretty certain the AIRS project is back in a holding pattern.

I even tried watching the driver lap a bit while working as usually that provides inspiration to stick with ti, but it got me discouraged because the driver can't even get back to the track very well after a spin without me manually intervening to reset the car. Well, you all know I will be back around again, and it may not be that long of a break as there is progress to be made with the memories and corner detection, and I'd really like to try that new steering algorithm, but that didn't seem to work as smoothly as I had hoped, when does it ever?

Thanks everyone.

Do you store youre project on github or similar? Would like to peek into the code.

It is stored in svn, the code isn't open source, at least not at this time and not sure it will be, but I can maybe look into making it a public read-only repository if you are that interested.

It is a giant mess though, as the nature of a project that has "on/off" activity for 6 years would be. It really does need a proper clean up.

Ok, so my initial question would rather be what interface you use to control the car? The InSim thingy is not sufficient enough as far as I peeked into it.

Maybe you have a write up what kind of tools/frameworks/apis/interfaces you used?

Quote from Kubica.MJ :

Ok, so my initial question would rather be what interface you use to control the car? The InSim thingy is not sufficient enough as far as I peeked into it.

Maybe you have a write up what kind of tools/frameworks/apis/interfaces you used?

He uses this tool.

Yup as Whiskey said I use vJoy to control a virtual steering wheel to control the player car, InSim, OutSim and OutGauge for information and some other file formats the LFS provides. I have not, nor will I, used any undocumented things within LFS.

For frameworks I use TurtleBrains, my own C++ game dev framework using OpenGL, InternalCombustion my own framework for the simplest of 3D rendering, and again my own networking implementation of TCP/UDP. If you sense a pattern, I don't really use much beyond my own stuff (Win32, OpenGL, WinSocks, etc) with the exception of vJoy.

vJoy was a bit of a pain to setup, especially at first, and for some reason I had some trouble using buttons 0 and 1, so I skip those altogether.

This thread is turning out to be an insane document of my thought process while I dig deeper into this AI project in non-traditional ways.

I got the driver running again and this morning I even made the WaitingOnGridAction multi-threaded so that the framerate didn't drop and the driver could keep the rpm's to a decent launch level.

I can't say I'll be making big updates to the project, but I've tossed the driver on XY3 for a bit and I really need to finish the new corner detection stuff because for these long tracks, or long sweeping corners, it is pretty painful. That will require a lot of "trial and error" which tends to zap my energy if results are not visible.

Along with that change I need to modify how the corner information is stored and accessed, along with how the driver modifies "memories" of the corner, what entry speed was safe, when to brake, etc. I really would like to see him have multiple memories to work from. And these memories need protection so the driver doesn't try increasing speeds above the cars potential in the area, or move a braking point before the exit of the preceding corner. This was causing Jared, the driver, to fail in some cases.

If I can manage to get that far there is also another thing related to the learning that needs some serious tweaking and that will also be a fair bit of trial and error unfortunately. This would be the limit detection algorithms and when the driver decides the car was pushed TOO HARD or not hard enough. Currently if he slips for even a moment above a threshold it triggers the "backoff" behavior and will go slower the next lap. But I've noticed that doesn't necessarily mean he went beyond the limit enough to back off.

There are tons of other things to address also;
- massive code clean up required
- better spin recovery, which is currently still pretty awful
- handling cold tires, especially on slicks
- auto save/load of memories for a track (vs manual)

So if I do get some momentum going for the project first priorities are:

- Some code cleanup (also helps getting refamiliar with codebase)
- Finalizing the new corner detection algorithm
- Restructuring the driving memories/corner access
... Protecting against brake before preceding corner exit
... Auto/save load driving memories
... Store driving memories for best lap, safe lap, etc
- New logic (more aggressive) for using limit detection for learning.

I think with those changes, he might actually be reasonably quick. Even the new corner detection algorithm could lower his lap times on some tracks drastically, although probably wouldn't help much at FE1, where the initial corner detection algorithm was based on/suited for.

It seems live I have indeed started working on the project again, and yesterday a few hours were spent fumbling around, on www.livecoding.tv/timbeaudet stream even, attempting to figure out a better way to detect those corners. I didn't really figure it out during that stream.

I then proceeded to clean up some of the code, which will make it easier to collect information about multiple tracks, including the ability now to zoom in and move that 2D track representation around to look at where corners are detected. I'm hoping with better tools I will get a better Corner Detection v2 algorithm developed.

I also found while testing that I had accidentally set the driver on the wrong setup. In general it is useful to always use the same setup so that any changes in his behavior or laptimes are due to, for the most part, actions I've taken by modifying code. With this I wonder if there is a way to get the current setup name from the local player.. I know I can see it on F12 screen, but I am hoping it could be displayed as text to the user, like a chat message, or, through InSim, which I found no options for. This could be useful so I could make the driver refuse to drive, or at least warn about unexpected setups.

This morning, so far, has been spent attempting to make the AIRS application a bit more friendly to disconnects. I've now made it so that if LFS is not running when I start AIRS it will show that it is disconnected from the racing sim. I can even press a button to attempt to connect again. However if it is connected and I abruptly kill LFS, the AIRS application can lock up with network issues. I'll be in good shape if I can fix that. Also among these changes, I've made it possible to go from the TrackDebugState into the RacingState, but that was minor., and useful.

After the abtupt kill issues, I've got a little more code cleanup to perform, hoping to remove lots of old code-rot from this 6+ year project, and then I've even got a few ideas for that new corner detection algorithm.

It has been a week, and I've run the driver a bit and he definitely still needs a lot of help. For instance at Aston National (AS3) he does pretty good in XRG, but putting him in the XRT will cause him to go too wide, getting onto grass and spinning. FO8 has too much power and after the second hairpin he will apply too much throttle and spin, or mess up his learning algorithm.

This issue got me thinking, what if he modified his corner speed memory at corner APEX instead of corner EXIT. The thought being that after apex the driver is essentially trying to accelerate out of the corner, and in the case of FO8 at the second hairpin this action is what caused the corner speed to get lower and lower. A quick code change and the testing showed it improved his corner speed, but still failed to exit because of wheel spin.

I'm not going to tackle the changes to his cornering behavior after apex, so that won't get fixed, but I am going to collect data before moving forward. I've been theorizing for awhile now that a new corner detection algorithm will help improve his lap times. The only way to know if that is correct is to know what lap times the current algorithm is doing. So I will run 3 tests of about an hour in length (less if fuel limited) at a few different tracks and in several different cars using the current corner detection algorithm and the modify driving memory at exit, then repeat the tests 3 more times for modifying the driving memory at apex.

Modify at Apex Test 1


Modify at Apex Test 2


Modify at Exit Test 1


Modify at Exit Test 2


I've actually already run 2 of each for AS3/LX6 comparing apex vs exit memory modifications but that wasn't part of this bigger test I'm performing. The results are here, and unfortunately I'm confused by the second modify at exit test, which you can see starts with a faster lap than the others and the first few laps look drastically different, which makes me wonder if I had not cleared his memories completely at that start like I thought. You can also notice that in modify at exit test 1 the final lap was way slower, Jared wound up popping the front-left tire which previous test runs showed happened at lap 30. It seems to happen anywhere from lap 24-30 at random. This is likely caused from the car setup not locking the drive wheels first, and that is the only way for the driver to know the wheels are locked.

I'm hoping by the time I run all these tests, I will have Corner Detection v2 algorithm ready to use. And I will NOT be making any changes to his setup or driving behaviors during this time. The only change will be the corners get detected given the left/right edge of track, center line and racing line that he currently uses.

Does anyone know if it is possible to link to the race results page (the one that shows the graphs above) for a given driver and given race?

I suspect it is impossible but this would make my life so much easier and more organized if that is indeed possible.

EDIT: This was actually possible, for the most part, by clicking on the small finish-line flag at the top left of the Online Race Results title bar and copying the link target. It doesn't link to the graph, but it is one click away.

Last night, this morning, and this afternoon has been quite busy for the AIRS project. I've been trying to run tests as constantly as possible, and some cars were failing pretty bad. It wasn't until I revisited the tried and true combo of XRG at FE1 that I realized what was happening. The "Modify at Apex" learning algorithm is faster, as I proved with data above, but it is less reliable. At FE1 the sharp right hand turn on the back stretch can cause issues, because after apex the corner tightens up enough that while getting on to the throttle the driver can slide.

Using the "Modify at Exit" approach this slide stays within reasonable limits, since the driver will keep the entry speed slower if a slide had occurred even between apex and exit in this mode. When using "Modify at Apex" the driver pays no attention to slip 'n slide behavior between apex and exit, so it gets worse, and worse, and whoops the car just spun. So while faster, it will definitely need behavior tuning after apex.

----

Last night I was working on a tool to visual the track corners as detected by the new corner detection. Surprising over the last few days I've had some break-through thoughts regarding the algorithm including a completely different way of looking at it. This was mostly triggered by my attempt to gather information. Instead of finding the first node less than a threshold, I instead mark each node that I think should be straight or corner, this has had some great results. The values still need some tuning but so far it is pretty promising.*

I also made a small menu tool that is so much easier to use than pressing random letters/numbers. Literally had about every letter and number used for increment/decrement these settings, so this debug menu tool simplified it a lot. On top of that I saved the basic track info for several tracks and created a way to quick load them for faster comparisons. I'm still trying to make the Corner Detection v2 combine small gaps, so say a small straight in a corner, or a small corner in a straight. To remove tiny errors within the detection that shouldn't bet there.

*There is one catch though, I will need to modify the drivers behaviors to protect against the braking point being before the exit of the corner preceding. The corners will definitely be much closer and the possibility for this to happen is definite. I will try to make as few changes to the behavior as possible, but this is actually a challenging problem to solve.

I plan to live stream tomorrow morning (approx. 11am UTC, give or take an hour) and it may be trying to find the "best fit" values for Corner Detection v2, which would theoretically be the final bit that needs to be done. Of which instead of using center line, or racing line to determine the corners, it seems like using left/right edges work even better!

Well well well, this is starting to get interesting. I spent about 2 hours tuning the various settings attempting to come up with the best "all around" Corner Detection v2 algorithm that I can. I may still tune it some more, or change/add to it as I see fit however, I have technically computed the Braking, Entry, Apex and Exit points for the tracks in a different way.

The apex is computed slightly better than before, or at least, slightly differently. It walks backwards from exit along the racing line and waits until the corner starts to open back up, meaning it finds the from exit walking backwards the tightest radius of the line. Unfortunately this isn't perfect, especially for left/right chicane like turns, or those that have an racing line near exit that is practically straight due to the next turn. But it works.

It also gives me a new idea, but it would require behavior changes and I'm attempting to hold off on those, (as much as possible anyway since some changes are necessary), until after I get Corner Detection v2 with some test runs for comparison.

So why haven't I started the test runs if the algorithm is mostly done?!

Well, because unfortunately some of the braking points are intersecting or before previous corners. The driver currently detects his corner phase ONLY when crossing one of the lines, so this actually isn't a trivial change, and unfortunately will change his behavior at least a little and I was trying not to do that so we could prove the improvements were caused by CDv2. While making these changes I will make every effort to keep the behavior as identical as I can to what it is now, however, the braking logic for the turn further up the road may, or may not, override the current phase of the corner he may be in at the moment and that is essentially changing behavior.

His memory modifications and such will all remain the same, for now, however I am seriously looking to getting CDv2 tested and hopefully everyone else is as well! The debug visuals for most tracks look very promising. BlackWood remains similar to CDv1, although CDv2 is a bit better for sector 1. I am worried the driver will fail at South City Classic because there is an issue detecting the chicane as a corner. Just the way the path file is, the turn is tight but so short it gets dropped as noise. I have an idea for this, I just haven't figured out if I want to continue modifying CDv2 or not. (Really I don't want to as I want to get it tested already, but it might be worth doing it right since I probably won't iterate it for awhile).

Well, I'm off for the night. I'll get back to it in the morning.

----

EDIT: Later that night, continued working. Fixed the South City Classic issue by NOT removing gaps if a high angle was found. Didn't effect any other tracks, so hopefully that was worth it... But I may be able to do the same for keeping gaps that are straight enough as well, and that might help at blackwood and potentially others, though, I'm not doing that one tonight, because it is time for bed!

Yesterday I was able to change the way the driver detects the phase of the corner he is in. This is one of the changes needed to fix the braking before preceding corner issues. It took a while to get it working as I intended since it works in a VERY different way, and the track I was testing at, AS1, luckily had an edge case that I got to solve all at the same time.

Then I went to test the brake point before the preceding corner issue, since I had a test case there already setup. And the issue continued. I had some other stuff to do so I paused that and went on.

Moments after setting it down I realized that the code I wrote was actually just a replacement of finding his current corner phase, not anything that would properly deal with the brake point issue. No wonder why it didn't work! A few hours later when I finally got back to the project I spent the rest of the day working on detecting the brake point issue. Most of it streamed live on www.livecoding.tv/timbeaudet, but it was really just me fumbling around. I did find and solve an interesting edge case when connecting AIRS to a copy of LiveForSpeed when there is NO cars on track.

Then I went to bed, but couldn't sleep because that issue just kept lingering. Unsolved. Haunting me. Taunting me! As I slipped into the state a bit beyond being awake and just a bit before actually sleeping, it hit me like a freight train. I had been trying to make as few changes as possible, but I've had a better method of tracking this phase in mind. It was the perfect solution to both problems, and actually doesn't change all that much logically. (Still the minor change of actually detecting the BP before preceding corner issue, but that is a needed change)

I went back to the computer and slammed some keys around, and BAM, first test worked flawlessly with the same old normal behavior. I added a tiny bit more and two tests later, the same time the SpaceX rocket landed on it's platform, it finally worked. It finally stayed in T1 braking even after getting into T5 Apex and T5 Exit. The coincidence in timing was amazing because just as I got super excited that it FINALLY worked the way I wanted it to work, the SpaceX team/crowd watching started cheering and screaming with joy.

That was all me.

----

This morning I plan on wrapping up a handful of things, I would like to make it so he can track both that he is in T5 Apex/Exit -and- the T1 Braking. It shouldn't be terribly hard, and might not be super important but it is related to the small change(s) I want to make to his learning behavior so that he can actually modify the T1 Braking point distance. This change is one that is required for testing CDv2 accurately, and unfortunately is -actually- likely to change the behavior enough that the tests I ran won't be 100% accurate that any laptime changes were due to the Corner Detection v2 changes.

Sorry if that barely made sense I rewrote it a few times and it came out a bit thick.

At NOON my time, (12:00pm EST), I will do my best to attempt running Jared using CDv2 for the very first time. I will do this live on stream and you can also join the party on the server. There will be no other cars driving on track during this particular test.

What this means for you:
Come Join/Watch the LiveStream at 12:00pm EST or 4:00pm UTC

Cool! Can't wait for that.
Definitely gonna watch

Still too early to tell, but the driver was a teeny bit faster at FE1 with a bad racing line. Because FE1 and a few other tracks had custom layouts instead of PTH files. When I was testing the CDv2 apparently it was no longer loading the layout for FE1 (and others), so all the tracks were using the PTH files for defining left/right edges, thus the algorithm got configured with PTH files.

What this meant is that the line through the chicane actually became more S like than it was previously, which is slower, and the sharp corner at the back winds up too sharp so the driver hits the curb and rises on two wheels loosing speed. However, because CDv2 split corners better the driver is still actually faster and could, I believe, hit a 56:2x if things went right.

I knew Westhill didn't have a layout file so started testing there next, but the driver had only done 78 laps, with who knows what fuel load. That said after 78 laps on CDv1 he had a PB of 2:25.77, with splits 57.10 and 1:28.28. After only 20 laps, learning from 0, he has managed to get down to a 2:18.30 and I'm sure still loosing time.

That definitely points to good things ahead! Unfortunately all the tracks I had tested on seem like they had layout paths, and the racing line can change that much. I have thoughts on racing line v2, but I have other things I want to tackle first, like a new "driving memory" system that allows him to keep memories of the best elapsed time through a corner, best exit speed etc, which I will work on once I get some code cleaned up.

Will be deleting the old corner detection logic (will always exist in source control) and all the testing hackery that I did to tune corner detection v2.

Can definitely tell I caught the bug again and hope to work on this for a bit to come now that I finally got beyond CDv2. Lets go test some other tracks!

EDIT: A few more data points.

Looks like at AS2 he can drive a bit better. I know AS2 was once a layout track, but even with PTH file he had issues braking for last turn as he would go wide into grass. It looks like this still happens in XRT but after doing many more laps than previously and his best time was improved a lot.

I've also given him some laps at BL1, but that also was a layout track (I believe it used the layout) that is now using the PTH file. Even so the old corner detection combined first turn and chicane as one corner, and this now splits into 3 corners. The driver gained 2 seconds in sector 1 with the XRT. [u]Unfortunately[u] the racing line changed a fair bit (maybe using the standard amount of iterations for racing line) and the line now uses a bit too much curbing in sector 2 which he loses all the time gained, and the more time lost in sector 3, I think also because of curbs.

What is super unfortunate is I don't have a real good test of old and new corner detection versions because of the path file mess. I would have continued to use the layout, but anyone that saw the live stream saw that blew up in my face. The layout edges were bumpy enough that most of the track was declared turning.
I could flip back to the old Corner Detector to run some tests and I am thinking about doing that to get actual data but I think it has already proven to be better overall, even if BL1 with XRT wasn't doing better. (It wasn't doing that much worse, and maybe with a long run with full fuel would help).

EDIT 2: For the first time ever the driver can go on KY1 because of corner logic changes. Will take him a long time to lift the corner speeds to reasonable levels, but given the difference to other tracks, I'm wondering what happens there!

Before deleting the code for the old Corner Detection algorithm, I figured I will gather some pictorial evidence of what changed. Here is a quick shot of BL1 changes, before (CDv1) on the left.

I was going to make a nice image with all the tracks, well some/most of them, to compare the old corner detection with the new. I even started going through the trouble of starting to capture these pictures before I realized they were inaccurate due to the, as if this won't be confusing, detecting what color to use at a specific point on the track. This is because the corner points are defined as distances around the racing line, and the color points are not. I spent a bit of time trying to fix it but honestly, it wasn't worth the effort in the end.

I could color the wrong spots in manually if I saved the images again, this time with the corner lines. But I probably won't as it would be time consuming and add little value besides being able to look back at the measured change.

If you have followed the project long enough you may remember that there was a time that I did not load the track information from the LFS PTH files and instead used a custom made layout to define the left and right edge of the track. This method was error prone, to say the least, but it did have some advantages. For instance the custom made layout could define the edge for dangerous or safe curbing better than the PTH files seem to, however the PTH files were much easier, less time consuming and simply work at all tracks.

I remind you of this because going forward there will no longer be a way to make the custom layouts to define track edges. ALL tracks will use whatever LFS supplied in the PTH files which is not always optimal but it simplifies some code, quite a bit actually.

Major code cleanup project has begun. So obviously I dropped processing the track edge information from layout files, but I've also found a few unused test algorithms for various things. Corner detection algorithm v1 has now been thrown away as well, since it is clear v2 is better overall; more simple, less edge cases and generally better corners detected. Altogether so far I've dropped 2850 lines of code and a handful of files. Keep in mind should I ever need any of it, I can use source control to get it back, but that is unlikely. It does feel scary and weird to delete all that code from the code base, even with source control That was about 10% of the total code.


Moving forward
-------------------------------------

Now that CDv2 is finally complete I think I might start digging into some behavioral changes, starting first with the way driving memories are stored, saved and loaded. I would really like the driver to keep track of the driving memories for each corner that led to the best elapsed time through the corner, and the best exit speed out of the corner. This might make it easier, or more reliable, to test personal bests after learning the track for awhile.

This morning I actually had another idea for CDv2 which I may consider adding. It could fix the issue at BL1 with the right/left turns at end of sector two by separating into two corners instead of one. I'm not sure yet if I will actually implement it, but essentially it would take a final pass over the color data looking for turns that go both left and right, then seeing if a straight section exists that is worth splitting. I do need to be careful, because FE1 chicane should be a single turn.

Another driving behavior idea I've been watching recently is the tendency to let off the brakes early. Say the driver is coming down a long straight at 100mph, and enters a braking zone for a corner with desired speed of 40mph. He will start braking hard for a bit, but as he gets down to 50mph he will start releasing the brakes and this extends his braking distance fairly significantly. He will still need to transition off brakes smoothly, but should threshold brake all the way to desired speed.

It would be very nice to get the driver to be better with higher powered rear-wheel drive vehicles. He is pretty good at XRG and XRT, even LX4 is usually okay. But some others have too much power and snappiness to them, so when coming out of the turn he should be a little more cautious before just slamming the pedal to the floor.

While I'm at it, driver logic v2 was written fairly quickly, and if you remember at first it failed to prove as interesting as I had expected, but finally got that worked out. With this I was a little silly and have recently had the brilliant idea that IF the driver goes beyond the limit in a particular corner, he shall immediately start going slower.

And finally going forward I would really like to find a way to get the driver to drive more precisely. Which will definitely be challenging, and it will very likely slow him down but at the same time make some tracks less of an issue by keeping him ON TRACK. (Like AS2).

EDIT: Forgot to mention that I'd like to revisit the prediction algorithm. Currently it is unused because it was not consistent or reliable. I'd like to figure out what might be causing that, and I think perhaps a longer time span may actually help make it more reliable.

Watching Jared run laps at BL1R in the LX6 I'm realizing his downshifting needs work. As in, he blips the throttle fairly well, but then after engaging the desired gear it appears he gets on throttle quickly while releasing the clutch. Like you would for up-shifting, this is potentially upsetting the car balance, but more importantly increasing time it takes to stop, if even by tiny amounts.

That would be all I have for this report. Stay tuned and come say hello on the testing server. I'm letting him train at various combinations and in most cases he is beating old personal best times.

This mornings developments went fairly well I actually found a bit more code to cleanup and wrapping up that task, I actually made acouple admin commands to change car and track. Now typing !car xfg will cause the driver to spectate, pit, select the car, select his setup, rejoin the race and restart. This was something I previously did manually. He can also change tracks, although I suspect that one could use a little work as I currently wait for 10 seconds for track to load and having had LFS on my surface connected to the server I know some track loads took longer, which will cause that to fail. (Not to mention AIRS still has a bug that -something- is a little odd during track reload, I found a few possibilities during code cleanup that I fixed, but it seems to still have a lingering issue.

This evening so far I've modified his downshifting behavior, so he no longer gets on the throttle after/while downshifting. He will blip the throttle though. The results are not as conclusive as I thought the would be. I didn't expect massive gains, but during the first test, (not shown) it started looking pretty clear that he was indeed faster, nearly a tenth faster than his fastest lap in a previous run. But he had an issue, I guess a potential edge case in detecting which phase he is in caused him to miss a braking point completely.

Before, downshifting with poor throttle usage



After, downshifting with no throttle usage



Here you can see the before and after effects of the changes. In the displayed graph the green, red, blue lines represent throttle, brake and clutch usages respectively. (Orange is steering) While the first test looked great, you can see the results in these images show the times are pretty much identical so the change is minute enough not to matter.

I'm going to attempt to change his threshold braking behavior next. This is currently what it looks like as he gets near the desired entry speed of the corner:



You can see that he is braking hard for quite a bit of time, but for about the same length of time he starts easing off the brake and has a really long tail. The new behavior should have him brake harder longer than ease off, probably a fair bit quicker. I've got to let him train some more on the track though since I can't run the test in the exact same manner, if I did the lap times would get slower to prove it worked (since he wouldn't modify braking distance to match the new braking behavior). But in allowing him to just modify his braking distance, without being fully trained at a track how am I to know if his improvements were just there all along? So he is now training at FE2 with XRG.



This is the new braking chart, (may be for a different corner), but you can notice he hits the brakes a bit quicker, harder and doesn't let the trail off quite the same way. I was a bit silly and didn't save the test run data for his previous training run, but he did manage to do a lap that was 0.64 seconds faster than his old PB, whether that was just all corner memories lining up well or because of the new braking is hard to say. But I think from the graph it should be better.

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.

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.

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?

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.