researching replays, position, speed and trafo (seperate thread)

[Wolf_pd]

I don't remember if this had been mentioned before, but what if we made an LP to TSD generator so we can lay down some of these lines on the ground and look at them in OPE?

Colourcode them and look in OPE if they are 'logical'

[Pavel 69]

I don't remember if this had been mentioned before, but what if we made an LP to TSD generator so we can lay down some of these lines on the ground and look at them in OPE?

Have anyone tried Nigel's AIEdit that I recommended?

[samsepi0l]

I don't remember if this had been mentioned before, but what if we made an LP to TSD generator so we can lay down some of these lines on the ground and look at them in OPE?

Have anyone tried Nigel's AIEdit that I recommended?

I forgot about it, but I will once I start tweaking some LPs for Sanair and Tamiami.

[Dennis]

Here are the spreadsheets for the conversions RPY->RW, RW->LP, LP->RW, where RW means real world data, which we want to edit manually. I attached the spreadsheets in ODS and XLS formats, I hope, you can open them, and see everything, like you should see. I didn't check the Nashville data with a video, because it didn't work (I have only audio), but I hope, the speeds are correct.
The ZIP files include also the according RPY, TRK and SG files. My next project will be, to get the corner radii also from the TRK file, to make the script usable without SG file, because normally we don't have it, and the trk2sg tool doesn't work here, and probably I'm not alone with this problem.

NOTICE FOR FUTURE USERS OF THE SCRIPT:
Through repeating conversions between CSV and LP formats, there is a risk of error accumulation. To avoid this, keep your CSV file for further editing, instead of converting the LP file back everytime.
There is also a limitation in the track layout. There can be only one radius change in a RPY and LP sector, so avoid short sectors. LP sector is about 11ft long,
RPY sector length depends on speed and in corners also on the lateral distance to the centerline, so the limit increases above 120mph linear (22ft at 240mph), and also at large lateral distance to the centerline in corners, like in Nashville. Adjoining straight sectors count in this case as one.

--------------------------------------------------------------------------------------------
DEVELOPER'S INFORMATION FROM HERE:

On sheet1 you can see the raw data from the RPY file (columns A-E). I kept the last 2 sectors of the previous lap and the first 2 sectors of the following lap, to make the calculations around the s/f line, the DLONG values are modified with the track length, to make the data consistent (dark green).

The next step is the determination of the straight (green), corner (orange) and mixed sectors (magenta). You get the DLONG coordinates from the TRK file, where the corner radius changes (column F). For the further calculations, these mixed sectors will replaced with corner sectors. This is still an underestimation, but better, than to replace them with a straight sector. I didn't want to make it more complicated. The calculation in the script differs here from the spreadsheet. To get the corner radius, don't use the neighborin sectors, because you will get a problem, if those are also mixed sectors. You have already the list with the radius changes, so you know from there, which radius you have before and after the changing point.

fictional radius of mixed section strtaight->corner
r[f]=(r*TAN((dlong[1]-dlong[c])/r)+dlong[c]-dlong[0])/TAN((dlong[1]-dlong[c])/r)
fictional radius of mixed section corner->straight
r[f]=(r*TAN((dlong[c]-dlong[0])/r)+dlong[1]-dlong[c])/TAN((dlong[c]-dlong[0])/r)
where
r[f]: fictional corner radius, used for later calculations
r: radius of the original corner
dlong coordinates: [0] sector start, [1] sector end, [c] point of the radius change

fictional radius of mixed section corner->corner
r[f]=(SIN((dlong[c]-dlong[0])/r[-1])*r[-1]+SIN((dlong[1]-dlong[c])/r[1])*r[1])/(SIN((dlong[c]-dlong[0])/r[-1])+SIN((dlong[1]-dlong[c])/r[1]))
where
r[-1]: radius of the first corner section
r[1]: radius of the second corner section

The next step is, to calculate the real world speed. We know, that each sector represents 1/15s of time, now we need the distance, which the car made in that time. To calculate the speed for a single record, I took the average speed of the neighboring sectors.

length of the previous sector, if it is a straight (column H)
d[-1]=SQRT(SQR(dlong[0]-dlong[-1])+SQR(dlat[0]-dlat[-1]))
length of the next sector, if it is a straight (column I)
d[1]=SQRT(SQR(dlong[1]-dlong[0])+SQR(dlat[1]-dlat[0]))
length of the previous sector, if it is a corner (column J)
d[-1]=SQRT(SQR((2*r[-1]-dlat[0]-dlat[-1])*(dlong[0]-dlong[-1])/(2*r[-1]))+SQR(dlat[0]-dlat[-1]))
length of the next sector, if it is a corner (column K)
d[1]=SQRT(SQR((2*r[1]-dlat[1]-dlat[0])*(dlong[1]-dlong[0])/(2*r[1]))+SQR(dlat[1]-dlat[0]))
real worls speed (column N)
V=(d[-1]+d[1])/2*54000/31680000
where
dlong and dlat coordinates: [-1] previous record, [0] actual record, [1] next record
r[-1]: corner radius of the previous sector
r[1]: corner radius of the next sector
V: real world speed

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

On sheet2 you can find the interpolation of the position and speed data between the RPY (green, orange, magenta) and LP (cyan) records. I used a linear interpolation between the neighboring RPY records. Keep in mind, that there can be more than one LP record between two RPY records.
The dlong coordinates of the LP records start with 0, increase with 65536, and the last record is equal to the track length (columns I-J). That means, the last LP sector is shorter.
The calculated data is for the CSV file for manual data manipulation.

