I now understand what you mean a bit more with just killing off the genes that go off track, I will certainly look into that suggestion! I'm still not sure how to apply the GA to a driver, but am looking forward to the moment it clicks and will continue trying to understand it a bit, learning is fun.

In other news I was watching the artificial driver lap around FE1 while I was working today, working from home is great, and besides the fact that the driver was not staying on track due to my recent changes, and too much wobble, as Tood and I have discussed a few times not too long ago. In watching it some more I realized that he would start braking for the turn as expected, but then stop, then start, then stop. The reason then clicked...

I have several points ahead of the driver, soonToBe, farToBe and farFarAway. The driver scans the track at several distances ahead so that he can start braking earlier for a turn, and it was working, with the exception that he would immediately forget about it once the angle of the track at those points increased, even though he hadn't actually arrived at the turn. (So he detects turn 1 is coming a the point farFarAway and starts braking. Before he gets to turn 1 the farFarAway point goes well beyond onto another straight portion so he stops braking, because the other points were not at T1 yet)

I modified the code slightly so that if the angle at those points is greater than some value, he will remember the maximum value it was at, and the distance to travel before reaching it. That way he will continue braking until he reaches the point and not look too much further ahead. This, in combination with the stuff I did a few weekends ago to make him drive smoother, has resulted in MUCH lower lap times. A 1:03:66 was the first new PB shaving more than 6 seconds off!!!

The current problem I saw is the racing line isn't as smooth as it once was because I didn't let the iterations play out for a long time, it only has 5000 iterations where 100k would be much better. Before running the racing line computation again I decided to watch him do 5 laps so I could give you all this replay, attached. He still needs to tone down on the wobble, and I will look for a fitting way to do that (without messing with the distances too much). But in the replay the artificial driver hit the new low of 1:02 (Okay, to be fair it was a 1:02:990).

I'm going to let the track recompute and save out a better racing line and then will run the test again to see if it helps, it should help a little, especially in the final downhill chicane, where the current version tends to get a little wobbly and can sometimes lose control of the XRG.

Enjoy.

Edit

After running the racing line computation for 300k iterations, and saving the new copy again, I came up with the second replay and another new personal best on laps 4 and 5! I wonder a little bit if tire heat is playing a roll. But I know the wobblyness is certainly playing a roll, will keep pondering a way to reduce that without adjusting the distance and/or cutting corners, a previous problem. Both replays are attached. The new PB 1.02:12 is actually much better than I was expecting it would get. Going to attempt a really long run of 100+ laps to let it actually see what it will get down to, I suspect at least a 1:01:7x is possible.

Edit 2:

After running 70 laps, with a new PB of 1:01:81 on or before lap 6, (can currently be seen on LFS World for airs_artificial_driver ) I noticed a pattern. First, the wobbling that I've been talking about today is effecting laptimes, a lot. The first sector is consistently in the range of 28.4x to 28.7x and averaging low 28.6x's - which is not terrible consistency given the wobbly, lag, etc. However, the lap times on the other hand, were averaging the 1:04s, and could bounce from mid 1:02's to high 1:05's. Which shows how inconsistent the second sector is, mostly due to the wobble.

Unfortunately, this really sucks, I was an idiot and didn't look at the setup the car had on it before changing to the LX6 to see what would happen. This thought hit me immediately after selecting the LX6. Why couldn't it have happened before. So, I tried default and 3 other sets that I felt were likely candidates but none of them are producing similar results. This sucks, and it proves how much the personal best will come down to a setup. When I find it, or come across another decent set, I will give it a name that will be easy to find in the future. Unfortunately I can't test fixing the wobbly, or other things until I find the setup or make new benchmark numbers which might even be slower.

