Quote from GAVD999 :

Really interesting to follow something like this and watching it develop, looks like a mammoth task to complete but looking promising so far, keep at it

Yeah very interesting to read about and see the progress.
Be aware that many people will read your postings, but don't want to react in this topic to keep it organised and/or because they haven't got the knowledge of what you are doing. (I am no exception to that)
Keep up the good work and keep those updates coming.

Okay I am happy to announce I have the Visual Sensor gathering the Reference points in view at a happy level of >40 frames per second!

Improved Sensor 1
Improved Sensor 2
Improved Sensor 3

Again the green, yellow, red lines indicate the visibility as noted in my previous post. The blue/green lines across the track separate the track into several sections. The Visual Sensor will gather all reference points from the section the car is in, as well as the previous and next sections. All these reference points are then tested for visibility to determine if they can be seen or not.

The good news, this remains true to the idea that the AI can see ONLY what the player can see. Although it is possible it won't see everything. On a long straight section, like Blackwood, the Visual Sensor will only sense the immediate reference points and not ones further down. This is an acceptable compromise for now.

Now I get to attempt to have the Visual Sensor estimate the speed of the car, and from there "predict" where the car will end up a few moments into the future!!!

That looks awesome, Tim.

Sorry if these questions are stupid/answered before! It's been a while, specially concerning LFS, but...

