Python tool to extract data from F1 app

[rhino2]

Hi, could you post again the API you have used? The link you posted is not active anymore.
Many thanks

[Oehrly]

Hi, could you post again the API you have used? The link you posted is not active anymore.
Many thanks

In case you're still searching:

https://github.com/theOehrly/Fast-F1

[Xwang]

Hi, could you post again the API you have used? The link you posted is not active anymore.
Many thanks

In case you're still searching:

https://github.com/theOehrly/Fast-F1

Thank you,
I was using the latest 1.5.11 version made by Ax6 after winter testing which I had on my pc with some modifications made by myself to be able to download data before the race or session is added to ergast F1 (so that to be able to get data just after the session ends).

[Oehrly]

[...]
Thank you,
I was using the latest 1.5.11 version made by Ax6 after winter testing which I had on my pc with some modifications made by myself to be able to download data before the race or session is added to ergast F1 (so that to be able to get data just after the session ends).

I noticed that Ergast problem to and have it fixed in my repo. It's now just printing a warning if the ergast lookup fails. Apart from that I only made minor changes to the original code so far.

I have been mostly working on trying to better synchronize lap comparisons. The current implementation is really not very accurate. The problem is that the API does not provide a timestamp for when a lap starts or ends.The difference between two laps can be multiple tenths of a second.
For example, if I take the the position of the car at the start of the lap and I compare that for each lap it can easily vary by 30 meters or even more.
The position data and telemetry have the same (likely exact) timestamps. That means it is highly likely that there is the same level of inaccuracy with the car telemetry data.

[Xwang]

[...]
Thank you,
I was using the latest 1.5.11 version made by Ax6 after winter testing which I had on my pc with some modifications made by myself to be able to download data before the race or session is added to ergast F1 (so that to be able to get data just after the session ends).

I noticed that Ergast problem to and have it fixed in my repo. It's now just printing a warning if the ergast lookup fails. Apart from that I only made minor changes to the original code so far.

I have been mostly working on trying to better synchronize lap comparisons. The current implementation is really not very accurate. The problem is that the API does not provide a timestamp for when a lap starts or ends.The difference between two laps can be multiple tenths of a second.
For example, if I take the the position of the car at the start of the lap and I compare that for each lap it can easily vary by 30 meters or even more.
The position data and telemetry have the same (likely exact) timestamps. That means it is highly likely that there is the same level of inaccuracy with the car telemetry data.

I have noted those kind of discrepancies when I tried to compare different laps.
I didn't had time to try to understand how to solve/minimize that because in any case I do not have enough time to use those data for parameter estimations (I think that the data are not enough because we know nothing about engine settings and operating mode status and about how much fuel is on board and how much pilot are pushing to the limit; the only think we can assume is that the best qualy lap is made at the maximum of the performance, but that does not let us know nothing about the race performances; so at the moment my project is in standby)

[LeeJohnson]

Xwang --
In one of your earlier posts you ask: "The total length is different between the two pilot traces (about 2 meters) so I think the best way to handle that is to normalize the length of the lap to the circuit official length. Do you agree? "

I think it is possible that (slight) variations in the drivers' lines around the track could easily account for the 2 meters difference in the two pilot traces.

