Unfortunately the code powering OpenPilot is not very reliable. As the OP alluded to it's time-sensitive code written in (very hard to understand) Python.
It's not really that time sensitive. The main event loop for something like this only has to run at like 50hz.
I didn't find the code to be all that hard to understand either (at least the car interface bits needed to port to another car).
That’s the sort of speed that has game developers, who can tolerate occasional pauses without getting anybody killed (although I’m sure some gamers act like they’re dying when it happens), avoiding memory allocations and tuning garbage collectors. That’s similar to how often the render callback for audio code will run, code where you carefully avoid taking locks or calling most system APIs and write the whole thing in C or simple C++ so implicit behaviors don’t result in audible glitches.
Python is good for many things (my whole web site runs on it) but it’s completely unsuitable for this job.
You're conflating speed and latency. The main event loop running at 50hz may or may not be fine, but a 50-100ms pause is certainly unacceptable, especially in the drive-by-wire / car interface components which are inexplicably combined with the entire platform and run on the same hardware.
How can this be not "really time sensitive"? The stability of these kind of controllers depend on smooth periods without jitter.
Putting these kind of controller on a phone written in Python is OK for a student project driving at 20 km/h on a closed off area. It actually madness and most likey illegal to use these modifications on public roads. Atleast it should be ...