Fast-F1: [BUG] Personal best times need to be kept for each qualifying segment individually

Discussed in https://github.com/theOehrly/Fast-F1/discussions/164

^{Originally posted by blakehinsey April 26, 2022} Has anyone noticed the behaviour of the pick_fastest() with Imola data for Qualifying?

I’ve looked into the code, and the only_by_time=True helps.

Does this mean that Q1 and Q2 laps were not counted as personal bests? It is a strange one as Q1/2 were dry and Q3 times were wet.

I will admit, my coding is not excellent, so maybe I have goofed something up.

It’s “BRRRAKE” from Twitter btw!

</div>

The API resets personal best for every quali section. Only a reference to the last received personal best time is kept in the API parser. Therefore, Q3 overrides Q2 here despite the times being slower. This could actually happen in some dry sessions too, which is not good at all.

Working around this is non-trivial.The API parser needs to keep track of the order of personal best times to kind of create a ranking of official best times, while still detecting lap time deletions. Additionally, it needs to be possible to split the laps in session.laps into Q1, Q2 and Q3 laps.

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 15 (5 by maintainers)

Commits related to this issue

Fix #165: session.laps.pick_fastest() should return the overall fastest lap, instead of the fastest lap in the latest session. — committed to AND2797/Fast-F1 by AND2797 2 years ago
Fix #165: session.laps.pick_fastest() should return the overall fastest lap, instead of the fastest lap in the latest session. — committed to AND2797/Fast-F1 by AND2797 2 years ago
Fix #165: Update basics.rst to reflect new columns added to laps dataframe. — committed to AND2797/Fast-F1 by AND2797 2 years ago
fix tracking of personal best times in the api parser (#165) — committed to theOehrly/Fast-F1 by theOehrly a year ago

Most upvoted comments

@hash55 please try to read through the contribution guidelines: https://theoehrly.github.io/Fast-F1/contributing/index.html. You’re questions will probably at least partially be answered there. If you have any further questions after that, please open a separate discussion. Then I can try to help you with whatever is still unclear.

theOehrly on Sep 29, 2022

I think adding a separate column like you did with the AllPersonalBests is good. I was thinking more like numbering them instead of duplicating the lap time into that column. But your way might probably make it easier to work with the data.

We could simply keep a track of all the “personal bests” and return the fastest personal best when calling session.laps.pick_fastest(). That way we don’t have to split the laps by Qualifying. That can be a separate feature, to get the fastest lap for a particular Qualifying session.

Agreed. That’s what I more or less had in mind. We could (potentially as a separate issue/feature) add another column that indicates Q1/2/3 for each lap. And a ready made method to select all laps from a specific quali section.

There is no further information given about the session status data in the docs. I haven’t analyzed it in detail and written down how it works (should probably). It’s fairly self explanatory though usually.

Regarding the timestamps of the race control messages, I need some time to look at that.

Whenever you want me to take a look at your code, feel free to open a PR, maybe as draft.

theOehrly on May 29, 2022

it seems like the issue is that after each Qualifying session, the personal bests are reset. So, even if a time in Q2 was faster, .pick_fastest() will return the fastest time from Q3, correct? In this case the lap_time may actually not be the fastest “legal” lap time set.

Yes, exactly. The API provides the current personal best lap time for each driver, but without any reference to the lap number. That’s a bit problematic. Currently, the API parser code only keeps the last personal best time that is ever received, which will be the last personal best in Q3 (or Q2/Q1 if a driver is eliminated earlier). Therefore, the information is lost for any drivers earlier Q sessions. Then the each drivers lap times are compared with the last received personal best time and the first lap that matches the personal best time is marked as fastest lap.

Generally, a new personal best is only received from the API if a driver goes faster than their previous time. Or, if a personal best lap is deleted, the personal best time from before that is sent again. For example, if we receive as personal best times

1:16:150
1:16:050
1:15:900  < deleted
1:16:050

we can assume that the third personal best time was deleted. We have no information about deleted laps, if they were not personal best lap times. (In theory, we could try to extract that information from race control messages. I’m not sure how reliable that would be)

If we set .pick_fastest(only_by_time=True) does that return the fastest lap, regardless of whether it was a legal lap or not?

Yes, it simply returns the lap with the minimum time without any further logic being involved.

theOehrly on May 22, 2022