So you're actually using just the closer track sections for references (3 sections, if I got that right)?
Could you 'lock' on a more distant marker (say you're on a straight and you can see the '100m for turn' marker quite further ahead) and completely ignore the closer markers? I guess that's how we work.
Will the AI know that in the next lap the markers are the same?

Also, how do you know that the marker is not visible, that some terrain is blocking it?

de Souza, no questions are ever stupid, and even if they were answered before (I don't think they were) it is worth pointing it out/clarifying for others!

You are correct the three closest sections are what are being used. Each section of the track is about 75 meters long or so. Which means the car can (at the best of times) see ~150 meters in front of it. Which means it will see the markers in front, but not extremely far.

I have been considering to add more sections in front, which could/will reduce performance a bit more, however I think where it is at right now will work great for the current time, from my quick tests it seems a good compromise. This can always be modified in the future.

That is correct, if the terrain is blocking the line of sight (from the position of the drivers eye to the position of the reference point) then the reference point is discarded as it is not visible at that time. (Before doing that more expensive test, I first check if it is even in the drivers field of vision).

As far as focusing on a single object further away, I feel we take a lot of points into consideration when processing the visual information. The AI driver will need to take multiple points into consideration if only because turning the car will make a point far away move, but not necessarily in the direction the car is moving, where-as the closer points will move less due to the turning and more due to the car motion. I'm hoping I can separate the two and make the Visual Sensor predict where the car will be, given the current conditions (speed, turning, etc).

The AI will see the marker on the next lap, but they won't know it exists until it comes to them. That would involve some form of learning algorithm which I am currently planning to steer clear of for complexity reasons.

Nice to hear from you again!

Well, I had started a post explaining several problems I was running into with an Outsim/Outgauge connection, however, I finally got it working! For one thing, I've been connecting to LFS with running AI drivers and in this situation you don't get Outsim/Outgauge information, and I had forgotten this minor fact. Another was old code that wasn't written well, now fixed.

So today I am working on the PhysicalSensor and CarSensor and depending how long that will take, I will start on the PredictionUnit which will use all the sensors to estimate the speed, slip angle, and other conditions of the car. And also, with that information, predict where the car will be in the near future.

Got a little stuck on the PhysicalSensor, if you know a bit about OutSim let me know: In this thread

For now I am going to ignore the PhysicalSensor and move on to the CarSensor so the AI driver can check the speedometer, rpm, etc.

Okay another quick update for the day. Here is the Physical Sensor for the driver, it is not hooked up to anything beyond making sure the values make some sense. A few of them might still be a little off for certain situations.

View of PhysicalSensor

This has visualization has quite a bit of information stored in it. First the small green circle. This represents the forces the players FEELS. Meaning it is opposite to the actual forces. (Turn the car right and it FEELS like you get pulled right) (Hit the throttle and if FEELS like you get pushed back). I'm still not sure how accurate the number/scale is, but the large circle is supposed to represent 1 full G. From the screen shot it seems a little off since the dot is not 58% to the right edge and 25% to the bottom. But otherwise this is working as expected.

The next part of the visualization is the red line which indicates the linear velocity of the car, from the cars perspective. So moving the car forward will make this line go straight up, if the car is moving sideways it will point that direction. If the car is going 100mph (will eventually make that a variable speed depending on car), the line will extend to the outer green circle. Since the velocity won't always be in the exact direction the car is pointing you can use it to monitor the slipAngle as well, as shown better here.

Physical Sensor Slipping

The final part is the pink line that always reaches the outer circle, and I'm not yet sure I've got a grasp on that in terms of "in car space". But it may not matter it is telling a story, and it might be telling it backwards at the moment. However, it represents the angular velocity of the car along the UP axis. Think of it like a steering wheel, when there is no rotation it will point straight up. If the car is rotating, the faster it rotates the more the line will continue around the circle.

I have captured the information from the gauges, but I have yet to make a CarSensor, and when I do I will create another visualization based on Speed, RPM, Fuel. Also actual throttle/brake/clutch/shift positions (vs what the AI will be saying, since there will be a delay of some sort).

Speaking of, does anyone know how to get the steering information from LFS? I would have thought it'd be included in with OutGauge along with the pedal positions, but it was not included, this would be a nice-to-have, although in all seriousness the important parts about the CarSensor will be the information from speedometer, tachometer and fuel gauge.


-----

EDIT:

Added a rough visualization of the speedometer, tachometer and current gear selection. The tach is the red line, going from 9 o'clock to 12 o'clock and the green line is the speedometer going from 12 o'clock to 6 o'clock.

CarSensor Visualization

Hey guys, nothing further to report yet beyond the work week has started and so progress will slow down a little bit. Also I am going to attempt to reduce the loading times of track terrain / quad tree / reference points greatly by computing what is needed and saving a file so those don't need to be computed each time.

I do have a few questions, if anyone actually following the project knows, about gathering information from LiveForSpeed.

1) Is there a place where the width of the car is stored/kept, or where I can get this value from? (I found the wheelbase value in the car_info.bin files, but I need the width)
2) Is there a place to find the limiter RPM value for each car?
3) Is there a place to find the optimum shift RPM value? (I did find max torque/power)
bonus) Is it possible to get information from the Steering Wheel position as it is not provided by OutGauge from what I saw.

I can (and will if needed) create approximations, but it would be great to know them if possible.

Dygear; Yea, I was thinking of doing exactly that for the limiter values. Do you by chance have these values available already? If not I'll do this a little later and post them for all to use.

I was surprised to see the wheelbase was available in the car info, but no width. Wonder if Scawen could bump the version and add that information quickly. :-) Or how I would go about even requesting that, pretty sure Improvement Ideas is ignored.

Edit:

Idle to Limiter (note: these values have been truncated to the lowest whole number, ie floating point dropped)
UF1: 969 to 6983
XFG: 950 to 7978
XRG: 951 to 6980
LX4: 934 to 8974
LX6: 934 to 8975
RB4: 958 to 7480
FXO: 955 to 7482
XRT: 958 to 7480
RAC: 964 to 6985
FZ5: 951 to 7971
UFR: 1430 to 8978
XFR: 1424 to 7979
FXR: 1408 to 7492
XRR: 1408 to 7492
FZR: 1425 to 8474
MRT: 966 to 12917
FBM: 1879 to 9179
FOX: 1867 to 7481
FO8: 1852 to 9476
BF1: 3452 to 19912

Regarding no 3, optimum shift point, a suggestion:

For the GT class cars that have a shift light there probably is an OutGauge variable.