On the other hand, given the behavior I did notice I could make the driver brake later than he does. I haven't done it yet, I wanted to remove wobbly steering first. But with a little tweaking of the speeds, I am sure sub one minute times are possible. Lets hope I can find the setup again, otherwise I'll need to redo the benchmarks before moving on. :-(

Edit 3:
Still looking for the setup. None of them seem to be reproducing the results I was seeing earlier, which is - super annoying. I haven't seen a single 1:02, or even a mid or low 1:03 for that matter, if I have even seen a 1:03... Most of the sets seem to be braking too hard on T1 locking the tires. I did some investigating watching the replay and was able to figure out that the set is using plain and normal tires, so I've been attempting to go through all XRG sets that meet that standard and I have like 10 of them. I'm just thankful it wasn't using Bridgestone as there are many more sets there. The crappy part is my choosing of the set is based on my memory of what was happening and what is happening, and the circumstances are different every lap anyway due to slight discrepancies in the lag/timing. I almost wonder if I've dismissed the good setup already, but I honestly hope I did not.

Edit 4:
I think I've found the set. This one seems to have lap times between mid 1:03's and mid/high 1:05's. Considering those fast laps earlier didn't appear more often in the 75 laps, I guess they are more like lucky laps than anything else. Still, 1.01:81 is nearly 2 seconds faster than what the artificial driver is doing, but this set feels fairly consistent with what I remember seeing earlier. Not exactly watching it full time, but the lap times are within the correct range. I suspect the 1:01s are possible when the "wobble" effect is minimized by chance, allowing better ending. As I saw before the first split is reasonably consistent, although it appears to be slightly slower at 28.6x to 28.8x but maybe that happens as fuel wears? I'm letting him run a long distance again, and will make sure to keep this set marked.

Last edited by blackbird04217, Tue, 3 Jun 2014 18:55.

I knew someone would pick on the messed up, sharp turn 1 where it overlaps. It shouldn't make much difference as those are there simply for our visual reference at this point. The track was defined by the center line and a width, of course that does mean that turn 1 has a radius that is tighter than the track width, hence the overlap.

I'm not sure the additional drag should slow the learning any more than just keeping the car on track? I could be wrong but I would think if the algorithm attempts to drive off track it will die out because the distance covered is to low, or a lap time is too slow. I suppose it is possible that an off track lap time results in a faster lap, but that can be thrown away by making sure the car was on track the entire lap.

I'm actually at quite a loss of where to go from here though. From my reading of GA I'm not quite sure how to apply it in this situation. I'll keep reading I guess!

So I've created this, extremely simple, top down racing "simulation".

Screenshot

It is as I described in my post above, with the addition that anything off track adds a huge resistance, like a sand trap that you can get out of. It is complete with checkpoints and will time your laps. You can use the arrow keys to control the car, and console prompt that appears will show you the lap times. You must be on track when going through the checkpoints, there is no give with that at the moment.

Now I can use this simple simulation to attempt to create a genetic algorithm or artificial neural network and have several cars as well as speed up the time so everything runs much faster than real-time. Let me know what you guys think of the extremely simple simulation.

Last edited by blackbird04217, Sun, 1 Jun 2014 18:17.

Of course, I'm thinking of pretty much the most basic of "simulations".

The world would not have gravity, but it would have a resistance to objects that are moving, pretty much air resistance. (No wind, slip streams or other effects), there would be no friction or any other objects besides the cars.

The track would be defined as a several curves linked together to create a circuit, and a constant track width. For visuals, this will allow me to draw the famous lines to outline the track.

The car would be defined as a world position (x,y) with a radius, so the car bodies are simple circles, and a direction (x, y) which way the car is facing / driving.

Once I get to a black screen with the ability to collect input from the user I will time myself to see how long it takes me to make a track representation, a car that can be controlled via the inputs: throttle (0 to 1), brake (0 to 1) and steering (-1 to 1).

I don't expect it would take too long, however I don't yet have working input in this project, so that comes first and that might take a little longer.

Increasing the distance of the point the artificial driver aimed at made him tend to cut corners a bit more, and essentially hit the tires in the chicane or the tall curbing on the sharp 90 degree turn. Although you are correct looking too closely on a straight tends to make the driver wobble from left to right as it goes beyond the desired direction. Interestingly, I tried solving this problem much earlier in development by interpolating the actual steering input in a smooth step or inverse squared manner.

Essentially the idea was that the closer the driver already is to the desired direction, the less he would steer towards it in a non-linear fashion. This sounded pretty intuitive to me at the time, however it resulted in the artificial driver turning in far later than he should, because it takes longer for his steering angle to actually increase, I decided to remove that and simply steer linearly.

I'm taking a break from the project currently to do some other things in life, but it is only a matter of time before I get some thoughts jumping and wanting to be tested. It is really unfortunate that I can't get the predictions to be smooth enough for actual usage. I was hoping to get the artificial driver to change the inputs based on the predicted position/direction and desired direction/position. Theoretically, this will automatically look further ahead when travelling at speed and should, also theoretically, reduce weaving/wobble on a straight. I do see a slight potential that it could actually make the wobble worse.

I may work on a very small, two-dimensional racer project just to try out the genetic algorithms and possibly ANNs, they sound neat in concept, and it also sounds like one of those very rewarding things to create. Watching the cars get a little better would be super neat. I will not be using true physics in this project. That is actually quite advanced. I may simulate the engine, clutch, gearbox properly, but that force will then just move the vehicle forward, and turning will simply rotate the vehicle instead of applying torque with the front wheels and adhering to the ground with friction. Simplifying everything only to play around with learning algorithms.

Yea the attempt of looking ahead is to get the AI driver to start braking as a turn is approaching. I am trying to avoid giving the driver the information about throttle/brake or speeds information by recording my own (or using WR).

The ANN stuff does scare me a bit with the "unknown" "magic" black-box. I understand it comes down to the training algorithm and unfortunately by using LiveForSpeed I am limited to real-time so I can't really fast forward, or use a swarm of any sort. The best thing I can see doing for the fitness routine is a full lap, or at least most of a lap.

I admit it would be neat to watch the AI driver learn how to drive, and hopefully, learn to get faster and faster. But you hit the nail on the head - it removes and ability to control it. My idea here was to feed in several points ahead of the driver (in driver/car space) and make the ANN take control of the throttle/brake/steering (shifting could be handled logically) and try to follow the given line.

This way when I decide to add other cars, or pit lane, the same algorithm can be used, and all that I need to change is the desired line for the car to follow. That was my concept anyway. It might even be possible to train the driver this way by using sections and the fitness be a function of how closely the last 100 meters was to the desired inputs.

Still unsure about using an ANN though since training it could be tricky and it can't be modified later, might be neat to watch.

I just went through the entire thread, skimming along the old posts and spikes of progress over the years. It certainly seems that 2009 was mostly tossing ideas around, a lot of very long winded posts. 2010 I kicked it up with some prototyping and threw together the first replays of the artificial driver driving with a virtual controller, of which now throw OOS errors. After an extended break and some refactoring of the initial code, 2013 comes back in for the challenge of creating a racing line, given only the left and right edges of the track. Fairly successfully.

Then since the beginning of 2014, by far the most improvements and progress has happened. Created the Visual Sensor, Car Sensor, Physical Sensor by gathering all possible information from LiveForSpeed, The Memory Unit and Prediction Unit looks amazing in their video, - unfortunately they don't behave quite as awesome despite a lot of effort trying to make it work.

The artificial driver now has an S2 license and the current personal best for FE1 with the XRG is a 1:09:920 however with the changes today (see the post above) this is no longer his current time as he lost speed... Ughf.

I am reaching a point where I need to gather thoughts and find an angle to attack this project from. In some way it would be nice for the AI driver to learn, and ANN's have appeared many times throughout the thread, I'm still unconvinced it would be worth doing, or really even how to fully implement. I've seen multiple implementations for pattern recognition or such, but it doesn't quite click how it would be used in this particular situation.

It is easy to see the inputs would come from the sensors, visual, physical, car and maybe even a "desired path" (probably a portion of the racing line, though with room to modify).

//-----------------------

Then I go back to one of the fundamental ideas of the project, and I realize I have strayed slightly. The driver is using the Visual Sensor and reference points for detecting his position, but he should be using them to signal when to brake, turn and exit a corner. This is, of course, much easier said than done.

There are times when programming can just beat you up. I spent a large portion of my weekend working on the AI project, I did make a little progress, but not nearly as much as I desired. The reference point manager will now save a "processed" file to disk including the track edges, center line, racing line, etc. This drastically increases load time and I no longer need to do the ugly code changing/copy file contents hacks in order to change tracks.

However in the process of doing that I ran into troubles left and right. Finally got it working. The next step planned was to break down the curve by estimated segment lengths, which is actually not working as expected. I'm still debugging that portion of code. I will eventually need to save that in the processed information also.

I've done a bit of reading on neural networks and am still at a loss of how to go about implementing this. In some manner it sounds pretty straight forward, a set of inputs, random weights, a set of outputs.... How that will help the AI drive at all is so far above my head I stopped searching for the moment.

I need to section the curve by length for an optimization, I also need to find the point on the curve that is closest to the drivers position, which is actually a very troublesome problem it appears, and my math knowledge at this time is unfortunately too low, need to level that up a bit. I do have ways to make it work, but it will be slower and slightly less accurate - the accuracy in this particular situation shouldn't effect much, it is essentially the "drive to point" on the racing line.

Once I get that curve broken down for the optimization, I should be able to get the driver to look further ahead and realize when he is on a straight section, and maybe improve his logic a bit from what it is now. It is actually miraculous that he can drive a high 1:09.92 at FE1 in the XRG. I realize that is not a special or fast time by any means, but his logic is pretty dumb at the moment.

EDIT: So I've finally have the ability to [u]roughly[/i] break down the curve based on a distance from start. I went ahead and tried using this without the optimized lookup table, and it actually works... for the first third of FE1. So now I need to process the curve into a more optimized structure like I was expecting but hoping I didn't need to do.

I am still running into the same issues with the memory/prediction units that I had a few months ago. I'm not sure the artificial driver will be able to rely on using the prediction unit for determining over steer / understeer or "at the limit" like I had previously planned and hoped for.

Just added a little bit of code so that instead of always looking 20 meters ahead, the artificial driver will now look from 10 meters to more than 40 meters ahead depending on vehicle speed. This has not proven to help lap times yet, because with the performance issues for two thirds of the track the artificial driver weaves back and forth over correcting like a maniac... Caused by low sample/simulation rates, not of LFS).