You also commented about a larger difference between "official" track length and the two pilot traces; this could easily be due to the path used to measure the official track length (for example, a path through the center line of the track width vs. a path thru corner/apex chords vs. many other "definitions" that idealize a car trajectory & account in some way for car width.

[Xwang]

Xwang --
In one of your earlier posts you ask: "The total length is different between the two pilot traces (about 2 meters) so I think the best way to handle that is to normalize the length of the lap to the circuit official length. Do you agree? "

I think it is possible that (slight) variations in the drivers' lines around the track could easily account for the 2 meters difference in the two pilot traces.

You also commented about a larger difference between "official" track length and the two pilot traces; this could easily be due to the path used to measure the official track length (for example, a path through the center line of the track width vs. a path thru corner/apex chords vs. many other "definitions" that idealize a car trajectory & account in some way for car width.

You are right and I agree with you, but the other problem is that the start of the laps is often not at 0 meters. If I have understood correctly this is the problem that Oehrly is trying to solve.
If laps correctly start at 0 then it is possible to evaluate if the different laps lengths are given by different trajectories or are "artifacts" given by the way the data are get and managed by the FIA app which, after all, is not intended to give high fidelity telemetry data, but to give some information at real time.

[Juzh]

[...]
Thank you,
I was using the latest 1.5.11 version made by Ax6 after winter testing which I had on my pc with some modifications made by myself to be able to download data before the race or session is added to ergast F1 (so that to be able to get data just after the session ends).

I noticed that Ergast problem to and have it fixed in my repo. It's now just printing a warning if the ergast lookup fails. Apart from that I only made minor changes to the original code so far.

I have been mostly working on trying to better synchronize lap comparisons. The current implementation is really not very accurate. The problem is that the API does not provide a timestamp for when a lap starts or ends.The difference between two laps can be multiple tenths of a second.
For example, if I take the the position of the car at the start of the lap and I compare that for each lap it can easily vary by 30 meters or even more.
The position data and telemetry have the same (likely exact) timestamps. That means it is highly likely that there is the same level of inaccuracy with the car telemetry data.

Would it be possible to sync start of the lap with the sector 3 speed trap data? Speed trap 3 radar is always positioned on the start/finish line, so when S3 speed reads lets say 266 kmh, then you know you have start of lap on that speed, even if actual number comes up a few tenths late, as you described. Just a thought, I'm not technical enough to know if this can be done or how practical is it.

[Oehrly]

That is a very interesting idea which I haven't thought of yet. If it works it would certainly be way more efficient than what I had tried before. I will give it a try as soon as I get around to it. I'm pretty sure that it is doable with the data that is available.
If I sync the laps using the speed trap data I can cross-check that against the position data. The coordinates should be the same at the start of each lap. That way I should be able to verify whether this is accurate.

[Xwang]

That is a very interesting idea which I haven't thought of yet. If it works it would certainly be way more efficient than what I had tried before. I will give it a try as soon as I get around to it. I'm pretty sure that it is doable with the data that is available.
If I sync the laps using the speed trap data I can cross-check that against the position data. The coordinates should be the same at the start of each lap. That way I should be able to verify whether this is accurate.

I'm not sure that one of the coordinate system axis is aligned with the main straight.
If X axis is aligned, it should have always the same value, but the Y coordinate could vary a bit.
If the system is not aligned both coordinates will vary because the pilot does not cross the start line always in the same exact position.
I fear that the X axis is aligned to North and the Y axis to East.

[Oehrly]

That is a very interesting idea which I haven't thought of yet. If it works it would certainly be way more efficient than what I had tried before. I will give it a try as soon as I get around to it. I'm pretty sure that it is doable with the data that is available.
If I sync the laps using the speed trap data I can cross-check that against the position data. The coordinates should be the same at the start of each lap. That way I should be able to verify whether this is accurate.

I'm not sure that one of the coordinate system axis is aligned with the main straight.
If X axis is aligned, it should have always the same value, but the Y coordinate could vary a bit.
If the system is not aligned both coordinates will vary because the pilot does not cross the start line always in the same exact position.
I fear that the X axis is aligned to North and the Y axis to East.

You're not getting something like GPS data from the API. It's more like all coordinates are on one line even though there is an X, Y and Z coordinate. You cannot get the on-track position or choice of line in a corner from the data.
There will still be some minor variance but not because of the driver crossing the finish line at different positions. Only because of the limited sampling rate.

It would be really cool if the data was that accurate.

[ispano6]

[...]
Thank you,
I was using the latest 1.5.11 version made by Ax6 after winter testing which I had on my pc with some modifications made by myself to be able to download data before the race or session is added to ergast F1 (so that to be able to get data just after the session ends).

I noticed that Ergast problem to and have it fixed in my repo. It's now just printing a warning if the ergast lookup fails. Apart from that I only made minor changes to the original code so far.

I have been mostly working on trying to better synchronize lap comparisons. The current implementation is really not very accurate. The problem is that the API does not provide a timestamp for when a lap starts or ends.The difference between two laps can be multiple tenths of a second.
For example, if I take the the position of the car at the start of the lap and I compare that for each lap it can easily vary by 30 meters or even more.
The position data and telemetry have the same (likely exact) timestamps. That means it is highly likely that there is the same level of inaccuracy with the car telemetry data.

Would it be possible to sync start of the lap with the sector 3 speed trap data? Speed trap 3 radar is always positioned on the start/finish line, so when S3 speed reads lets say 266 kmh, then you know you have start of lap on that speed, even if actual number comes up a few tenths late, as you described. Just a thought, I'm not technical enough to know if this can be done or how practical is it.

That is a good suggestion. I've been working on a F1 global telemtery map in Simhub and the leaderboard data is calculated and rendered after the first lap, not the start of the race.

[Xwang]

That is a very interesting idea which I haven't thought of yet. If it works it would certainly be way more efficient than what I had tried before. I will give it a try as soon as I get around to it. I'm pretty sure that it is doable with the data that is available.
If I sync the laps using the speed trap data I can cross-check that against the position data. The coordinates should be the same at the start of each lap. That way I should be able to verify whether this is accurate.

I'm not sure that one of the coordinate system axis is aligned with the main straight.
If X axis is aligned, it should have always the same value, but the Y coordinate could vary a bit.
If the system is not aligned both coordinates will vary because the pilot does not cross the start line always in the same exact position.
I fear that the X axis is aligned to North and the Y axis to East.

You're not getting something like GPS data from the API. It's more like all coordinates are on one line even though there is an X, Y and Z coordinate. You cannot get the on-track position or choice of line in a corner from the data.
There will still be some minor variance but not because of the driver crossing the finish line at different positions. Only because of the limited sampling rate.

It would be really cool if the data was that accurate.

Running this code:

Code: Select all

import fastf1 as ff1
gp=3; Hungarian_2020_Q_laps=ff1.get_session(2020,gp).get_quali().load_laps()
lap=Hungarian_2020_Q_laps.pick_team('Ferrari').pick_fastest()
from fastf1 import plotting
from fastf1 import utils
from matplotlib import pyplot as plt
fig2, ax2 = plt.subplots(figsize=(12, 6.75))
ax2.plot(lap.telemetry['X'], lap.telemetry['Y'], color=plotting.TEAM_COLORS['Ferrari'])

I get this image:


So it seems that some kind of geographical, if not GPS data are included. Of course they are not latitude and longitudes, but meters in east and north direction.

I've used the Ax6 original code, because I've had time to install your, but I think that you'll get the same image.

[Juzh]

That is a very interesting idea which I haven't thought of yet. If it works it would certainly be way more efficient than what I had tried before. I will give it a try as soon as I get around to it. I'm pretty sure that it is doable with the data that is available.
If I sync the laps using the speed trap data I can cross-check that against the position data. The coordinates should be the same at the start of each lap. That way I should be able to verify whether this is accurate.

You've had any luck with this?

[Oehrly]

That is a very interesting idea which I haven't thought of yet. If it works it would certainly be way more efficient than what I had tried before. I will give it a try as soon as I get around to it. I'm pretty sure that it is doable with the data that is available.
If I sync the laps using the speed trap data I can cross-check that against the position data. The coordinates should be the same at the start of each lap. That way I should be able to verify whether this is accurate.

You've had any luck with this?

I haven't gotten around to trying it yet. Xwang had sent me a version of the original code that is more recent than the version which I had based my repository on. (The original had already vanished when I started working on this.) I wanted to get that merged with my current version first before they diverge any more.
I finished that yesterday. Now, I have time to look into your idea. I'm very interested in finding out whether it works too.