A few weeks ago I started making my own physical world so that I would have to deal with all the hang ups I've hit of doing the AIRS project in LFS. While this might not sound as awesome to some people, the project goals and intentions still remained the same to me...

http://img717.imageshack.us/img717/4107/airace.png

I didn't get very far, I only worked on it for a weekend. The car doesn't have tires because I was planning on integrating my TireSim deformable tires, just because. The car doesn't move, there is no real engine or anything in it, just a cone and a car from my old TireSim project back in 2009. I am confident I will (at some point in time) work on the ideas behind the AIRS project... As always: too busy at this time though.

lx4

Does the replay in this post work for anybody?

I keep getting OOS errors, even when using 0.5Z 28, which is what it was recorded on. I was hoping to get a video of this, and have very much been considering jumping back on this project. A lot of good ideas started coming to my mind again and although it never got beyond 'theory' before, there is a lot to move forward with.

Thanks for trying.

I've been back and forth about using LFS vs creating my own physical simulation for quite some time, I am currently leaning towards using LFS more than I have in the past. I read through some of my hesitations, where I can't get the information per tire, and I think a few members who were actively interested said it right; is that information really needed?

If anyone can get that replay working, it will show in 2010 I had an LFS car driving around from point to point. However it should be obvious to anyone who read this thread, that is not how I want the AI to work. It did prove that I could get the AI driver to aim the car where I wanted though.

I am taking a step back from LFS or building my own simulation. The very first part of this project should have been, "find the best racing line". Given all the reference points for the left and right edges of the track, I need to create a best line through this. I should be independent of the simulation as all it requires is the data.

Anyone here even/still interested in following this old project?

Quote from blackbird04217 :

Anyone here even/still interested in following this old project?

Seems quite awesome, I'll follow up*

*I've got much spare time to read at work, I work at a university..

Good to know someone is interested. So, I have been doing a bit of research in what little time I do have for this project and I my plan is to plot out the points of one of the LFS tracks so that based on these points, I can then have the AI drive compute the best line.

My question to any of those who have some input, what is the easiest LFS club sized track configuration, that is not a rally track. I am thinking the size of AS1 or FE1. What do you guys think?

Is there any place I should revive a thread that might see more traffic than the programmer forum? I'm thinking this topic is interesting to others more than just programmers, even if it might be a touch technical.

Thanks for the input guys!

I can't see an area that would be more appropriate then the programmer forum.

Okay, ignoring the fact that I think more people would be interested in this project than just programmers, I have picked FE1 as the track to start on.Not yet sure the car, but that is not a big deal.

My first step is to compute the theoretical best line, or the line the AI drive will try to drive around. Given that I am trying to resemble how a human would do this I have decided to call this portion of the AIRS project the "Track Walk".

During the Track Walk, the artificial driver will gather all the reference points around the track. Most importantly; Left Edge, and Right Edge. But any other reference points, like signs, cones, curbs, bumps, etc, would also be gathered at this time and stored in the drivers memory for later use. Though I am calling this the Track Walk, it is simply taking the reference point data and tossing it into the artificial driver, in no way is the artificial driver 'walking' the track.

Unfortunately, the Left/Right Edge reference points will need to be ordered as they go around the track, they can't just be random points, as that could cause misjudgment of a hairpin or chicane possibly. But this can be achieved, and is how one would walk around the track anyway.

Once that reference points have been gathered, the center line is computed from the Left Edge and Right Edge reference points. This will be achieved by taking the leftEdge[n] and leftEdge[n + 1], computing the perpendicular to this, ignoring height changes, and checking all rightEdge[m] and rightEdge[m + 1] until a collision occurs. Once this perpendicular 'leftToRightEdge' is found, placing the center point is simply a matter of scaling it back by half. Then continue with n = n + 1, until the track is completed.

This is obviously not the best racing line, yet. But it is the very first step needed to get there. The Track Walk will only be completed once the best line is found. I am starting this project from scratch, using very little to nothing of what I previously wrote. I plan to gather the Left Edge and Right Edge reference points from FE1 and I plan to make the AIRS project display what the AI driver is seeing, to later help with debugging and tracking. Previously I relied on print statements, which proved little help once the car got moving.

One problem I need to overcome to make this work with LFS is the PPJoy calibration. Last time I could not get it calibrated without a giant hack, it seemed holding the steering wheel at -15 degrees was 'straight'. I will have a copy of LFS meant only for the AIRS driver so that I don't need to fiddle with configurations like I did last time.

Lets see if I can do this project setup, and this portion of the Track Walk before June 1st 2013.

Guess I will keep posting if only for my own amusement looking back on this project. I have made some progress and got my lfsScanner class to grab data from layout file that will resemble the reference points. Currently I have two types of reference points: LEFT_EDGE and RIGHT_EDGE. Left edge is resembled by place blue cones in LFS, and the right edge is the green cone. It is critical that when placing cones, they are placed in order going all the way around the track, otherwise the scanner will just get random points of data, which would be hard to infer where the track actually is. (In the case of a hair pin, bridge, etc).

In the AI project, I placed yellow cones where all these reference points are. (On a flat surface as the LFS layout file lifts some for physics dropping). The yellow cones are not visible in this picture but dots resembling their orientation lines are visible, and shows the front stretch, turn 1, chicane and hill of FE1.

