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

411–420 of 589 posts

Re: Former Tesla Firmware Engineer Discusses the System

#411

Post by BugsJustFindMe »

agitator wrote: post #409
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.

As someone who worked on RTOS systems and now works on autonomy. 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…

You're making a lot of unwarranted negative assumptions and setting up a lot of strawmen here.

Re: Former Tesla Firmware Engineer Discusses the System

#412

Post by amanaplanacanal »

atomicthumbs wrote: post #370
mlaretallack wrote: post #99

Earlier quoted context omitted.

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.

So what sort of interlocks do you have on top of that to prevent simultaneous greens?

Traffic signals have hardware interlocks so that can never happen. I don't know if they are using mechanical relays or what, but you can't turn both sides green in software.

Re: Former Tesla Firmware Engineer Discusses the System

#413

Post by BinaryIdiot »

fidz wrote: post #400
noselasd wrote: post #379

Earlier quoted context omitted.

To communicate with all the other traffic lights and sensors at the other intersections on the road to optimize traffic flow.

Such thing does exist? I thought traffict light only time-based on no sensor involved.

Depends on the area but yeah many intersections use sensors (cameras, sometimes under the road pressure sensors, etc) to make anywhere from subtle to extreme changes based on traffic patterns. The under the road pressure sensor has been around for decades.

When I was a kid there was one light that, when you drove over the pressure sensor, it wouldn't really do much. But if you backed up and drove over it again it must have registered an additional car coming through and the light would almost immediately go through its light cycle to change. It was really interesting to see!

Nowadays I think it's mostly cameras? We have a light near my home and the left signal will literally never trigger unless someone is in one of the left lanes.

Re: Former Tesla Firmware Engineer Discusses the System

#414

Post by h4b4n3r0 »

rrcaptain wrote: post #393
h4b4n3r0 wrote: post #363

Earlier quoted context omitted.

Nah. No way the mcu responsible for braking would run an OS

Didn't they already do an Over-the-Air update to fix the braking time in response to a bad review?

You don’t need an OS for that.

Re: Former Tesla Firmware Engineer Discusses the System

#415

Post by BugsJustFindMe »

Keyframe wrote: post #184
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.

you really don't need a fancy RTOS for this stuff maybe you don't, but genuinely curious how do you validate/guarantee scenarios then?

I suppose my best questions back to you might be:

1) What concrete guarantees do you think you get from a special RTOS?

2) Which of those guarantees are meaningful to the scenario?

3) How (by what mechanisms) do you think the special RTOS guarantees the things that it guarantees?

4) Which of those behaviors are something that only an RTOS can provide?

Re: Former Tesla Firmware Engineer Discusses the System

#416

Post by coatmatter »

pwinnski wrote: post #284
Twirrim wrote: post #58

Earlier quoted context omitted.

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…

People quote this repeatedly here, but I'm not sure what it's intended to demonstrate. Most code is buggy, and the more closely you look, the buggier it is. Most of that same code operates without noticeable error. That code analysis turns up "inadequate protections against stack overflow and buffer overflow" does not actually suggest that there was any stack overflow or buffer overflow, and people quote this as if i…

> Meanwhile, it is all-but-certain that the overall findings were correct: people hit the wrong pedal regularly, and if enough press attention is given, all of those wrong-pedal-pushers find each other and try to blame the manufacturer instead.

At risk of beating a dead horse, I do find it interesting how despite the myriad of "driver hit the wrong pedal" news stories out there, only the Prius one starts from the "it had a mind of its own" angle.

I think what most people don't realise is that it's so incredibly easy to be fallible with "automatic" familiar everyday activities (i.e., not maths or remembering facts). I recall in driving school approaching a quiet intersection where I once lost proprioception of my foot and had to call the instructor to use her dual brake because I didn't know where my foot was or could no longer reach the brake pedal (I guess I'd have attempted the hand brake if I were alone).

From this single experience along with running other dark hypotheticals through my head, I am so cautious with many things that it bewilders me that activities such as "carpool karaoke" is not an atypical practice.

But otherwise yep, same thing with software only that the stakes are often lower thanks to the sheer number of non-mission critical projects out there. It's only the mission critical bugs that get the most attention and surprise.

Re: Former Tesla Firmware Engineer Discusses the System

#417

Post by Pastrami »

samstave wrote: post #395
ummonk wrote: post #329

Earlier quoted context omitted.

If it were that easy to setup tech-based infrastructure, we would have had positive train control implemented years ago.

You're right. We should all just give up. I mean, heck. If it were that easy to start a unicorn... But seriously - I am not saying its easy , I'm just surprised that we haven't made much (publicly known about/announced) efforts along these lines. I mean, we have TCP down pretty good - if we are simply thinking of cars as packets, a lot of the math should exist to ensure collision-less delivery?

> if we are simply thinking of cars as packets

You better hope you don't get any dropped packets.

Re: Former Tesla Firmware Engineer Discusses the System

#418

Post by mikeash »

h4b4n3r0 wrote: post #363
mikeash wrote: post #296

Earlier quoted context omitted.

Tesla’s MCU runs Linux. Older ones use a 2012-era Nvidia mobile SoC, while newer ones use something from Intel.

Nah. No way the mcu responsible for braking would run an OS

This must be an acronym mixup. We’re talking about the Media Control Unit, i.e. the giant screen in the center of the dashboard responsible for zero safety-critical systems.

Re: Former Tesla Firmware Engineer Discusses the System

#419

Post by Keyframe »

BugsJustFindMe wrote: post #415
Keyframe wrote: post #184

Earlier quoted context omitted.

you really don't need a fancy RTOS for this stuff maybe you don't, but genuinely curious how do you validate/guarantee scenarios then?

I suppose my best questions back to you might be: 1) What concrete guarantees do you think you get from a special RTOS? 2) Which of those guarantees are meaningful to the scenario? 3) How (by what mechanisms) do you think the special RTOS guarantees the things that it guarantees? 4) Which of those behaviors are something that only an RTOS can provide?

Among other things, determinism, since timing can be guaranteed (within a margin). RTOS will run with consistent timing, which is guaranteed and facilitated by control over tasks priority and checks whether timings are met. You could probably do that without a hard RTOS, but without any sort of formal guarantee. So, it might work all fine and dandy, until it doesn't. Doesn't should not exist in a hard RTOS by definition and proofing of it.

Re: Former Tesla Firmware Engineer Discusses the System

#420

Post by [deleted] »

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

[deleted]
Post reply on HN