Wann platzt die TESLA-Blase (Seite 13263)

[aceniro]

Juli USA

VW Group +3.4%
Audi: +0.8%
Bentley: +2.4%
Lamborghini: +85.6%
Porsche: +23.3%
VW: +2.2%
Mercedes: +22.9%

Tesla: -6.7%

[charliebraun]

Antwort auf Beitrag Nr.: 61.157.123 von gagaga am 02.08.19 00:37:43

Eher ja, wengleich nicht 100% richtig, und tatsächlich nicht exakt nachprüfbar, weil Tesla keine Länderlieferungen bekanntgibt (was für sich schon absurd ist).
Ich glaube, die Iev-Schätzung beruht auf Zulassungszahlen und das könnte die Lösung des Widerspruchs sein. Nämlich indem von den "Brechstangenlieferungen" ganz zum Quartalsende hin viele nicht mehr im selben Quartal zugelassen wurden und ins nächste Quartal "rüberschwappen".

[gagaga]

Antwort auf Beitrag Nr.: 61.155.209 von charliebraun am 01.08.19 19:58:53

Insideev-Schätzungen für Juli heraußen. 13.450 US-Model3-Lieferungen halt ich für viel zu hoch.!

hat mich auf verblüfft. ABer die Inside EV Schätzungen waren doch immer ziemlich gut, oder hab ich das falsch in Erinnerung ?

[colouredanthouse]

Antwort auf Beitrag Nr.: 61.157.033 von mozzila am 02.08.19 00:04:03

Der Ansatz ist nicht kompliziert, und wo denke ich da negativ?

Dass man nicht erst mit dem Auto an einer Baustelle vorbeifahren muss, um die winzige Radar-Rückstreuung einer Pilone herauszufinden, ist sehr positiv gedacht - und kompliziert ist das erst recht nicht.
Dass man einfach herausfinden kann, dass die selbe Pilone mit LIDAR durch diffuse Streuung einfach sichtbar ist (und zwar in Ausdehnung und Abstand) ohne, dass man einen Fuß vor die Tür setzt, ist auch positiv.

[xwin]

Antwort auf Beitrag Nr.: 61.156.907 von colouredanthouse am 01.08.19 23:32:06

Vergiss es. Du versuchst gegen Menschen zu argumentieren, die glauben da muss nur 'Bibi Blocksberg' kommen und 'hex hex' macht der Tesla Wunderchip FSD mit reiner Computervision.

Statistiken, Physik und selbst durch den AP getötete Menschen als empirischen Beweis für die Theorie zählen als Argument nicht. Da kannst du im Grunde genommen schreiben was du willst.

Elon hat gesagt also isses so.

Ich dachte ja ansich, dass sich die Diskussion erledigt hat, wenn die Zauberkiste gegen ein paar Objekte fährt - wiederholt. Aber es ist halt ähnlich verzwickt wie mit Religionen. Gegen den Glauben anzuschreiben ist zwecklos.

[mozzila]

Antwort auf Beitrag Nr.: 61.156.907 von colouredanthouse am 01.08.19 23:32:06

Zitat von colouredanthouse:

Zitat von sg-1: ich glaube, ihr habt keinerlei Ahnung von Software Development, Geschweige denn von Neuralen Netzwerken, deren Training oder der Herangehensweise bei auftretenden Problemen, Entwicklungszyklen usw.

Hier wurde jetzt eine lange Liste an Zitaten gepostet. und nun? Was genau sagen diese?
- Sie sagen, dass bei der Entwicklung Probleme auftreten - anders formuliert: neue Situationen, die eine Anpassung erfordern.
Sie sagen, dass man auf solche Probleme gestoßen ist und Dinge anpassen musste.
Sie sagen, dass man praktisch festgestellt hat, dass Komplexität ein großes Problem ist.

Das zeigt mMn auf, dass die Flotte ein sehr wichtiger Punkt ist. Denn im Labor wird man auf solche Fehler bzw Situationen nicht stoßen. weder real-life Daten betreffend, noch Architektur betreffend. So etwas kann man nicht im Labor entwickeln ohne massenweise Daten.