A little later. . .

So, I have succeeded!! In making the artificial driver [u]even slower!!![/u] His best laps around FE1 are now in the mid 1:23s... Awesome. I was attempting to change the way he used the throttle and brake, attempting to make him a little smoother. It is tricky though, I certainly need to find a better way to perform this logic. Currently I'm using angles of points along the racing line, essentially a tighter radius turn results in higher angles and using this I've been attempting to modify the throttle/braking inputs. With little success.

Obviously there is more to just the radius of the turn to take into account, such as over/under steer. But this is very similar to the approach I had previously and yet working so much worse. Maybe it was simply better to treat the throttle a little more like an on/off switch... Let me try making him have a heavier foot.


Backing up a bit...

I've now added a new supported track for the AI drive, I use the term track loosely. It is actually the skidpad.



The prediction and memory units are still having troubles and I've temporarily run out of ideas on how to solve that. I am going to attempt to use the skidpad and maybe an autocross layout, if I can figure out how to do a multiple lap playout, to with any luck create the logic to sort out if the car is at the limit, and if not, push harder... As well as get it back under control if it is over... This will be challenging to say the least and at this moment I don't know exactly where to begin.

Last edited by blackbird04217, Mon, 26 May 2014 20:39.

I should have seen that one coming... Having a few issues converting the Reference Point Manager (which contains the track edges, center line and racing line), to use curves for these instead of a container of points...

