Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Former Tesla Firmware Engineer Discusses the System

twitter.com

Post reply on HN
Print view View original

111–120 of 589 posts

Re: Former Tesla Firmware Engineer Discusses the System

#111

Post by flamedoge »

BugsJustFindMe wrote: post #74
8_hours_ago wrote: post #52

Earlier 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.

muh arteries...

Re: Former Tesla Firmware Engineer Discusses the System

#113

Post by Avshalom »

Twirrim wrote: post #58
liber8 wrote: post #31

Earlier quoted context omitted.

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...

Regardless of whether the acceleration were caused by the software or not, the testimonies for the software experts called in to review Toyota's source code for the case were eye-popping: http://www.safetyresearch.net/blog/articles/toyota-unintende... > Skid marks notwithstanding, two of the plaintiffs’ software experts, Phillip Koopman, and Michael Barr, provided fascinating insights into the myriad problems with To…

I mean it's a bit depressing but its only eyepopping if you suffer from murray-gelman amnesia about literally every piece of software even written.

Re: Former Tesla Firmware Engineer Discusses the System

#114

Post by bipson »

sz4kerto wrote: post #8

Why 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…

Especially considering that the engineer was partially blaming Bosch as a supplier that made these processes necessary.

Bosch supplies VW (includes Audi, Seat, Skoda, ...) and various other large incumbents, as one of the biggest car manufacturer supplier. Why do people think they are considerably better off? Their practices are often equally ridiculous and dangerous.

As a rat in that cage you do whatever you need to make things work.

Re: Former Tesla Firmware Engineer Discusses the System

#115

Post by gamblor956 »

ddevault wrote: post #11

I 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…

Given the many ASP.NET software packages that handle all the backoffice functions you've described, it sounds like they chose the right platform for that.

Why would you want to run backoffice on Linux and then re-create all those wheels by hand in-house? Relying on the expertise of other companies for basic backoffice systems is actually recommended practice until you become big enough to actually need custom software (generally, north ten thousand employees).

Re: Former Tesla Firmware Engineer Discusses the System

#116

Post by mwfunk »

tcoff91 wrote: post #62
8_hours_ago wrote: post #52

Earlier 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).

Yeah I don't even do embedded work or anything real-time and even I know that in applications like this you should probably be using something like Green Hills Integrity RTOS.

I'm amazed that anyone would think that. I've worked on all sorts of embedded systems and worked with a many more people who've worked on far more than I, and RT Linux was very common and suitable for these sorts of things 10-15 years ago, never mind now.

Re: Former Tesla Firmware Engineer Discusses the System

#117

Post by crististm »

bipson wrote: post #94
8_hours_ago wrote: post #52

Earlier 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).

Any substantiated argument why using Linux "is a huge accident waiting to happen"? Did you know that Linux can handle hard RT, if you use the right hardware (and maybe the right kernel/patches).?

I'm speculating that he does know. But with all the filters you added (right hardware, right patches etc.) you would be better off to add the right patch -Linux/+

Besides, if you follow Linux kernel development, you see that the effort is virtually never for real-time but for general purpose.

Re: Former Tesla Firmware Engineer Discusses the System

#118

Post by f4rtcl0ps »

dewey wrote: post #63
dswalter wrote: post #16

Earlier quoted context omitted.

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.

There's still the problem with exploding phones and batteries so even if it's just a phone it can go wrong in dangerous ways. (If it happens on a plane for example)

or if the phone weighs thousands of kilograms and is traveling at highway speeds

Re: Former Tesla Firmware Engineer Discusses the System

#119

Post by [deleted] »

nightski wrote: post #108
mandeepj wrote: post #29

Earlier quoted context omitted.

> This application was responsible for practically everything that ran the factory: inventory, supply chain management, cost analysis, etc. They could have bought something off the shelf. Not sure what was the value in building everything from scratch

What like SAP? And then spend 10s of millions in customizing it for their needs and dealing with an arcane, unintuitive interface? I've seen this over and over again.

[deleted]

Re: Former Tesla Firmware Engineer Discusses the System

#120

Post by arcticfox »

mlaretallack wrote: post #99
BugsJustFindMe wrote: post #74

Earlier quoted context omitted.

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.

Agree completely. Hard real time is possible with Linux, we use it for sub millisecond control of Traffic Lights. The only issue we ever hit is proving that the code running is the stuff we expected to run.

> Agree completely. Hard real time is possible with Linux, we use it for sub millisecond control of Traffic Lights.

Out of curiosity, why do traffic light controls need to be that precise?

Post reply on HN