"Wo genau sagt er denn, dass sie irgendwas können?"
Er sagt nicht, dass das was sie gerade entwickeln funktioniert und bereits fertig ist.
das ist aber ein großer Unterschied zu: "wir können nix und wissen nicht, wie wir es entwickeln sollen" - im Gegenteil, sie haben ja anscheinend bereits mögliche Schwachpunkte ausfindig gemacht und arbeiten daran. Das ist auf jeden Fall mehr als NIX können.

Auch hier: Der Ausgangspunkt - also die ellenlange Liste an Dev-Aussagen lässt keinerlei Aussage zu, ob es funktioniert oder nicht. es ist lediglich ein verzweifelter Versuch, jedes Wort auf die Goldwaage zu legen. Andere Entwickler können evtl. dadurch Hinweise bekommen, wo man auf Hindernisse stoßen könnte, oder Anregungen bekommen wie man es (nicht) machen sollte.

Wie sollten sich denn Entwickler eurer Meinung nach artikulieren? Bzw. welche Aussagen habt ihr denn erwartet bei einer fortlaufenden Entwicklung und Präsentation vor Fachpublikum auf der ICML2019?

Hmm, was soll man dazu sagen ...

Keine Ahnung mit Software develpoment ... mmm...
ich bin Software Entwickler im Bereich der Physik (und erstelle Software eine spezielle optische Technik).
Diese Entwicklung bezieht auch die Schnittstelle zur Hardware mit ein.

Das allererste - noch vor den praktischen Problemen die hier beschrieben wurden -, muss sein eine Hardware zu definieren, die mit an Sicherheit grenzender Wahrscheinlichkeit in der Lage ist die Daten die man benötigt zu erzeugen (Sensorik, Detektion) und die in einer zweite Ebene die Daten im Echtzeit erfassen und analysieren kann. Dabei ist es sinnvoll die Hardware so auszulegen, dass sie deutlichen Spielraum hat.
Wenn man z.B. meint das es unter Umständen auch ohne bestimmte Sensoren gehen könnte, wird man diese In der Entwicklung (wenn Zeit ein knapperes Gut als Geld ist) diese Sensoren trotzdem einbauen und sie dann später bei Tests ab- bzw. zu-schalten.

Um die Notwendigkeit bestimmter Sensoren zu Testen sind Laborbedingungen zunächst einmal besser geeignet wie der Felseinsatz. Warum ist das so? Ganz einfach: Beim Test des FSD auf der Straße findet man zwar Fehler heraus, jedoch ist die Situation zu komplex um die Ursache der Fehler einfach zu identifizieren. Das bedeutet das das System nach der Laborphase schon so perfektioniert sein sollte, das beim Feldtest nur noch selten Fehler auftauchen, die dann besser Analysiert werden können, da man das System dann im Labor schon deutlich besser verstanden hat.

Im konkreten Fall ist doch ganz klar, dass Tesla mit dem Einbau eines LIDAR Systems im Labor schon erkannt hätte in welchen Situationen man LIDAR braucht. Das kann man unter Laborbedingungen leicht feststellen und zum Beispiel durch Zuschalten des LIDAR direkt sehen.

Ehrlich gesagt hätte man auch schon durch relativ einfache Simulationen feststellen können, dass bei 4-12 mm Radar (160m) + Ultraschall (bis 8m) mit 1 mm Wellenlänge + Kameras viele wichtige Situationen nur unzureichend erfassen kann die mit LIDAR direkt erkennbar sind.

Das die Software Entwickler wegen unzureichender Sensorik / Detektion dann scheitern ist weniger deren Fehler sonder der Fehler der Person die behauptet, dass man LIDAR nicht braucht.

