Apps Motec i2 ACTi improvement

[KFMaster]

Using Motec i2 with AC via the ACTi app, when I compare two laps, unless both traverse exactly the same path on the track, the comparison can give false information. For the example below, where the cursor is, it shows red braking early than blue and starts to lose time during braking in the variance plot. But this is not true. The error is introduced with i2 plotting the two laps using their own distance traveled rather than a common distance reference. Notice in the track map plot, the car location for the two laps are not at same spot even though the cursor is at the same distance traveled.

Is anyone else interested in getting this fixed? Or, is there a fix for this already?

I think I can fixe this if I can access the data that ACTi generates for i2 (the .lx and .ldx files). But I don't know the file format. If I do, I can write an script to normalize the distance traveled for each lap against a common reference, so that when compared in i2, it won't introduce error described above.

 

[mclarenf1papa]

Welcome to data logging. There isn't really a "fix" per se, you're plotting over either time or distance traveled on x axis in Motec by design (also make sure you have snap distance to lap disabled, it causes more problems than it fixes, in my experience). Same as how most lap data analysis softwares work. Common practice is to use something like damper travels to line the data up per corner before analyzing.

In AC, the only way around this would be using the lap progression (calculated from AI line), but ACTI doesn't save this, nor would it be easily converted to meters (it's a normalized value and you'd need the total length of the AI spline for it to be de-normalized). You could maybe try doing something with the world coordinates and math channels, but probably wouldn't be worth the effort.

 

[KFMaster]

Welcome to data logging. There isn't really a "fix" per se, you're plotting over either time or distance traveled on x axis in Motec by design (also make sure you have snap distance to lap disabled, it causes more problems than it fixes, in my experience). Same as how most lap data analysis softwares work. Common practice is to use something like damper travels to line the data up per corner before analyzing.

In AC, the only way around this would be using the lap progression (calculated from AI line), but ACTI doesn't save this, nor would it be easily converted to meters (it's a normalized value and you'd need the total length of the AI spline for it to be de-normalized). You could maybe try doing something with the world coordinates and math channels, but probably wouldn't be worth the effort.

I didn't see your response just now -- I must have missed the notification.

No known fix is what I expected. I know how to fix it, I just need to be able to read the ld file. Would you by chance know the ld file format? The calculation I need to do would be way too cumber some (probably impossible from what I have played with the math channels) to implement in Motec math channels.

 

[RasmusP]

Common practice is to use something like damper travels to line the data up per corner before analyzing.

That makes a lot of sense, as long as the bumps are similar enough if the laps don't have identical lines.
I guess for good drivers it works very well.

No known fix is what I expected. I know how to fix it

Cut your quote to re-frame it
There's a manual fix and I also know how to fix it:
You press "o" (offset) to enable the offset axis', which means having 3 distance-axis' now.
One is the "reference" and the other two are the two laps.
If you now drag the lowest axis to the left or right, you can sync both laps before each corner.
It's annoying since you have to do this manually for every corner, but it works very well and it's how I'm doing it.

Quite often you only have to do this for 1-3 corners, since the lines don't vary that much overall.

I'm doing it visually via the line-map! Just to be sure..

 

[KFMaster]

That makes a lot of sense, as long as the bumps are similar enough if the laps don't have identical lines.
I guess for good drivers it works very well.

Cut your quote to re-frame it
There's a manual fix and I also know how to fix it:
You press "o" (offset) to enable the offset axis', which means having 3 distance-axis' now.
One is the "reference" and the other two are the two laps.
If you now drag the lowest axis to the left or right, you can sync both laps before each corner.
It's annoying since you have to do this manually for every corner, but it works very well and it's how I'm doing it.

Quite often you only have to do this for 1-3 corners, since the lines don't vary that much overall.

I'm doing it visually via the line-map! Just to be sure..

Thanks Rasmus for sharing the "o" trick, I didn't know. But this is not a real fix. It only works if the two laps are off in one corner, which is probably the case for comparing my own laps, where the difference typically come from driving error at a particular corner. But if I am comparing my lap with someone else who drives a different line through out the lap, then this trick does not work. Besides, doing it manually just not a nice thing. Further, this is really not an offset. It is part of the lap got "stretched" and at different rate from corner to corner. So to really fix this we need to map the distance traveled for each lap to a common reference. Then use that reference coordinate as distance to plot the traces. What I would like to do is to essentially do a coordinate transformation for every lap's distance data to this common coordinate. I just need to know how to read the ld file to do this

For the same reason mentioned above, MaclarenF1Papa's damper trick also does not work in general.

 

[mclarenf1papa]

Thanks Rasmus for sharing the "o" trick, I didn't know. But this is not a real fix. It only works if the two laps are off in one corner, which is probably the case for comparing my own laps, where the difference typically come from driving error at a particular corner. But if I am comparing my lap with someone else who drives a different line through out the lap, then this trick does not work. Besides, doing it manually just not a nice thing. Further, this is really not an offset. It is part of the lap got "stretched" and at different rate from corner to corner. So to really fix this we need to map the distance traveled for each lap to a common reference. Then use that reference coordinate as distance to plot the traces. What I would like to do is to essentially do a coordinate transformation for every lap's distance data to this common coordinate. I just need to know how to read the ld file to do this

