Former Tesla Firmware Engineer Discusses the System • Hacker News Board

Re: Former Tesla Firmware Engineer Discusses the System

#431

Post by Cyph0n » Sat, Aug 25, 2018, 1:27 AM UTC

noselasd wrote: post #379

Cyph0n wrote: post #342

Earlier quoted context omitted.

The real question is: why do you need an entire OS kernel to control traffic lights?

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

Yeah, I still think that's overkill, simply because the bulk of the computation is done on a remote server anyways. All you really need on the frontend is a TCP/IP stack to send telemetry and receive commands.

If the connection is lost, the exchange can just fallback to "naive" mode.

Re: Former Tesla Firmware Engineer Discusses the System

#432

Post by camtarn » Sat, Aug 25, 2018, 1:32 AM UTC

nickserv wrote: post #217

joering2 wrote: post #140

Earlier quoted context omitted.

Ubuntu and Centos come pretty naked; what would you strip and why? Im asking because I run few instances with very heavy traffic and have no issues whatsoever. Just added nano and fail2ban and it runs with no issues for about 2 years now.

Any kernel module that's not required (wifi, graphics, sound, USB, etc depending on application), any security system like selinux, any unnecessary libraries, helper utilities, etc etc. Basically you rip out anything not strictly required for the task at hand. Running on embedded hardware is quite different from running on server hardware, disk space and memory are measured in megabytes, not gigabytes...

Not necessarily. I'm working with B&R's range of industrial controllers at the moment, which are Atom processors with a few hundred Mb of RAM and CF cards up to 32Gb, but still running a traditional RTOS with hard timing guarantees. They have built-in web servers and (basic) web browsers...!

Re: Former Tesla Firmware Engineer Discusses the System

#433

Post by scrollaway » Sat, Aug 25, 2018, 1:34 AM UTC

mrep wrote: post #422

scrollaway wrote: post #341

Earlier quoted context omitted.

Looking at what's been done isn't a good way of determining whether your process is efficient at doing said thing. You need to be able to compare it to something else. To put it another way: If your method of writing novels is to hire an infinite amount of monkeys and put them to work on typewriters, you can't say "Something about this model must be working right, I came out of it with the complete works of Shakespea…

True, but they also did that while maintaining the lowest launch prices in the industry and presumably they can now decrease that even further if they need to. So while it may not be the most efficient process, the overall process is much better than their competitors since they can launch for so much less money.

At the end of the day that still doesn't really answer the question: "Do companies save money by mistreating employees?"

I don't think you can answer that question by just looking at Tesla.

Re: Former Tesla Firmware Engineer Discusses the System

#434

Post by BugsJustFindMe » Sat, Aug 25, 2018, 1:34 AM UTC

Keyframe wrote: post #419

BugsJustFindMe wrote: post #415

Earlier quoted context omitted.

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

You don't need an RTOS to know that a system without extraneous background processes isn't doing extraneous background processing. Where precisely do you think think your timings are going? You're not also running a Minecraft server on the nav computer. Using Linux doesn't mean you also need to enable stupid PC things like search indexing or seti@home. Navigation isn't resource constrained. The only resource constrained component in the whole system is the computer vision module and it's going to be on its own processors, and the rate at which it can hand off new output is on far faaaarrrr longer timescales than your interprocess communication latency.

Re: Former Tesla Firmware Engineer Discusses the System

#435

Post by coatmatter » Sat, Aug 25, 2018, 1:38 AM UTC

ryandrake wrote: post #125

Content aside, what is the deal with images of screenshots of a forum, then posted to Twitter? Why not include a fax machine in there while you’re at it? Just link to the forum and we can all read the text.

Twitter has a character limit which is bypassed through screenshots. Screenshots also are a sort of backup in case the original content is deleted for whatever reason. Not a good backup, but a backup nonetheless.

It's also faster and easier to take screenshots than it is to preserve formatting of HTML/CSS and it suits Twitter.

Related topic: Azealia Banks's recent screenshots of messages relating to Elon Musk, his companies, and other things.