interpolated dlat for CSV (column K)
dlat[0]=((dlong[0]-dlong[-1])*dlat[1]+(dlong[1]-dlong[0])*dlat[-1])/(dlong[1]-dlong[-1])
interpolated real world speed for CSV (column L)
V[0]=((dlong[0]-dlong[-1])*V[1]+(dlong[1]-dlong[0])*V[-1])/(dlong[1]-dlong[-1])
where
dlat and dlong coordinates and real world speed(V): [-1] previous RPY record, [0] actual LP record, [1] next RPY record

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

On sheet3 you can find the calculations between LP speed and real world speed. Because only the speed data differs between the CSV and LP files (sectors and position data are the same), the relation between the speed values is the same, as between the sector lengths. The sector length in the CSV file is the real distance, which the car made within the sector, in the LP file it is the distance parallel to the centerline (real world distance without lateral movement).

To get the real world sector lengths, the same calculations needed, as in sheet1, without the speed calculation (columns A-M), because we have already speed data, imported from the CSV or from the LP file (grey). The difference to sheet1 is, that we don't have data from the neighboring laps. To make the formulae work in the spreadsheet, I extrapolated the first and the last records (dark green). This isn't necessary in the script, because it gives the same result, as if you use only the one existing sector for the later calculation. But if you want to make the script really smart, you can check, if the first and the last record have the same dlat and speed values. If yes, you can take the last 2 records before the first one and the first 2 behind the last one, and change the dlong coordinates, like in sheet1 (dark green), to get better result.

To calculate the length of the LP sectors, I used the same pattern, as for the real world length, but because the formulae are more simple, I put it in only two columns in the spreadsheet (columns O-P).

length of the previous sector, if it is a straight (column O)
dl[-1]=dlong[0]-dlong[-1]
length of the next sector, if it is a straight (column P)
dl[1]=dlong[1]-dlong[0]
length of the previous sector, if it is a corner (column O)
dl[-1]=(dlong[0]-dlong[-1])*(r[-1]-dlat[-1])/r[-1]
length of the next sector, if it is a corner (column P)
dl[1]=(dlong[1]-dlong[0])*(r[1]-dlat[0])/r[1]
where
dl[-1]: LP length of the previous sector
dl[1]: LP length of the next sector
r[-1]: corner radius of the previous sector
r[1]: corner radius of the next sector
dlong and dlat coordinates: [-1] previous record, [0] actual record, [1] next record

calculation of LP speed from real world speed (imported from CSV) for LP
v=V*(dl[-1]+dl[1])/(dr[-1]+dr[1])
calculation of real world speed from LP speed (imported from LP) for CSV
V=v*(dr[-1]+dr[1])/(dl[-1]+dl[1])
where
dr[-1]: real world length of the previous sector (column L)
dr[1]: real world length of the next sector (column M)
v: LP speed
V: real world speed

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

The calculations, as they are in the spreadsheet, doesn't make accumulating errors at repeating conversions between CSV and LP. But, because the files use different units and precision, this can happen though. To minimize the risk, always use the round statement instead of truncate.
To test the error accumulation, make several conversions from CSV to LP and back and forth... and compare the results, if the difference gets larger after each conversion.

During the developing process, you can compare the intermediate results with the spreadsheet, they must be the same.
Since my stroke I noted, that I more often switch letters and numbers, so if you find single errors during the developing process, check the spreadsheet for such mistakes.

Let me know, if you have questions.

[samsepi0l]

Here are the spreadsheets for the conversions RPY->RW, RW->LP, LP->RW, where RW means real world data, which we want to edit manually. I attached the spreadsheets in ODS and XLS formats, I hope, you can open them, and see everything, like you should see. I didn't check the Nashville data with a video, because it didn't work (I have only audio), but I hope, the speeds are correct.
The ZIP files include also the according RPY, TRK and SG files. My next project will be, to get the corner radii also from the TRK file, to make the script usable without SG file, because normally we don't have it, and the trk2sg tool doesn't work here, and probably I'm not alone with this problem.

So check at first the spreadsheets, if the format is OK, or if I have to change something. I will update this post during the weekend with a detailed explanation to the data and the conversion process, when I have time for it.

I am looking at your spreadsheet, and scratching my head a little....

Is "RW" real-world just speedometer speed?

I'm sure you've done something brilliant because you never fail to impress me however I am still trying to understand.

[Dennis]

Is "RW" real-world just speedometer speed?

Yes, it is.

[checkpoint10]

Check this out! Now I'm thinking about coloring the LP line based on speed (green = fast, red = slow), or acceleration (green = speed increasing, red = speed decreasing) or by type (race, maxpanic, etc.).



This might actually be useful in identifying problems with AI lines, like this example from my PASS1.

[checkpoint10]

Updated rpy2lp package with the new tool to create .TSD files from a .CSV file.

Same as described in previous post, with new option:

--tsd <color>

Example:

python csv2lp.py race.csv race.tsd --tsd 106

[checkpoint10]

@Dennis, your Nashville LP data looks like it has 993 records but the track should have 1009 records. Why is there a difference?

[Dennis]

@Dennis, your Nashville LP data looks like it has 993 records but the track should have 1009 records. Why is there a difference?

Because it is an older layout. I think, it is the first one with the 90 degree chicane, which I downloaded in August. As I told, I can't make SG from TRK, so I used, what I had. The files are in the ZIP.