Earlier quoted context omitted.
Well, you can reboot the system while driving(both console and dash), nothing special happens other than the AC turning off for a brief period of time. Brakes, wheel, throttle all respond normally. Source: Done this a few times to clear bad map data or occasional glitch.
AC should be considered mission critical.
Former Tesla Firmware Engineer Discusses the System
401–410 of 589 posts
Re: Former Tesla Firmware Engineer Discusses the System
#402Earlier quoted context omitted.
If the infotainment system caused the MCUs to reboot while someone traveling "130mph on San Mateo Bridge" and that caused the break system to segfault due to unconventional way of loading parts firmware, it might be a life&death situation, easily. Examples in that threads go on, literally hundreds!
There’s no concept of “reboot” with MCUs, since there’s usually no OS. Likewise there’s usually no concept of segfault, because segfault requires memory protection which is something most MCUs don’t use.
Re: Former Tesla Firmware Engineer Discusses the System
#403I used to work at SpaceX on the team that did a piece of software called "WarpDrive". It was a massive monolithic ASP.NET application, with large swaths done with ASP.NET WebForms and a slow frontier of ASP.NET MVC gradually growing when I was working there. This application was responsible for practically everything that ran the factory: inventory, supply chain management, cost analysis, etc. Elon is a big Windows f…
The majority of the professional world runs on Windows. There are many advantages: (1) Stable platform that's backward compatible over long periods of time. (2) Very good rapid application development tooling, e.g. Visual Studio which is probably still the best IDE overall. (3) A huge trained developer base making it easy to recruit. Same goes for IT personnel. (4) A huge pool of software, custom dev firms, etc. (5)…
Re: Former Tesla Firmware Engineer Discusses the System
#404Earlier quoted context omitted.
Remember the Toyota uncontrolled acceleration bug and the report that came as a result of the trial. It seems like software is a bit of a second thought for some incumbents too.
Not sure if you're being sarcastic or not, but the Toyota issues were not caused by any software bug. Most cases were caused by people hitting the wrong pedal. The others were caused by floor mats that were a bit too long, causing the gas pedal to stick. https://www.caranddriver.com/features/its-all-your-fault-the...
Re: Former Tesla Firmware Engineer Discusses the System
#405Why 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…
what about the iphone demo was hacky ?- just curious
>The iPhone could play a section of a song or a video, but it couldn’t play an entire clip reliably without crashing. It worked fine if you sent an e-mail and then surfed the Web. If you did those things in reverse, however, it might not. Hours of trial and error had helped the iPhone team develop what engineers called “the golden path,” a specific set of tasks, performed in a specific way and order, that made the phone look as if it worked.
>They had AT&T, the iPhone’s wireless carrier, bring in a portable cell tower, so they knew reception would be strong. Then, with Jobs’s approval, they preprogrammed the phone’s display to always show five bars of signal strength regardless of its true strength.
>None of these kludges fixed the iPhone’s biggest problem: it often ran out of memory and had to be restarted if made to do more than a handful of tasks at a time. Jobs had a number of demo units onstage with him to manage this problem. If memory ran low on one, he would switch to another while the first was restarted. But given how many demos Jobs planned, Grignon worried that there were far too many potential points of failure.
Re: Former Tesla Firmware Engineer Discusses the System
#406I used to work at SpaceX on the team that did a piece of software called "WarpDrive". It was a massive monolithic ASP.NET application, with large swaths done with ASP.NET WebForms and a slow frontier of ASP.NET MVC gradually growing when I was working there. This application was responsible for practically everything that ran the factory: inventory, supply chain management, cost analysis, etc. Elon is a big Windows f…
Elon nearly brought the newly merged X and Confinity to its knees during a critical period in its development by 1) insisting on the "X" brand when Paypal was more popular with users, and 2) insisting on Windows over Linux despite the protests of his tech team. Soon after he was ousted and Thiel was made CEO. Interesting to see he's still pushing Windows. Source: Paypal Wars by Eric Jackson
Re: Former Tesla Firmware Engineer Discusses the System
#407Earlier quoted context omitted.
Banks can reverse transactions if they want to. Tesla's cavalier attitude towards manufacturing has yielded a 14% first pass through rate on the Model 3 line (which is abysmal and may bankrupt the company along with declining M3 demand) vs. the industry standard of ~80% FPT rate. Source - https://www.businessinsider.com/tesla-hit-model-3-target-by-... We're at the point in the Tesla story similar to that of 2008 wher…
I don't think the rework rate is a big deal for the customer. Ultimately manufacturing is about increasing the yield rate so that costs are lowered, because rework is expensive. But if you can make money with lots of manual rework on every product, it's no big deal. Something to improve next quarter. I have so many electronic devices, from cheap to expensive, that have some passive component manually bodged on somewh…
It's not about money. Correcting and refacturing a board takes time, in the order of months even for a simple one. It's too long.
Re: Former Tesla Firmware Engineer Discusses the System
#408Why 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…
As an embedded engineer this was: a) interesting, because it shows how other companies solve (or fail to solve) specific common problems. b) surprising, because I thought they'd be much better at it. Car infotainment is generally not categorized as safety-critical and can be quite similar to regular software development. Having remote access changes things: I always thought their security must be top notch if they ha…
Re: Former Tesla Firmware Engineer Discusses the System
#409Earlier 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).
As a person who used to write navigation and control software for autonomous vehicles who occasionally gets downvoted for telling people that you really don't need a fancy RTOS for this stuff, you really don't need a fancy RTOS for this stuff. Linux is a very common platform for highly responsive robotic systems. I promise that their pid control isn't an Electron app.
These things frighten me everyday. What frightens me even more, is the people who work on autonomy without a real grasp on determinism. It's unfortunate that the people who have the most high tech backgrounds (phds in computer vision AI, etc) applicable to autonomy, have never implemented safety critical autonomous systems outside of a research project that tested some aspect of detection or control in a test environment and had to only work once to get a paper published.
For general robotics linux is great. But there is an enormous difference between a robot roaming around your house bumping off walls, and a vehicle carrying a whole family at 70mph.
Most of the linux based systems I have worked with have some form of redundancy, whether it be other chips running linux, or ideally ECU's running an RTOS that perform monitoring, gating, and/or some level of safety fallback control. The RTOS based redundancies often are what provide ASILD. Trusting a single linux processor is what everyone does to get funding, but when you go out and test on public roads with human lives at stake, or start selling a product, you better have some quantitative guarantees other than "It's been fine so far..." That kind of stuff makes me angry.
Re: Former Tesla Firmware Engineer Discusses the System
#410Earlier quoted context omitted.
Or maybe that is THE SMART THING. Realizing that you need resources to accomplish it, and throwing money would do it for you.
Monkeys have no salary and no rights. It's more scalable and easier to manage than regular employees. Get a lot of monkeys and put them at work. They will produce something. Better have something than have nothing.