The OP user did end up posting a link to the thread, but I never bothered clicking it. The first screenshot grabbed my attention sufficiently that I just continued looking at the next. They almost act in a similar manner to Wikipedia link previews. Twitter for better or worse is where things still go "viral". I had a love-hate relationship with it but no longer spend a lot of time there these days. There is some method to the madness...

Re: Former Tesla Firmware Engineer Discusses the System

#436

Post by ams6110 » Sat, Aug 25, 2018, 1:41 AM UTC

coldtea wrote: post #146

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.

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

Bear in mind that the software only controls the cycle. The lights are electrically wired so that it is impossible for example to have "GREEN" illuminated in crossing directions. Or so I've read -- I don't work in traffic control software or hardware.

Re: Former Tesla Firmware Engineer Discusses the System

#437

Post by h4b4n3r0 » Sat, Aug 25, 2018, 1:43 AM UTC

mikeash wrote: post #418

h4b4n3r0 wrote: post #363

Earlier quoted context omitted.

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.

MCU in the case of braking and steering is “micro controller unit”.

Re: Former Tesla Firmware Engineer Discusses the System

#438

Post by mikeash » Sat, Aug 25, 2018, 1:47 AM UTC

h4b4n3r0 wrote: post #437

mikeash wrote: post #418

Earlier quoted context omitted.

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.

MCU in the case of braking and steering is “micro controller unit”.

Yeah, those definitely aren’t running Linux, and the guy here wasn’t working on them.

Re: Former Tesla Firmware Engineer Discusses the System

#439

Post by camtarn » Sat, Aug 25, 2018, 1:54 AM UTC

grumblestumble wrote: post #404

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

I actually experienced this with a rental car in South Africa. I drove for 10+ seconds with the engine revving at full blast with the car in neutral and no mat impacting the pedal. Both feet completely removed from any pedal, using the handbrake to decelerate and pull onto the verge. The floor mat thing is total deflection by Toyota. The only thing that reset the accelerator was turning the ignition off.

In the case, this could possibly have been limp-home mode. I believe this engages if the ECU thinks the throttle pedal is faulty. It disables the throttle and applies a constant throttle setting to allow you to continue driving slowly - it sounds alarming in neutral, but once you put the car in gear, the revs drop as the engine is required to produce torque.

Happened to my 2001 Clio several years back, although in my case it was when I started the car, not during driving. My hypothesis was that it triggered due to my bad habit of turning the car off in traffic queues then restarting it with the pedal held down.

Re: Former Tesla Firmware Engineer Discusses the System

#440

Post by Robotbeat » Sat, Aug 25, 2018, 1:59 AM UTC

scrollaway wrote: post #433

mrep wrote: post #422

Earlier quoted context omitted.

True, but they also did that while maintaining the lowest launch prices in the industry and presumably they can now decrease that even further if they need to. So while it may not be the most efficient process, the overall process is much better than their competitors since they can launch for so much less money.

At the end of the day that still doesn't really answer the question: "Do companies save money by mistreating employees?" I don't think you can answer that question by just looking at Tesla.

I'm not sure that's quite a fair way of wording that (legitimate) question.

The whole company seems to be operating in the "burning the candle at both ends," not just the workers at the bottom. Also, it's not just "saving money" but pushing super hard to accomplish something extraordinary, i.e. generating new revenue, not just reducing costs. Additionally, the workers are partially compensated via stock options, so they share in the success of the company even if not through higher wages alone. So I'm not sure "mistreatment" is the right word to use.

At the end of the day, SpaceX (and Tesla) are not for everyone forever. I am not in a station in life to want to join right now, but may in the future. And maybe this strenuous effort is not especially profitable for SpaceX because of the churn that it creates. But that churn IS helpful for the industry (and thus, in my opinion, society) at large because it has spread SpaceX's know-how throughout the US aerospace community and resulted in alumni founding probably dozens of companies that can leverage the lessons learned from SpaceX. But some people work well in that environment and stay long term (which isn't to say it can't be improved).

So I am glad SpaceX is the way it is, and I hope they're successful in the future. But it also doesn't have to be the model for everyone else to copy. It might not work for everyone else, nor should it be expected to.