The first issue is nearly everything wants a container of points, not a curve... I tried to take a short cut by converting the curve to points, but funny enough, by doing that the data gets too dense for no benefit. Drastically slows the loading process.

I should have seen that coming.

In other news, the driver can, mostly theoretically, shift a sequential gear box, although watching him drive the XRR nearly killed me as he couldn't get the car moving. Stalls every time, so needs to be a little more aggressive with launching that car, all cars really as I haven't yet done that logic.

Good weekend to all,

Well, it is a good weekend for the Artificial Driver. I am not sure whether or not they want to remain anonymous or not, so I will err on the side of caution until I know otherwise - someone generously gave the AI driver an S2 license.

This means we can now track his mileage, personal best laps, fuel used, and ... you can actually see him if I get a server setup. I actually just set one up on my local machine, however port forwarding has always eluded me and the world may not be able to connect. His LFS user name is: airs_artificial_driver

I'll reach out to some people to see if they want to lend a server, to allow anyone to actually visit - if they so wish - during the development to watch the artificial driver live.

I've also been thinking about giving the AI a single state to allow for "learning". I will still be programming logical states, but I will take a look into how hard and complex it actually might be to create and apply a learning algorithm. My thought was to input car speed, engine speed, car gear, etc etc... car position, input positions, and most importantly the 5 to 10 points ahead of the driver that are on the racing line.

The outputs obviously would be the control positions. I don't know how this would work exactly, as I've never actually implemented a learning algorithm and still think it'd be too complex for the scope of the project, but maybe a side project within. For scoring how well the learning is doing I would take some distance/time parameter of the desired and actual course followed. The closer the actual course is to the desired course - along with the faster overall movement, the better.

I'm not focusing on that right now. But will at least peak into create a learning state just for playing around with....

Back to the current plan....

Now that the AI can join a server, I'd like to be able to change tracks a lot, LOT, easier than I can currently. Currently I must adjust some code to allow the Racing Line to be computed, wait 5 to 10 minutes while it optimizes the geometric racing line, then outputs that to the file which I then paste into the code and adjust the code so it doesn't compute the racing line next time...

The plan is to save out the racing line and other reference points into a file that can be loaded quickly, with version identifier so if I ever modify how the racing line is computed (I do plan to in the future) it will update the file.

Also planned, is to get the artificial driver to be able to drive/shift the cars with a sequential gearbox - which shouldn't be terribly hard, but currently he only does H-shifter. He may not be able to drive the MRT only because it would require some extra logic for first gear to shift down from neutral, and no reverse, but I maybe?

