Elon: "Feature complete for full self driving this year"

[linux-works]

I really doubt any software team in the world writes all the software, and THEN write the unit-tests. That would make no sense, because you need to know the code you're testing, to write good and valuable tests, which means the only reasonable time to write the tests is the same time and the same person who wrote the unit.

you don't want to know how many bay area companies have employees that skip the unit test phase, or just fake it. not kidding; schedules are brutal and we as engineers are usually not given enough time for a proper job. that's one of the faults of software life in the bay area, sad to say. nothing tesla-specific, here.

System-level testing however mostly cannot be automatic

actually, most of it can. automation can happen at Hardware-In-the-Loop (HIL), software in the loop, model in the loop, etc. when you are at system level, there are often very expensive vector brand chassis that setup test cases, inject triggers and look for the expected results. it can take hours and hours and its a key investment for the company. there are requirements vendors (jama), there are vendors who sell testing 'systems' (dspace) - and there's a LOT of money in this whole 'test the car before you ship it' ecosystem. (in fact, I'm rather annoyed by how much these companies charge for stuff like this; they used to be able to get away with it, but not sure they can continue to ask such high prices, as more vendors choose to write their own instead of buying).

development and hw/sw test for automotive is like 'making laws and sausages'; most people should probably NOT see the actual real world process that goes on.

 

[ChrML]

actually, most of it can. automation can happen at Hardware-In-the-Loop (HIL), software in the loop, model in the loop, etc. when you are at system level, there are often very expensive vector brand chassis that setup test cases, inject triggers and look for the expected results. it can take hours and hours and its a key investment for the company. there are requirements vendors (jama), there are vendors who sell testing 'systems' (dspace) - and there's a LOT of money in this whole 'test the car before you ship it' ecosystem. (in fact, I'm rather annoyed by how much these companies charge for stuff like this; they used to be able to get away with it, but not sure they can continue to ask such high prices, as more vendors choose to write their own instead of buying).

I think that is a very good idea, and required for self-driving. This is probably the driving simulator they have been talking about.

Obviously a huge task, but if every time an accident happens, and you can add a system-level test for that particular scenario, then it could ensure that no accident with that particular setup occurs again. And hence gradually increase the safety of FSD.

 

[golfcart]

I wonder how that would go down. I sold my HW2.0 MCU1 car and I got the class action punishment checks and not the current owner after the fact. If they refund some significant amount of $$$$ for the FSD purchase price for cars ordered with FSD I wonder if the current owner or the original purchaser would get the $$$$.

I better get it. I bought a car with FSD and they sold me a car with FSD at a higher price than they would have sold it without FSD.

 

[ChrML]

you don't want to know how many bay area companies have employees that skip the unit test phase, or just fake it. not kidding; schedules are brutal and we as engineers are usually not given enough time for a proper job. that's one of the faults of software life in the bay area, sad to say. nothing tesla-specific, here.

Guess I'm kinda spoiled there. We always prioritize good tests. Eg if you haven't tested it, you haven't coded it.

Skipping the unit-tests is kinda like peeing in pants to stay warm. It goes faster for a while, and then it will start slow you down a lot once the complexity increases. At the end, the software will become unmaintainable.

Fortunately we have a good organization with the engineers in the lead. Obviously the management wants progress, but not at the cost of long term viability. We make sure to push the engineers to work faster, but also encourage them to paint a realistic picture of the actual situation. It's ok to not be finished, but it's not ok to lie about the progress.

 

[diplomat33]

I think that is a very good idea, and required for self-driving. This is probably the driving simulator they have been talking about.

Obviously a huge task, but if every time an accident happens, and you can add a system-level test for that particular scenario, then it could ensure that no accident with that particular setup occurs again. And hence gradually increase the safety of FSD.

Cruise does this to improve their autonomous driving. Here is what Vogt wrote in a recent blog about how Cruise analyzes disengagements after the fact to improve their software:

"In more complex or interactive scenes, we run simulations to examine what would have happened in another universe where the AV was operating in driverless mode instead. We use one of our simulation engines to forensically reconstruct the scene in as much detail as necessary to model the critical elements of the scene. We then fork reality at the time of disengagement and apply an AI model to other agents in the scene (cars, humans, bikes, etc.) to examine possible potential future outcomes in a highly interactive way that closely resembles what we’ve seen other people do on the road in the past.

We also use these same techniques to confirm that changes to our software have a positive impact on scenarios where we deemed the AV to be in error in the past. The net result is that every software release is at least slightly better than the previous one."
The Disengagement Myth

 

[ChrML]

Cruise does this to improve their autonomous driving. Here is what Vogt wrote in a recent blog about how Cruise analyzes disengagements after the fact to improve their software:

"In more complex or interactive scenes, we run simulations to examine what would have happened in another universe where the AV was operating in driverless mode instead. We use one of our simulation engines to forensically reconstruct the scene in as much detail as necessary to model the critical elements of the scene. We then fork reality at the time of disengagement and apply an AI model to other agents in the scene (cars, humans, bikes, etc.) to examine possible potential future outcomes in a highly interactive way that closely resembles what we’ve seen other people do on the road in the past.

We also use these same techniques to confirm that changes to our software have a positive impact on scenarios where we deemed the AV to be in error in the past. The net result is that every software release is at least slightly better than the previous one."
The Disengagement Myth

Great! Automatic regression testing for full self-driving. That's the reason self-driving will be flawless and ultra-safe at some point in the future. Human driving can only be partially safe as long as humans are involved.

 

[Az_Rael]

but I would be pretty happy with a trip from home to work with 1-2 interventions while they work on refining the features.

