Live data from Hacker News

Former Tesla Firmware Engineer Discusses the System

twitter.com

461–470 of 589 posts

Re: Former Tesla Firmware Engineer Discusses the System

#461
post #128

Earlier quoted context omitted.

What's wrong with ASP.NET? It might not be the most sexy framework out there, but it's great for this sort of thing - there's a huge business application ecosystem surrounding it.

While that may be true, a huge monolithic system that does everything is seldom great.

Monolithic does not always mean unmaintainable, though.

Re: Former Tesla Firmware Engineer Discusses the System

#462
post #431

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.

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.

Consider the overhead of maintaining two entirely separate software stacks, with different libraries and controllers then? And the ongoing costs of discovering your "minimal" hardware can't accomodate a future improvement, compared to just using general compute at a marginal upfront cost, and then having everything else be familiar?

Re: Former Tesla Firmware Engineer Discusses the System

#463

Earlier quoted context omitted.

They periodically have times when the forum or at least some subforums are viewable by registration only.

yeah i didn't bother finding out whether the paywall was operational or not, and nobody's gonna read a forum thread in 2018

welcome mr funy computer man

Re: Former Tesla Firmware Engineer Discusses the System

#464
post #431

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.

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.

I guess using off-the-shelf mass market hardware combined with a software stack anyone can design, setup, and implement is way easier and cheaper than a customized solution.

Re: Former Tesla Firmware Engineer Discusses the System

#466

Earlier quoted context omitted.

Because it runs counter to the "epic nerd" persona Musk was trying to build with his authorized biography. Windows isn't cool right now.

When was it cool?

When NT4's kernel was released and Linux was on 2.2, there was a good reason to choose Windows for stability - or at least, there were trade-offs that were acceptable up to Windows 2000. After that, it became a battle for libraries. If you're using C# or other dotNet, then you're on Windows (or Mono?!?), otherwise your platform is Linux.

Both are reasonably capable of high service uptimes and solid performance. With Server Core and PowerShell, there's a lot more parity than my fellow Linux admins want to admit, but either is a viable choice for general IT services at this point.

Note - I'm excluding licensing entirely from this, as well as infrastructure maintenance and control surfaces. Nobody likes DSC, and there are several superior config management solutions for Linux that don't have meaningful analogs on Windows.

Re: Former Tesla Firmware Engineer Discusses the System

#467
post #429

Earlier quoted context omitted.

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

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?

Re: Former Tesla Firmware Engineer Discusses the System

#468

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…

Thankfully, the critical reactive components of the Tesla vehicles do seem to be run by an RTOS -- spesifically FreeRTOS [0].

[0]: https://youtu.be/KX_0c9R4Fng?t=8m47s

Re: Former Tesla Firmware Engineer Discusses the System

#469
post #134

Earlier quoted context omitted.

RT Preempt / Preempt-RT patch still exists. It slowly is being integrated into mainline as per everyone's wishes but it is still a thing.

The original RTLinux it also still usable and it provides it's own hard RT scheduler.

I've worked with RTLinux in automotive. It is only used in R&D and testing. It's much worse than INTime (windows rtos) or L4, which are usually used. I've even patched g++ to work on RTLinux eliminating all the dynamic, unreliable stuff.

People are using Linux when they need HW and driver support, e.g. gigabit Ethernet, firewire and such. RTOS vendors charging shitload of money on those drivers. I trust the Linux drivers more than the RTLinux scheduler or libc. But well, recently networking went to hell, so even there they start fucking up.

Re: Former Tesla Firmware Engineer Discusses the System

#470
post #232

Earlier quoted context omitted.

Burning out people at large rate is not effective and persistent crunch is contraproductie. It is less of capitalism and more of wishfull thinking combined with wish to be seen as tough manager.

I'd say it's the pace in which modern capitalism operates at, particularly in tech. When the rate of production goes higher and higher due to automation and a global outsource-able workforce, the shareholders chase after higher and higher profits.

Tesla can't outsource globaly and does not have profits yet. Effectivity is about whether burnout brings higher profits, not whether people unable to gain them burnout themselves or those under them due to wishful thinking.
Post reply on HN