Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Investor Engineering Discussions

This site may earn commission on affiliate links.
I've been considering the Robotaxi platform. In part because some videos have been circulating that discussed the topic.

The Wuling Air EV is one data point, if Tesla made a car of similar size with similar specs it would be cheap:-

Of the videos that I have seen Sandy Munro makes so points that I agree with:-
  • Rear facing seats are currently illegal, but it is worth trying to change this.
  • A dedicated 'city car' design makes some sense.
  • A 'city car' could have a top speed limited to 45 Mph and should not be able to travel on highways.
  • Stainless steel is heavy and expensive.
  • Drag isn't a major consideration at low speeds -Sandy prefers a "Box like" shape
"Box like" is a fairly good description of the Wuling.

Where I disagree with Sandy is I think that the right body construction technique can allow the body to be larger while still being light weight and to have a bit more of an aerodynamic design.

The right design is some mix of the Wuling, Model 3, Cybertruck and a van- I lean toward being more "van like".

In common with the Wuling is a narrower vehicle with a smaller fontal area, there are some small vans with a similar width.

In addition to conventional seating I would like rear facing bench seat at they very front of the car for the Robotaxi variant, For that variant I'm happy to trade agree to a 45 mile speed limit and no highway driving. The regular version of the car would replace the bench seat with a dashboard.

The other area of the Robotaxi worth considering is the side doors, which need to be electronically opened when the vehicle is stopped.
There are 4 door options:-
  1. Regular doors (how to open and close).
  2. Doors similar to bus doors.
  3. Doors similar to sliding van side doors.
  4. Doors which are like the Cybertruck automatic bed cover.
Doors could be different depending on how the vehicle is used.

For the vehicle body, I take inspiration from aluminium speed boats, unpainted aluminium is similar to unpainted stainless steel.
Rivets/welds might be visible, but a wrap can cover them up.

Also the fact that some cars are made unpainted, does not mean all need to be unpainted, Paint is obviously an option the buyer can select, but Robotaxis don't need to be painted. The factory would need a paint shop, but not on day 1, and not for the total vehicle capacity.

The reason for aluminium instead of stainless steel is weight and cost. Glass would also be minimised with an aluminium roof.

Body structure comes from cast aluminium sections bolted together with steel reinforcement added where necessary, but only if it is strictly necessary.

Minimising the use of steel and glass helps make the body light and cheap,.

A smaller battery is also used with LMFP being a good candidate chemistry.

Aspects like windows, seats and trim are adapted to the budget, with budget being the priority.

Compared to the Wuling, I expect a bigger and safer car with better aesthetics and tech.
 
Last edited:
  • Like
Reactions: Maarten
Metal foam -- anybody know about it? I have an idea that Tesla and maybe SpaceX and Boring will use this material and I'm wondering if this is this crazy or not? I don't know much about metallurgy and die casting.



It has really great material properties and I'm wondering if Tesla would ever try to introduce foaming into the gigacastings at some point. If Tesla could pull this off and make castings that are like bones where the outer surface is hard but the inside is porous and lightweight by not having unnecessary mass. It seems like the ultimate first-principles metal structure design for the car, but also very hard to pull off. I guess it might be doable by manipulating the cooling rate of the mold to the metal while also having a foaming agent.

Benefits for body-in-white:
  • High strength to weight ratio (due to cube-square law)
  • Excellent noise, vibration and harshness damping
  • Less raw material required for chassis
  • Absorbing impact energy in a crash

Aluminum foam is used for some aerospace applications and I would not be surprised if SpaceX has used it for some parts. We know Tesla and SpaceX share a material engineering and metallurgy team and that Tesla has used SpaceX tech like friction stir welding and the Cybertruck stainless steel alloy.

There are different kinds of foams but here's one example of an aluminum foam sandwich which is close to what I have in mind:

1668558146066.png
 
Last edited:
At Boeing the Safety Dojo invented 3D-printed foam handle attachments (not metal though) for hand tools like rivet guns that majorly absorbed impact shocks. I tried it out and it was surprising how well it damped vibration and harshness and I'm pretty sure metal foam would have the same properties.
 
  • Informative
Reactions: wws
I've been considering the Robotaxi platform. In part because some videos have been circulating that discussed the topic.

The Wuling Air EV is one data point, if Tesla made a car of similar size with similar specs it would be cheap:-

