Well.

That didn't work.

I decided to see if I could take a break from work to at least get the airs_driver doing some laps. The answer, no.

It would seem that updating from VS2010 to VS2015 changes enough things to be a pain in the butt. First my debug output seems to be redirected on me for some reason or another, ie, the console is not outputting any of my text. Yay. Second there seems to be a crash. Now, I know I didn't leave the project in a crashing state, although it is very likely in an undesirable state with Driver Logic v2, but now it seems I crash, deep in an unhelpful stack which my only guess is something graphics related nVidia / OpenGL.

I wasn't able to look to far into it, but it is already a steeper hill to climb than I was expecting. I will also need to update the project to use the latest version of TurtleBrains, and since it is using revision #123 and needs to be updated to #478, there are a few changes to make, more than I was able to do in a quick "just get it working" break.

So for now, back to work for me, and a little depressed things didn't "just work". I know when I left the project it was in working condition, but I have since built a new PC and updated the development process slightly.

Thanks for the call out nacim, glad to know others are still interested in my on again/off again project that is the artificial driver!

I remember now why I will never be able to actually release this program for others to use, you know, beyond the other obvious effects of people abusing it in some way or another.

Setting up the virtual controller, and configuring it is the biggest pain in the *** ever. I've been fiddling with it for the last two hours. Still looking at a black screen, so that kinda sucks too. I left the project alone for too long it seems, I will get it working again, but it is being a pain.


Later
Well, finally I got beyond that issue. However, many MANY more hurdles still exist. Seems the drive can start as expected, but doesn't actually drive as expected.

Even Later
So after re-calibrating about 15 more times I finally figured out that I had a script that was resetting the buttons, now that the script is set I can now close and restart LFS(for airs) without worry about reconfiguring again. Unfortunately, it seems the steering is -WAY WAY OFF-. But before I can handle that, I need to get the airs visuals back up. Something with the framework updates have really screwed over what I have going on, so ... I don't know what happened but I may need to update all the rendering code of airs from legacy OpenGL to use OpenGL 3.2 (shaders). I have most of the pieces I need, it will just be a matter of ripping the old and replacing with new, but it will take a bit of time. I was actually expecting to see visuals at this point, but I have a wonderful [i]empty black screen[/b] instead. Almost.

Once the empty visuals is fixed it may require completely retuning all the steering functions. Each of the drivers actions seem to be working except when the driver is attempting to "Drive" he seems to turn the wheel way more violently than before, hard to say without other visuals, but I fear the values I am using were calibrated for a different wheel calibration, like maybe the steering axis didn't use the full range before. I hope I'm wrong and the visuals show me something silly.

Quote from blackbird04217 :

...Thanks for the call out nacim, glad to know others are still interested in my on again/off again project that is the artificial driver!

Nacim is not the only one!

Well this concludes the attempt to get the driver running again, at least for the moment. Unfortunately I end with defeat. The terrain, car and other meshs are not renderering, but at the very least I have my visualizations of what the driver things is happening.

Good news, everything there seems to be working as expected.

Bad news, what the hell is with the steering? The driver use to be precise, and get around the lap. I have to assume something with a bad calibration or something of the steering axis lead to this? I've tried multiple cars and settings, attempted to change the steering wheel angle in LFS (although my script was setting this to a specific value so I don't think that should change).

In other words: The driver does not get around a lap anymore. He is lucky to make it beyond the FE pit wall.

I have, sort of, got something working again. It amazes me how often going backwards allows forward progress. Essentially I undid all changes I tried yesterday with exception of the vJoy interface updates (which were required) and things worked, reasonably well. The driver seems to spin out on FE1, and I don't remember him doing that, but he was able to make it around a few laps. I am not sure why the driver was unable to drive correctly when I had attempted to update to the latest version of my framework, but I must have done something silly in updating that?
I am now trying to get the server setup again. Which means adding all the port forwarding settings, and even, updating LFS. I have now done both of those, but still can't see my server on the master server.

If anyone can try to join, you might be able to find the server or driver:

Server: SRS:TestingGrounds
Driver: airs_artificial_driver

It might not be found at present time, as I'm still trying to get it working again.

I did find the server, but it's private. I'm guessing that's intentional for now.

Doh, I had set a password on it from previous issues with people messing with the driver when I was away. I've taken it off for now although have to work, so even though the driver is lapping, I'm not really around the server anymore, but the drive is lapping.

There were some complaints the server is laggy, sorry it runs on my PC, although my connection usually streams and races just fine. I suspect there is some issue with my insim message handling / sending. It appears I am getting quite a few TCP errors from it. I suppose this is made more of an issue due to the faster speeds things can run with the new PC, however I had also thought I addressed the issue (could have done so very hackily, likely).