So if you want to check out the progress live, try finding the user: airs_artificial_driver

Warning: The driver may not always be online. The driver may be sitting on the grid, spectating, or stopped in the course for large chunks of time as I tweak or write more code. The driver will not respond, but if I am around and see you join I will attempt to get him running. He is not competitive at this time, and will not pay attention to the location of another car.

Last edited by blackbird04217, Sat, 24 May 2014 12:38.

Yea Gutholz, like I mentioned it doesn't have a proper timer yet.

I am still placing it by hand, but with the curves it makes this process much better and eliminates any problems I had in the past. Still takes time to make new tracks, but it isn't too bad.

I actually started a basic track for the autocross area, and I will continue working on that a bit until I'm happy with it, although the project is taking a bit of a back burner or still low priority with other things in life taking my attention.

I actually got it working. I am not 100% sure the "normal" is correct for a curve, but it will work for all situations I can think I'll ever want, (normal = cross product of UP and tangent). Basically I may have cheated a bit there, but it will work for my needs.

It isn't a video but it isn't hard to imagine what the video would look like, this is my testing application for the curves and it seems to be working pretty well:
Screenshot 1
Screenshot 2
Screenshot 3

Ignore the two red dots in the first screenshot, I was attempting to take multiple screens quickly, but it failed.

NOTE: I've actually added the application, it doesn't have a proper timer so it may run SUPER fast or SUPER slow for you, but running it allows you to see it in motion, if you care that much.

So I think that is working better, now to put it back in the AI project and multiple steps to make the center line computations use the curve, then the racing line computations... Ughf.

Last edited by blackbird04217, Sat, 10 May 2014 00:22.

Okay, in my test kit I figured out what I was doing wrong with the tangents.

Screenshot here