Of the videos that I have seen Sandy Munro makes so points that I agree with:-
  • Rear facing seats are currently illegal, but it is worth trying to change this.
  • A dedicated 'city car' design makes some sense.
  • A 'city car' could have a top speed limited to 45 Mph and should not be able to travel on highways.
  • Stainless steel is heavy and expensive.
  • Drag isn't a major consideration at low speeds -Sandy prefers a "Box like" shape
"Box like" is a fairly good description of the Wuling.

Where I disagree with Sandy is I think that the right body construction technique can allow the body to be larger while still being light weight and to have a bit more of an aerodynamic design.

The right design is some mix of the Wuling, Model 3, Cybertruck and a van- I lean toward being more "van like".

In common with the Wuling is a narrower vehicle with a smaller fontal area, there are some small vans with a similar width.

In addition to conventional seating I would like rear facing bench seat at they very front of the car for the Robotaxi variant, For that variant I'm happy to trade agree to a 45 mile speed limit and no highway driving. The regular version of the car would replace the bench seat with a dashboard.

The other area of the Robotaxi worth considering is the side doors, which need to be electronically opened when the vehicle is stopped.
There are 4 door options:-
  1. Regular doors (how to open and close).
  2. Doors similar to bus doors.
  3. Doors similar to sliding van side doors.
  4. Doors which are like the Cybertruck automatic bed cover.
Doors could be different depending on how the vehicle is used.

For the vehicle body, I take inspiration from aluminium speed boats, unpainted aluminium is similar to unpainted stainless steel.
Rivets/welds might be visible, but a wrap can cover them up.

Also the fact that some cars are made unpainted, does not mean all need to be unpainted, Paint is obviously an option the buyer can select, but Robotaxis don't need to be painted. The factory would need a paint shop, but not on day 1, and not for the total vehicle capacity.

The reason for aluminium instead of stainless steel is weight and cost. Glass would also be minimised with an aluminium roof.

Body structure comes from cast aluminium sections bolted together with steel reinforcement added where necessary, but only if it is strictly necessary.

Minimising the use of steel and glass helps make the body light and cheap,.

A smaller battery is also used with LMFP being a good candidate chemistry.

Aspects like windows, seats and trim are adapted to the budget, with budget being the priority.

Compared to the Wuling, I expect a bigger and safer car with better aesthetics and tech.
 
OTA via CANbus, this person got it right.

Also, since CANbus is deterministic, if something doesn't perfectly match, the update will fail (car might be bricked), but will need to be towed back to VW for full diagnostics and most likely an ECU replacement.
I may be misunderstanding your post.
How does the deterministic nature of CAN arbitration negatively impact the failure modes of a bootloader/ reflash protocol?
 
I may be misunderstanding your post.
How does the deterministic nature of CAN arbitration negatively impact the failure modes of a bootloader/ reflash protocol?
We did this at first, but then, used a more efficient way to do it, that nearly ensured we never bricked devices and it was much faster, more like an efficient delta flash like Chromebooks update. And Tesla's ECUs are connected via a high speed Ethernet equivalent now.

