[HN Gopher] Rivian reduced electrical wiring by 1.6 miles and 44...
___________________________________________________________________
Rivian reduced electrical wiring by 1.6 miles and 44 pounds
Author : addaon
Score : 159 points
Date : 2024-08-10 00:12 UTC (22 hours ago)
(HTM) web link (www.popsci.com)
(TXT) w3m dump (www.popsci.com)
| warkdarrior wrote:
| Couldn't they just use Wi-Fi? So much wiring..
| Jtsummers wrote:
| "just use Wi-Fi?", probably not. I don't think you'd want to
| create so many openings for attackers. Besides, EMI is a real
| issue and not something you want interfering with your critical
| systems too much.
| dylan604 wrote:
| > EMI is a real issue
|
| To the point they are wanting to eliminate AM radio because
| they've gotten to the point that the uncontrollable EMI makes
| AM "unlistenable". So move the goal posts, and make AM radio
| out-of-fashion and get rid of it rather than solving the EMI
| issues.
| katzinsky wrote:
| 1) I don't think you'll ever be able to make an electric
| vehicle electrically quiet enough to make AM work nicely
| and if you somehow did between the shielding and all the
| balancing currents there's no way it would be efficient. I
| like AM radio but these two things are probably never going
| to be compatible.
|
| 2) WiFi really isn't as reliable as a cable. There are all
| kinds of things internal and external that could cause an
| outage. Why bother with that when you can just run maybe a
| dollar of copper to the ECU?
| adrian_b wrote:
| So that anyone could crash your car with a jammer?
| silisili wrote:
| Ignoring wifi as a poor use case here(you'd likely use
| something with much less interference and better latency), RF
| will still usually have more latency than a wire. It's more
| prone to interference from other random devices and even other
| cars. Canbus is typically shielded, which you obviously can't
| do with something relying on radio.
|
| Then you have physical interference...imagine all your warning
| lights come on, wipers come on, and radio cuts off because your
| wife put her Stanley in just the wrong spot.
| Gibbon1 wrote:
| People don't like your comment but I have a side project that
| requires controlling 36 lamps in groups of 3. I rolled it over
| and I'm just going to slap a cheap radio on a PCB's and just
| daisy chain the power.
| kkfx wrote:
| I've built my "smart home" explicitly without wifi [1] to
| shield against any kind of "local exterior attack" and mere
| communication issues due to natural phenomenon. Even for
| light I decide for ShellyPro 4PM to avoid wireless...
|
| Surely without cables it's far easier, but this easiness have
| a price.
|
| [1] with the exception of the car charger since I wasn't able
| to find a damn cabled one (it's 230Vac, not CCS eh!)
| nurettin wrote:
| > "local exterior attack"
|
| I appreciate the geek, but is this useful in practice? Does
| it happen to anyone?
| kkfx wrote:
| I do not know any statistic, but for instance
| https://www.cnet.com/home/security/can-burglars-jam-your-
| wir... it's a well known phenomenon, as it's well known
| enough you can buy a ready-made multi-frequency jammer
| for very little price from China.
|
| Aside another aspect is how to make the home impossible
| to live in case someone illegally occupy it (here,
| France, but essentially all south Europe is a relatively
| new but spread thing) while you are on vacation to be
| quicker than local authorities. Another one is avoiding
| connecting too much black boxes to their OEM homes.
|
| Another final aspect is mere reliability, as a small
| anecdote: a neighbor due to some unknown issue have had
| roller shutters locked down because they have ONLY a
| wireless remote with a kind of ESP32 inside, all
| proprietary, no emergency manual opening, no access to
| the motor to power it directly or detach the break
| manually on the shutters. My home while "a bit smart"
| have a far little attack surface in that regard. For
| instance just to have central/remote lights control I've
| chosen a set of ShellyPro 4PM (the least expensive option
| of that kind I was able to find) witch operate remotely
| (LAN only, via HA or directly logging on the device,
| extended via wireguard) but i can also operate via
| classic mechanical switches and internally the Shelly are
| "dumb classic switch" + extras so if their fw crash from
| the physical buttons (not the one on the devices, but
| their normally open contacts) they still operate. For the
| car charger I'm obliged to go wifi (I find exactly no one
| domestic charging station with wired connections for
| control) but it's a dedicated WLAN (a small GL.iNet
| "stamp" size on the back of the charger, wired to a
| dedicated port of my homeserver on a completely separated
| LAN without internet access and the charger itself is
| MQTT/ModBUS-bridged to its local, internet-less
| controller/server for p.v. integration.
|
| I can't do nothing for my car and well... Sometimes it's
| "app-service" to remote control A/C etc get connected to
| someone else car in another country and yes, I can
| monitor it and act on it when this happen (few times per
| years so far). No special hacking needed. No response
| from the vendor (MG/SAIC)... And for cars some demoed
| serious remote vulnerabilities able to physically make a
| car crash while running.
|
| All those might be very rare events, but their
| seriousness it's relevant enough for me to avoid them as
| much as possible.
| viraptor wrote:
| There's often the "wifi or wired" discussion around here,
| so I'll just add that those are not the only choices. Zwave
| for smart devices for example is a local wireless protocol
| which is completely separate from WiFi and doesn't have the
| same addressing / access issues.
| stavros wrote:
| I built everything in my house with Zigbee and could not
| be happier. The "everything is just a message queue"
| approach that Zigbee takes is fantastic for the home, and
| the fact that I don't have to worry about a whole
| complicated protocol that can do anything is great.
| gruturo wrote:
| Maybe you already completed your project, maybe you already
| knew about Charlieplexing
| (https://en.wikipedia.org/wiki/Charlieplexing), maybe it
| doesn't apply to your case as your controller didn't support
| tristate output, but, just in case you didn't know about it:
|
| It's a technique for controlling (or reading) large numbers
| of LEDs, switches, etc, with surprisingly little wiring.
| Instead of the usual X/Y of multiplexed I/O, the wiring is
| diagonal. To control 12 outputs (36 in groups of 3) you'd
| need just 4 pins (if your lamps are not LEDs, though, you
| probably need to put some diodes in there)
| daghamm wrote:
| OP is heavily downvoted, but yes some ECU are moving to
| wireless communication although not WiFi.
|
| It started with places where you simply can't have wires, for
| example tire pressure monitoring. But is now spreading to other
| simple ECUs. And yes, it can be jammed so obviously it's not
| for brakes and steering and things like that.
| janice1999 wrote:
| It's a good question. Wireless is already replacing wiring
| inside the battery pack performing some of the most sensitive
| data transmission. See here for details: https://www.gm-
| trucks.com/explained-general-motors-wireless-...
| gorgoiler wrote:
| The before/after ECU layout diagram is very instructional.
|
| I like to imagine some kind of engineering "meet cute" whereby,
| one random day, the headlights engineer and the parking radar
| engineer happen to be working on the front of the car together.
| Their eyes meet:
|
| "hey, I'm John -- I didn't know you had an ECU here!",
|
| "hi, I'm Claire -- wow, you have an ECU right up front too? It's,
| like, right next to mine and we never knew!"
|
| "I know, crazy right?! Hey this is going to sound really forward
| and I don't normally do this but I'm only running at 70% compute
| capacity. I don't suppose you need any real-time budget this
| evening?"
|
| "So funny you should ask, I was just about to run a whole bunch
| of heavy new wiring to..."
|
| And in a story as old as time they get ECU married and raise
| their control loops in the same front-of-vehicle ECU together
| instead of living their separate, lonely, ECU-right-next-to-each-
| other-and-they-didn't-know-it lives.
| jdiez17 wrote:
| I ... am a bit speechless ...
|
| I didn't know this was something I could be into so much, and
| yet here we are.
| brundolf wrote:
| That's what they said
| kevin_thibedeau wrote:
| Ford did this with the cost reduced version of SYNC 3, merging
| two modules to form SYNC 2.5. The result is an unstable heap of
| trash.
| dangus wrote:
| Well, it is Ford. You buy a Ford you should expect it to be
| trash.
| plg94 wrote:
| wow, you made hackernews turn into tumblr. Well done, great
| explanation.
| gregmac wrote:
| It's interesting to think about the failure modes here.
|
| With domain-based ECUs, a failure means your locks OR windows OR
| windshield wipers stop working.
|
| With zone-based, it could be the entire "west" zone that stops,
| which means you can't unlock the driver's door, open the windows,
| adjust the seat, and maybe even the ventilation fans don't work
|
| I actually thought a lot of that was already on the CAN bus
| anyway, but my knowledge of cars stops there so maybe someone can
| fill in the gaps. Seeing only three "zones" is actually
| surprising to me. As I was reading I started forming the idea of
| a single bus cable that went around the car, with I/O modules
| anywhere there were physical buttons/lights/etc. There would just
| have to be a cost+weight balance of where it makes sense to stick
| a small I/O module vs run individual wires back to a bigger
| module. My assumption is as technology advances it becomes
| cheaper to have more small I/O modules with very short wire runs
| to buttons, but it doesn't seem like this is what they're doing.
|
| I am also making the assumption this is "dumb I/O", and somewhere
| there is a "door lock" program that handles all locks/buttons. In
| the main computer you'd run all the domain programs
| individually/isolated, but there would still be a single program
| responsible for each domain, eg: all the locks (eg: considering
| button presses, fob buttons, door state, moving or not, etc, and
| act on the locks accordingly).
|
| From a pure software point of view, if the east/west/south ECUs
| are actually doing the logic for their respective parts of the
| car, that seems like a nightmare to build: the code would end up
| being all partial and distributed. In the worst case you end up
| with bizarre bugs like "if you open the passenger door, then open
| the tailgate, then close the passenger door and press the lock
| button, the driver's door will lock but the passenger won't until
| you first unlock then shut everything" (which gets reported as
| "the locks are unreliable, some will randomly just not work every
| few days").
| edmundsauto wrote:
| Some door locks will trigger the servo every time you hit the
| heron (older-ish cars) and some have a sensor. Not clear to me
| if it's a remote sensor or some sort of smarts in the local
| mechanism.
|
| Given some of the chip shortages of recent year, I'm curious
| how the teams responsible for those trade offs made the
| balance.
| Animats wrote:
| > "if you open the passenger door, then open the tailgate, then
| close the passenger door and press the lock button, the
| driver's door will lock but the passenger won't until you first
| unlock then shut everything"
|
| I have a Jeep where the dome light logic has a problem like
| that. If you open a door, the dome light comes on. When all
| doors are closed, but the engine is not running, the dome light
| dims out after a delay. If the engine is running or is started
| in the all doors closes, dome light on situation, the dome
| light goes out. If you open the tailgate, the dome light comes
| on as well. That's all normal.
|
| But if I open a side door, then close it, and the light times
| out and dims, then, for some period of time thereafter, opening
| the tailgate will not turn on the light. I can just see some
| horrid mess of IF statements written in C behind this.
| sdwr wrote:
| State management is the only difficult problem in computer
| science
|
| Or something like that
| euroderf wrote:
| Have they never heard of fuzzing.
| Timshel wrote:
| They though of the failure mode opening doors should be part of
| the "vehicle access" which get its own ecu.
| daghamm wrote:
| There is a short answer to all this:
|
| Distributed systems are hard, more so in a real-time
| environment. If you can reduce the number of components or the
| need for them to communicate they will almost always become
| more robust and also easier to code.
|
| Rivian added some network redundancy and central monitoring to
| make this design safe, but otherwise the core design principle
| was basically KISS.
| morning-coffee wrote:
| From the article:
|
| > The system includes an array of 11 internally developed
| cameras and five radars performing over 250 trillion
| operations per second, which Rivian says is an industry-
| leading statistic
|
| I generally like what they are doing with their overall
| architectural simplifications, but gee-zus; the feeling of
| complexity I get from that one statement leaves me with the
| feeling of "it's just a car man... it takes us from point A
| to point B... is all that really necessary?"
| mynameisvlad wrote:
| The point is that it might in the future take you from
| point A to B autonomously.
| moring wrote:
| When I read this, my first thought was: Why do these ECUs have
| any deep logic at all? I would have expected all logic to be
| centralized at one point (or in a few points, but with each
| domain localized to one of them), and everything at the edge be
| dumb(1) port extenders. That's a single point of failure, of
| course, but as far as I understand the zonal approach has those
| too -- multiple SPOFs, actually. At least when it's a single
| SPOF, that problem can be better mitigated.
|
| (1) "dumb" meaning no decision-making logic. It could still
| mean a lot of decision-less logic, from button debouncing to
| input signal filtering/processing and outputting compressed
| audio streams.
| guai888 wrote:
| Standard approach is following ISO 26262 development to deal
| with risk resulting from failure mode.
| Lvl999Noob wrote:
| > With zone-based, it could be the entire "west" zone that
| stops, which means you can't unlock the driver's door, open the
| windows, adjust the seat, and maybe even the ventilation fans
| don't work
|
| From my reading, I thought the important parts were on their
| own dedicated ECUs (7 ECUs, 3 zones). Battery management,
| driving related stuff, infotainment, door mechanisms, etc have
| their own ECUs. The three zones are for smaller things that are
| probably important but not urgently important.
| Moto7451 wrote:
| Some cars work this way logically already. If you scan my Audi
| with a compatible tool it will read various functional modules.
| If one dies than that modules' systems go down but other nearby
| functions work. Child locking is a separate unit from door
| locking and as a result in my car my driver side rear door will
| lock in such a way that only the inside manual latch will open
| the door.
|
| The dealer can't figure out the issue four years in.
| techdmn wrote:
| Some days I'm really happy that I kept at least one analog car.
| indoorcomic wrote:
| I love this. I hope this more manufactures go this route. I've
| always felt that having ~100 ECUs in a car is complete overkill.
| Jtsummers wrote:
| See gregmac's comment, it changes the failure modes and makes
| what could be isolated subsystem failures larger regional
| failures. However, components are also becoming much more
| reliable so this is an engineering tradeoff. Cases can be made
| in both directions.
|
| EDIT: That's not the only tradeoff, but it is a key one.
| metadat wrote:
| https://news.ycombinator.com/item?id=41207335
|
| In the future, please include the actual link. It is 10x more
| useful.
| AlotOfReading wrote:
| I've been a (somewhat successful) advocate of similar
| approaches at the automakers I've worked for, but it's not as
| simple as the article makes it sound. Individual components in
| each "zone" can have different reliability requirements, for
| example. They also might be produced by different suppliers, or
| only be present on certain models / trims.
|
| Rivian is able to do this because they're taking advantage of
| modern heterogenous processors and they haven't made the
| mistake of outsourcing almost all of their software
| capabilities to tier 1,2,3 suppliers. Legacy OEMs find it much
| more difficult to adopt, especially once the institutional
| inertia takes over.
| Ekaros wrote:
| Replacing word ECU with micro-controller makes number seem less
| insane. Okay, PCs are having less and less components. But one
| might ask why do so many components have any logic at all? We
| got extremely insanely powerful central CPUs with loads of
| memory and storage space. So why not just do absolutely
| everything there?
|
| Remove any logic and computing from screens, keyboards, mice,
| SSDs, HDDs, off load everything from network chips and sounds
| chips. Just move all of it to CPU?
| moring wrote:
| I think you'd want at least some "dumb" logic moved to the
| periphery, otherwise everything has to be conected directly
| to the CPU and you would still end up with tons of wiring.
| Also, some functions done in the periphery are ideal
| candidates for parallelization, such as the keyboard scanning
| the key matrix for pressed keys.
| maxerickson wrote:
| Seems like modularization is going to be beneficial pretty
| much anytime you can define an interface you think is going
| to be somewhat stable.
|
| I wonder to what extent Rivian has removed intermediate
| controllers here, where they used them in the first place
| to get things done on a tighter timeline.
| kevin_thibedeau wrote:
| The value proposition of CAN bus is that peripherals can be
| scattered around connected by two data lines and a power
| wire. Dumb peripherals need more wiring.
| moring wrote:
| They are deviating from that already, aren't they? If
| they use one ECU per zone, then the peripherals in that
| zone can't be connected via CAN bus, otherwise they would
| need their own controller.
| OptionOfT wrote:
| I think having multiple ECUs over time is a cost savings
| mechanism. You have a module that you can use in all your models
| because it works.
|
| If Rivian wants to add a new feature that doesn't 'fit' on the
| AIO ecu, then what? Replace it and re-certify ALL of its
| functions?
|
| A good example is the ABS controller which is usually just a
| Bosch COTS ECU.
|
| You wouldn't even want to implement that for yourself.
| daghamm wrote:
| "four categories get their own ECUs: infotainment, autonomy,
| vehicle access, drive units, and its battery management system."
|
| Am I reading this wrong, or are these actually five categories?
| masklinn wrote:
| Given the wording of "drive units, and its battery management
| system" I'd think the BMS is linked to the drive units and
| under the same ECU. I'd assume the drive units and BMS are
| tightly integrated, as that's basically the entire high-voltage
| system and you have to manage the two-ways energy flow between
| the two (propulsion and braking / regen).
| trainsarebetter wrote:
| Not really, the FOC software that runs on the inverters is
| compute heavy and safety critical. It gets its own dedicated
| controller (they are actually running to cpus in parallel in
| case one fails) and same with the bms. They talk over can
| currently in teslas. bms states it's max charge and discharge
| current, and everything else listens
| schobi wrote:
| The diagrams for the new west south and east zones still show a
| lot of wires going all across the vehicle. This step might be a
| good first one to reduce the number of ECUs by combining them,
| but there is still the same cross-car wiring. You still seem to
| have a single ECU per function, but merged into a few dedicated
| boxes for example.
|
| Next step: Each wire only goes to the nearest box. I'm curious
| how the Tesla unboxed architecture will eventually play out. I
| understand that eventually, the ECUs will be split up, so you
| have some aspect of each ECU in each corner of the vehicle. Part
| of the "lights" function is in front-left, part of it in the
| back. Wires only go to the nearest box.
|
| A powerful vision, with the potential to further reduce wiring.
| Complex until you get a distributed brake ECU.
| yc-kraln wrote:
| The electrical wiring in cars is Conway's law manifest in copper.
|
| For those unfamiliar with Conway's law, I am arguing that how the
| car companies have organized themselves--and their budgets--ends
| up being directly reflected in the number of ECUs as well as how
| they're connected with each other. I imagine that by measuring
| the amount of excess copper, you'd have a pretty good measure for
| the overhead involved in the project management from the
| manufacturers' side.
|
| (I previously worked for Daimler)
| mensetmanusman wrote:
| Would be funny to have a 'mm Cu / FTE' scaling law.
| throwaway48476 wrote:
| Complexity is a function of the number and depth of
| suppliers.
| westurner wrote:
| The ohm*meter^3 is the unit of electrical resistance.
|
| Electrical resistivity and conductivity: https://en.wikipedia
| .org/wiki/Electrical_resistivity_and_con...
|
| Is there a name for Wh/m or W/m (of Cu or C) of loss? Just %
| signal loss?
|
| "Copper Mining and Vehicle Electrification" (2024)
| https://www.ief.org/focus/ief-reports/copper-mining-and-
| vehi... .. https://news.ycombinator.com/item?id=40542826
|
| There's already conductive graphene 3d printing filament (and
| far less conductive graphene). Looks like 0.8ohm*cm may be
| the least resistive graphene filament available: https://www.
| google.com/search?q=graphene+3d+printer+filament...
|
| Are there yet CNT or TWCNT Twisted Carbon Nanotube
| substitutes for copper wiring?
| lofaszvanitt wrote:
| 3rd generation: no wires from sensors to detectors.
| twoWhlsGud wrote:
| 4th generation: wires are back so the car doesn't stop working
| every time it drives by a source of RF noise...
| xbmcuser wrote:
| I recalled I read something similar before so I searched for it.
| It was Tesla doing something like this in 2019
|
| https://electrek.co/2019/07/22/tesla-revolutionary-wiring-ar...
|
| "In order to facilitate the automation of manipulating cables,
| Tesla has been reducing the length of wiring harnesses in its
| vehicles.
|
| Musk said that Model S has about 3 kilometers of wiring harnesses
| and Tesla brought it down to 1.5 kilometers in length for the
| Model 3.
|
| But that's just the beginning. Tesla is working on a whole new
| wiring architecture for future vehicle platforms and they aim to
| bring it down to just 100 meters starting with the Model Y."
| grecy wrote:
| Tesla have taken it to a whole new level on cyber truck.
|
| It is assumed this will continue in their next gen vehicles
| theluketaylor wrote:
| The legacy car makers have flirted with 48V components for
| decades but haven't been willing to do the hard work to
| realize all the benefits it brings. The germans in particular
| are stuck in limbo. For their PHEV and BEV cars they are
| shipping 12V for all traditional functions, 48V for advanced
| functions like active suspension and anti-roll bars, and high
| voltage systems for the traction motor. Complete mess.
|
| It's frustrating to be a Tesla owner. For every great
| engineering choice they make like going all in on 48V they
| make a user hostile choice like removing stalks and selling
| "full self driving" that is downright dangerous.
| jvanderbot wrote:
| The single most frustrating thing Tesla did re: Power was
| not allowing me to plug an appliance in. We lose power
| somewhat regularly where I live due to storms, and the
| tesla has 6-10 days of my household power budget sitting in
| its banks. Just let me plug in a deep freezer and coffee
| maker, please.
|
| INB4 the 12V terminals: They are hard to access, have
| limited amps, and are _a separate crappy battery_.
| trainsarebetter wrote:
| For sure, but the economics don't work out for the
| earlier Bev battery chemistry's. The additional cycle
| where from v2x don't justify it, getting a power wall
| just makes more sense in the long run.
|
| But I still agree the option should be there for
| emergencies
| jvanderbot wrote:
| The thing is, Tesla is the _only_ large battery I can put
| in my house, according to local regulations (I can get
| solar+battery, but the solar provider terms in my area
| are garbage, and I can only sell power to local company
| and get credits for later use. I can 't actually store
| it).
|
| This is a disruption opportunity wasted.
| postalrat wrote:
| Adding one additional voltage doesn't turn something from
| elegant to a complete mess.
|
| I don't know why you mentioned the traction motor voltage
| as part of the mess. Do you want hundreds of volts DC
| running all over the car?
| throwaway48476 wrote:
| The problem is for the whole industry to go 48V costs money
| and whoever pays will also benefit the competition because
| everyone has the same suppliers. There needs to be some
| kind of industry regulation that says by so and so date
| everything had to be 48V.
| katzinsky wrote:
| In my homebrew BEV I've started just using AC for most
| smaller things. It's easier than finding 48v components,
| the connectors are nicer than 12v (I've really come to hate
| cigarette lighter plugs) the high voltage means the
| conductors can be small and the zero crossing means the
| switches can be much cheaper too.
|
| And being able to find replacement parts at the dollar
| store no matter where you are is really great.
| samatman wrote:
| > _selling "full self driving" that is downright
| dangerous._
|
| Is there evidence of this, at this point?
|
| I haven't looked into it in several years, but back then,
| Teslas were getting in fewer accidents per driver mile than
| average. I would think given that there's a faction of the
| public, and especially of the activist public, who are
| hostile to Tesla/Musk, that if FSD is in fact more
| dangerous (which would mean more accidents per driver
| mile), there would be a good URL you could provide us which
| makes that case using the available statistics on the
| subject.
|
| Because it's an entirely empirical question. Anyone can
| argue from first principles in either direction, but one of
| two things are the reality: either FSD driver miles are
| less prone to accident than average, or they're more so. I
| suppose it could be precisely at 50%, as well.
| mrgoldenbrown wrote:
| It may be an empirical question, but as long as Tesla
| insists on keeping the raw data secret, it's reasonable
| to suspect their conclusions/claims
|
| https://www.wsj.com/business/autos/tesla-autopilot-crash-
| inv...
| toast0 wrote:
| To do proper statistical analysis, you'd need to compare
| miles driven with FSD to miles driven by humans in
| _similar_ conditions. That 's not the easiest thing to
| do. Tesla had occasionaly released statistics with their
| earlier driver assistance technology, but without enough
| detail to form informative comparisons. Based on past
| experience, I don't expect Tesla to provide meaningful
| statistical data or to allow outside access to their raw
| data (which fwiw, seems like a huge privacy risk to
| collect), so I don't think we'll have an empirical result
| unless there's discovery for a lawsuit.
| theluketaylor wrote:
| Extensive analysis of Tesla and NHTSA crash reporting
| (some by NHTSA themselves) shows that autopilot and fsd
| do not have significantly better safety outcomes than
| manual drivers or drivers aided by other non-tesla
| assistance systems.
|
| This NHTSA report is pretty damning about Tesla's
| cavalier attitude towards the design of safe systems.
|
| https://static.nhtsa.gov/odi/inv/2022/INCR-
| EA22002-14496.pdf
|
| https://www.forbes.com/sites/bradtempleton/2023/04/26/tes
| la-...
|
| https://www.forbes.com/sites/bradtempleton/2020/10/28/new
| -te...
|
| https://www.wired.com/story/tesla-autopilot-risky-deaths-
| cra...
| samatman wrote:
| > _shows that autopilot and fsd do not have significantly
| better safety outcomes_
|
| Ok. So in the middle then. Not, in other words,
| "downright dangerous".
|
| That would be, worse safety outcomes. Rather than
| insignificantly better.
| gamblor956 wrote:
| _either FSD driver miles are less prone to accident than
| average, or they 're more so. I suppose it could be
| precisely at 50%, as well._
|
| This has been proven false by Tesla's own data released
| to the NHTSA. Teslas have more accidents per vehicle than
| any other cars with advanced cruise control from _every
| other automaker in the world combined._ And that doesn 't
| even include the far worse accident statistics for 2023
| and 2024.
|
| There were three Tesla-related fatalities in the past
| week in the U.S. alone, including one in which the design
| of the Cybertruck is thought to have contributed directly
| to the death of its driver. Teslas get into so many
| accidents that news media don't even bother to report on
| Tesla-related accidents anymore unless someone dies.
| samatman wrote:
| > > _either FSD driver miles are less prone to accident
| than average, or they 're more so. I suppose it could be
| precisely at 50%, as well._
|
| > _This has been proven false by Tesla 's own data
| released to the NHTSA._
|
| What I said is very close to a tautological statement,
| and cannot be proven false by data.
|
| What data can do is determine which of these three
| categories that data falls into.
|
| Your anecdotes don't appear to align with the actual data
| as summarized by someone kind enough to provide some.
|
| > _Teslas get into so many accidents that news media don
| 't even bother to report on Tesla-related accidents
| anymore unless someone dies._
|
| Why would they?
| Sysreq2 wrote:
| You are confusing a claim - specifically that "Teslas are
| dangerous" or "FSD is dangerous" with a much broader
| reality; that _all_ Cars are dangerous.
|
| You assert that 3 people died this week due to Tesla
| related fatalities in the US alone. That adds up to more
| than 150 per year! But considering that Tesla's comprise
| 5% of the car market, that 150 is a drop in the bucket
| compared to the 43000 that die in car accidents in the US
| every single year.
|
| Tesla's fully autonomous self driving is about as safe as
| a regular person. Many of it's "accidents" as shown by
| the various investigations have shown that "drivers" in
| the plurality of cases had several(>5) seconds to react
| but failed to do so.
|
| The curious case of Tesla's safety record will one day be
| a case study in every undergraduate business class. The
| naysayers want to see the company fail, the CEO fail, or
| the technology fail. But the problem is not the
| technology, but rather the people using it. It's been
| long known that increasing protective equipment in sport
| decreases minor injury but paradoxically increase the
| likelihood of severe ones.
|
| Why? Because people are lulled into a false sense of
| security. Individuals take risks they would not otherwise
| due to the inhibition of the natural feedback mechanism
| that would otherwise deter them from continuing to push
| the bounds. Since they keep getting away with it, they
| continue to push, only to discover that the failure mode
| has gone from mild to extreme.
|
| Those small injuries are the warnings that keep you safe
| and prevent you from taking greater and greater risks.
|
| Technology is like that. Cars are safer now than ever.
| Seat belts, crumple zones, air bags - and yet looking at
| the statistics you would never know it. This has led to
| urban legend like cars in the 1940s being "safer" due to
| their all steel construction. But this is not true.
|
| What is true is that people drove slower in the 1940s.
| Most highway traversal occurred at a mere 40 miles per
| hour. A far cry from the 80 everyone does on the way to
| work today. As safety increases so too does our tolerance
| for risk.
|
| Ultimately, that is the problem with self driving cars.
| They work too well. They unintentionally encourage
| drivers to take greater and greater risks. And they get
| away with it. Until suddenly. They don't.
| hulitu wrote:
| > The legacy car makers have flirted with 48V components
| for decades but haven't been willing to do the hard work to
| realize all the benefits it brings
|
| Can you name some benefits ? ICs working at 48 V are
| expensive and hard to find.
| brianwawok wrote:
| Massively smaller wires and higher powered accessories
| AlotOfReading wrote:
| That's why DC/DC converters exist. Only the things that
| can take 48v (and associated voltage spikes) get exposed
| to it.
| quanto wrote:
| quick math check
|
| > 1.6 miles and 44 pounds
|
| pure copper density at 9000 kg/m3, wire diameter assumed at 1mm,
| length at 3000 m (1.8 mi, approx) gives 21 kg, approximately 46
| lb. math checks out.
|
| > the company claims a 20 percent savings in material costs and
| 15 percent reduction in its carbon footprint between Gen 1 and
| Gen 2.
|
| surely this is not just due to the reduction of copper. copper is
| around 10 USD/kg at bulk.
|
| now let's see if we can address the copper length number. can 1.6
| mi (< 3000 m) of copper be saved from wiring alone?
|
| The car dimensions are 2m x 5m. That means, in the worst case,
| two ECUs placed at opposite ends will need 5m of wire (half of
| perimeter). There were 17 ECUs originally. Call it n = 20, and if
| we wire dense (in the graph sense), we get n^2 = 400. So, in the
| absolute worst case, the densest possible graph would have had 5m
| x 400 = 2000 m of wire. The claimed wire saving is significantly
| (but not by an order of magnitude) larger than this. I would say
| this passes the smell test (albeit barely), but original wiring
| must have been truly inefficient.
| spydum wrote:
| maybe i missed in your estimate, but most circuits need more
| than one wire?
| hn72774 wrote:
| In a vehicle, the chassis is the negative wire in the
| circuit.
| AlotOfReading wrote:
| The vast majority of automotive buses use differential
| signaling over multiple conductors for EMI reasons. The
| only common exception is LIN and maybe SWCAN if we're
| exceedingly generous with our definition of "common".
| caleblloyd wrote:
| I didn't completely follow either but I think the n^2 = 400
| worked out to 20 ECUs each with 20 wires
| thelastgallon wrote:
| Rivian can switch to 48V for more gains.
|
| https://news.ycombinator.com/item?id=38576612: The move to 48V
| means much less power is lost (power loss = (IxI)xR ), cables can
| be much smaller, cables and terminals can be much lighter and
| much less copper can be used used.
|
| Discussion: Tesla shares 48V architecture with other automakers:
| https://news.ycombinator.com/item?id=38557203
| jondwillis wrote:
| Those are rookie numbers. Let's bump it up to 96V while we are
| at it.
| throwaway48476 wrote:
| 50V is the generally accepted safe cutoff. There are separate
| electrical certifications for 'low voltage' <50V.
| addaon wrote:
| SELV is often capped at 60 V, not 50 V, although this is
| often treated as "48 V with crappy bounds". An example that
| takes advantage of this would be PoE, which allows 44 V -
| 57 V at the PSE; but most PSEs are, in my experience, in
| the 54 - 57 V range.
| maxerickson wrote:
| 60 volts DC is treated as a safety threshold. Human bodies
| start to conduct better about there.
| amluto wrote:
| There are massively diminishing returns. 1kW at 12V is 83A,
| which needs a rather beefy wire that is expensive to buy,
| annoying to route, difficult to route, and needs careful
| termination with large tools. 1kW at 48V is ~20A, which can
| be done with 12 gauge wire, which is not bad at all to work
| with.
| hulitu wrote:
| Your microcontrollers need 5V, 3.3V and 1.8V. Your RAM needs
| 1.2 V.
|
| There are power losses when translating from 48V to 3.3V, you
| know. /s
| Vecr wrote:
| Not really, if the converter's switching it should be fine
| either way. Generally you would want to tune it for the input
| voltage but in many cases the input range is large.
| _heimdall wrote:
| I was expecting to see a mention of whether there were any safety
| concerns related to running fewer ECUs. I'd assume not since they
| chose to go this route, but the idea of the infotainment system
| going down and taking other systems offline with it seems like a
| risk they would have had to consider.
| therealdkz wrote:
| There is nothing like perf improvement that removes sleep() put
| in earlier...
___________________________________________________________________
(page generated 2024-08-10 23:02 UTC)