Software versie 9.0

[DutCH_CourA_64]

Voor iedereen die het 'onbegrijpelijk' vindt dat AP nog zoveel fout doet, verdiep je eens in wat wordt genoemd 'adversial example'. Komt er in het kort op nieuw dat zelfs kleine aanpassingen in de waarneming (input) die ons niet zouden opvallen toch heel verkeerde output (reacties van de AP) kunnen leiden. Er staat aardige artikelen over op internet, waaronder dezen:

Breaking neural networks with adversarial attacks - Towards Data Science

Evolving AI Lab - University of Wyoming

Belangrijke constatering: slechts een hele kleine aanpassing in de input, kan leiden tot een gigantisch ander resultaat dan beoogd. In dat licht bezien doet de AP het niet eens zo slecht ...

 

[Hbrink]

Vandaag Naarden-Zutphen vv met NoA

Maar één keer 10km snelheidsvermindering zonder reden. Wel is inhalen met maar iets van verkeer niet mogelijk: start lane change en afbreken.

Verder heel vreemd dat de auto nooit naar een lege rechterbaan wil.

Ik vind 'gewoon' EAP relaxter rijden. NoA doe ik alleen om systeem beter te maken.

Op mijn wensenlijstje staat met stip nr 1: herkennen van verkeersborden, mn snelheid.

 

[curry684]

Ik weet niet waar je dat gehoord hebt, want het is niet waar. Dan heeft iemand dat via cron oid specifiek zo ingeregeld.