For the same reason mentioned above, MaclarenF1Papa's damper trick also does not work in general.

The idea is that on a corner-by-corner basis, the stretch should not be significant enough to matter. If two people are taking wildly different lines, one of them is wrong. You align dampers before every corner (or multiple times throughout if the lines are wildly different) to compare them. Works fine and also tells you more (if the distance traveled from one corner to the next is different, you know that the driver(s) took different lines, vs. just knowing the raw time delta).

I would say you're generally overcomplicating/overthinking things.

 

[KFMaster]

...

I would say you're generally overcomplicating/overthinking things.

I understand your perspective. But it really depending on how you look at it. When I am doing a comparison of two laps, a quick glance of the variance plot tells me where I brake differently from those bumps in the the trace. If I have to go investigate each to see if it is real or an artifact of trace misalignment, I would say that is an unnecessary complication.

The point is, I can fix that with a script, then I don't have to worry about it. Just run the ld files through the script, done.

Only if someone could share with me the ld file format so I can read it, modify it, and write back the transformed data.

 

[mclarenf1papa]

When I am doing a comparison of two laps, a quick glance of the variance plot tells me where I brake differently from those bumps in the the trace. If I have to go investigate each to see if it is real or an artifact of trace misalignment, I would say that is an unnecessary complication.

I don't disagree with your point. However, I think the usefulness of data analysis to your driving will be quite limited if two laps are not similar enough that you can't evaluate brake distances without an offset. Data analysis is predicated on repeatability, so if you're driving inconsistently enough that you're getting 10+ meter shifts in your lap distances (with around 5m being the point at which you should start caring about a brake point difference), you're going to gain more time by learning to drive consistently than from comparing data traces.

 

[KFMaster]

I definitely need to work on my consistency. This is just a convenience thing. And itchy to try some Python programming

 

[peterasmith]

I definitely need to work on my consistency. This is just a convenience thing. And itchy to try some Python programming

I'm curious what sort of calculation you were planning on doing to normalize it?

I've been looking at normalizedCarPosition compared to iCurrentTime, not sure what channels those are from ACTI(Car Pos Norm/Lap Time I think), but the point where the norm position goes back to zero seems to be ~20mS earlier than when the current lap time flips back to zero. This is like 4 or 5 raw data samples, before I interpolate to the motec channel frequency I want.

Was hoping I could just create a Lap Distance channel from multiplying norm position by the track length, but it looks like motec wants accumulated distance, not just per-lap, and digging into my converter to implement that reminded me of this offset again. It was frustrating to create a consistent time base and get it to sync the lap beacons with what AC thinks the laptime is, especially when dealing with pause events as well.

 

[KFMaster]

I'm curious what sort of calculation you were planning on doing to normalize it?

Conceptually, what I would do is to make a grid of the track. Start at the start/finish line, on the center line of the track, at equal distance make a line normal to the track centerline. We can make the grid however fine to match the vehicle position samples. The car trajectory will have cross these grids. We ignore the lateral dimension of each vehicle position, but interpolates its linear position from the intersections of the vehicle trajectory to the two bounding grid lines. This will map every vehicle position on to the track centerline linear position. That linear position will be the normalized distance.

Above is the just the general concept. The actual implementation will depend on what data is available from the LD file and track map. I happen to have done my graduate work in autonomous vehicle control so am quite familiar with different ways to calculate some equivalent form of this concept. The only trouble is that I haven't done much hands on work in quite some time and never did python programming so it is going to take me some time (in my spare time) to figure out that parser.py code. My programming background was in C and Matlab.

I've been looking at normalizedCarPosition compared to iCurrentTime, not sure what channels those are from ACTI(Car Pos Norm/Lap Time I think), but the point where the norm position goes back to zero seems to be ~20mS earlier than when the current lap time flips back to zero. This is like 4 or 5 raw data samples, before I interpolate to the motec channel frequency I want.

Was hoping I could just create a Lap Distance channel from multiplying norm position by the track length, but it looks like motec wants accumulated distance, not just per-lap, and digging into my converter to implement that reminded me of this offset again. It was frustrating to create a consistent time base and get it to sync the lap beacons with what AC thinks the laptime is, especially when dealing with pause events as well.

By doing the mapping I described, it would be very easy to make a consistent, continuous accumulated distance in the centerline equivalent coordinate. If using this for your Lap Distance channel, every lap no matter the trajectory it actually traveled, will have the same overall distance. Should make all the problems you mentioned travail. This will also enable the lap time comparison of any laps to avoid the problems I mentioned in the earlier posts.

 

[peterasmith]

By doing the mapping I described, it would be very easy to make a consistent, continuous accumulated distance in the centerline equivalent coordinate. If using this for your Lap Distance channel, every lap no matter the trajectory it actually traveled, will have the same overall distance. Should make all the problems you mentioned travail. This will also enable the lap time comparison of any laps to avoid the problems I mentioned in the earlier posts.