http://imgur.com/8fq52OA

A long ways from where it was, but I think this will be much better than previously. Using the data from the track edges I will now try to compute the center line of the track. This is not the best/racing line, but it will be the first step in getting me there.

LFS layout files do contain rough height data. The cones do contain a Z (vertical) axis, LFS attempts to place them on the nearest surface (within 1 metre) I think. Scawen's made a post about this one time.

Yes, this is documented in the layout format and I actually had them using the z component too. 90% of the cones were great, but a handful were lifted much higher and it looked odd, so I decided to flatten my representation, at least for now.

EDIT: More Progress! I have the center-line of the track computing itself, just as I described a few posts back.

Screen shot here

However, as you see it has some issues if the person placing cones makes sharp turns. I think I need to do this a little better or more robustly, but that is going to require a bit more thought. I have a few ideas, such as blending the normals while going along the left edge, but even that might not work completely.

I cannot contribute with anything here sadly, but just wanted to pop in and saying that I'll keeping an eye on this. Intersting to see what people with solid minds can accomplish.

hi
the screen from your ftp need a login and password, maybe you can upload it somewhere else?

Heh, that is because it was not suppose to be an ftp link, I have now switched it up! Good catch I will be sure to double check that in the future. Should be working now.

Great idea! I also just want to say I've been following this

I decided I would make a video of my progress, and that meant programming the algorithm in a visual way. I think the results are spectacular, though not quite the final product.

This video is not a permanent video It will be deleted and replaced with another at a later date, when the actual racing line is computed. Currently this is showing the computation of the center line of the track, and at that you can see what I described above where it is not doing so perfectly.

Enjoy: Computing the Centerline on Youtube

Interesting!
I see it's no easy job doing this!

You might have answered this before, but what is your goal, what do you want to archive with all this? Is it some sort of self-test, only reason is because you can and want to look back at what you accomplished?

I find it interesting. I have a passion for racing, the ability to program and find a lot of things wrong with "game" artificial intelligence being used in a racing simulation; see the very early posts of the thread.

That said it is a research project to see if it is possible to tackle the artificial intelligence from a standpoint of taking more realistic inputs/outputs, and trying to use reference points humans would use. I am making the video of progress for myself to look back upon, and for others to see, visually, how some of the computations are working. Reading about an algorithm is nothing compared to seeing a video of that algorithm in motion.

Just a thought from the top of my head.

If you calculate the center line from the right edge too, and then do the "average" of the 2 center lines, would that be ok?

I guess it will be better, but I don't know if it could give good enough results.


Beeing able to watch those calculations in a graphical enviroment is really nice

That is close to the plan I started implementing last night, with a bit of a difference. I will find the first position exactly as I did with the first algorithm; as you see in the video, and with that I will have the forward direction from that. Using the center position, and moving along the forward direction I will travel "some distance". I will place a temporary position there, and extend both left and right until collisions occur. Which I can then compute the actual track center at that position. I will then get a new forward direction based on the previous position and current position and continue.

The issue I am having here though, is how to know when I've travelled all the way around the track and reached the end again. I suppose a simple radius check will work, as finding a new position "close enough" to the first position would then say the track is completed.

This new algorithm is better in two ways, it will be adjustable roughly how far between each center point is and it should be more accurate, although that will need to be seen. It shouldn't suffer from the same issue anyway.

Since learning about it, I have been planning on writing a SLAM approach for the a.i. to learn the track, and a big problem was getting the reference points. You're going for a different approach and it is very interesting.

If you want to use the checkpoints from the track (I mean the places where you get the split times) then using their position should help a lot in figuring out when one lap has been completed.

Is the "some distance" you travel fixed all over the track? Because we usually pay more attention during the corners and/or at low speed, so we get more reference points than at high speed.

By my current definition of the algorithm it is fixed, but it by no need actually needs to be fixed. I plan on running optimizations to the "racing line" once it is finally computed, in that if three points are all in a straight line, remove the middle point.

There is no reason this first algorithm couldn't have "some distance" change depending on the angle changes of last few points, I will try to keep this in mind, but at the current time I will leave it fixed and optimize straights once the final data comes, this actually might be crucial for the way I plan to use springs to find the actual racing line.

Why not just cut the track into sections and link equivalent points on two sides? It's simple and also zigzag-free. Optimizing based on angle between track side lines and link lines is also trivial.

I'd like to echo the others in registering my continued interest, and support in your project.

The problem of knowing when a circuit has been completed could be addressed by exploiting the fact it is a circuit, and has rhythm. The AI must have memory, so therefore patterns can be recognised, and from this, refinements made in a true learning mode.

A purely "visual" approach may need supplementing with inertial data too.

Oh yes. Oh yes...

This is a much better way to compute the centerline, much smoother - mostly from having more points, and more flexible. Still not perfect by any means, but I think it forms the center line well enough for me to move onto the next step... Rather than post another temporary video I will throw up a few screen shots of the old problem spot, and wait until the next step is complete for a more complete video.

Screen Shot of Visualizer
Old Problem Spot 1
Old Problem Spot 2
Full FE1 Track

You can see how the centerline no longer doubles back on itself with this new algorithm. Now time to make the center line turn into the racing line!!!!! This step should involve a bit of magic, so I am digging for the bag of pixie dust.