In any case, if you can read the gear ratios, then the optimum shift point (also as calculated by VHPA) is the point when the torque at the wheels in the next gear is higher or at least equal to the current torque at the wheels.

Now this can get a bit more complicated if you take into account the fact that the gear change is not instantaneous and even more complex with turbo cars as the turbocharger will spool down but this might be too much already.

I did see the shift light, and I thought about using that, except I felt a player wouldn't wait until the shift light is on. I want the driver to be able to prepare to shift / anticipate it based on the current RPM and the pattern of the RPM over the last few moments.

That said the next portion of your answer does get the calculated optimum shift point for whatever the setup is, and since I don't want to give the driver an unfair advantage, I will probably keep looking. I guess what I can do is just input that I usually upshift at 7200 in the LX6, and downshift at some other value.

Do any aliens (or anyone really) want to weight in here and give me a reasonable shiftDownRPM and shiftUpRPM for each car? Please?

I hope to have the car widths calculated, probably via the cmx file, by the weekend and then I will start working on the MemoryUnit and PredictionUnit for the drivers brain.

Quote from blackbird04217 :

Do any aliens (or anyone really) want to weight in here and give me a reasonable shiftDownRPM and shiftUpRPM for each car? Please?

For the siftDownRPM I think you can calculate that. When I need to know if I can reduce without blowing up the engine I do a couple downshifts to see where the RPM increase is below the redline. So in my opinion it should be fine to do the calculation artificially (not very accurate if you want, or a bit random to avoid it being always perfect).

Well, I have loaded the car mesh from the LiveForSpeed CMX file. Interestingly, the car seems to be missing rims? Already it is an improvement over my old mesh that had no suspension or tires... and I can use this to compute the bounding area of the car, and will use it for the visuals from now on.

Probably will not skin it as I have not created a texture loader, but still it looks neat: See the FOX here

You should be able to get the optimum shift time by RPM by looking at the RPM when the AI shifts into the next gear. I don't know for sure, but I think the AI (written by Scawen) knows the best time to shift.

AFAIK, the auto gearbox mode uses the optimum shift points, that might be easier to use for measuring than AI drivers.

I guess you'd have to use the up-shift values to work out at what points a kick-down is needed, as the auto box's downshifts while decelerating are pretty shocking for actual racing (mostly because there is no one optimum down-shift point when braking - it can vary massively based on engine braking, limits of traction etc)

To reduce the advantage of knowing the optimal shift points, you could add a bit of randomness to it.

Quote from Degats :

AFAIK, the auto gearbox mode uses the optimum shift points, that might be easier to use for measuring than AI drivers.

I guess you'd have to use the up-shift values to work out at what points a kick-down is needed, as the auto box's downshifts while decelerating are pretty shocking for actual racing (mostly because there is no one optimum down-shift point when braking - it can vary massively based on engine braking, limits of traction etc)

To reduce the advantage of knowing the optimal shift points, you could add a bit of randomness to it.

Fair point, about just using the auto gearbox mode. But it would depend also on the gear ratios ... I guess you could fuzz this information. Set 20 different values evenly spaced apart in 20 different setups then have the AI do a hot lap and find out where it shifts up and down. From there you'd only have to read the setup file and tween between the numbers if they are not on a value already set. That should get you 90% of the way there. When it comes to engine breaking and everything else, you'd also have to take in weight of the car, if it's on an incline or decline while breaking when you should be shifting ect.

I am going to try to avoid opening the setup files or gathering every piece of information if I can help it. Although that would allow me to compute the exact values, which I could then blur a little as mentioned.

I'm actually wondering if I can do something with the 4 values I already have, which should probably be enough: IdleRPM, LimiterRPM, TorqueRPM and PowerRPM. I figure the driver will want to keep the RPM as close to the TorqueRPM / PowerRPM range as possible, likely error on the side of less than the range more than over.

I'm thinking something like the following:


With a little more logic to prevent shifting from first to neutral when starting out, and maybe tweaking the 1.2 / -1.8 values accordingly. This should have the driver attempt to keep the engine in the power/torque range.

1. A real life driver may not have any prior knowledge of t/pRPM.

2. It you use this method with fixed range values, some race cars with rev limit near pRPM will never shift up.

3. If you use car-specific values or hard overrides, you are adding more prior knowledge.


My suggestion would be let the AI observe rev/speed change and work out shift points based on the change rate, which is what real drivers do. If rev is not increasing quickly any more, try shifting up.

I guess it all depends on what you're trying to achieve (accuracy vs realism vs type of driver/driving).


Peak torque/power @rpm values probably aren't actually all that useful for picking decent shift points, although using peak power probably isn't going to be too terrible for up-shifts.
Your percentage calculation seems like a nice simple way of trying to keep in the power band, but how well it would translate to decent shift points would depend on the car's specific torque curve.

Using Keling's method is delving into machine learning and could get quite complex (in both programming and processing), but would indeed represent someone getting into a new car blind so to speak.

If you want it to be like a vaguely serious racing driver, finding out more or less where the shift points are for a specific gear ratio set should be fairly normal.


You probably have two ways of working that out the *actual* ideal shift points (other than trying to use the auto box, which would only be reliable for up-shifts anyway):

1. Pre-compute the torque curves for every car (IIRC there have been a couple of pretty good attempts on the forum already) and read the ratios from the setup. This would be the cheaty way that I suppose you're trying to avoid.

2. When the AI first starts driving, attempt to calculate a rough torque curve in one gear (preferably not traction limited) based on acceleration readings. Work out rough relative ratios by comparing acceleration at the same rpm at different gears.
This would be a compromise between human style complex learning and fully cheating using external/pre-cooked resources, with the added benefit of being generic without having to pre-calculate stuff.


As I said, which method you use depends on what you're ultimately trying to achieve.

Quote :

1) Is there a place where the width of the car is stored/kept, or where I can get this value from? (I found the wheelbase value in the car_info.bin files, but I need the width)

Ingame using the shift+u camera mode then press D for distance measure tool, would probally accurate to 10cm or so?
Or maybe look at "3D Renders" subforum: There are ways to import the car models into various modeling software (ex. blender) and then should be possible to get dimensions from there.

Quote :

Not sure if anyone is still interested in the project, I know it takes time between updates, but I think that is changing.

Find it interessting and check thread from time to time.

Some of your ideas I did not quite understand, especially the whole "driving by visual thing", for example: "attempt to have the Visual Sensor estimate the speed of the car, and from there "predict" where the car will end up a few moments into the future."
Position and movement vector are already in insim, what is the motivation not to just use them from there? Is it just for the challenge/interesst or to make it more realistic or what is the idea? Will not the result in most situations (except blind turns and such) be the same? It is interessting approach just something I was wondering about.

From my understanding, the idea of this project is to make a Driving AI that is agnostic to a single game. That's why there is a visual sensor, so he could then take the project and load up iRacing and it should just work because it can "See" the track the same way we do.

Keling: I do understand what your getting at with the AI learning where to shift, however I'm attempting to avoid that complexity of teaching a machine to learn. I also feel a racing driver would actually know the power band of the car, maybe not the exact values, but then, that is why I've given the range. For your second point, that is easily changed by making sure the shiftUpRPM is less than limiterRPM.

Degats; I believe you'd be right for a semi-serious driver with a lot of experience in a single car/setup. However if the car/gearing changes often, I don't think the driver would go out thinking "5500 for first, 5600 for second, 5300 for third... etc" I do feel they would understand the best torque/power range of the car is between 5200 and 5500, and attempt to keep the car within that range while accelerating, regardless of set. Of course, there is some assumption that the next gear will be within some reasonable range of the current.

Gutholz; I have managed to load the car mesh files from LFS and will use these to determine the width / dimensions of the car. It will be the width of the model, but it should be close enough for the needs the driver has.