Es hilft beim praktischen Problem nicht, dass theoretisch sogar zwei hochauflösende Kameras (Augen, zwei akustische Sensoren (Ohren), ein Sensor für Chemische Stoffe (Nase), und ein biologisches neuronales Netzwerk (Gehirn) ausreichen um ein Auto zu steuern. Abgesehen davon sollte man auch berücksichtigen, dass dieses biologischen Systeme erst einmal 18 Jahre lernen müssen, dass sie eine biologische Intelligenz entwickeln, um ein Fahrzeug relativ zuverlässig steuern zu können – und selbst dann braucht die BI oft noch einige Jahre um sicherer zu werden.

Das ist alles viel zu kompliziert, und zu negativ gedacht.

[colouredanthouse]

Antwort auf Beitrag Nr.: 61.153.460 von sg-1 am 01.08.19 16:51:23

Zitat von sg-1: ich glaube, ihr habt keinerlei Ahnung von Software Development, Geschweige denn von Neuralen Netzwerken, deren Training oder der Herangehensweise bei auftretenden Problemen, Entwicklungszyklen usw.

Hier wurde jetzt eine lange Liste an Zitaten gepostet. und nun? Was genau sagen diese?
- Sie sagen, dass bei der Entwicklung Probleme auftreten - anders formuliert: neue Situationen, die eine Anpassung erfordern.
Sie sagen, dass man auf solche Probleme gestoßen ist und Dinge anpassen musste.
Sie sagen, dass man praktisch festgestellt hat, dass Komplexität ein großes Problem ist.

Das zeigt mMn auf, dass die Flotte ein sehr wichtiger Punkt ist. Denn im Labor wird man auf solche Fehler bzw Situationen nicht stoßen. weder real-life Daten betreffend, noch Architektur betreffend. So etwas kann man nicht im Labor entwickeln ohne massenweise Daten.

"Wo genau sagt er denn, dass sie irgendwas können?"
Er sagt nicht, dass das was sie gerade entwickeln funktioniert und bereits fertig ist.
das ist aber ein großer Unterschied zu: "wir können nix und wissen nicht, wie wir es entwickeln sollen" - im Gegenteil, sie haben ja anscheinend bereits mögliche Schwachpunkte ausfindig gemacht und arbeiten daran. Das ist auf jeden Fall mehr als NIX können.

Auch hier: Der Ausgangspunkt - also die ellenlange Liste an Dev-Aussagen lässt keinerlei Aussage zu, ob es funktioniert oder nicht. es ist lediglich ein verzweifelter Versuch, jedes Wort auf die Goldwaage zu legen. Andere Entwickler können evtl. dadurch Hinweise bekommen, wo man auf Hindernisse stoßen könnte, oder Anregungen bekommen wie man es (nicht) machen sollte.

Wie sollten sich denn Entwickler eurer Meinung nach artikulieren? Bzw. welche Aussagen habt ihr denn erwartet bei einer fortlaufenden Entwicklung und Präsentation vor Fachpublikum auf der ICML2019?

Hmm, was soll man dazu sagen ...

Keine Ahnung mit Software develpoment ... mmm...
ich bin Software Entwickler im Bereich der Physik (und erstelle Software eine spezielle optische Technik).
Diese Entwicklung bezieht auch die Schnittstelle zur Hardware mit ein.

Das allererste - noch vor den praktischen Problemen die hier beschrieben wurden -, muss sein eine Hardware zu definieren, die mit an Sicherheit grenzender Wahrscheinlichkeit in der Lage ist die Daten die man benötigt zu erzeugen (Sensorik, Detektion) und die in einer zweite Ebene die Daten im Echtzeit erfassen und analysieren kann. Dabei ist es sinnvoll die Hardware so auszulegen, dass sie deutlichen Spielraum hat.
Wenn man z.B. meint das es unter Umständen auch ohne bestimmte Sensoren gehen könnte, wird man diese In der Entwicklung (wenn Zeit ein knapperes Gut als Geld ist) diese Sensoren trotzdem einbauen und sie dann später bei Tests ab- bzw. zu-schalten.

Um die Notwendigkeit bestimmter Sensoren zu Testen sind Laborbedingungen zunächst einmal besser geeignet wie der Felseinsatz. Warum ist das so? Ganz einfach: Beim Test des FSD auf der Straße findet man zwar Fehler heraus, jedoch ist die Situation zu komplex um die Ursache der Fehler einfach zu identifizieren. Das bedeutet das das System nach der Laborphase schon so perfektioniert sein sollte, das beim Feldtest nur noch selten Fehler auftauchen, die dann besser Analysiert werden können, da man das System dann im Labor schon deutlich besser verstanden hat.

Im konkreten Fall ist doch ganz klar, dass Tesla mit dem Einbau eines LIDAR Systems im Labor schon erkannt hätte in welchen Situationen man LIDAR braucht. Das kann man unter Laborbedingungen leicht feststellen und zum Beispiel durch Zuschalten des LIDAR direkt sehen.

Ehrlich gesagt hätte man auch schon durch relativ einfache Simulationen feststellen können, dass bei 4-12 mm Radar (160m) + Ultraschall (bis 8m) mit 1 mm Wellenlänge + Kameras viele wichtige Situationen nur unzureichend erfassen kann die mit LIDAR direkt erkennbar sind.

Das die Software Entwickler wegen unzureichender Sensorik / Detektion dann scheitern ist weniger deren Fehler sonder der Fehler der Person die behauptet, dass man LIDAR nicht braucht.

Es hilft beim praktischen Problem nicht, dass theoretisch sogar zwei hochauflösende Kameras (Augen, zwei akustische Sensoren (Ohren), ein Sensor für Chemische Stoffe (Nase), und ein biologisches neuronales Netzwerk (Gehirn) ausreichen um ein Auto zu steuern. Abgesehen davon sollte man auch berücksichtigen, dass dieses biologischen Systeme erst einmal 18 Jahre lernen müssen, dass sie eine biologische Intelligenz entwickeln, um ein Fahrzeug relativ zuverlässig steuern zu können – und selbst dann braucht die BI oft noch einige Jahre um sicherer zu werden.

[sg-1]

stimmt, 2014 wurde drüber diskutiert, dass man sowas bräuchte. Der Bericht kam dann ca januar 2016
..mein Fehler

Mein Marktführer finde ich lustig. Ihr seid so Musk / Tesla fixiert. Die Erde dreht sich aber nicht um Musk.
Der Ausgangspunkt der Diskussion war außerdem der "elon says" tweet, der da irgendwas zusammen konstruieren sollte. Für mich ist es erst mal egal, ob das mit Tesla zu tun hat. Der tweet und die Behauptung dazu: "Ingenieur XY gibt zu, wir können nix" ist halt komplett falsch und konstruiert. Es war ein sauberer Vortrag zum Stand der Technik und den Überlegungen dahinter. Da war aber keine Aussage drin, ob Tesla das jetzt perfekt kann. Es war auch keine Aussage drin, dass Tesla etwas zugibt, nicht zu können.

[xwin]

Antwort auf Beitrag Nr.: 61.156.568 von sg-1 am 01.08.19 22:23:20

Zitat von sg-1: eine DMV statistik von 2014 bringt uns nicht weiter

2016 steht da. Lesen geht auch nicht ?

2016 war das letzte Jahr in dem dein 'Marktführer' autonom gefahren ist. Frag doch Elon warum das so ist. Wir können da nichts für.

[mozzila]

Antwort auf Beitrag Nr.: 61.155.092 von erwinsklein am 01.08.19 19:48:36

Zitat von erwinsklein:

Zitat von sg-1: ...

Ja. Wenn dadurch auch nur 10% der Leute defensiver fahren bzw der Autopilot sie fährt. Es ist definitiv sinnvoll, selbst wenn es nicht perfekt ist. Ich behaupte Mal,es wird noch eine lange Zeit lang nicht perfekt sein.

Die Frage ist nur,wie hoch legen die Zulassungsstellen die Hürde. Die legen ja quasi fest,ob es so ok ist. Das gilt ja für jeden Hersteller

Du willst doch nicht etwas diesen chaotischen AP von Tesla schön reden!

Welcher AP anderer Hersteller kann noch etliche Tote und Verletzte sowie einige Schäden vorweisen.
Wer solch ein nicht funktionierende Feature schön redet, beweist nur das was du selber immer vehement abstreitest .... das du parteiisch pro Tesla bist und den Schrott noch lobpreisen will.

Keiner tut den AP schön reden. Genau so wie ich die LKW Fahrern auch nicht schön reden will.