Their low level control is done in Python, on top of Android, on a smartphone. No further comment, your honor.
https://github.com/commaai/openpilot/tree/devel/selfdrive/co...
Among the processes that runs on the Eon, you can find algorithms for perception, planning and controls. Most of it is actually autogenerated code in C++ (see model predictive controls). Python code is used mainly as a wrapper and for non-computational expensive parts. To use functional safety terminology, the Eon functionality is considered QM (Quality Management). This means that any failure in delivering the desired output at the right time is perceived as bad quality and has no safety implications. So, how often those algorithms deliver the wrong output because some parts are written in Python? How often because RT isn’t enforced? Negligible. Pretty much all the mistakes of a level 2 driver assistance system are due to the quality of the algorithms, the models, the policies etc… There is a long way to go before changing the coding language will be the lowest hanging fruit to improve the system. Until then, using the simplest and most agile coding language (given performance constraints) is probably the best way to maximize quality.
* consumer hardware does not normally fulfil automotive safety requirements. It could for instance go into thermal shutdown or into a degraded mode if the temperature is too high. Additionally, there is no HW redundancy, I assume that if any of the HW components of the smartphone fail, the system cannot continue to maintain its safety properties.
* Android is a consumer OS, designed for consumer workloads. A real-time, safety certified OS like INTEGRITY, ThreadX, Nucleus etc should be typically used for such workloads.
* The safety-relevant software running on top of the OS is developed with specific toolchains and using specific programming languages. Some requirements [1] for a language used in safety-critical context are defined behaviour, explicit dependability support (e.g. design by contract), predictable timing, suitability for static verification, significant field use, strong typing (not necessarily static typing!), feasibility to restrict the language to a subset (e.g. MISRA, JSF, etc).
One of the most popular languages for such software is C, which is not safe and doesn't fulfil several of the above criteria. This is mitigated through tooling, processes, code generation, design validation & verification and so on.
[1]: Taken from Embedded Software Development for Safety-Critical Systems, Hobbs. Interestingly the author would personally choose D or Rust for safety-critical development with the condition of having enough confidence in the compilers.
This sounds crazy even to a person who makes living from running software on commodity hardware (x86/x86_64). Android does not sound like a hard real-time OS. I've seen it hang up in a fsckin' coffee machine! I don't want it at the center of two tons of steel that move 100km per hour.
Python has a GC as well, but we turn it off for the control loop processes. https://github.com/commaai/openpilot/blob/devel/selfdrive/co...
Haters love to bring up the Python, but they never stick around long enough to explain exactly why it's a problem.
Great for scripts, but there is a reason why most large companies start bolting on types on whatever dynamic language they started with.
Edit: also, Python does eagerly signal type errors, unlike say Javascript or C, so you don't get silently wrong answers. C is the default language in auto industry. .
Yeah, this is a bit of whataboutism, certainly it would be nice if the state of the art in production languages was closer to the ideal of statically verified... Haskell and Rust are in the right direction, and would be clearly superior in this regard
Statically typed languages are mature and you have no excuse not using them if your doing anything that approaching a need for reliability. Cars do, social cat pictures, not so much.
Why does everyone assume the phone is doing all the work?
Having your code open source means that outsiders will notice flaws in it, try not to "push back" too much against them. Sometimes they will point out serious flaws that allow you to improve your code significantly, sometimes they will point out non-issues or simply be wrong about things. So instead you should embrace it and take the time to consider the feedback. The crowd is a valuable resource that you have, that closed source projects don't.
Sounds like they're just using open source to avoid liability and side step regulators. I love open source, but I do not think it's being used for benevolent reasons here.
Such software needs to react in real time though, if the task that's turning the steering wheel gets preempted in the middle of taking a curve on a cliff your self-driving car will become a self-flying car.
Such a system would be the equivalent of a driver that suddenly starts texting at all sorts of poorly chosen times.
They weren't connected to other shuttle computers, were they?
https://airandspace.si.edu/collection-objects/calculator-han...
I remembered reading it in the newspapers at the time which would have probably make the reports generally pre internet (or pre newspapers on the internet) in the 1980's. Of course I could be remembering it wrong or it could have been a HP calculator ad.
it used to be that certain chipsets could do motor control by bitbanging the parallel port, but modern pcs/phones can no longer do this due to latency.