On one hand I agree with you wholeheartedly (I also think python is a weird language choice for something that probably has some hard real-time requirements), but also consider that stuff like that may very well be present in the code bases of the closed-source commercial solutions, but unless someone who has worked on one of them speaks up, we'll never know.
There's openpilot code, and then there's panda code that runs on a separate real time micro chip. All the safety relavent code runs on the panda, and it's written in C following misra c guidelines. They also comply with iso 26262.
See more info about their safety model in the safety architecture section of this blog post.
Yeah, that's why I couched my critique a little bit: I have no insight whatsoever into the commercial side of this and, for all I know, it could be even worse!
But that alone is bloodchilling: it terrifies me, as a pedestrian and cyclist, to think that stuff like this is probably controlling the pieces of machinery that could kill me in a split second.
In their system, the actual real-time safety critical code is elsewhere, on a dedicated processor. The python code sends messages to the safety code, which applies limits and sends commands to the car hardware. And other safety systems like AEB are totally untouched and still functional.
The safety code has a limit on steering ramp rate and a max torque limit. The driver can easily overpower the torque limit, and the ramp rate limit means it won't suddenly jerk.
The python code I think is temporary, they ultimately want to do end-to-end models that do both perception and control (rather than a model to do perception and traditional controller to do control). If that effort fails I think they would probably replace the python code, the current stuff is definitely amateurish.
George just said today during a Q+A session that they do not intend to do learned control because traditional control is already greatly exceeds human ability.