Nee hoor, alle 3 zijn daemons met forked worker processes, waarbij met name bij Apache (https://httpd.apache.org/docs/2.4/mod/mpm_common.html#maxconnectionsperchild) en de default max connections per worker aardig conservatief zijn zodat na een paar honderd requests het process wordt gerecycled om handles en memory leaks impliciet vrij te geven. PHP-FPM regelt het via de *pm.max_requests* setting. Gehoord in de manuals en de sources

 

[bugboy]

Nee hoor, alle 3 zijn daemons met forked worker processes, waarbij met name bij Apache (https://httpd.apache.org/docs/2.4/mod/mpm_common.html#maxconnectionsperchild) en de default max connections per worker aardig conservatief zijn zodat na een paar honderd requests het process wordt gerecycled om handles en memory leaks impliciet vrij te geven. PHP-FPM regelt het via de *pm.max_requests* setting. Gehoord in de manuals en de sources

Ik heb dit nog nooit gezien op de NGINX servers die ik beheer, maar wellicht dat er servers zijn die dit wel doen. Je ziet meestal wel dat op server de processen een maximaal hoeveelheid resources toegewezen krijgt. Gaat die daarover, dan wordt het proces de nek omgedraait en opnieuw gestart. Maar het blijft een lapmiddel om een resourcelek op te lossen. Wellicht dat Apache dit doet om resourceleaks in plug-ins het hoofd te bieden. Het blijft brak in mijn ogen.

Daarbij vind ik de vergelijking niet helemaal opgaan. Bij (serieuze) web-services zit er een load-balancer voor die bij tijdelijke downtime de requesten naar een andere server kan sturen. Daarbij is het geen abnormale situatie dat een webrequest niet uitgevoerd kan worden (transiente fout). Goed geschreven clients zullen dan ook een verzoek opnieuw versturen bij een dergelijke transiente fout. Bij een real-time systeem, zoals EAP, is dit volstrekt onacceptabel.

Natuurlijk kunnen bugs ervoor zorgen dat er resources lekken en er uiteindelijke een kritische grens wordt bereikt. In het geval van EAP/NoA/FSD zou er maar één juiste oplossing zijn. De functie volledig uitschakelen totdat het systeem opnieuw is opgestart. Ik neem toch aan dat Tesla dergelijke veiligheden inbouwd. In de HW3.0 is het systeem volledig dubbel uitgevoerd, waarbij de resultaten vergeleken worden. Nu zal een softwarefout wellicht 2x hetzelfde foute resultaat opleveren dus 100% veilig is dat ook niet.

Overigens heb ik in het verleden wel een keer een crash gehad van het auto-pilot systeem. Begon die uit het niets heel hard te piepen en was die direct uitgeschakeld. Is wel al een tijd geleden.

 

[curry684]

Nginx zit ook duizend maal beter in elkaar dan Apache en PHP-FPM bij elkaar, maar het gaat zo wel erg offtopic - punt was dat de diverse voorbeelden van de meestgebruikte 24/7 software van het internet zich van vergelijkbare middelen bedienen om ten behoeve van stabiliteit regelmatig te restarten. Mijn Samsung telefoon biedt het overigens zelfs aan, een optie om dagelijks 's nachts automatisch te rebooten "om de telefoon snel en responsief te houden". Daar ging het om dat simpelweg het periodiek restarten an sich niet de facto causaal leidt tot de conclusie dat Tesla buggy crap code zou schrijven.

 

[arne-nl]

Nee hoor, alle 3 zijn daemons met forked worker processes, waarbij met name bij Apache (mpm_common - Apache HTTP Server Version 2.4) en de default max connections per worker aardig conservatief zijn zodat na een paar honderd requests het process wordt gerecycled om handles en memory leaks impliciet vrij te geven. PHP-FPM regelt het via de *pm.max_requests* setting. Gehoord in de manuals en de sources

Dat beschrijft wel een iets ander mechanisme dan jij in eerste instantie zei, maar goed, daar gaat deze thread idd niet over.

 

[Gaston]

Dit is helaas onzin. De A en N wegen zijn prima idd, daarbuiten is het 1 grote bende van inconsequente fietsstroken, wegen van anderhalve auto breed, wegen met al dan niet doorgetrokken belijning voor bermbescherming en weet ik het wat allemaal. In het ELDA klachtentopic werd de hoofdprijs verdiend door de gemeente Meerssen waar de belijning zo idioot was dat we zelfs met mensen niet snapten waar de auto nou eigenlijk nog hoorde te rijden.

Vwb de phantom brakes: ik lees hier nogal onzinnige claims als dat Tesla het "al lang had moeten fixen". Bij deze - het verschijnsel zal altijd blijven bestaan, alleen de frequentie zal verlagen. Net als bij mensen.

Probleem is simpelweg dat geen situatie hetzelfde is. De zon staat altijd net anders, het weer is altijd net anders, de verkeerssituatie is altijd net anders, de snelheid en richting van je eigen auto is altijd net anders. Geen 2 situaties zijn ooit letterlijk identiek. Wat je auto doet, met dat neurale netwerk, met al die miljoenen regels code, is continu analyseren wat hij moet doen en of dat veilig is. En bij de minste twijfel of ie keihard moet remmen stampt hij keihard op die rem. Omdat het beter is een keer te vaak een noodstop te maken dan een keer te vaak een paar mensen dood te rijden. Precies dezelfde reden dat mensen bij twijfel een noodstop maken. Alleen zijn die niet zo snel waardoor ze in plaats daarvan een paar mensen doodrijden.

Moet de frequentie omlaag? Natuurlijk, dat gebeurt ook met de verbeteringen aan NN en software. Maar 0 wordt het nooit, omdat bij twijfel de noodstop altijd de betere keuze is. Net als voor mensen.

Natuurlijk wordt de frequentie nooit nul. Geen van de critici hier beweert dat dat zou moeten. Dat is ook helemaal geen interessante discussie.

Punt is dat de Phantom brakes (onverwacht hard remmen), te vaak optreden. Veel te vaak.
Zo vaak, dat het systeem beter in schaduw mode zou kunnen draaien. Dus AP/AEB moet loggen "hey, ik zou hier een noodstop hebben gemaakt, maar de bestuurder heeft dat niet gedaan en de airbags zijn ook niet geactiveerd."

Dan kan het systeem leren, zonder dat er ongelukken gebeuren. Dat leren is hard nodig, want in tegenstelling tot wat hier wordt beweerd, het is de afgelopen anderhalf jaar niet beter geworden met de phantom brakes. Eerder slechter.

En dat zou volgens (een medewerker van) Tesla komen door een ingeplugde usb-stick? Te belachelijk voor woorden.

Je leest inderdaad niet vaak over schadegevallen als gevolg van een phantom brake. Nu is het toevallig zo, dat de achteroprijdende auto altijd schuldig is. En de bestuurder van de Tesla gaat echt niet roepen: "noteer mij maar als schuldige".

Ik heb in ieder geval zelf 1x een kopstaart aanrijding zien staan, op de A35, 3 auto"s, waarvan de voorste een model X. Maar daar mag ik natuurlijk geen conclusies aan verbinden.

 

[shthpnz]

And Now Something Completely Different.

Er zit een akelige bug in 2019.24

Het starten en eindigen van de laadsessie wordt namelijk niet meer gemeld op de smartphone.als je in de auto het ladingsniveau weergeeft in procenten.

De oplossing is ook nabij. Je omzeilt deze bug als je in je middenscherm de weergave op ‘kilometers’ zet.

Deze bug deed zich vele updates eerder ook voor. Het duurde toen maanden voor dit euvel werd rechtgezet. Jammer dat ie weer terug is gekomen.

 

[Carl]

Een M3P accelereert van 121 naar 130 km/u in ca 0.6 seconde dus bij een noodstop (< 0.6s) vang je dat echt niet op bij 121 km/u. Het is ook absoluut menselijk dat je tijdens een rit niet constant en optimaal presteert. Zelfs een F1 coureur heeft toegegeven dat hij wel eens op het rechte stuk denkt aan iets dat hij niet moet vergeten in de supermarkt. Niet ideaal, wel normaal…

Ik heb zelf nooit EAP zodanig weten 'ten volle' remmen dat ABS zich vanzelf activeerde, vooraleer ik ingreep, dus ik denk inderdaad dat mijn eigen ervaring (snel kunnen ingrijpen bij onnodig remmen op de snelweg) niet dezelfde is als diegene die beschreven zijn (gierende banden etc.). Ik heb 'emergency braking' op 'late' staan, en verder denk ik dat Sentry Mode Off + een Reboot zin kan hebben vermits SeCs het blijkbaar (volgens de Talking Tesla podcast van gisteren) zelf voorstellen, wegens een bug in Sentry Mode.

Ik begrijp nu dat anderen totaal onverwachte 'volremacties' zouden hebben met gierende banden en ABS die zichzelf activeert etc. OK, da's een ander paar mouwen, en zulke situaties heb ik nog nooit meegemaakt. Voor zulke situaties heb ik alle begrip voor de reactie!

 

[shthpnz]

Nog een bug in 2019.24.1:
De S gaat niet meer slapen. 24/24 staat ie klaar om de baas van dienst te zijn. Fijn natuurlijk, maar t neemt me teveel accustroom.

 

[curry684]

Zet eventuele diensten als TeslaFi e.d. eerst op pauze voordat je je auto daarvan beschuldigt. Ik heb zelf TeslaFi maanden terug 2 weken gebruikt, auto wilde nooit slapen, TeslaFi weg en hij sliep weer als een roosje.

 

[bugboy]

Ik heb 'emergency braking' op 'late' staan, en verder denk ik dat Sentry Mode Off + een Reboot zin kan hebben vermits SeCs het blijkbaar (volgens de Talking Tesla podcast van gisteren) zelf voorstellen, wegens een bug in Sentry Mode.

Je kan de forward collision warning wel op late zetten, maar emergency braking is volgens mij gewoon aan of uit. Emergency braking is overigens vooral bedoelt om de snelheid eruit te halen om een eventuele aanrijding minder zwaar te maken. Geen garantie dus.

Een bug in sentry die problemen geeft met EAP zou ik kwalijk vinden. Niet dat er een bug bestaat (dat kan gebeuren bij zo'n snelle software ontwikkeling), maar wel dat de systemen elkaar zo beïnvloeden. In de auto-industrie was het voorheen zo dat verschillende modules verschillende taken hebben, zodat je functionaliteit kunt scheiden. Sentry zou geen invloed mogen hebben op EAP, omdat het op een ander systeem zou moeten werken.

 

[Luc2000]

Blijkbaar kun je AP uitzetten en dan houd je adaptive cruise control over. Zit de phantom break bug ook in de adaptive cruise control?

 

[Onno]

Blijkbaar kun je AP uitzetten en dan houd je adaptive cruise control over. Zit de phantom break bug ook in de adaptive cruise control?

Fyi: ik heb af en toe dat hij wat inhoudt (snelheid inzakt, gebruikmakend van de regeneratie, tikje op het wattpedaal en daar ga je weer). Verder zijn die phantom brakes mij niet bekend.

 

[Daniel_M]

Mijn (slechte) NOA ervaring vanochtend 9u vertrokken, ritje A15 -> A16, A15 op bij Rhoon naar SuC Dordrecht

Allemaal heel erg herkenbaar, lane change werkt vaak niet, ook als er nog heel veel ruimte is, auto wil continu wisselen van baan zonder enige reden en al 5km van tevoren achter een vrachtwagen gaan rijden vanwege een afslaag die eraan komt. Wat mij verder opvalt met NOA geactiveerd is dat de auto ook vaak heftig in de ankers gaat voor een auto op een andere rijbaan, waarschijnlijk wordt dit veelvuldig als "voorligger" wordt gezien, erg irritant.

Ik heb momenteel NOA maar even uitgezet, kijk met volgende updates wel of het beter wordt en anders zet ik het weer uit...

 

[Roberto 2018]

Zet eventuele diensten als TeslaFi e.d. eerst op pauze voordat je je auto daarvan beschuldigt. Ik heb zelf TeslaFi maanden terug 2 weken gebruikt, auto wilde nooit slapen, TeslaFi weg en hij sliep weer als een roosje.

Wat is TeslaFi?

 

[Roberto 2018]

Voorlopig geen updates meer?
Tesla Revamps Autopilot Team amid Pressure to Deliver on Elon Musk’s Promises

 

[TANE]

Vandaag een rit van Nieuwegein naar Rotterdam en weer terug. Onderweg veel regen en wat langzaam verkeer.

Zo veel mogelijk NoA gebruikt wat erg goed ging. (beetje verbaast)
Ik heb de baanwissel op uit staan. Het voegt op dit moment niet veel aan toe en meldingen zijn storend.

Wat verder opviel is dat NoA melding van slecht weer is gekoppeld aan de snelheid van de ruitenwissers. Maakt niet uit hoeveel regen als je stand 2 blijft houden blijft NoA werken. Zelf met droog weer en stand 3 krijg je melding van slecht weer.

 

[TheoSchijf]

In diverse Amerikaanse blogs gelezen dat er een link is tussen sentry mode en slecht gedrag van NoA.
Ook gelezen dat phantom braking in Canada en Amerika ook een pest is.
Gedeelde smart is halve smart en geeft hoop op verbeteringen.

 

[TANE]

In diverse Amerikaanse blogs gelezen dat er een link is tussen sentry mode en slecht gedrag van NoA.
Ook gelezen dat phantom braking in Canada en Amerika ook een pest is.
Gedeelde smart is halve smart en geeft hoop op verbeteringen.

Inderdaad ook gelezen. Maar begrijp de link met Sentry mode niet helemaal. Dacht dat deze enkel opneemt als de auto geparkeerd is. Tijdens rijden is de dashcam actief en dat zou niks meer moeten zijn dan een simpele camera.