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

481–490 of 589 posts

Re: Former Tesla Firmware Engineer Discusses the System

#481

Post by Corrado »

prolikewh0a wrote: post #405
misiti3780 wrote: post #168

Earlier quoted context omitted.

what about the iphone demo was hacky ?- just curious

https://gizmodo.com/the-iphones-first-demo-was-buggy-as-hell... >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 o…

That's actually pretty interesting to me. I specifically remember seeing those multiple iPhones in the demo and wondering what they were for. Jobs kept putting one down and picking up another one to do a different part of the demo. It never occurred to me that the iPhone wasn't fully cooked and couldn't handle the demo without problems.

Steve was a full on sales person and was really, really good at presentations.

Re: Former Tesla Firmware Engineer Discusses the System

#482

Post by Dreami »

TheKarateKid wrote: post #467
Cyph0n wrote: post #429

Earlier quoted context omitted.

It's not a pressure sensor, but an induction loop. Basically, there is a coil placed on the road that has a small AC current passed through it. When a car (metal) sits on top of the coil, the two "coils" couple, changing the overall inductance. A simple sensor can detect this change.

The current is even able to pass through the tires?

As far as I understand, it's just electromagnetic waves. No current passing through to the car, but the coil can "register" a change in its magnetic field and can determine that it's a car and how fast it goes

Re: Former Tesla Firmware Engineer Discusses the System

#483

Post by adrianN »

jgalt212 wrote: post #406
agorabinary wrote: post #369

Earlier quoted context omitted.

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

read this book too. The insistence on Windows blew my mind, given his "reputation" as an engineer.

There are many engineers who actually like Windows. Especially if they're not software engineers. A lot of industrial equipment runs some embedded Windows.

Re: Former Tesla Firmware Engineer Discusses the System

#484

Post by Fnoord »

Cyph0n wrote: post #342
coldtea wrote: post #146

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 real question is: why do you need an entire OS kernel to control traffic lights?

An OS has a kernel. TRON [1] equally fits your description. Which is IIRC what traditionally runs on traffic lights.

[1] https://en.wikipedia.org/wiki/TRON_project

Re: Former Tesla Firmware Engineer Discusses the System

#485

Post by espadrine »

8_hours_ago wrote: post #52
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…

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

An RTOS has nice guarantees, and I definitely see the appeal, but on the other hand:

- SpaceX machines receive more irradiation that computers on the ground, so computation errors already make the behaviour of the software chaotic,

- The wealth of complex, widespread libraries helps a lot.

Re: Former Tesla Firmware Engineer Discusses the System

#486

Post by kalleboo »

coatmatter wrote: post #425
monocasa wrote: post #332

Earlier quoted context omitted.

It's not a shift. It's the language used by the rest of the industry including manufacturers, not just private owners.

What's being scrutinised here is the difference of being forced to be a part of a fleet as opposed to separately owning and controlling your own fleet. If you buy a Tesla, you will not be able to control access to it without limiting its normal set of features. If you buy a normal bicycle, you always have full direct control of it. No software updates, no data uploading, no tracking. Normally fleet is reserved to mea…

Do you prefer the alternative where after you bought the car, Tesla tells you to screw off if there's something wrong? "it's your car now, no more bug fixes"

As long as they still have responsibilities, they also have partial ownership.

Re: Former Tesla Firmware Engineer Discusses the System

#487

Post by kalleboo »

marssaxman wrote: post #325
illumin8 wrote: post #265

Earlier quoted context omitted.

Your post conveniently ignores the fact that over the last 20 years cars and trucks have become physical delivery vehicles for software. In fact, the complexity of the software running in any manufacturer's modern car dwarfs the complexity of the hardware in the car itself. So, if you have a car manufactured any time in the last 25 years, you're running software that hasn't likely been patched in years, has a ton of…

This is why I do not have a car that was manufactured any time in the last 25 years. You can't trust software, and you definitely can't trust software developers.

So you're trading off the theoretical unsafeness of software (how many car accidents have been caused by faulty software?) against the huge improvements in crash safety (engineered crumple zones, AEB, etc) in the past 25 years

Re: Former Tesla Firmware Engineer Discusses the System

#488

Post by Too »

rrcaptain wrote: post #392
vvanders wrote: post #204

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.

Seriously yes, at least ventilation. Anybody who don't believe this, try turn off your AC completely and see how quickly your wind screen is fogged up to the point you can't see out. (depending on which climate you live in)

Re: Former Tesla Firmware Engineer Discusses the System

#489

Post by gmueckl »

BugsJustFindMe wrote: post #322
gascan wrote: post #256

Earlier quoted context omitted.

Is that like, you really don't need a fancy RTOS for this stuff 99.999% of the time, although sometimes you do? Or truly, despite the life safety element, there is never any need for RTOS.

In every application I can think of off the top of my head, but mostly in the ones that apply to Tesla, you truly don't, except when the law or a contract says otherwise. I'm sure there are exceptions for things that don't apply to Tesla (or for that matter SpaceX). Here's what's inside of every autonomous vehicle ever made: a message-passing subsystem, sensors, fusers, navigation, dynamic control, actuator device dr…

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) results. A "fuser" as you call it (never heard that term before) needs to make sure that it does never act on stale sensor information (sensor malfunction, accumulated communication issues). Transmission errors need to be detected. Random bitflips in values that are stored in volatile memory for long time spans need to be checked and acted upon.

Every independent controller in such a system requires some kind of watchdog that needs to be reset periodically. Too many watchdog resets in a row indicate a failure and the affected system must shut down in a defined way. You need ways to deal with any combinations of controllers going belly up and avoid taking unsafe actions. For many systems transitioning into a totally inert safe mode is sufficient, but not always.

All of the hardware must constantly run self tests. That includes periodic CPU and memory tests (both volatile and non-volatile memory) and also all periphery that us involved. If, for example, a DAC is used to send a signal, the resulting signal must be read back by different hardware to check that the generated voltage is indeed correct.

Manually threading together all these different kinds of cycles and asynchronous events without a RTOS scheduler is hard and becomes error prone. The result is likely less resilient than a preemptively multithreaded firmware.

Post reply on HN