I still have to clean up the code in the bezier curve. Dygear, if you are planning to use it, the above zip has a few quarks about it that I was silly about. (In particular in the Curve Section structure, A is the start, B is the end and C / D are control points. I am going to modify it to be A as the start, D as the end and B and C as the controls. As well as test the isLooping more, and implement the non-looping mode too.

Dygear; The files are far from complete, however, here I will share them in their current state. I added a little documentation where things were not yet implemented, but it should be enough to get you started.

EDIT: After a little bit of actual testing I've found that isLoop is actually not completing the loop like I expected. Glad I setup a test kit for this...



I am trying to implement a way to get normals and tangents from any point along the curved path to actually make use of the curves in the racing project. Gutholz; I will swing back around to your idea of a practice layout on the autocross area once I get the curves ready. Otherwise making new track layouts is much more painful than it should be.

Last edited by blackbird04217, Fri, 9 May 2014 23:34.

Ahh, yea. Now that is a grand idea. I think setting up one layout around the autocross circuit would be great, then I could put the drive into a car with a understeer induced setup until he can control that situation, then put him into an oversteer inducing setup until that is also handled.

Then move to the autocross and setup the ultimate "practice" layout with two most of a circle turns, one tighter than the other, linked by two, (or more), slaloms, one slow one faster, could prove useful for getting the driver to handle different car conditions.

This will still require me to get the prediction unit working at the appropriate level so the driver can actually understand what the car is doing.

Dygear - Not sure if you are familiar with C++ much or not, but once I finish my basic "Curve" object I will upload the class header and source and from there you, and others, can use it how they wish.

The class currently:

Makes a curve from a set of points along the curve.
Allows you to make a container of points from the given curve.
Estimates the total distance. (Estimation only because it is a curve and the more steps the more accurate the estimate but it will never be exact).

This is an image of adding curves to handle the track edges, center line and racing line. You can clearly see the better precision the curve math will have, but the major benefit and driving force of this improvement is for adding tracks easier.

Lines vs Curve

Although the Curve is visible it is still quite a bit of work to make the Reference Point manager use curves completely. But once it does that will be great.

Just opened up the AIRS project again, decided I tracks should be easier to create and a bit more accurate. So instead of using line segments for the track edges, I am attempting to create a bezier curve that lies along the points represented by the track edges.

Using a curve will allow a much higher level of accuracy as well. The primary reason for doing this is due to the failure of my attempt to add AS1R as a driveable track. Well it wasn't a complete failure but it was made much more difficult than it needed to be. One of the line segments had turned TOO sharply so the centerline algorithm could not find the other track edge correctly. (The perpendicular line went down the front stretch). It took nearly half a day to track it down and correct it as I wasn't able to just move the cone in the layout file - that seemed to reorder the cone and mess up the entire layout file as AIRS would be expecting the cones in order.

So, by converting the points into a curve it should remove that possibility entirely and allow the layout to be created with FAR fewer cones, making it easier. Also by doing this, I have the option to give the AI driver direct access to this curve, or to create N number of reference points around the edges to be tested against, or both. It also means I will be able to use the mathematics of a curve to represent the centerline and the racingline.

Unfortunately, this involves redoing a bit of work that I've already got completed, but hopefully it will make things a lot better overall, certainly easier for a new track.

The inputs from LFS are running as fast as it LFS lets me, so I get approximately 100 updates a second about the car information, and I have added a some prediction to this to attempt to smooth it a little more when there are bigger delays between packets...

The low FPS of the sensors is a big concern, certainly, and it would make it hard to drive. I've actually driven a handful of laps using only the view available from the AIRS screen- I can't hit near PB times as there is some lag between the game and the update, but it was reasonable.

The racing line computation, as it stands right this moment, is creating a geometric racing line. Meaning it is pretty much the smoothest path while remaining in the borders specified by the track edges. I won't get as detailed to do per car, or per setup racing lines, however I would like to take another pass at the racing line in the future to attempt to add "sacrificial corners" or to change the apex. As in, taking the geometric line through a corner is reasonable for fair laps, but taking a later apex should help enter a long straight with more speed.

EDIT: Yea that graphic looks pretty neat. You are spot on with the faster it goes the more difficult it is to drive and control. There are a few things the driver needs to learn, (be told how to deal with via programming), in order to drive faster. Among the first of those, it to be able to see/plan for further ahead the faster he goes. Right now it is programmed to aim for a spot about 20 meters in front of the car and has a temporary "look ahead" point on the racing line of about 60 or 70 meters in front of the car. The braking is dependent on the angles, but he needs to look ahead further than that when going faster.

That and I need to teach the driver how to actually use the Prediction Unit more in order to understand the "limit" of the car and to predict. Such that, if the prediction unit shows the car is going to go off track, SLOW DOWN. If the prediction unit shows an oversteer situation, handle it appropriately. Etc.

Last edited by blackbird04217, Fri, 4 Apr 2014 17:58.

DANIEL-CRO - I am actually already getting the data from OutSim, but the Sensors, MemoryUnit and PredictionUnit update fairly slow because of the problems I ran into above. It is essentially why I've lost some steam on the project. I did make a very good attempt to smooth the values coming in from OutSim even more and it still fail when I turn the speed of the Sensors and MemoryUnit / PredictionUnit to be faster. Fails in the sense that the PredictionUnit no longer has any curve, and it acts very bizarrely.

Another issue that you may be unaware of is my machine capabilities are being pressed extremely hard. My machine is a bit outdated: (Intel Core 2duo 2.4ghz, 2gb ram) Graphics cards should not be the slow down, however I am running LFS and the AIRS project on the same machine, both take significant resources as each of them want to run full throttle, and I've already taken a lot of steps to optimize things in AIRS. Ultimately more machine could help, but the reason of the choppy steering is the delay I've set on the sensors, which was set to make the predictions more accurate.

I'm not sure why running the sensors faster caused the predictions to be less accurate, I designed and implemented it in a way that time between memories shouldn't impact it, but to my surprise running the sensors and memory/prediction units at the faster speed causes glitches. Also, even though I am getting the position of the car through OutSim, the AI Driver is estimating the position based on the visual reference points, and this is what it uses to drive, along with the fact that I don't update the "drive to this point on the racing line" in real-time, which could help the driver be more smooth, and smooth is fast so it might be worth investigating. At the speed he is traveling I doubt the jerky steering input is causing traction issues.


Gutholz - Thanks for the comments. It would be POSSIBLE to create a "track" on the autocross park to avoid the curbing and bumps, but I've made it so it will load track information based on the track reported by the InSim, in hopes that one day the AI Driver could drive around any track that has a layout made for it. That said, it is something I could hack in, "if the track is AU, then load the AU track" which would be easy enough, so maybe worth considering.

If you want to attempt to make an autocross layout, and can follow specific directions, I could give those to you and attempt that. Also I am open to suggestions for other cars to start with instead of the XRG. I would prefer rear-wheel drive, but at this time the driver can get into any car with an h-shifter. Funny, the driver doesn't yet know how to use a sequential / paddle shifter but that wouldn't be terribly hard to edit. I am open to suggestions and if you want to guess a lap time around FE1 with a particular car I can easily setup a 5 lap race for the driver and see how close of a guess you came. (It might be possible that some cars would require more tweaking which won't happen at this time. In some cars, if the driver gets going too fast on the front straight he doesn't brake early or hard enough before T1 and slides off.)


The Very End - As Gutholz said I've actually created my own AI driver. A completely separate program that is controlling the Player car in LFS through a virtual controller. Back in the thread Dygear was interested in seeing how the PTH files the AI uses (and the racing line displayed in LFS) compares with the racing line my algorithm generated. There was also an interesting comment of modifying the PTH files based on the WR replays. In my Computing the Racingline video I added these paths as the white line that appears near the end of each section.

I thank everyone who has followed this project, and I will return to it with more energy at a later point in time. I am happy to have the driver successfully driving around FE1. The driver is not yet using the Prediction Unit very much and that is something I'd like to improve upon, but I need to make it run faster as I was discussing with DANIEL-CRO.

Last edited by blackbird04217, Thu, 3 Apr 2014 17:15.

I'm waking this project up for at least today. Felt some motivation to try a few things, including adding a new track. That has actually been quite an uphill battle with some of the assumptions I made previously. I did eventually get AS1R data to be loaded, however, it fails computing the center-line of the track. must have messed up ordering the layout cones in some way.

A bit frustrated, I decided to try again with AS2. There shouldn't be anything special about making the layout file beyond making sure NOT to modify or add a cone out of order. Such that, each cone you add along the left edge of the track must be further along the track than the previous. I have a feeling, but no way to tell, that I miss clicked and added a cone behind one, which makes the track out of order.

For temporary purposes I've added a list of sub-actions for the driver, which will allow the driver to shift and turn at the same time. I also have the driver shifting up to third, and to some degree 'braking' for a turn. This is not yet using the prediction unit, and is only using the racing line. The AI is still very slow, but lap times dropped from FE1 (1:30.82) down to (1:10.96). The attached replay is with the AI driving, following the racing-line pretty well with three states: "Full Speed 50% throttle", "Take it Easy 30% throttle" and "Full Brakes 0% throttle, 50% brakes.

When the AI is shifting in this replay he is not updating the thought process that controls turning or brakes, which is why I've added the sub-actions. More replays may follow. Lap 5 is the fastest lap, and as you can see the racing line clips a tire, this is why I wanted to go to another track and attempt to build the track edges a bit better.

CarlLefrancois: That is close to how I develop, although there are other times where I'll go into prototyping mode and get incredible amounts of stuff done in very short time, often though that ends up falling to pieces because the code quality was suffering from "trying to go to fast". I've certainly witnessed the walk before you run building of a project works much better for the long term, which is how I know I'll be able to come back to the AI project after a break and still get things done.

I also already have the racing line computed by the AI driver, giving him only the left/right edges. It comes out reasonable well.



jtw62074: I've already fully grasped the challenges of getting the AI to behave exactly as I want, and I don't even have a notion of how I want the AI to behave, which makes that even more challenging. But a large portion of the project, probably the largest portion of the project, has been dedicated to making the AI approach driving in a way similar to what we do. Obviously that approach differs even from person to person, but hey, I'm just playing with different things to see what results.

I've never expected the AI driver to be fast, or fun for that matter. Just seeing what happens.

//-----------

As a side note, I did open up the project and got the prediction line curving properly, only if the framerate of memories/predictions is turned down. I don't understand why that is required now that I've added the client side prediction.

Well, I am again running out of steam on this project, as slightly hinted to in my last posting. I did get the client side prediction implemented for OutsimPacks, however to my surprise that did not help. Which I've tried investigating, but for some reason the prediction unit gets extremely fragile and breaks as the time step decreases, but leaving the time step where it wants to be, will leave the driver with invalid information. It made complete sense why this would happen without the OutSim prediction code, but not sure why it would continue.

The prediction unit is no where near as smooth as it was in the video and unfortunately because of this I have been draining myself trying to get it smoother. Without the smoothness of the prediction unit I am unable to make the AI driver follow the racing line based on his prediction. Hell, just moving a "go to point" along the racing line makes the XRG too wobbly and eventually fails.

I was really looking forward to getting the driver to navigate around an LFS track using the prediction unit before getting to this point, however I know the project is not over and I will revisit it again in the future with more steam, so remain subscribed to the thread for future updates!

The primary goal has never actually been to drive at competitive speeds, although it would obviously be a nice thing to achieve. As you stated, it is a project to have fun with, which is why it takes as long as it does. I actually suspect I'm running out of steam, but I am interested to see the artificial driver make a few laps using the prediction unit instead of the "drive to point".

Last weekend I started on a drive to point action, so I could get the AI back on track, and I figured constantly moving the point along the racing line would then be reasonable for the driver to make a lap. Unfortunately, even at slow speeds, the AI gets too wobbly, the racing line too close to the track edge and eventually loses control by the chicane of FE1.

This is a good deal due to rate of input not being smooth enough, so I need to add a little client side prediction at what the next LFS inputs will be.



I want to make it clear I'm not adding error yet, nor will I try until I get other things how I want. The reason for the error is so the AI doesn't take the 'exact' line every time simply based on the sensors, not to make the AI worse, although admittedly it will not make it a better/faster driver.

I'm not so sure that I am actually prototyping, certainly trying something new, but the prototyping happened much earlier in this thread when I had proven that I could get all the data I needed from LFS, and that I could control a car, to some degree, in LFS using a Virtual Controller.

The geometric inverse is not what will introduce the error at all, actually that would be a bad inverse, with the exception of error in the floating point computations.

It is already done this way, and I'm not going to remove it to simply move the world coordinate for estimation. Actually as it stands for this moment I want the AI to have 100% accuracy with his Vision Sensor and perceiving his world space position to eliminate any problems. This is exactly how it works right now, with a note of where error will be added in the future.

coneA, coneB, coneC, coneD ... coneN all have positions in worldSpace.
The Visual Sensor knows the worldSpace position and orientation of the car/driver.
The Visual Sensor tests each cone, for field of view, some cones will fail here and not continue.
Then the cone is tested for visibility, cones hidden behind terrain will fail here and not continue.
Finally the Visual Sensor will take the cone and bring it into driverSpace: computing the direction to, and distance to the cone from the drivers eye. there will be an estimation here, that doesn't exist yet.. The distance and direction in driverSpace is stored.

Only once all cones go through that process will the Visual Sensor then perceive the world space position by applying the inverse steps for each distance and direction. Averaging each of those together to get the perceived position in worldSpace. It is done this way so that once the estimation randomness is added, the position is not given.

This is the way my brain thought to solve the problem while sticking to my own beliefs in the project. It sure would be easy to say:

perceivedPosition = worldPosition + estimationError;

But then it isn't based on the same estimation errors in the Visual Sensor, and, I feel, is just fed to the AI. I want to make it clear I'm currently working without any error algorithm in the Visual Sensor, and will continue doing so as it will be a hard enough job without adding the errors.

As you've pointed out earlier there is much more difficult, challenging and interesting things about the project than perceiving the worldSpace position. I think it became a big deal because I sat down to attempt solving it without resources before deciding to use the transform matrix, which oddly enough was used before Todd mentioned using it, and I explained that right after he responded, I admit I should have made another post prior to that explained the solution I came up with. I usually do that and in this case it came later but was explained in post #322.

I am sorry if I seem stubborn on this point but I don't find reason to change something that is already working, especially when I feel the alternative is less true to the overall idea of the project. I may be bad at explaining my overall ideas.

I do appreciate the thoughts, ideas and conversation this is sparking.

I have found a new problem, which I always had in the back of my mind, that will need to be solved before I can go much further. Early indications were that the sensors jumped around, and visually in AIRS the car would jump around. The cause is simply the delay in input from LFS, networking, etc. But it exists, I've gone on ignoring it, knowing it would add a little error to the AI (that is unintentional error) but figured it could work.

Anyways, I recently sped up the rate the AI driver senses the world and controls the car to 100hz (from something like 20hz) and the problem magnified itself. The Prediction Unit can no longer create curved paths of prediction, and sometimes even the straight paths get messed up. As you can see in the video of the Prediction Unit, it is very jumpy based on the input problem.

The reason for the problem is the Memory Unit can have multiple states of memory that are identical. So when averageVelocity is computed from the information in the memory it has a lot of error, enough to start confusing the Prediction Unit.

The best solution I know will be somewhat difficult to add, but would be added to the LFS Scanning side of the project. That is, to add client side prediction to what the LFS Scanner reports to the AIRS project. I figure tracking the last three OutSimPackets and time between each packet and then either interpolating between them (delaying the AI's knowledge further) or predicting the future path of the car (which could be inaccurate when a new packet comes), and it may need to be a combination of the two, interpolate until time reached then predict. As of note I do already have LFS sending me OutSimPackets as fast as it will send them

I figure I'd try the prediction first, it will be built similar to the Prediction Unit but used far prior than the AI ever sees the data. Doing this should smooth out the results and help the Memory Unit keep different values for each memory.