You could argue its not necessary to achieve performance for an L2+ product and so keeps BOM cost down while still achieving goals. I'm not personally opposed though, the systems I worked on did have other sensors we could use.

That wouldn't resolve the concern around debugging/root-causing and remediating failures more quickly though. You still have a black box system that is difficult to simulate closed loop.

That's fair but the comment I'm responding to seems to take offense at just storing and distributing it on threads, which is exactly what every single fediverse instance has to do. There are also tools for dealing with this, namely you can configure a mastodon instance to not federate with a server.

If someone is more concerned about training models on the data and whether that is legal or not, I assume Meta could easily be doing that already if they wanted to via scraping.

This is a fundamental part of the fediverse, or at least mastodon, right? There can't be an federation without doing exactly this between mastodon instances.

I'm a huge proponent of e2e learning for robotics (worked at two places doing e2e before Tesla adopted it) and personally believe its the right approach long term. I also have FSD on my Model 3 and love it for L2+. That said, my experience with disengagements is very different than yours.. I have a few a week for things like road works, school zones, route map following. Perfectly fine for L2+, L4 it would be unacceptable.

If these robotaxis end up looking more like my experience than yours then another layer of trouble will be root causing and fixing failure modes. Training models e2e makes both of these much more difficult.

This was a similar issue with android/apple pay at the beginning (at least in the states where card tapping was less common). I expect given enough time it will become more common to verify your age at bars/stores, get through airports, etc with just a phone/watch tap.