Earlier quoted context omitted.
> we use it for sub millisecond control of Traffic Lights Why would anyone need "sub millisecond control of Traffic Lights"? Traffic lights are mission critical systems, of course, but even millisecond precision should be more than enough, and possibly even 0.5x-1 second precision...
The sub-millisecond precision ensures they can totally destroy your day with short left turn arrows and yellow lights.
Former Tesla Firmware Engineer Discusses the System
531–540 of 589 posts
Re: Former Tesla Firmware Engineer Discusses the System
#532Earlier quoted context omitted.
On a tangent, but still germane to the thread: Why arent their efforts to create "autonomous only" traffic managment scenarios, where people drive into a given, known area, and the area then takes control of managing the traffic and vehicles. Such that you relinquish control of the vehicle to that area's control system, with your destination stated and then your vehicle is managed accordingly. For example, a parking…
Well this would mean collaboration between autonomous car manufacturers to build a common protocol. And this does not fit with their business model of getting massive investment on the grounds of potentially being the first player on the market. I don't think there is any possibility of large scale autonomous driving without a shared control infrastructure. Autonomous driving will only work as long as autonomous cars…
Even if manufacturers would somehow manage to agree on an API, it could then be "abused" by competitors or accessory vendors to sell their own customized car assistants, which would instantly work with any car brand - without them having to negotiate with the manufacturers.
I fear we will sooner have a usable open IoT standard than manufacturers giving up that level of control.
Re: Former Tesla Firmware Engineer Discusses the System
#533Why is this interesting or surprising? Of course almost all challengers have hacky tech under the hood because they don't have the resources. Winning from that position is possible not because of generally better tech but by delivering something that the incumbents don't. Remember the demo of the first iPhone (vs the huge expertise of Nokia). Or how Microsoft won the desktop starting from a single user, cooperative m…
Cars weigh thousands of pounds and routinely drive upwards of 60 miles per hour. The success of the first iPhone or Facebook app didn't depend on using it to navigate through life-and-death situations not only for the users but also for everyone around them. There are places for 'move fast and break things'. But cars move fast already, and they can really break things.
Re: Former Tesla Firmware Engineer Discusses the System
#534Earlier quoted context omitted.
Capitalism. Need for money and results. I don't think that anybody wants to burnout anybody, it's just the pressure of the whole system I guess. Money pushes to do things fast. Shareholders and clients to keep happy.
> Shareholders [..] to keep happy. In my opinion, this is the biggest flaw of the system. For many investors, a company is less about what it makes and more like a process to grow their money. Even when a company becomes profitable, there's always pressure to make it even more profitable quarter after quarter.
Would you keep your retirement funds in a company that doesn't grow?
Re: Former Tesla Firmware Engineer Discusses the System
#535Earlier quoted context omitted.
Nice high level conceptual model of such a system. What you conveniently ignore is the complexity that is necessarily introduced by hard real time constraints, safety and all the reliable communication required. This stuff really does get complex. A sensor controller will likely be on multiple cycles internally: one for oversampling the sensor hatdware and one for transmitting the (filtered/corrected/calibrated) resu…
I had a very mean line-by-line response, but then I deleted it because it wasn't in keeping with HN guidelines. I apologize for having written it even though you'll never read it. Instead I'll just say that literally nothing you've mentioned has anything to do with whether you choose to use Linux. Yes your serial lines will be noisy. Yes you have to write software. Yes you need specific domain knowledge to do it well…
So to me, "you don't need an RTOS" means that you're running on bare metal. And that would be hard to pull off for the reasons that I outlined above. And I think this is where we ended up misunderstanding each other.
I enjoy the kinds of restricted RTOS environments that we use because their simplicity means that I can get a total understanding of what is going on quite easily.
This does not mean that Linux is completely inappropriate for real time tasks. I am sure that you could analyze and patch the kernel to match pretty high standards (others mentioned patches). Given the relative size and complexity of a Linux system, this is no simple task. But if you run it on appropriate hardware (not your run of the mill x86), I don't see why you couldn't get reliable realtime responses.
But safety essentially means that the software will not fail more often than once every x hours where x ranges between 10^5 and 10^8, depending on the level of safety required. Proving that for a complex system is hard. For example, how do you show that the essentially indeterministic pattern of dynamic memory allocations happening in a Linux system will never lead to memory exhaustion by fragmentation?
I know of no version of the Linux kernel (or GCC, for that matter) that got a functional safety certification. Safety standards are transitioning away from allowing positive track records as sufficient proof that a piece of software meets safety standards. Do-178 now only allows certified software AFAIK and I expect this to be carriedover into ISO 61508 and ISO 26262. This means a regulated development process, pretty strict coding standards, complete test coverage, full documentation, and so on also for all 3rd party software. Not sure how this transition is going to play out in practice.
Do you know any ASIL-C or ASIL-D (or SIL-2/SIL-3) software that is running on Linux? I am curious whether anybody managed to get that certified. I know that Linux is running on some class II medical equipment, but then, standards for these devices are inexplicably lower in practice in my experience.
Re: Former Tesla Firmware Engineer Discusses the System
#536Earlier quoted context omitted.
> the rockets fly with a heavily customized Linux install My jaw hit the floor the first time I heard this. Why Linux instead of an RTOS?? Apparently Tesla's autopilot also runs Linux, which seems like a huge accident waiting to happen (pun intended).
> Why Linux instead of an RTOS? Same reason SpaceX eschews radiation-hardened processors for redundant off-the-shelf cores: supplier competition. There aren't many RTOS engineers on the market; there are many Linux engineers. Once they got over the cost of hardening the kernel, SpaceX found itself at a scaling advantage versus RTOS-based competitors.
Re: Former Tesla Firmware Engineer Discusses the System
#537Earlier quoted context omitted.
Those two, particularly Ubuntu, are the opposite of naked. Try something like Arch.
Arch? Arch ships packages with debug symbols and docs included, and takes over a hundred MB for just a base install! Alpine is way smaller; base image under 10MB, packages broken apart so you only get binaries unless you ask for more, linked with musl to make it even smaller. EDIT: This is meant to be a bit tongue-in-cheek, but I seriously do prefer Alpine over literally every other Linux distro I've yet seen for min…
Re: Former Tesla Firmware Engineer Discusses the System
#538Earlier quoted context omitted.
There is difference between entertainment system and infotainment system. Infotainment systems are increasingly used as primary UI for almost anything on car that is not controlled by steering wheel and pedals and thus has to be able to communicate with almost everxthing that is in the car. Tesla is pretty extreme example of this, but it works this way for most manufacturers.
That’s true, but only part of the story. If the only interaction between the automated systems and the braking system is to apply more braking power and the cars breaks can significantly overpower the engine then nothing the infotainment system can do would prevent the car from coming to a complete stop. Similarly, if the power steering was limited to applying say 5lb of force to the steering wheel (as felt by someon…
Re: Former Tesla Firmware Engineer Discusses the System
#539Earlier quoted context omitted.
read this book too. The insistence on Windows blew my mind, given his "reputation" as an engineer.
Thinking from first principle you can reason why Elon pushed for windows. Elon is a guy who wants to get done. On windows you get a linear output with time spend on it. On Linux the output is exponential. Relative to windows lot of time is required for entry on Linux.Since Elon is man of output he did not like to spent so much upfront time. Also he don't want to let go the control as he is micro manager.
Re: Former Tesla Firmware Engineer Discusses the System
#540Is there any corroboration of this? Like that this is even someone who worked at Tesla? I'm certainly not discounting that it could be real, but with so many people shorting Tesla, any uncorroborated information should be looked at with a high degree of skepticism.
I think people are shorting the company because it's bankrupt and way behind no fulfilling orders + having major rework problems in factories. Elon likes to push that narrative that there's this epic battle between himself and people with short positions in a good vs. evil way. In fact, it seems pretty apparent that the company is in trouble and the people saying that have put their money where their mouth is. They a…
My point was only that when there's a lot of money on the line, we should be skeptical of uncorroborated info (good or bad).