Anyway, it went something like this...In order to flash new code onto an ECU, you first read the contents out and put it into a table, you then map the new code you want to replace into the map (remember there is no default memory map or any kind of assistance of where you read the data or how much you can write back) and then you put the CANbus into a write only mode, due to it being deterministic, you tell the ECU that whatever you are writing is correct (you do this as the new code is unknown to the ECU so it doesn't know if it is correct or not. If you write to the bootloader incorrectly, it cannot be undone as most of the code is not laid out in contiguous blocks. An incorrect write will almost always result in a bricked bootloader.

Guess how many bootloaders we bricked flashing radars? Too many!

Edit: As I left some stuff in my edit box for the main thread...sorry!
 
We did this at first, but then, used a more efficient way to do it, that nearly ensured we never bricked devices and it was much faster, more like an efficient delta flash like Chromebooks update. And Tesla's ECUs are connected via a high speed Ethernet equivalent now.

Anyway, it went something like this...In order to flash new code onto an ECU, you first read the contents out and put it into a table, you then map the new code you want to replace into the map (remember there is no default memory map or any kind of assistance of where you read the data or how much you can write back) and then you put the CANbus into a write only mode, due to it being deterministic, you tell the ECU that whatever you are writing is correct (you do this as the new code is unknown to the ECU so it doesn't know if it is correct or not. If you write to the bootloader incorrectly, it cannot be undone as most of the code is not laid out in contiguous blocks. An incorrect write will almost always result in a bricked bootloader.

Guess how many bootloaders we bricked flashing radars? Too many!

Edit: As I left some stuff in my edit box for the main thread...sorry!
Gotcha, I've dealt with Automotive, CAN, and bootloaders in various combinations. Along with experiencing the fall out when (a different suppliers) software didn't do a cross module restore properly.

So the issue is/ was relying on CAN to be error proof and rewrite in place? Seems like there should be a retry route though since the flash was either block erased to start or rewritable.

Partial update: bad, partial update of bootloader: really bad.
 
  • Like
Reactions: Discoducky
Gotcha, I've dealt with Automotive, CAN, and bootloaders in various combinations. Along with experiencing the fall out when (a different suppliers) software didn't do a cross module restore properly.

So the issue is/ was relying on CAN to be error proof and rewrite in place? Seems like there should be a retry route though since the flash was either block erased to start or rewritable.

Partial update: bad, partial update of bootloader: really bad.
CAN is very old and owned by Bosch who have no interest in updating it as they push their supposed new stuff instead like FlexRay (which is also way outdated, slow and clunky).

I believe FlexRay is more flexible and has better error correction and a memory manager type-thing which saves memory from corruption if you have a single typo.
 
  • Like
Reactions: mongo
CAN is very old and owned by Bosch who have no interest in updating it as they push their supposed new stuff instead like FlexRay (which is also way outdated, slow and clunky).

I believe FlexRay is more flexible and has better error correction and a memory manager type-thing which saves memory from corruption if you have a single typo.
Oh gah, that's right, OEMs all required suppliers to use 'approved 3rd party bootloaders and CAN drivers/ stack (with all their bugs)...
Ughggggghhghghgg, the flashbacks...
 
FWIW while I think Hughes is exceedingly knowledgeable on a lot of Tesla HW for a 3rd party person, I'm unaware of him having any special expertise in anything really related to FSDs development.

That said- I agree with him that you're never getting L5 on existing hardware/sensors-- but I don't think that's due to any special insight he has by being Jason Hughes and it's something a lot of folks have been saying for a long time.

Weather alone, with lack of redundancy of the cameras, tells you you're not getting L5, among many other things. I still have both FSDBeta and NoA turn off (well, drop back to "basic" AP anyway) with even moderate rain, let alone anything heavier.
 
  • Like
Reactions: navguy12
Jason Hughes doesn't think Tesla FSD Level 5 will ever work on existing hardware

Notice Jason doesn't mention AI. He seems great at reverse engineering, but seemingly lacks a ton about AI and NN.
That said- I agree with him that you're never getting L5 on existing hardware/sensors-- but I don't think that's due to any special insight he has by being Jason Hughes and it's something a lot of folks have been saying for a long time.
Engineering-wise, it is simply not a matter of compute, memory, pixels or lenses. And if you think it is lacking, please explain from an engineering perspective.

Hardware is not the issue.

First principles: A human could remotely drive a Tesla without issue based on the current sensor suite and telematics provided by the vehicle.

AI is the issue. The AI is still making stupid mistakes.
 
Notice Jason doesn't mention AI. He seems great at reverse engineering, but seemingly lacks a ton about AI and NN.

Engineering-wise, it is simply not a matter of compute, memory, pixels or lenses. And if you think it is lacking, please explain from an engineering perspective.

Hardware is not the issue.

It really is though.

There's no redundant cameras for most of the 360 view, there's blind spots close to the car with current # and placement, and there's no ability to clear most of the cameras in bad weather.

Auto lane change disables itself if there's a spot of dirt on one of the side cameras, or if there's too much sun glare on one of them.

NoA and FSDb shut down in even moderate rain here, let alone heavy rain (can't speak to snow, we rarely get it and don't drive in it when we do- but certainly that's not true of elsewhere).

Jury is still out on issue of b pillars being as far back as they are for obstructed intersections (Chuck Cook has a nice video of this where he has external cams at the b-pillar and front fender locations to show this issue-- I know I've personally had BOTH situations where it just never went because it couldn't see well enough at the creep limit- and cases where it DID go and should not have because the creep limit wasn't quite far enough but it thought it was)


The weather aspect BTW is one place I strongly disagree with removing radar... I get that it's a low res radar, and eliminating it for MOST uses is probably a net benefit.... but in bad weather it was still better than just vision- and better radar is pretty cheap now too.


I get the "humans are fine with vision so car should be too" argument-- I've made it myself.

But the humans eyes are behind glass, they have ways to clear most of that glass if obscured, and they can lean and turn their head as needed to see further around objects or out of direct line of the suns rays.

The 3 front cams arguably have 1 and 2 going for them- not so much the other cams, and the lack of lean/turn makes placement, esp without any redundancy, problematic for the car cams.



Further- I'd say HW is STILL the issue even if it -were- just an AI problem (which it's not as I mention above) because there's not enough HW compute on HW3 to do L5.

That point is arguable- though I feel the preponderance of what evidence we have available supports my view of it-- but I don't think there's ANY evidence to support the view that FOR SURE there's enough and HW is FOR SURE not an issue there either.


Ideally HW4 both sensors and compute fixes all this-- and more ideally is fully retrofittable to current cars (though seems less likely for cameras esp. if there's new number or location).

But we don't KNOW how much is needed for L5.

Neither does Tesla- which is why they've been wrong about it several times now. (HW2 was enough- then 2.5, then 3....now 4?... They even changed the color filters on the cams because the original HW wasn't sufficient-- and there's new cams coming soon too)

nobody knows how much HW is enough until it actually works.
 
Last edited:
It really is though.

There's no redundant cameras for most of the 360 view, there's blind spots close to the car with current # and placement, and there's no ability to clear most of the cameras in bad weather.

Auto lane change disables itself if there's a spot of dirt on one of the side cameras, or if there's too much sun glare on one of them.

NoA and FSDb shut down in even moderate rain here, let alone heavy rain (can't speak to snow, we rarely get it and don't drive in it when we do- but certainly that's not true of elsewhere).

Jury is still out on issue of b pillars being as far back as they are for obstructed intersections (Chuck Cook has a nice video of this where he has external cams at the b-pillar and front fender locations to show this issue-- I know I've personally had BOTH situations where it just never went because it couldn't see well enough at the creep limit- and cases where it DID go and should not have because the creep limit wasn't quite far enough but it thought it was)


The weather aspect BTW is one place I strongly disagree with removing radar... I get that it's a low res radar, and eliminating it for MOST uses is probably a net benefit.... but in bad weather it was still better than just vision- and better radar is pretty cheap now too.


I get the "humans are fine with vision so car should be too" argument-- I've made it myself.

But the humans eyes are behind glass, they have ways to clear most of that glass if obscured, and they can lean and turn their head as needed to see further around objects or out of direct line of the suns rays.

The 3 front cams arguably have 1 and 2 going for them- not so much the other cams, and the lack of lean/turn makes placement, esp without any redundancy, problematic for the car cams.
Valid concerns.
If you could control the wipers, would you be able to safely drive the car based on the HDR camera feeds?

(I now have visions of Pole Position on Atari 2600)
 
First principles: A human could remotely drive a Tesla without issue based on the current sensor suite and telematics provided by the vehicle.

There's no redundant cameras for most of the 360 view, there's blind spots close to the car with current # and placement, and there's no ability to clear most of the cameras in bad weather.

Auto lane change disables itself if there's a spot of dirt on one of the side cameras, or if there's too much sun glare on one of them.
My rear camera is a blurry mess sometimes and I often get warnings that one of my side pillar cameras is obstructed. What actually happens is on cooler days the camera facing the sun gets a condensation buildup inside the plastic panel. In both those conditions a human inside the vehicle can drive without issue but a remote driver or vehicle AI could have problems.
 
Valid concerns.
If you could control the wipers, would you be able to safely drive the car based on the HDR camera feeds?

(I now have visions of Pole Position on Atari 2600)


I think basic AP is probably fine with current HW-- because it's mostly relying on the 3 forward cams that actually benefit from the wipers (and redundancy)

I've only had basic AP tell me it had to disable itself for weather ONCE--- and it was in truly horrific rain that I pulled over for 10 min for it to pass because even humans should probably not have driven in it.


It's NoA and FSDb that fail in weather humans can easily safely drive in (or even without any weather) because it's the fender, rear, and b-pillars that get blocked/dirtied/sun blinded with no redundancy or recourse (to say nothing of an actual HW failure- which while very rare would be non-zero in a huge robotaxi fleet).


Now- you could easily get to L3 with those problems- because you have a backup human on board.

But L4 and L5 you simply can't... because if suddenly one of the side cams is out and you're not already in the lane next to the shoulder-or there is no shoulder- the car can no longer "fail safely" without a human by knowing it's clear to pull off the road and park until someone comes to help.

I suppose you could add some really bizarre "find some place you CAN safely pull over with whatever cams still are working so like only make rights and right lane changes if a left cam is out" type code that might involve going long distances out of your way but even that I can think of many situations that'd be insufficient due to lanes ending, one way streets, etc...