Anyways, seems the driver can do laps again, so that is step one. Step two will be getting things updated to the latest version of my framework, although, honestly, I might skip this. Not sure there is any real reason besides "it would be really nice" to do it. Not sure what I have planned after that.

Password please?

I'm going to try sharing the password again with those that stay tuned with the thread and understand the project a bit: airs but I will have to change it if I find that people join and mess up the driver/testing. That didn't happen last time so, lets hope it continues!

Password is: airs

If it is ever something different, I'm probably busy testing something else or something that is failing in a way that I don't want other users interfering with.

I am currently developing on the PC so the driver is not running at this very second.

Woah.

Unfortunately I don't have any -hard- factual numbers to give for my previous PC performance, I know that AIRS was running approximately 16-20fps on average, lets say 30fps on the best case, while LFS was running around 30fps in windowed mode while it was running.

My new PC, woah. I do have some hard, factual numbers to give. AIRS (on the non-upgraded version of my framework) is running at 1650-1700 fps and LFS is at 350-380 fps. I honestly don't know if it is beneficial to run LFS at a faster rate or not, that would depend how the main loop pumps through the InSim/OutSim/OutGuage messages, it is possible letting LFS update freely could reduce lag, it is also possible that it doesn't matter after say 60 or 100fps.

On the AIRS side it will allow the updating of the virtual controller more often and running the logic with smoother data, actually the prediction sensor is actually smooth! That is the first time I've seen that smooth since I first wrote it and made that video. Shortly after (I think it was adding the visual sensor?) the performance dipped and it has been jumping around ever sense.

I may rip out the visual sensor and just give the AI driver his position directly, even though that went against my initial intentions, I know now that he could (if needed) compute this by the visual reference points, although with the extra horsepower this PC has, do I need to do that?

I'm still trying to get the project working on the updated framework, it would make some things a bit easier to deal with and would fix some issues that have been fixed with the framework, but, currently having an issue getting the terrain mesh, and other meshes, rendered to the scene. That and the whole steering issue that occurred somewhere during that update, wtf?

EDIT:

In the project with the updated framework, I finally got the car and track visible again. But I am still chasing the steering issue. The good news is, like before, version control system allows me to check out every different line of code. Unfortunately, a lot of lines changed for the update, so time to hunt down the one that cause the issue.

EDIT2: I claim rendering was working, but the car doesn't rotate correctly, yay. :-(

EDIT3: HECK YEA! WOOT. Got it figured out, and glad my brain had a moment to put 1 and 2 together. Going through every code change would NEVER have found the issue. The issue was a fundamental change months ago in my math framework to use degrees for _all_ rotations, and it had previously used radians for some rotations that were untouched in airs code. Would have looked right over it. Turns out, both issues were the same thing, basically the driver didn't know the direction he was facing because the car transform was a little wonky. All working now with the latest version of the framework, woot!

Left the driver running over night but it appears to have mishandled some player IDs when someone joined to race along side him. So I woke to him sitting in a corner. I'll need to dig into that are of the code, or at least handle failure cases better, if I can.

I've recently been reading Going Faster! by the Skip Barber Racing School, part of what lifted my motivation for the project, and the first part of the book hammers in how important the line, corner exit speed and braking distances are. In that order. Yesterday I watched the driver while working and noticed he is actually REALLY bad at following the racing line he believes is best.

I think I'm going to create a completely new state for the driver for "Car Training". I'm hopeful that at anytime I could send a command like !traincar to the driver and have him automatically change track to either the autox area or skidpad. Here he would drive to the widest opened space and proceed to drive in circles. Which led me to the discovery that we humans don't think of the steering as an axis from -1 to 1. (We do pretty much think that way with throttle, braking and clutch though, I was 10% on the throttle is like saying 0.1 throttle.) So I am going to add an additional function to set steering position by angle.

Then the driver will be able to SetSteeringByAngle(10degrees) and drive in circles to get a reading on what the radius of the circle is when the steering wheel is 10 degrees to the left (or right, doesn't matter which). That is a good start to learning the capabilities of the car given any setup, vs the hardcoded values it has currently been using. There are a few problems:

1) The radius driven when the wheel is at 10 degrees will change if going 1mph or 50mph. (See below).
2) The driver has no sense of understeer. Currently I have not found a reliable way to detect it with the information I have. Hoping this helps.

I am hoping 1 and 2 can be resolved by driving the first circle(s) slowly. I think if I start at 1mph, (or at least below say 5mph), the radius of the circle will be the "expected" radius for that steering angle. After getting this reading, the driver can then start increasing speed, slowly, until the radius starts to grow. When it does start to grow, the driver will have found (and exceeded) the ability of the car.