Turns out my approach was sound. Motec is just finicky about where the lap marker beacons are with respect to the Lap Distance values. My interpolation algorithm was mangling the end of the sawtooth so it was getting confused when the last point in the lap was below the track length, or the first point was above the 2nd. Looks so much better comparing two laps when the distance reference is exact. Unfortunately(oddly?) my current test data is a bit too consistent, so there wasn't much variation to see, even to the one AI car dataset I extracted.

What were you planning to use to get the track boundary data? is that in fast_lane.ai? I just noticed yesterday that the 3DMap app uses that and seems to render the track width. I had been tediously extracting track edges from converted kn5 data using blender to get inside/outside lines into motec for reference. No way was I gonna try to drive the edges of Nords or the Targa!

 

[KFMaster]

Turns out my approach was sound. Motec is just finicky about where the lap marker beacons are with respect to the Lap Distance values. My interpolation algorithm was mangling the end of the sawtooth so it was getting confused when the last point in the lap was below the track length, or the first point was above the 2nd. Looks so much better comparing two laps when the distance reference is exact. Unfortunately(oddly?) my current test data is a bit too consistent, so there wasn't much variation to see, even to the one AI car dataset I extracted.

That is cool you worked out this part. But from your earlier description of normalizing the Lap Distance using the total distance per lap against a "standard" distance, I don't think it will solve the problem I was describing. This is because of "stretching" of the Lap Distance is not uniform through the lap. I.e., stretching only happens when you take a line that is longer than normal, say when making a mistake in a corner.

What were you planning to use to get the track boundary data? is that in fast_lane.ai? I just noticed yesterday that the 3DMap app uses that and seems to render the track width. I had been tediously extracting track edges from converted kn5 data using blender to get inside/outside lines into motec for reference. No way was I gonna try to drive the edges of Nords or the Targa!

For the actual calculation, I was not planning on using track data. First it makes calculation more complex, second, people don't always have a track map. I was going to look at the LD data and figure out an efficient way to use just the lap data to create an equivalent grid.

 

[peterasmith]

That is cool you worked out this part. But from your earlier description of normalizing the Lap Distance using the total distance per lap against a "standard" distance, I don't think it will solve the problem I was describing. This is because of "stretching" of the Lap Distance is not uniform through the lap. I.e., stretching only happens when you take a line that is longer than normal, say when making a mistake in a corner.

I probably didn't describe it that well. The Lap Distance channel I created comes from the AC internal calculation of distance normalized to the track spline. It isn't just a uniform shrink/stretch. I'm pretty sure it uses the path defined in the fast_lane.ai file in one of the track subdirectories.

It was pretty cool looking at the cursors of all of my laps move through a corner where the selected reference lap had a big spinout from tapping an AI car(Bahrain, turn 13).
The normalization isn't perfect, there still tends to be some tiny offset in places, likely due to data precision or maybe an artifact in my sampling, I think I have a small error in how I reconstruct the time base from laptime/lastlaptime.
I'm curious to see what happens on the targa, but I'd have to manage to complete a couple of full laps...

For the actual calculation, I was not planning on using track data. First it makes calculation more complex, second, people don't always have a track map. I was going to look at the LD data and figure out an efficient way to use just the lap data to create an equivalent grid.

Is the idea to use a reference lap similar to the way AC normalizes to the fast_lane spline? There isn't much else coordinate-wise available.

Having just spent entirely too much time playing with this, I've determined that the laptime resets when the front wheels cross the line(as it should), but the normalized position resets when the CG crosses a line across the track at the 1st point of the fast_lane.ai spline. So it will vary based on the car, and how close the spline starts to the finish line on a given track. Frustrating...

 

[KFMaster]

I probably didn't describe it that well. The Lap Distance channel I created comes from the AC internal calculation of distance normalized to the track spline. It isn't just a uniform shrink/stretch. I'm pretty sure it uses the path defined in the fast_lane.ai file in one of the track subdirectories.

If AC is not doing a simple uniform stretching, then it should be OK. The grid stuff I talked about is so to this stretching only where it is needed.

It was pretty cool looking at the cursors of all of my laps move through a corner where the selected reference lap had a big spinout from tapping an AI car(Bahrain, turn 13).
The normalization isn't perfect, there still tends to be some tiny offset in places, likely due to data precision or maybe an artifact in my sampling, I think I have a small error in how I reconstruct the time base from laptime/lastlaptime.
I'm curious to see what happens on the targa, but I'd have to manage to complete a couple of full laps...

Is the idea to use a reference lap similar to the way AC normalizes to the fast_lane spline? There isn't much else coordinate-wise available.

I don't know exactly what AC does. But if it doing a similar thing to the grid idea I mentioned then it is good. What reference path to use actually does not matter, so long as once the grid is formed, every thing is calculated using that same grid, then the comparison will be good.

Having just spent entirely too much time playing with this, I've determined that the laptime resets when the front wheels cross the line(as it should), but the normalized position resets when the CG crosses a line across the track at the 1st point of the fast_lane.ai spline. So it will vary based on the car, and how close the spline starts to the finish line on a given track. Frustrating...

These things are no doubt time sinks