For me it would depend on the interventions. If the 1 or 2 interventions in a commute involves slamming on the brakes to not run a stop sign or red light, that will be quite an invigorating commute. Guess it might help me reduce my caffeine habits.

 

[diplomat33]

Here is a clip from Third Row Tesla's podcast interview with Elon Musk. Elon explains a bit more about what he alluded to in the earnings call about video labeling and gives some new info:

Significant rewrite in AP system almost complete: instead of having planning, perception, image recognition being separate, they are being combined together. "NN is absorbing more and more of the problem." Video labeling will mean that the NN will label paths in 3D that the car should take.

Third Row Podcast on Twitter

So it appears that Tesla is working on making the AP3 NN eventually do all of the driving.

 

[powertoold]

Elon "orders of magnitude" Musk

City NoA likely 6+ months away from that statement.

 

[diplomat33]

Elon "orders of magnitude" Musk

City NoA likely 6+ months away from that statement.

Yes, I expect "City NOA" will miss Elon's "a few months away" deadline. It is good though that they are working on perception and planning and path labeling. These are indeed important basics in autonomous driving. But it will probably take longer than Elon thinks.

 

[ramonneke]

I would be pretty happy with a trip from home to work with 1-2 interventions while they work on refining the features.

I would be happy with only 50 off highway interventions.........

 

[Az_Rael]

Interesting video with Elon talking about a rewrite of the AP code. Not sure if this is another rewrite after the one they had previously talked about last year (if I recall)

Third Row Podcast on Twitter

 

[diplomat33]

Interesting video with Elon talking about a rewrite of the AP code. Not sure if this is another rewrite after the one they had previously talked about last year (if I recall)

Third Row Podcast on Twitter

View attachment 506030

You are late. I just posted it 20 minutes ago.

Yes, it is a new rewrite.

 

[boonedocks]

I'd expect original owner as that's who paid Tesla for the feature- which is what you already saw with the previous situation.

It'd only be AP2.0 FSD money though (so likely 3k for most people, and not THAT many people given it's only AP2.0 S/X buyers who also bought FSD)

Which I did hmmmm lol lol

 

[Silicon Desert]

Hmmmm, it seems like the last several hundred posts are people arguing about if or when FSD will ever happen. Time to rename the thread..... FSD Speculation

 

[Silicon Desert]

So it appears that Tesla is working on making the AP3 NN eventually do all of the driving.

Yes, but I just hope Elon doesn't say it will be "3 months maybe, 6 months definitely", else we will know it might take years

 

[linux-works]

Guess I'm kinda spoiled there. We always prioritize good tests. Eg if you haven't tested it, you haven't coded it.

Skipping the unit-tests is kinda like peeing in pants to stay warm. It goes faster for a while, and then it will start slow you down a lot once the complexity increases. At the end, the software will become unmaintainable.

Fortunately we have a good organization with the engineers in the lead. Obviously the management wants progress, but not at the cost of long term viability. We make sure to push the engineers to work faster, but also encourage them to paint a realistic picture of the actual situation. It's ok to not be finished, but it's not ok to lie about the progress.

[rant]

I could write pages about how bad silicon valley has become, in terms of lower software quality. we are pushed to ship before its ready, we are told to make compromises that we don't agree with, budgets and timelines are not realistic, employees often stay 2 years or less (so there's tribal knowledge lost) and we have a real problem with hiring primarly younger folks who are 'affordable' to companies but lack experience and think everything to be approached like a school assignment.

we all know what we should be doing; but usually time and money force us to not do the right thing. I'm aware that other areas of the world are a bit more sensible, but the bay area has jumped the shark and its nothing like it used to be, decades ago.

[/rant]

 

[Silicon Desert]

[rant]
I could write pages about how bad silicon valley has become, in terms of lower software quality. we are pushed to ship before its ready, we are told to make compromises that we don't agree with, budgets and timelines are not realistic, employees often stay 2 years or less (so there's tribal knowledge lost) and we have a real problem with hiring primarly younger folks who are 'affordable' to companies but lack experience and think everything to be approached like a school assignment.

we all know what we should be doing; but usually time and money force us to not do the right thing. I'm aware that other areas of the world are a bit more sensible, but the bay area has jumped the shark and its nothing like it used to be, decades ago.
[/rant]

That's a bummer to hear. Are you sure you aren't in China ?

 

[linux-works]

lots of work is shifted to india and china, in fact.

testing is the most common thing that is sent overseas.

if you think finding people who know linux (which is becoming a Big Thing(tm) in cars) in the US is hard, try doing that in india or china. they care more about windows, in general, for some reason ;(

 

[ChrML]

lots of work is shifted to india and china, in fact.

testing is the most common thing that is sent overseas.

if you think finding people who know linux (which is becoming a Big Thing(tm) in cars) in the US is hard, try doing that in india or china. they care more about windows, in general, for some reason ;(

Fortunately today the toolchains now are so good, and most software we deal today with is cross platform. So people can develop on Windows, Linux or Mac by their own choice. As long as you know the few basic Linux commands, you're fine. Unlike before just 5-10 years ago when porting an application cross-platform was a real pain.

Had a .NET webserver application today that had never been tested on anything other than a Windows 10 laptop. Literally spent 10 minutes adding a few simple scripts to the Git repo and it built and passed the unit-tests on the first attempt at the Linux buildserver. Pushed a Docker image and generated a Helm chart. Had the applications never created with Linux in mind running on the Linux cluster in the cloud after just 15 minutes with no porting.

It's a shame if developers don't last long in other parts of the world ... I believe in long term success and sustainability, and I'm happy we have that culture. Distributed responsibility and happy very competent developers, it's our edge on the market. No top down management.