The driver will do this over and over for several steering angles, and collect minimumRadius and maximumSpeed values for each inputAngle. With that I -THINK- I could get the understeer sensor working? Maybe? But I'm really hoping I can use it to drive the car closer to the ability of the car.

First I must see if the driver training in the car like this will be at all valuable. Then I'll implement it, and it still won't do much until I find out how to use it.

Quote from blackbird04217 :

I am hoping 1 and 2 can be resolved by driving the first circle(s) slowly. I think if I start at 1mph, (or at least below say 5mph), the radius of the circle will be the "expected" radius for that steering angle.

I don't know if LFS suffers from this, but bear in mind that many games have to change physics equations when speed gets closer to zero. Maybe starting at 20 or 30 mph if the radius is big enough could yield better results?

Your driver is aware of G-forces, isn't he? Understeering occurs when more degrees result in lower lateral acceleration. This may not be useful while racing, but if you are doing stable circles it sure is consistent.

That is indeed something to keep in mind, thanks for the reminder. I don't think LFS physics changes like that as I am pretty sure they are not using Pacejka's model, although, what the hell do I know about the physics used, not like I've ever seen the code! I was using 1mph as an example, but 20mph might start pushing into understeer for some steering angles.

I will try taking the car out for a spin myself to see if the idea works. It is possible the radius at 5mph is far different from 30mph even without being at the limit, and that wouldn't work so well.

EDIT: Regarding G-forces, he is aware of them in his physics sensor. But I've yet to find a reliable way to use it to detect understeer. He is also aware of the yaw forces acting on the car, which I think would be more reliable than lateral-g's, however there is no way to know from yaw forces alone whether understeering. It is complicated. And that doesn't say enough.

LATER: Just found a bug that any player joining causes an error message box to appear and this takes focus away from the AI driver. I will dig deeper into this and see if it should instead be a warning, or find a fix. But currently I've limited the server to run just the AI driver to prevent the issue from occurring until I can look at it.

So, interesting news. After watching Jared (the artificial driver) yesterday and today I was noticing that he was some 6 seconds off his personal best times, regardless of driving logic version 1 or 2. And it felt like steering was way off line compared to what it had been previously.

Then for giggles I changed steering range from 270 to 900, to see what would happen. He followed the line almost perfectly. And then I had a moment.

Turns out back when I was having my steering issues, I had tried some different calibration settings including changing wheel turn compensation to 1.0, I'm not entirely sure what that option does, but I found that it used to be 0.23 with steering range 270 degrees, and after resetting that the driver was much more on target with the racing line and seemed also to gain nearly 6 seconds a lap to get back into the 57s! Woot.

After messing with it a bit more, (hey .23 was better than 1.0 so what happens at 0.0) 30-40 laps in DLv2 he even beat his PB 57.15 still at 270 degrees, I wonder if 0.0 and 900 degrees will help any more which I will test in a little bit.

Quote from blackbird04217 :

wheel turn compensation to 1.0, I'm not entirely sure what that option does

LFS steering wheel animation only does 720º, if wheel turn compesation is set to 1, LFS and real wheel turn in sync, meaning that any more turn on your wheel is ignored. (That's why LFS ask how many degrees your wheel turns)

IMO is a stupid slider. You either want it to turn in sync or not. I prefer having the full 900º, other people what the sync, and others even hide driver arms or the whole wheel. I've never understood why some people use a value inbetween.

I think there might be more behind the scenes than just that, both of those values are definitely not only for graphical effects as it has a 6 second difference when wheel turn compensation is set to 0 or 1.

Time for bed, but I've got the race restart stuff worked out a bit better tonight, as long as I keep the LFS window the same size it doesn't matter where it is located and the lights can be found. Still need to modify Jared's StartFromStop behavior so that he really gives some go to the launch, currently he fights to keep the car from stalling.

Also added a way for me to manually save and load the corner reference points for DLv2. I guess the smoother frame rates have actually helped allow that logic to work instead of failing.

Finally, a quick video of the AIRS visualizations with mini LFS window:

Quote from blackbird04217 :

I think there might be more behind the scenes than just that, both of those values are definitely not only for graphical effects as it has a 6 second difference when wheel turn compensation is set to 0 or 1.

Don't you think that difference could just be based on the genetic learning you did and if steering setting changes it just goes crazy?

Anyway, impresive video, it feels faster than what I was expecting, and it handles the bounce out of the kerbs pretty well.

Genetic algorithm in here will slow. Need a lot of time for learning.

Whiskey, no it wasn't his "learning" that I saw in the difference. First he doesn't actually do genetic learning he just modifies brake points and corner entry speeds, and the difference is immediate and reproducible. Those values definitely effect physics also.

repeat83, indeed I can't really use genetic algorithms here, although I did play around with it in a small side project. Too much variation in lap times just based on the LFS <-> AIRS <-> LFS lag, that and only having a single test subject would indeed take forever, fuel load would constantly change, as would tire conditions etc. (Those points could be saved by restarting for each test, and the consistency could average out by running more laps for each "individual", so it is possible but like you say would be slow!.

I tried modifying his launch behavior last night, but there is a bug in there that I don't yet understand. In other news, he was still running laps when I woke up this morning so the race restart logic seems to be finally working.

But last night I also tried loading some other tracks, even tracks that I had previously been able to load, and it appears there are some issues with either a) the track edges, center line and racing line computations, or b) the corner detection, braking, entry, apex, exit computations, or c) both. I know the corner detection needs to get a little better, especially from what I saw loading FE2. Some of the apex finds were a little less than desired.