As far as the reasons behind predicting from the visuals and not using the actual position provided by LFS, Dygear is correct in I want to make as few LiveForSpeed assumptions as possible and keep the driver generic. Meaning if I could get a certain amount of information from another simulation (perhaps one I make someday) then the AI should be ready to drive there reasonably well. However I am sure there will be assumptions and things tweaked to be optimal in the LFS environment. And though this is a valid thing in the back of my mind, it is not the primary reason.

The primary reason I want the AI driver to use a visual sensor to predict where the car will end up is because that is exactly how we would go about it. I haven't given the AI driver their position in the world. We don't know our position in the LFS world when driving. We can estimate we are about 2 meters from the track edge, 20 meters from start/finish etc... and at what direction from our point of view those objects are. This is how I'm trying to make the AI driver think closer to how we would think with the information we have.

Of course I don't promise it will perform well, or that the computation will be light enough to use in a game, or anything really! But by using this visual sensor to estimate the location of each reference point seen, I could then go in and tweak the visual sensor to give faulty information. Faulty meaning, not perfect estimations. By doing this it should create some degree of error, without actually programming the AI to make mistakes.

Though, I'm working with perfect sensors for now, and will be until the car is driving fairly well.

---------------------------------------------------------------------

Speaking of, I finally have the physics sensor feeling the acceleration and linear velocity correctly. That took a lot of time. Once I am done cleaning up all the failed attempts and broken bits, hopefully without breaking it, I will be able to begin the memory and prediction units for the driver.

The memory unit will store the position of around 32 reference points. Each update will change the memory, throwing away any 'memories' older than 1 second (or so), and adding the new memories. It will have a way to use the remembered reference points to get the average velocity between one memory (A) and another (B). If you do this again and get the average velocity from (B) and (C) you can then use those two average velocities to get the average acceleration (visually).

Of course, as I said much earlier in the thread, this might prove harder than I make it sound as the car could spin slightly and the reference points far away will seem to move far while the ones closer won't. I will need to find a way to get rotational values from the view to correct.

Lets see how it works out. Here is a shot of the physics sensor working.

Physics Sensor

Another step of awesomeness. It works like a charm, a little hard to see in the first image, but the second has a digital speedometer and matches perfectly. This estimation only comes from the current and previous memory. So when I add more, in theory, it should be more accurate; and/or maybe more inaccurate based on acceleration.

Visual Speed Detection 1
Visual Speed Detection 2

Well. That gave me a great idea of the current speed of the car, and I can use it to get the current acceleration of the car, and both of these values are reasonably accurate in a straight line. This makes it easy to predict the path of the car in a straight line based on the current speed and acceleration, however, race tracks have corners, and I'd like the prediction unit to be able to predict reasonably well where the car will be given the current state. Meaning, if the car is currently making a turn, it will predict the cars position if it continues turning at that rate. I definitely have my work cut out for me here!

//------------------------------------------------ Later

Prediction 1

This shows the line the car will continue to follow if it continued along the current velocity. Since the I haven't been able to estimation rotation/turning based on the visuals this won't work very well for a turn, which is why the image is taken along the straight!

A little later. . . And now based from the average change in distance from the visible cones (velocity), as well as the change in that change (acceleration). This created a fair prediction/estimation of turns. Not perfect, but it I think it's pretty damn good prediction using only the visual sensor. It may be worth trying to create one based on the physics sensor. Maybe combine the feel (acceleration) of the physics sensor with the velocity from the visual sensor.

Path Prediction 2
Path Prediction 3
Path Prediction 4

The driver is predicting the path ONLY using the visual information (direction and distance) to each cone in the field of view.

Youtube: Path Prediction in Action

Please, enjoy.

Quote from blackbird04217 :

Youtube: Path Prediction in Action

Is the AI driver driving or is it just predicting where the car should go. As far as path's go, would it not make sense to include a cone of uncertainty. The cone of uncertainty being the same visual representation that is used for hurricane paths.