For today, I'm going to let him spend some time at FE1 and I will periodically change his car. Obviously some cars he will be awful in, and others will do okay. Since he is applying 100% braking I suspect only cars with ABS will have any chance of working, so on the list after the understeer sensor and better following of the racing line will be the braking behavior.

Reduce the braking power so low in the setup that lock-ups don't happen, for cars that don't have ABS.

That is a really valid point, I'm now giving it a try in the FOX, and after also adjusting tires, pressures and adding downforce he seems to be lapping. Lets hope he stays within his limits! He is a little throttle happy though, so for LX6 or FO8 I would need to add intake restriction also.

Though in general I do avoid to tailor a setup for him.

Quote from blackbird04217 :

Whiskey, no it wasn't his "learning" that I saw in the difference. First he doesn't actually do genetic learning he just modifies brake points and corner entry speeds, and the difference is immediate and reproducible. Those values definitely effect physics also.

My bad then. I must have mixed some things in my memory, pretty usual on me

A second (and last) thought about the wheel turn compensation, 0.23 might result in a non-linear input, therefore the AI can't determine how many degrees the car is going to steer at any given actual state.

Whew, was busy today.

Started by adding a bit of extra information to the insim interface for those that joined the server to see what the AI is thinking/doing. As in, you can watch DLv2 adjust braking point and entry speed.

Then I got tired of Jared (the artificial driver) launching from a stop so bad, so I spent a lot of time there and ended up rewriting the entire state. Instead of using a timer to lift off the clutch and press in the throttle, I added a bit of logic that seemed to work in my head. In some cars Jared will launch about 90% as effectively as the LiveForSpeed ai on Pro. In other cars, he doesn't do so well. LX6 is what I used for most of the testing.

It is a remarkably short period of time, I had to watch a replay in 0.125x speed to dig into what was happening, and watching the LFS ai didn't help. The logic I used can be found in this blog post on my site.

While watching the starts over and over, I noticed that the driver waits until the green lights to put the car into first. Why not prepare that during the red lights?! It was almost as easy as pushing a state during the red lights, except, not because the car would stall. I opened the ShiftToGear action and modified it to have a case where it could keep clutch pressed, for waiting on the grid in gear.

While in there I decided to add in support for the MRT which has the special case of downshifting to get into first. Success. Jared can now drive the MRT.

I did a lot of watching today and even tried a few different tracks, BL1, FE2, SO3, etc, and the only track that is working really well is FE1. Partly because it is still using my hand created layout, and partly because most of the algorithms that process the track (center line, racing line, corner detection etc) were written and tested primarily with FE1.

I think spending a little more time on the basic racing line and getting the corner information corrected could go a long way in allowing Jared to drive faster laps. While BL1 and SO3 were working, they did throw some errors/warnings at me and the corner detection was a little, off. For instance SO3 turn 3 started at turn 3 and ended down the back straight after turn 6. As much as I can I want to avoid feeding hand crafted data to the driver, so I need to spend some time to figure out how to process the data better.

On another note, On FE1 with the XRG Jared is faster than the LFS AI on Learner mode. As long as he starts, or gets, in front he can start pulling a gap. He still doesn't know about other cars, so he won't pass cleanly, and will probably take himself out if he comes up from behind on another car.

This is not for everyone, but if interested in watching a development stream, some people seem into that, I've started streaming and probably will for about 45 minutes or so.

Stream Live at: www.twitch.tv/timbeaudet/

Or swing in the SRS:TestingGrounds server and say hello!